Кто что думает?

← →
sniknik © (2007-06-12 13:55) [480]

Alx2 © (12.06.07 13:09) [478]
пример неудачный, автоприведение типа в операциях вполне логично, и без двусмысленностей. (если не понимаешь почему и как, но надо определенное делай явное преобразование и все. никаких false вместо true не будет)
тебя кстати почемуто не смутило, что ShowMessage показал строку... сконвертировал из варианта (неважно "1" или "true").

← →
Sergey Masloff (2007-06-12 13:58) [481]

Да можно считать неоднозначностью - побитовый и логический операторы не различаются (ср. в том же це: | и ||, & и &&)

← →
Sergey Masloff (2007-06-12 14:03) [482]

Юрий Зотов © (12.06.07 13:54) [479]
Юр, у меня дельфы под рукой нет проверить, но все же мне кажется дело тут не в старшинстве.
Можно заменить boolean на LongBool который равен integer но ничего не поменяется (я предполагаю).
Тут наверное механизм такой - у логического and оба операнды булевы. Если хотя бы один нет то он смотрит а не побитовый ли это оператор. И сразу видит integer как один из операндов - отлично то что нужно и быстро приводит второй операнд к интежеру.
Но может я и не прав.

← →
Юрий Зотов © (2007-06-12 14:04) [483]

> Sergey Masloff (12.06.07 13:58) [481]

Они распознаются при парсинге. Соответственно, компилятор всегда строит правильный код и результат всегда однозначен. Нет смысла вводить в язык избыточные операции.

← →
db2admin © (2007-06-12 14:05) [484]

Удалено модератором

← →
Alx2 © (2007-06-12 14:09) [485]

>Юрий Зотов © (12.06.07 13:54)
>sniknik © (12.06.07 13:55)

Ребята, я это понимаю. Но подошел к этому вопросу с точки зрения "как понять человеку", которая, кажется, у Юрия в этой ветке верховодит.

>Юрий Зотов © (12.06.07 13:54)

>При вычислении выражений со смешанными типами младшие типы
>приводятся к старшим, а результат получает самый старший тип.

Заменим integer на longint
а i := 1;
заменим, например, на i := 1 shl 35;
Результатом будет 8.

То же самое и с типом i : double;
Он приводится к integer. Хотя по-классике уже криво смотрится double в связке с and.

И, судя по трассе отладчика, приводится только к integer.

← →
Alx2 © (2007-06-12 14:13) [486]

С другой стороны, ведь и с теми "неоднозначностями" на С++ достаточно помнить о спецификации.

← →
sniknik © (2007-06-12 14:18) [487]

> Заменим integer на longint
заменим все!
Var i : Integer; b : byte; k : word; v : Variant; begin b := 1; i := 1; k := 1; v := boolean(k and b and i); ShowMessage(v); end;
и получим правильный результат (вернее то чего хотелось).
тип boolean это же тоже фактически число...

"ты думаешь ты тут воздухом дышишь?" @Морфиус

> То же самое и с типом i : double;
??? да ну? а ты туда точно с плавающей запятой значение задал? или такое какое позволило оптимизатору привести к целому?

← →
Alx2 © (2007-06-12 14:22) [488]

>sniknik © (12.06.07 14:18)

>??? да ну? а ты туда точно с плавающей запятой значение задал? или такое
>какое позволило оптимизатору привести к целому?

var d: double; b: boolean; v: Variant; begin b := true; d := 1.55; v := true; v := b and v and d; ShowMessage(v); end;

Ответ round(d).
В данном случае 2.

PS
Мне кажется, не понимаете о чем я писал.
Давайте договоримся о том, что все мы знаем этот аспект Delphi.

← →
Anatoly Podgoretsky © (2007-06-12 15:49) [489]

Это не аспект Дельфи, эти типы из АПИ - варианты
А с волками жить, по волчьи выть.

← →
palva © (2007-06-12 17:37) [490]

Юрий Зотов © (12.06.07 12:37) [476]
Пример?

Берем Pointer присваиваиваем ему какое-нибудь целое число, а потом читаем байт по этому указателю. Синтаксически верная программа при разных запусках на разных машинах будет давать разные результаты. А если число подберем удачно, то и исключение получится.

← →
Однокамушкин (2007-06-12 17:44) [491]

> palva © (12.06.07 17:37) [490]

