Athari писал(а): МАМА, я как только встретил описание одной программы "Размер 10 КБ! Но чтобы программа работала, нужно скачать 20 МБ машины .NET", сразу понял, что пока как-нибудь без этой технологии обойдусь.
Кстати да! сегодня меня ожидало разочарование в этом :-(((
Но зато на некоторых компах эта машина установлена и мой шпиёнский проект сработал.
Athari писал(а): и сортировку массива пузырьком с помощью 10 ООПных классов.
Ну почему... Я видел подобный код - когда используется штук 20-30 классов, котрые друг друга подцепляют при инициализировании чтобы только что-то отсортировать/загрузить файл ;) Просто все сделано на классах с наследованием и прочим. Ведь для каждого указателя можно исаользовать класс "умного указателя" - котрый будет сам следить за корректностью указателя... Ну и развивая мысль.. :)
2 Athari Ты по каким книжкам училась?
Ведь писать на языке и знать его - разные вещи.
Можно предпологать, что в C++ - массив - это несколько ячеек, в которые можно класть переменные.
Советую почитать Липмана.
The milk of the male could awaken new life in his mate, and the milk of the female could sustain it after birth. THE LEONINE STORY OF BEGINNINGS
Я такое корявое плавание влево-вправо видел только в простеньких программах у программистов-чайников.
Ну конечно, ведь только тот кто пишет на С и в сишном стиле крут. Открывай исходники VCL и смотри как там все оформленно, begin и end всюду на одной вертикали.
у дотНЕТа есть удобная фича – пишешь на любом языке, используешь программы на любом другом языке. А это само по себе что-то.
Тот же VB уже давно никому на хрен не нужен. А разница в возможностях между C и Delphi невелика. На Delphi и драйвера писать можно. => Если чужие dll-ки не подключаешь, то нахрен эта многоязычность нужна, ведь не будешь же один проект сразу на 2-х языках писать.
Ни тебе сборщика мусора, ни понятного синтаксиса...
Ну синтаксис никуда не делся. Если в С сделать нормальный синтаксис, то это уже будет не С. А сборщик мусора это фича самой .NET, а не зарешеченного.
За что же ТЫ ненавидишь Симбу? Про SP вот и <a href="http://www.pridelands.ru/?p=texts&a=get&id=328" target="blank">вот<
Beltar писал(а): А сборщик мусора это фича самой .NET, а не зарешеченного.
Сборщики мусора так или иначе есть почти во всех языках. Вопрос что в .NET оно возведено в идеализм - как в скриптовых языках типа php - то есть совершенно не надо думать что где создать, и что где разрушить... И если создание не везде происходит автоматически, то о разрушении в 90% беспокоится не надо вообще в c#. В обычном C у тебя будут ужасные утечки памяти при таком раскладе
Кстати именно из-за сборки мусора дотнет, как и джава, непригоден для приложений реального времени. Так что мне не светит им на работе попользоваться :)
Сборщики мусора так или иначе есть почти во всех языках.
p:=MyClass1;
p:=MyClass2;
И куда же это Class1 подевался... Может порекомендуешь что-нибудь для мониторинга утечек. Я как-то скачал MemProof, но не понял как им пользоваться, а документации нет.
За что же ТЫ ненавидишь Симбу? Про SP вот и <a href="http://www.pridelands.ru/?p=texts&a=get&id=328" target="blank">вот<
Никуда, он не был удален командой p:=MyClass2. Он будет удален вместе со всеми остальными локальными переменными когда закроется scope данной процедуры. Если конечно компилятор не выкинет p:=MyClass1 вообще на стадии оптимизации. Только это никак не связано с GC.
А для утечек мне лично очень нравится valgrind.
блин, из-под текстовых браузеров автоматическое цитирование тут не работает.
3) Идешь в MemProf. там нажимаешь на "открыть приложение" (сверху кнопка с желтой папочкой, аттач 1)
4) Выбираешь свое приложение
5) Нажимаешь "|>" (запустить, аттач 2)
6) Работаешь в приложении -окошки вызываешь и тд тп.
7) закрываешь приложение
8 ) МемПроф перескакивает на закладку "Resources detail". Там будет список всего что осталось в памяти - то есть все, что было не уничтожено. А так же инфа о том, где это было создано и, в идеале, строка исходника/номер строки... Так же во время выполнения при выходе из функции или еще откуда, где не разрушается локальный объект - оно может прямо в дельфи выделить строку и написать в стандартном окне инфы дельфи (где пишутся ошибьки и варнинги), что произошло и что не разрушилось (аттач 3)
Диего, если ты уверен, что любую программу можно написать на Астме, и все дело только во времени, ты просто не писал больших программ. На определенном размере кода астматик загибается.
Это как он загибается? Поясни. Ну да, больше 700Кб непрерывного кода писать вряд-ли приходилось. Я говорю о 32-х битном программировании.
Это так, что отладка становится невозможной, например, на функциональном языке, не поддерживающем структурное программировани, насколько мне известно объем кода, который 1 человек может довести до ума всего что-то около 5000 строк. Для структурированного около 100000 строк.
За что же ТЫ ненавидишь Симбу? Про SP вот и <a href="http://www.pridelands.ru/?p=texts&a=get&id=328" target="blank">вот<
Компьютеры еще в 40-х годах появились. И с тех пор были накоплены определенная статистика и опыт. Так что эти данные мне в институте давали и они явно по среднему программисту.
За что же ТЫ ненавидишь Симбу? Про SP вот и <a href="http://www.pridelands.ru/?p=texts&a=get&id=328" target="blank">вот<
Beltar писал(а): например, на функциональном языке, не поддерживающем структурное программировани, насколько мне известно объем кода, который 1 человек может довести до ума всего что-то около 5000 строк. Для структурированного около 100000 строк.
Не "функциональном" а "императивном". Вобще-то это довод 70х годов за использование C вместо Фортрана. Много воды утекло с тех пор.
Правильно, сейчас такие языки если и встречаются, то чисто как встроенные однако существование пределов по размеру кода этот пример иллюстрирует.
Насчет терминологии спорить не буду, как мне давали, так и говорю.
За что же ТЫ ненавидишь Симбу? Про SP вот и <a href="http://www.pridelands.ru/?p=texts&a=get&id=328" target="blank">вот<
Beltar писал(а): Правильно, сейчас такие языки если и встречаются, то чисто как встроенные однако существование пределов по размеру кода этот пример иллюстрирует.
Фактически, количество сегментов ограничено только пространством на винте. Не беря во внимание 512 и 1024-барьеры, преодолеть которые не так уж и сложно. Ну и от разрешений ОС, конечно.В старом добром Досе этого сделать никто не запретит.
Ну конечно, ведь только тот кто пишет на С и в сишном стиле крут. Открывай исходники VCL и смотри как там все оформленно, begin и end всюду на одной вертикали.
Белтар, про крутизну — это ты сам сказал, я такого не говорил. Я сужу по тому коду, что вижу в Сети. Что он в большинстве случаев оказывается на сях — это уже другой вопрос. Но тем не менее дельфовых исходников я тоже видел не мало, да и басиковские использовать приходилось. Так-с, сейчас глянем, как исходники оформлены...
В дельфовых программах преобладает "дельфовый" стиль, хотя "сишный" тоже очень часто бывает. В сишных исходниках расклад противоположный. Но чтобы преобладание хоть одной из стороны было 90% — такого нет ни в одном случае. Так что приходим к выводу, что на вкус и цвет... (Смотрел только серьезные исходники с большим объемом кода.)
К слову, не понимаю, в чем проблема... Границы блока прекрасно определяются по отступу. И не забывай про сочетание Alt+[ / Alt+].
Вообще-то, когда я говорил, что тебя плохому научили, я имел в виду не размещение открывающего элемента на отдельной строке, а болтание отступов блоков влево-вправо в зависимости от предшествующего кода (например, длины строки), а не от глубины вложенности. Вот это — напрягает.
Если чужие dll-ки не подключаешь, то нахрен эта многоязычность нужна, ведь не будешь же один проект сразу на 2-х языках писать.
Почему не будешь? Дотнет это позволяет.
Ну синтаксис никуда не делся. Если в С сделать нормальный синтаксис, то это уже будет не С. А сборщик мусора это фича самой .NET, а не зарешеченного.
Фича чего именно — это уже вопрос десятый. Важно, что в шарпе сборщик есть, а в плюсах — нет. С утечками иногда очень сложно воевать...
Может порекомендуешь что-нибудь для мониторинга утечек. Я как-то скачал MemProof, но не понял как им пользоваться, а документации нет.
В Дельфях есть встроенный Code Guard, который тебе и утечки покажет, и использование освобожденных блоков памяти, и вызовы с неправильным this... Причем действует он прямо во время выполнения программы, указывает где что создано, где что удалено вместе с указанием полного стека вызовов на эти моменты времени. Project > Options > CodeGuard.
Это как он загибается? Поясни. Ну да, больше 700Кб непрерывного кода писать вряд-ли приходилось. Я говорю о 32-х битном программировании.
Диего, ты про "кризис программного обеспечения" слышал? Это когда создание больших (действительно больших) систем по срокам ни в какие ворота не лезет, когда результат оставляет желать лучшего, когда проекты элементарно закрываются от капитального затыка...
Сначала люди писали на машинном коде. Как попало. Получился облом. Начали предъявлять требования к коду. Ну и так далее. А ООП появился, когда программные продукты начали заваливаться где-то на миллионе строк.
Ну и перечисленные выше пределы для одного человека. На ООП один человек может поднять бОльшую сложность, нежели при процедурном подходе. А в процедурном стиле он напишет больше, нежели на ассемблере.
Атари, первое и главное условие - руки должны быть прямыми. Далее, есть такое понятие, как хорошо скоординированная работа. Да, жрёт всего много, и трудозатрат больших, и времени. НО. Достигается колоссальная оптимизация кода, следствие - потребление ресурсов. Выгода от этого, к сожалению, только у потребителя.
Сначала люди писали на машинном коде. Как попало.
Кто тебе мешает "как попало" писать на языках высокого уровня? Насчёт требований к коду, это ещё вопрос, где их больше. Обычно те, кто пользуются "свободой" компилятора знакомы и осознают последствия.
Когда увеличение штата приводит к тому, что они никак не могут скоординироваться, а уменьшение — к бесконечному отодвиганию сроков. В результате разработка прекращается, проект закрывается.
первое и главное условие - руки должны быть прямыми. Далее, есть такое понятие, как хорошо скоординированная работа. Да, жрёт всего много, и трудозатрат больших, и времени. НО. Достигается колоссальная оптимизация кода, следствие - потребление ресурсов. Выгода от этого, к сожалению, только у потребителя.
Диего, расскажи это тем, у кого проекты заваливались. :р Легко сказать, ты сделать попробуй...
И вообще, речь про то, что на определенном рубеже сложности системы проекты начинали заваливаться. Перешли на другие подходы — рубежи преодолели. Или ты будешь отрицать истоические файкты? ^^
Кто тебе мешает "как попало" писать на языках высокого уровня? Насчёт требований к коду, это ещё вопрос, где их больше. Обычно те, кто пользуются "свободой" компилятора знакомы и осознают последствия.
На ассемблере свободы больше. У тебя большой риск получить "макароны" из-за бесконечных переходов goto. В языках высокого уровня goto запрятан подальше, Паскаль вон и вовсе издевается над теми, кому goto понадобился.
В объектно-ориентированных языках ты можешь писать по-прежнему, но при чем здесь это? Это другие подходы к самому процессу программирования и разработки. ООП — это не просто использование class вместо struct и удобный метод вызова методов obj.DoSmth(), это гораздо большее.
Ага, из-за того, что выбрали асм. :)
Если говорить о последнем кризисе, то тогда писали на процедерных языках. АСМ уже долгое время используется лишь для оптимизации слабых мест.
Диего, расскажи это тем, у кого проекты заваливались. Легко сказать, ты сделать попробуй...
Пробовал уж. В завалах в среднем один из пятидесяти заваливается не из-за рук. Действительно больших(тысячные уровни вложений, подключение VCL или необходимой Dll,это вообще отдельная песня) было не больше десятка пока. Но мне этого хватило, завала небыло ни одного, всё писалось последовательно с предобработкой.
С goto вообще смехотворная ситуация. Здесь я солидарен с автором учебника Пироговым - нагородили до черта непойми-чего, а от JMPа никуда не ушли, разве что более длинно прыгать стали.:)
Если говорить о последнем кризисе, то тогда писали на процедерных языках. АСМ уже долгое время используется лишь для оптимизации слабых мест.
Спорить не буду. Но оч.много программистск.коллективов существует, там именно и только чистый асм, ну и сами коды, разница небольшая. Ещё больше одиночек.
PS Я не отрицаю "исторические факты". Просто всё это можно(и нужно бы)сделать без извращений, с максимальной оптимизацией.
