2 Athari у меня тоже такой же стоит ;) Точнее Pluser 0.4 - по намлоку включается простой калькулятор. NumLock по моему гораздо более замудрен и мне не понравился ;)
Кстати пришлось мне попробовать более детально язык СИ и хочу сказать, что он рулит. А паскаль сукс по сравнению. Не знал, что языки так сильно разнятся.
2 MAMA сколько пишу на С, сколько пишу на паскале, сколько пишу на пхп, сколько пишу на RSL и прочих - мне больше нравится Delphi (паскаль) и php. И вообще уже достаточно давно проблема с прямыми руками, а не с языком программирования.
И могу сказать, что очень не зря во многих местах выбирают Дельфи. И не зря в других местах выбирают Си. А вообще за религиозные споры "одно кал - другое рулез" буду наказывать. На других сайтах уже надоело, когда криворукие ламеры начинают орать то, чего не понимают
2 SamatiX 10.... ;) у многих за несколько сотен перевалило...
Нет, в общем, целом и философски глядя — машинка неплохая... Ну, если о первых впечатлениях — я хотел с ним посидеть получше, да все никак...
По удобству. Недурственно, и даже очень хорошо. Из того, что непременно нужо реализовать - это повесить «=» на Enter. Давить ее мышью смерти подобно. Размещение, в общем-то, испытанное временем, тут нареканий нет.
По функциональности. Возможности, конечно, можно наращивать и наращивать, но основное все как будто здесь. Подробно на функциях не будем, это уже проскакивало... Сходу ввел логарифм и обнаружил, что недурно бы ему подсказку по количеству аргументов - во многих пакетах так обозначается натуральный. Вообще функции многих аргументов, вижу, присутствуют - это дело доброе...
Как ведет себя в вычислениях, детально еще не посмотрел. Навскидку - гиперболические тангенс и котангенс от больших значений дают ошибку переполнения. На больших аргументах в вашем случае их можно не считать - там они быстро стремятся к единице, и выходят за разрядную сетку.
На более подробный осмотр мне пока не хватило времени. Собственно, я предпочитаю железный SR-35T, но иногда его нет под рукой, а запускать по любому поводу что-то из тяжеловесов — жаба душит, до такого буржуйства я еще не дошел... ;)
2 Dimonius Я высказал свое личное мнение по поводу си и паскаля. Я думаю, я на это имею право?
При чем тут достававшие тебя ламеры?
В си намного больше наработок уже в самом языке и код программы становится меньше, многое не придется писать. В то же в си можно детально задавать многие параметры. Взять хотябы writeln и printf. Си мне показался более проффессиональным.
А может сравним возможности самых первых версий Си и Паскаля? А то printf уже давно существует и в Delphi под названием format.
Может это дело вкуса, но регистрозависимость C, для меня серьезный недостаток, поскольку ни к чему кроме бессмысленного вытья компилятора и трудностей при наборе не приводит.
код программы становится меньше, многое не придется писать.
Он и без всяких наработок обычно меньше, сам синтаксис более лаконичен до крайности. Вот только компенсирует ли это увеличение времени на понимание кода...
За что же ТЫ ненавидишь Симбу? Про SP вот и <a href="http://www.pridelands.ru/?p=texts&a=get&id=328" target="blank">вот<
2 MAMA обычно как раз надо думать, для выбора имен переменных. Иначе через какое-то время когда надо будет дополнить код ты просто можешь запутаться что у тебя делает i, I, j, J и какая где. А создавать "много переменных" - обычно это не есть хороший стиль программирования изначально. У меня даже в сложных функциях обычно переменных не много, и названны они по смыслу - типа R,G,B - dR, dB, dG и тд. i,j,k,n - обычно индексные. Больше 4 индексных переменных в 90% не нужны. f,r - обычно структыры типа реестра, ini файла. b - часто TBitmap. ну и тд.
Чем мне как раз очень нравится паскаль - это своей строгостью - что переменные объявляются в одном месте, а не "по ходу программы. Тут она всплыла, тут забыли про нее". Про читаемость кода я и не гооворю - в паскале она в разы лучше, чем в С.
Про наработки - format дает все возможности printf. Кстати, сравнивал уж тогда бы с Object Pascal. А то сравнивание нраработок разных годов - это бессмысленное дело.
Что-то вы не туда смотрите... Мне, например, совершенно все равно, какой регистр имеют переменные. Где-то лучше одно, где-то другое. Все равно у меня давно сложилась привычка, как что называть, поэтому проблем с вспоминанием регистра букв не возникает никогда. Единственный случай, когда может быть польза от регистронезависимости – это если ты используешь чужой код, и в нем названия тебе не очень нравятся. Например, названия структур в WinAPI всегда сплошными заглавными – не сказал бы, что это красиво и легкочитаемо, особенно, когда название символов эдак 20-30.
В Дельфи и Паскале мне не нравится как раз названная Димониусом строгость языка. Слишком уж много ограничений в них.
Я уж не говорю про горясо любимые мной шаблоны и множественное наследование – ими в Дельфи и не пахнет. А привык я к ним слишком сильно, чтобы сразу взять и отказаться.
Читаемость – это да, слабое место. Например, мне хотелось бы видеть не "=0" около объявления функции, а толковое слово вроде "pure", например. Еще мне "overload" дельфового не хватает...
2 Athari а try finally ? в С есть только try except
По поводу строгость переменных - это не ограничение. В любом случае можно сделать реконверт ожного в другое. То есть "присвоить пустыне значение клетки и сказать что лев внутри клетки". Можно сделать. Только не нужно, и не так просто - чтобы такие умные потом не ловили долго кучу багов. Так что не надо путать строготь и ограничения. Это разные вещи. Объявление переменной в специальной секции не мешает мне использовать неограниченное количесто этих переменных.
Кстати оверлоад в С есть свой - там вообще можно даже знаки перегружать. Вопрос в нужности - в дельфи чаще всего знаки значат именно то, что логически и нужно. Шаблоны да. Их в дельфи нет. Но и в среде С у них много противников и сторонников. Не даром в С образных языках нового поколения шаблоны убрали. Кстати множественное наследование - тоже. ;)
Кстати, я пишу с 87 года, серьезно с 94 года, и тоже не разу не не сталкивался с ситуацией, где надо было использовать множественное наследование.
И вообще очень многий код можн написать очень многими методами. Причем в каждом методе могут быть свои плюсы и свои минусы. Во многих местах "фитчи" С могу просто реально запутать код. Когда как в паскале все будет прозрачно видно.
Димониус, в C++ есть: catch(класс_исключения) (для определенного исключения), catch(...) (для любого исключения), __finally (аналог finally).
Объявление переменной в специальной секции не мешает мне использовать неограниченное количесто этих переменных.
Но у такого подхода есть несколько минусов:
1) Каждый раз приходится возвращаться в начало функции/метода. Муторно.
2) Если переменная объявлена в месте ее использования, то легче понять ее назначение. Если идет сплошной список, то в нем немудрено заблудиться.
3) Меньше проблем со случайными присвоениями, взявшимися из ниоткуда.
Кстати оверлоад в С есть свой - там вообще можно даже знаки перегружать.
Я несколько другое подразумевал. В Дельфи есть слова "virtual" и "overload", а в Си первое выполняет обе функции (а при оверлоаде его можно и вовсе опускать). Иногда оказывается, что вместо переопределения метода в наследнике ты создаешь новый метод из-за простой опечатки. Если бы было реализовано, как в Дельфи, то такие ошибки бы отлавливались при компиляции.
Шаблоны да. Их в дельфи нет. Но и в среде С у них много противников и сторонников.
Вот хоть убей, но не хочу я пользоваться разными CList и каждый раз преобразовывать объекты к нужному типу. Пусть даже сам ты обходишься без шаблонов, библиотеки вроде STL (Standard Template Library) очень упрощают жизнь.
Кстати множественное наследование - тоже. ;)
Сделали, как в Дельфи – множественное наследование только у интерфейсов. Для 90% случаев этого вполне достаточно. Но вот в те 10% мне уже доводилось попадать. ^_^ Если интересно, могу привести пример из жизни.
Кстати, я пишу с 87 года, серьезно с 94 года, и тоже не разу не не сталкивался с ситуацией, где надо было использовать множественное наследование.
Это сильно зависит от того, как и что писать, ИМХО. Зачастую можно не извращаться с множественным наследованием и просто скопировать код. Правда, в моем случае это было бы очень неудобно.
Во многих местах "фитчи" С могу просто реально запутать код. Когда как в паскале все будет прозрачно видно.
Вот здесь совершенно согласен. В Си можно сделать такое, что и ящик пива не может понять. ^_^ Но такого кода я стараюсь избегать и использую только в случае острого желания поиздеваться над преподом. ^^
Вспомнил еще два "минуса" Си – в нем конструкторы предков вызываются насильно, а не по желанию программиста как в Дельфи; и вызов методов из конструктора статический (вызывается текущая реализация), а не динамический. Последнее, кстати, сильно раздражает. ~_~
Athari писал(а): Но у такого подхода есть несколько минусов
А для меня они - плюсы. Тем более сразу видно сколько переменных использовано, и соответственно бывает что-то пишешь в несовсем трезвом уме и здравой памяти. На утро открываешь код и сразу видишь что у тебя есть куча лишних переменных котрые можно легко сократить. В бэйсике, Си и тд этого не видно. Кстати случайных присвоений и возникновения никому не нужных переменных там часто больше. Я тут переписывал код с бейсика и Си на паскаль. Дык половина переменных только проинициализированна, другая часть переменных объявлена, но используется совершено в других блоках. Я долго матерился - ибо после переписывания программа стала "прозрачной", и стала использовать в десятки раз менбше переменных (а переменная это как минимум получение и потом разрушение блока памяти).
Athari писал(а): Меньше проблем со случайными присвоениями
Наоборот больше! Может конкретно у тебя и меньше, но у достаточно приличного объема кода, котоый я видел в разных местах в интернете, а так же из реальной жизни их просто в разы больше. Когда переменные нормально оюбъявленны Дельфя сразу говорит - а вот в блоке вы переменную объявили-с, но ни разу не использовали. Или "Вот тут присвоили в нее данные, но потом она нигде не используется" - даже скачанные с инета функции, часто оптимизирую выбрасывая много мусора из них.
Насчет преобразования типов - да, когда долго пишешь на "разгильдяйских" языках типа Си и php то потом неприятно смотреть на строгость паскаля. Но зато не остается неоднозначности как именно ты используешь переменную или указатель. Я уже много раз видел утечки памяти, совершенно не заметные - просто потому, что компилятор считал что указатель на память другого типа и соответственно очищал память не нужное, а 4 байта - размер указателя. Ну и прочие варианты.
По поводу множественного наследования - варианты бывают разные. Но в 95% этого н енужно. В оставшихся 5% можно сделать пятком других вариантов.
В общем опять не получается однозначного что лучше что хуже. О чем я и говорю. Так что может прекратим? В конце концов это только способ получить желаемое. Мы же не спорим что лучше доллары, рубли или евро - в свете вопроса что купили новую плюшку и какие деньги для этого лучше.
Кстати случайных присвоений и возникновения никому не нужных переменных там часто больше. Я тут переписывал код с бейсика и Си на паскаль. Дык половина переменных только проинициализированна, другая часть переменных объявлена, но используется совершено в других блоках.
Димониус, по-моему, ты путаешь язык и программистов. Как программисты напишут, так оно и будет. Другой вопрос, что Паскаль дисциплинирует – на нем несколько сложнее написать непонятную программу, чем на Си. Но в конечном счете все равно все зависит от программиста.
Кстати, насчет переменных. Компиляторы умные – если ты что-то не используешь, то тебе об этом незамедлительно сообщат: и о переменной, которая нигде не участвует, и о значении, присвоенном переменной, которое пропадает попусту.
Когда переменные нормально оюбъявленны Дельфя сразу говорит - а вот в блоке вы переменную объявили-с, но ни разу не использовали. Или "Вот тут присвоили в нее данные, но потом она нигде не используется" - даже скачанные с инета функции, часто оптимизирую выбрасывая много мусора из них.
Наверное, тебе попался очень плохой компилятор Си, потому что подобные предупреждения без проблем выдаются и на сишном коде. Тут же дело не в том, где переменная объявлена, а где она используется и что ей присваивается. Так что при "одинаковом" коде на Си и Паскале с большой вероятностью выдадутся одни и те же ошибки.
Но зато не остается неоднозначности как именно ты используешь переменную или указатель.
Чисто из люболпытства в следующий раз буду смотреть, можно ли было бы выловить ошибку на стадии компиляции, пиши я на Дельфи. ^^
Вроде бы по части строгости с указателями и объектами Си на одном уровне с Дельфи. Си только преобразования между символами, числами целыми и с плаваующей точкой делает автоматически без ругательств.
И еще насчет строгости. Все это неправда! Си строже! ^^ Например, Си не позволит преобразовать объект (не указатель на него) к другому объекту (или объект-число), даже если объекты одинакового размера и ты делаешь это насильствнно. А вот Дельфи такое позволяет.
Я уже много раз видел утечки памяти, совершенно не заметные - просто потому, что компилятор считал что указатель на память другого типа и соответственно очищал память не нужное, а 4 байта - размер указателя.
С объектами это решается просто – просто делаешь деструктор виртуальным... Не знаю, у меня если подобные ошибки и были, то от силы пару раз.
По поводу множественного наследования - варианты бывают разные. Но в 95% этого н енужно. В оставшихся 5% можно сделать пятком других вариантов.
Сделать можно много чего. Только решение будет некрасивым. Неестественным.
Шаблоны тоже можно реализовать – просто делаешь объявления типа "type item=class_item", а потом на каждое новое использование копируешь модуль и выставляешь новый тип. Вот только некрасиво это и неудобно.
Мне, например, совершенно все равно, какой регистр имеют переменные.
Забываем нажать Shift и получаем сообщение об ошибке компиляции, которая в той же Visual Studio процесс длительный. Мелочь, а неприятно.
Так что при "одинаковом" коде на Си и Паскале с большой вероятностью выдадутся одни и те же ошибки.
А еще бывают "лишние" куски кода, которые сначала что-то делали, но потом стали не нужны, и на результат не влияют. Особенно это присваиваний касается. Да и предупреждения могут затеряться в Warning'ах
Кстати, если сначала продумать подпрограмму, а потом писать, то объявлять переменные по ходу не придется.
Я вообще-то не понял, ты чем вообще заниматься должен? Зачетами и переводом или здесь трепаться? С переводом можно вопрос просто решить, я просто проставлю все везде как считаю нужным и все. Сэкономлю при этом кучу времени.
За что же ТЫ ненавидишь Симбу? Про SP вот и <a href="http://www.pridelands.ru/?p=texts&a=get&id=328" target="blank">вот<
Про переменные я хотел сказать то, что
у моей проги заччастую нужно много однотипных переменных. Дх Ду тут не прокатит. Нужно больше имен. Например я вынужден брать переменные x,y,x1,x2,_x,_y,_x1,_x2...
А в си это намного проще например x,X,x,Y. Думать надо всетаки меньше и к тому же код красивее.
Меня в отличие от Бельтара не разадражают сообщения компилятора о регистре введенных идентификаторов. Вот и все что хотел сказать на данный момент ибо слишком нетрезв чтобы дискутировать на другие вопросы. Кстати всех с новым годом.
Я посмотрю на тебя, когда ты будешь вылавливать баги, возникшие из-за того, что Shift не нажал. А если еще и программа будет выдавать результаты, правильность которых сложно проверить.
За что же ТЫ ненавидишь Симбу? Про SP вот и <a href="http://www.pridelands.ru/?p=texts&a=get&id=328" target="blank">вот<
2 MAMA он далеко НЕ красивее, гораздо менее понятнее и читабельнее. Плюс бывает что ловишь баг, где вместо x стоит y - и тоже не везде ловится. А если там еще и разные регистры будут, и где весьма сложно будет проверять ответы - то вообще вожно с отладкой такого кода уйти в долгое плавание
А если это не класс а структура? У нее нет вообще ни конструктора ни деструктора.
Димониус, в C++ структура и класс – почти одно и то же. ^_^ А вообще, я не совсем понял, что ты имеешь в виду. Можешь привести пример дельфового кода, в котором эта ошибка вылавливается, а в аналогичном сишном – нет?
Пример?
type rec = record q : double;
end;
var v : real;
begin rec(v).q := 0; // Никаких ошибок или предупреждений не выдается end;
Это тоже зависит от программиста. И от ситуации. И опять от программиста.
Если язык не позволяет сделать красивое решение, то от программиста зависти только то, насколько некрасивым будет решение.
Забываем нажать Shift и получаем сообщение об ошибке компиляции, которая в той же Visual Studio процесс длительный. Мелочь, а неприятно.
Белтар, это тебя Дельфи плохому научила. Если бы ты изначально писал на Си, таких ошибок бы не было. Вот лично я не могу вспомнить, когда у меня подобная ошибка была.
Да и предупреждения могут затеряться в Warning'ах
Я всегда делаю, чтобы никаких предупреждений не оставалось.
Кстати, если сначала продумать подпрограмму, а потом писать, то объявлять переменные по ходу не придется.
Бывают какие-то улучшения, дополнения и прочее. А вообще, посмотрел бы я на того программиста, который хороший кусок кода с первого захода напишет без единой ошибки, да еще и последовательно, не исправляя уже написанное. Ну-ну.
МАМА, а вот мне такой подход не нравится. Может, со стороны оно и выглядит красивее, но читабельности кода оно не добавляет.
Бельтар,
ну и посмотри на меня. Нет у меня с вылавливанием
ошибок никаких проблем. Ну разве если я
укуренный был когда писал,
ибо обычно я внимательно пишу
и форматирую текст красиво.
делаю отступы и для каждого объявления сразу забиваю его конец begin/{ - end/} , потом вписываю код внутрь.
А не пишу просто весь код как он должен выглядить последовательно.