Ну так это ведь не потому, что клмпилятор генерирует разный код, а потому, что окружение меняется... а то так можно договориться до того, что программа, скаладывающая два введённых пользователем числа, тоже работает по-разному на разных компьютерах - пользователи ведь разные значения вводят... А Юрий говорил о совсем другом случае - когда компилятор одну и ту же строчку может по-разному откомпиляировать в зависимости от фазы луны и расположения звёзд...

← →
palva © (2007-06-12 17:49) [492]

Однокамушкин (12.06.07 17:44) [491]
Мы явно не понимаем друг друга. Компиляция строчки f(a++,b++) не зависит от фазы луны и расположения звезд. Она зависит от компилятора, ключей компиляции и окружающего кода. Точно то же самое можно сказать про паскалевские компиляторы.
Давайте пусть Юрий уточнит, какой пример он хочет.

← →
palva © (2007-06-12 17:52) [493]

Кстати я как раз и привел пример того, что просил Юрий. Я же написал

> Я подозреваю, что там тоже есть правильные синтаксические конструкции, которые не ведут к определенным действиям.

Юрий в ответ на это попросил пример.

← →
Однокамушкин (2007-06-12 18:27) [494]

> palva © (12.06.07 17:49) [492]
> Однокамушкин (12.06.07 17:44) [491]
> Мы явно не понимаем друг друга. Компиляция строчки f(a++,
> b++) не зависит от фазы луны и расположения звезд. Она зависит
> от компилятора, ключей компиляции и окружающего кода. Точно
> то же самое можно сказать про паскалевские компиляторы.

Абсолютно не понимаем... в одном случае от компилятора зависит получающийся код, в другом код одинаковый, но из-за разных входных данных выполняется по-разному - вы не находите, что ситуации не совсем эквивалентны?

Я могу привести пример, который просил Юрий... вот он:

var X, A, B: Integer; // глобальные переменные function GetFive: Integer; begin Result := 5; X := 10; end; begin X := 5; A := X + GetFive; X := 5; B := GetFive + X; WriteLn(A); WriteLn(B); end.

Какие значения получат переменные A и B? 10 или 15? Стандарт языка Паскаль не определяет, в каком порядке вычисляются аргументы бинарных опреаций, компилятор имеет право выбирать этот порядок сам... во всех известных мне версиях Delphi компилятор в обоих случаях сначала вычислит GetFive, изменяя таким образом X, а потом к результату добавится значение X, т.е. и A, и B будут равны 15... но другой компилятор может решить по-другому, и тогда одна или обе переменные получат значение 10... вот о каких примерах говорил Юрий, а ему в ответ какие-то невнятные примеры с вариантами и указателями - всё запутано, но либо детерминировано, либо зависит от внешних условий...

Delphi такой пример, конечно, не украшает, но ведь, с другой стороны, Delphi - далкео не самый продвинутый в смысле выверенности конструкций язык, самый продвинутый на сегодня, это, видимо, Оберон... а Delphi всё же ближе к Оберону, чем С++ :))

← →
Zeqfreed © (2007-06-12 18:46) [495]

> Однокамушкин (12.06.07 18:27) [494]

Отличный пример. FPC выдает 10 15, в режиме совместимости с Delphi — 15 15. Только боюсь, что сейчас начнется, что это совсем разные языки и прочее.

← →
palva © (2007-06-12 19:19) [496]

> Абсолютно не понимаем... в одном случае от компилятора зависит получающийся код, в другом код одинаковый, но из-за разных входных данных выполняется по-разному - вы не находите, что ситуации не совсем эквивалентны?

Нахожу, что не совсем эквивалентны.

> вот о каких примерах говорил Юрий, а ему в ответ какие-то невнятные примеры
Ну что тут сказать... На внятные вопросы будут внятные ответы. Это вам удалось его понять и интерпретировать. А я, например, не понимаю почему
> 3. Язык программирования обязан быть определенным.
да еще с точки зрения синтаксиса. Я не понимаю, где в f(a++,a++) неопределенность в синтаксисе. Это вполне определенное задание компилятору скомпилировать код, причем программисту неважно, в каком порядке выполняются параметры, раз он такое пишет. В конце-концов, возможно, что функция f симметрическая. С другой стороны непонятно почему язык, который должен быть "определенным", но таковым не является, используется гораздо шире чем "определенные" языки.

← →
Однокамушкин (2007-06-12 20:18) [497]

> palva © (12.06.07 19:19) [496]

> Я не понимаю, где в f(a++,a++) неопределенность в синтаксисе.
> Это вполне определенное задание компилятору скомпилировать
> код, причем программисту неважно, в каком порядке выполняются
> параметры, раз он такое пишет.

Неважно или нет, это вопрос... для кого-то неважно, а кто-то просто сделал неверное предположение...

> С другой стороны непонятно почему язык, который должен быть
> "определенным", но таковым не является, используется гораздо
> шире чем "определенные" языки.

Ну, если считать широту использования главным критерием, то и опреационных систем лучше Windows нет...

А почему многие любят С и С++, это понятно... для многих главным достоинством любого ЯВУ кажется возможность писать конструкции типа while (*d++=*s++); примитивные рассуждения из серии "на С я могу записать одной строчкой то, для чего в Delphi понадобится десять строк, значит, С++ круче"... а понимание того, что за эту крутость приходится расплачиваться неуправляемостью большого проекта, приходит не ко всем... Или, точнее, приходит в итоге ко всем, но к некоторым - только после собственного горького опыта, когда проект уже с нуля не перепишешь... Вот и возникают всякие корпоративные стандарты кодирования, которые прямо запрещают использования некоторых конструкций языка или комбинаций этих конструкций по причине того, что разгребать такой код, если что, будет очень трудно... А теперь вопрос на засыпку: зачем в языке нужны конструкции, которые потом запрещаются правилами написания ясного кода? Не лучше ли будет, если язык не будет вообще содержать таких конструкций?

← →
Zeqfreed © (2007-06-12 20:48) [498]

> Однокамушкин (12.06.07 20:18) [497]

> while (*d++=*s++);

Вместо этого уже давно есть strcpy. А если бы не было, то ее бы сделали и, вполне возможно, что тем же злосчастным циклом. Наглядность не портится. Лаконичность остается. Все просто, очевидно и понятно. Не нужно искать проблемы там, где их нет :)

← →
Однокамушкин (2007-06-12 20:55) [499]

> Zeqfreed © (12.06.07 20:48) [498]
> Вместо этого уже давно есть strcpy.

Вместо этого есть, а вместо чего-нибудь ещё подобного нет, на все такие извращения стандартных функций не напасёшься...

← →
Zeqfreed © (2007-06-12 20:56) [500]

> Однокамушкин (12.06.07 20:55) [499]

Зато можно единожды написать ее для всего проекта, оттестировать и продолжить жить напеваючи.

← →
Однокамушкин (2007-06-12 21:01) [501]

> Zeqfreed © (12.06.07 20:56) [500]

Можно написать... а можно - не написать... в этом-то и заключается главная проблема С++, что можно писать простой и понятный код, а можно - запутанный и небезопасный, и конструкции языка не побуждают программиста к первому варианту...

← →
Zeqfreed © (2007-06-12 21:10) [502]

Начинается :) Ладно, философствуйте далее. Я наблюдаю :)

← →
palva © (2007-06-12 21:59) [503]

> А почему многие любят С и С++, это понятно...
Любят? Если это про меня, то это не то слово. Хорошо знают. Если говорить о любви, то мне больше нравится паскаль. Но в тех конторах, где я работал раньше мне либо было предписано писать на си, либо, в случае, когда я сам мог выбирать средство разработки, я выбирал си. И не потому что он круче, а потому что я его лучше знал, а мой проект могли сопровождать другие. Один раз я выбрал паскаль. Еще под DOS. Писал на Turbo Vision. Но следующий проект на Turbo Vision писал уже на си.

> А теперь вопрос на засыпку: зачем в языке нужны конструкции, которые потом запрещаются правилами написания ясного кода? Не лучше ли будет, если язык не будет вообще содержать таких конструкций?
Почему в языке есть такие средства? Честно сказать - не знаю. Наверно, сложились исторически. Но я не занимаюсь разработкой языков. А вот к корпоративным стандартам имел отношение, и нахожу их нужными и правильными. Вообще любая возможность языка, даже не разрешаемая корпоративными стандартами, сама по себе является благом. Другое дело, что иногда широкий спектр возможностей делает затруднительным для компилятора изготовить эффективный код. Но программисту широкие возможности не мешают. Он просто не использует то, что не нужно. Возможно даже не имеет об этих возможностях понятия - пишет на сабсете языка.

А то ведь таким образом много рацпредложений можно предложить. Например, зачем в корпоративных стандартах требуют тело цикла выделять отступом? Зачем требуют соблюдать правила при наименовании переменных? Не лучше ли будет, если отступы будут носить семантический смысл, а сам компилятор по первым буквам имени переменной будет понимать, какой ее тип? Может быть и лучше. Только это будет уже не си, а питон или бейсик. В некоторых организациях и выбирают, кстати, бейсик.

← →
palva © (2007-06-12 22:15) [504]

> в этом-то и заключается главная проблема С++, что можно писать простой и понятный код, а можно - запутанный и небезопасный, и конструкции языка не побуждают программиста к первому варианту...

Что-то я не наблюдаю среди делфи программистов склонности к ясному и безопасному коду. Почитайте вопросы в начинающих - раз в неделю спрашивают, как работать со строкой или с динамическим массивом функцией Move. Или еще какие-нибудь подобные сомнительные фокусы. Если пишущий на языке ощущает его ограничения, то он стремится из них вырваться. Это психология человека. А сишники гораздо больше ценят ясность и безопасность когда. Они просто лучше понимают что это такое. Ощутив свободу и поэкспериментировав с ней они сразу же устанавливают самоограничения без всяких корпоративных стандартов. Иначе через месяц не разберешься со своим собственным кодом.

Здесь наверно есть какая-то аналогия со спорами демократов и коммунистов. Что лучше безудержная свобода или скромненький лагерь.

← →
ProgRAMmer Dimonych © (2007-06-12 22:29) [505]

> Не лучше ли будет, если отступы будут носить семантический
> смысл, а сам компилятор по первым буквам имени переменной
> будет понимать, какой ее тип? Может быть и лучше. Только
> это будет уже не си, а питон или бейсик. В некоторых организациях
> и выбирают, кстати, бейсик.

Насколько я знаю классический Basic (времён MS-DOS), там никогда не было ничего из вышеперечисленного...

← →
Sergey Masloff (2007-06-12 22:35) [506]

Так, долго маскировавшийся под добросовестного дельфина palva(c) оказался засланцем и адептом це. Куда катится мир ;-)
На самом деле нужно не париться а есть возможность изучать что попало потому что на самом деле интересно. Правда бывает сначала трудно научиться писать на це как на це а не как на дельфе (на ьбейсике как на бейсике а не как на це, и так далее). А так нормально. И позволяет адекватные инструменты выбирать.
Замерюсь тут как я троих сишников в джавистов переделал. Был проджект который писали и развивали три человека. Но трудно было так как платформ много и приходилось подстраиваться - то там то сям что вылезет. Хотя ребята серьезные я с большим удовольствием код их читал потом и многому научвился.
Но когда я посмотрел на задачу я (некрасиво хвалиться, на самом деле это могли сделать многие) написал библиотеку на PL/SQL. Которая ясно дело кросплатформенная, а объем клиента после этого уменьшился в 10 раз (кроме шуток, 10% от исходного) и настолько простой как бубен что я его сам написал. И сейчас его поддерживает один человек который вообще не программист а по совместительству.
А сишников отправили на курсы яву учить потому что ребята правда квалифицированные а проектов новых сишных не осталось.

← →
palva © (2007-06-12 23:04) [507]

> Насколько я знаю классический Basic (времён MS-DOS), там никогда не было ничего из вышеперечисленного...

Ну это я не стал объяснять. В сишных корпоративных стандартах определяют тип по первым символам, а в бейсике - по последним.
И в Turbo Basic и в Quick Basic было правило определения типа переменной по последнему символу: a$ - это строка, X& - Long, W% - Integer и т. д. Это правило работало вплоть до VB6. Даже тип возвращаемого значения у функции можно было не писать явно а шифровать в имени функции.

Так что формально вы правы. Но там было нечто похожее.
Похожая штука есть в Perl там применяются символы $ @ %. За последний символ не ручаюсь, давно не писал на Perl, совсем его забыл.

← →
Юрий Зотов © (2007-06-12 23:43) [508]

> palva © (12.06.07 17:37) [490]
> на разных машинах
Саш, ну самому-то не смешно?

> Однокамушкин (12.06.07 18:27) [494]
+1

Слишком лаконично. Общественность ждала публичного раскаянья :)

> palva © (12.06.07 22:15) [504]

> Что-то я не наблюдаю среди делфи программистов склонности
> к ясному и безопасному коду. Почитайте вопросы в начинающих
> - раз в неделю спрашивают, как работать со строкой или с
> динамическим массивом функцией Move. Или еще какие-нибудь
> подобные сомнительные фокусы.

Умора :-)) где ты видел в "Начинающим" делфи-программистов? Там 80% крютых перцев даже справку читать считающих ниже своего достоинства...

> Если пишущий на языке ощущает его ограничения, то он стремится
> из них вырваться.

Речь идёт о тех же, что и в предыдущих предложениях? Тогда это не ограничения языка, а ошибки в днк этого так называемого "пишущего"...

> Общественность ждала публичного раскаянья :)
от вас, вообщето... хотя бы за то, что свое мнение пытаетесь за общественное выдать.

> palva © (12.06.07 22:15) [504]
>
> > в этом-то и заключается главная проблема С++, что можно
> писать простой и понятный код, а можно - запутанный и небезопасный,
> и конструкции языка не побуждают программиста к первому
> варианту...
>
> Что-то я не наблюдаю среди делфи программистов склонности
> к ясному и безопасному коду. Почитайте вопросы в начинающих
> - раз в неделю спрашивают, как работать со строкой или с
> динамическим массивом функцией Move. Или еще какие-нибудь
> подобные сомнительные фокусы.

Ты бы ещё упомянул спам в конференциях сего форума!
Саш, ну ты же уже не "дитё неразумное"! Причём тут "язык программирования"? В "начинающие" "сваливают" всё, что не является явным спамом, оффтопиком, etc.
Но может ты знаешь форум по С, где есть конференция "начинающие"?

← →
Однокамушкин (2007-06-13 09:36) [515]

> palva © (12.06.07 21:59) [503]
> Но программисту широкие возможности не мешают. Он просто
> не использует то, что не нужно. Возможно даже не имеет об
> этих возможностях понятия - пишет на сабсете языка.

Неправда, иногда мешают, он может неосознанно применить их... например, программист, не знающий, что С++ умеет неявно превращать вещественные числа в целые, может случайно подставить вещественное значение там, где требуется целое, потерять и-за этого часть данных и долго мучаться, пытаясь найти ошибку, потому что ему просто не придёт в голову искать её именно в этом месте - он же не знает, что такое в принципе возможно...

Однокамушкин (12.06.07 20:18) [497]

> А почему многие любят С и С++, это понятно... для многих
> главным достоинством любого ЯВУ кажется возможность писать
> конструкции типа while (*d++=*s++); примитивные рассуждения
> из серии "на С я могу записать одной строчкой то, для чего
> в Delphi понадобится десять строк, значит, С++ круче"...
> а понимание того, что за эту крутость приходится расплачиваться
> неуправляемостью большого проекта, приходит не ко всем..
> .

Дорогой друг, объясни мне, бестолковому, почему на грязном неуправляемом С написано так много больших проектов, начиная от Unix, Windows, Oracle и Firebird, заканчивая кучей бизнес-приложений.

В то же время обилия подобных же проектов на Паскале, Обероне или Delphi не наблюдается :)

Мне очень трудно поверить, что большинство программистов корпораций страдают скрытой формой мазохизма или находятся в глубоком отрыве от окружающей действительности.

> Ощутив свободу и поэкспериментировав с ней они сразу же
> устанавливают самоограничения без всяких корпоративных стандартов.
> Иначе через месяц не разберешься со своим собственным кодом.

Что, собственно, и требовалось доказать. Комментарии уже излишни. Разве что один: разве можно назвать хорошим и безопасным язык, программируя на котором приходится вводить самоограничения? Разве не лучше было бы ввести ровно те же ограничения в сам язык?

Вот интересно, а какие цели преследуют люди, старающиеся убедить остальных в том, что С/С++ это такие монструозные языки, что на них ничего сложнее "Hello ,World" не напишешь (проект потеряет управляемость) или что Дельфи - это такой "игрушечный" язык, на котором опять же ничего сложнее "Hello, World" не напишешь?

> какие цели преследуют люди, старающиеся убедить остальных
> в том, что С/С++ это такие монструозные языки, что на них
> ничего сложнее "Hello ,World" не напишешь (проект потеряет
> управляемость) или что Дельфи - это такой "игрушечный" язык,
> на котором опять же ничего сложнее "Hello, World" не напишешь?

никаких. У них просто нет целей

> разве можно назвать хорошим и безопасным язык, программируя
> на котором приходится вводить самоограничения?

Конечно можно.

> Разве не лучше было бы ввести ровно те же ограничения в
> сам язык?

Юра, а скажи мне, опять же, бестолковому, нафига в Паскале оператор GOTO оставили, который considered harmful много-много раз ?
Разве не лучше внести ограничения в сам язык и убрать оттуда этот оператор ?

Кто что думает? Найти похожие ветки