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

← →
Bless © (2007-06-10 10:22) [440]

Не то процитировал у Algol-а. Мое возражение конечно же относится к предложению

> После передачи первого параметра в функцию some(a++,a++)
> , значение a увеличивается на единицу, и в качестве второго
> параметра передается уже 2.
>

← →
Однокамушкин (2007-06-11 09:30) [441]

> Algol (10.06.07 09:28) [436]
> Отнюдь. Да, железо совершенствуется, но и задачи усложняются.
> Причем если производительность имеет тенденцию расти линейно,
> то сложность задач как правило растет совсем нелинейно.
> Поэтому какое бы железо не было, всегда найдутся задачи,
> которые требуют еще большей производительности. А времена,
> когда компьютеры считали только корни квадратного уравнения
> - давно прошли.
> <Цитата>

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

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

← →
Algol (2007-06-11 12:15) [442]

> Это не так. Стандарт не определяет порядок вычисления аргументов.
>
> Цитата из "ISO/IEC 14882:1998 - C++ Final Draft" касаемо
> аргументов функций:
> The order of evaluation of arguments is unspecified. All
> side effects of argument expression evaluations take effect
> before the function is entered. The order of evaluation
> of the postfix expression and the argument expression list
> is unspecified.

А я спорю?) Я привожу пример как вычисляет конкретно мой компилятор (MSVS), а он вычисляет именно в такой последовательности.

← →
celades © (2007-06-11 12:18) [443]

> Я привожу пример как вычисляет конкретно мой компилятор
> (MSVS),

ты уверен? просто порядок может меняться от вызова к вызову...

← →
Vga © (2007-06-11 12:57) [444]

Гм. AFAIK, поведение компилятора на выражении, в котором одна переменная инкрементируется более одного раза непредсказуем и зависит как минимум от компилятора (а С++ не дельфи, где компилятор ровно 1), а возможно и от придури одного и того же компилятора (например изменение уровня оптимизации или взаимодействие при оптимизации с кодом на строчку выше/ниже... но это уже только мое предположение).

← →
hahol_64_rus (2007-06-11 20:35) [445]

а по моему чем проще тем лучше
ну этот С++ в ..опу

← →
Юрий Зотов © (2007-06-11 23:17) [446]

> Vga © (11.06.07 12:57) [444]

> поведение компилятора на выражении, в котором одна переменная
> инкрементируется более одного раза непредсказуем и зависит как
> минимум от компилятора

Совершенно точно. Несовместимость и непредсказуемость уже на уровне исходников. Самые натуральные подводные грабли, да еще какие!!!

Но заметьте - стоит только убрать из языка этот самый инкремент, как тут же все становится на свои места. Однозначно.

Об чем и речь.

← →
ferr © (2007-06-11 23:20) [447]

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

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

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

> ferr © (11.06.07 23:20) [447]

Иногда встречаются люди, у которых воображение развито значительно сильнее логики, Вы не находите?

:о)

← →
ferr © (2007-06-11 23:28) [449]

> Иногда встречаются люди, у которых воображение развито значительно
> сильнее логики, Вы не находите?

Я чтот не понимаю, это я себя так должен найти? Ну да бог с ним..

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

← →
Юрий Зотов © (2007-06-11 23:37) [450]

> ferr © (11.06.07 23:28) [449]

Поскольку второй абзац еще раз подтверждает первый, с Вами трудно не согласиться.

← →
celades © (2007-06-11 23:38) [451]

Пробема не в языке, а в людях. С++ не все могут "асилить".

← →
Юрий Зотов © (2007-06-11 23:55) [452]

> celades © (11.06.07 23:38) [451]

Ничего уж такого особенного для осиливания там нет. Как, впрочем, и в других ЯВУ. А насчет того, где проблема - перечитайте [444] и несколько постов выше.

Продолжая логику [447]: что Вы скажете о пистолете, который неизвестно куда выстрелит - то ли вперед, то ли назад?

← →
Anatoly Podgoretsky © (2007-06-11 23:57) [453]

> celades (11.06.2007 23:38:31) [451]

Просто не все могут получить справку из психдиспансера

← →
ferr © (2007-06-12 00:09) [454]

> Продолжая логику [447]: что Вы скажете о пистолете, который
> неизвестно куда выстрелит - то ли вперед, то ли назад?

Ну есть книжка в которой написано в какую погоду куда он стреляет ;-)

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

> ferr © (12.06.07 00:09) [454]

> Ну есть книжка

Угу, есть. Причем далеко не одна. И в каждой написано по-разному.

[444] читали? Поняли?

← →
ferr © (2007-06-12 00:20) [456]

> [444] читали? Поняли?

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

← →
Юрий Зотов © (2007-06-12 00:26) [457]

> ferr © (12.06.07 00:20) [456]

Люди имеют полное право использовать абсолютно все возможности, которые предоставляет им синтаксис языка. А этот самый синтаксис ОБЯЗАН быть таким, чтобы НИКАКИХ неоднозначных трактовок не могло возникнуть в ПРИНЦИПЕ. В том числе, и у разработчиков компиляторов.

Иначе это язык для общения на одесском привозе, а не с компьютером.

← →
ferr © (2007-06-12 00:35) [458]

> Люди имеют полное право использовать абсолютно все возможности,
> которые предоставляет им синтаксис языка. А этот самый
> синтаксис ОБЯЗАН быть таким, чтобы НИКАКИХ неоднозначных
> трактовок не могло возникнуть в ПРИНЦИПЕ. В том числе, и
> у разработчиков компиляторов.
>
> Иначе это язык для общения на одесском привозе, а не с компьютером.

Всё б вам использовать.. Вот вы на джаве писали я знаю.. И вы без задний мысли использовали derpecated методы? Думаю нет, тогда объясните неучу разницу.

← →
ferr © (2007-06-12 00:36) [459]

Всё б Вам.. ;-)

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

> ferr © (12.06.07 00:35) [458]

Странно, что ПРОГРАММИСТ ссылается на deprecated-методы в ветке, где речь идет о ЯЗЫКАХ...

Derpecated-методы бывают у КЛАССОВ и к ЯЗЫКУ абсолютно никакого отношения не имеют.

← →
ferr © (2007-06-12 00:48) [461]

Вещи-то разные но смыслом похожи, ни те не рекомендуется использовать, ни эти.

Хорошо, приведу другой пример, создатели java отказались от оператора безусловного перехода, в то время как например в delphi он есть. Но де-факто он derprecated, не так ли?

← →
Anatoly Podgoretsky © (2007-06-12 00:50) [462]

> ferr (12.06.2007 00:48:41) [461]

Ничего подобного, просто не рекомендуемый, но derprecated его не объявляли.

← →
ferr © (2007-06-12 00:54) [463]

> Ничего подобного, просто не рекомендуемый, но derprecated
> его не объявляли.

Ну я его так назвал, возможно, чересчвур вольно, на самом деле его просто не рекомендуют, как и многие "крайние" возможности с++.

← →
Юрий Зотов © (2007-06-12 01:00) [464]

> ferr © (12.06.07 00:48) [461]

Скажите честно - Вы ПОНИМАЕТЕ, о чем идет речь в ЭТОЙ ветке?

При чем тут ВООБЩЕ всякие там deprecated?

В Паскале Вы можете писать goto. Можете не писать. Как угодно. На однозначность это абсолютно НИКАК не влияет. Она сохраняется ВСЕГДА, какую бы синтаксическую конструкцию Вы ни использовали. Хоть рекомендуемую, хоть нет. Результат всегда ПРЕДСКАЗУЕМ.

Но когда результат вызова MyFunction(i++, i++) НЕПРЕДСКАЗУЕМ... и эта программа управляет ядерным реактором...

← →
ferr © (2007-06-12 01:18) [465]

> Скажите честно - Вы ПОНИМАЕТЕ, о чем идет речь в ЭТОЙ ветке?

Мне казалось что да, жаль вот только я не понимаю смысла ЭТОЙ ветки.

Пожалуй, я удалюсь из этой ветки, чтобы лишний раз никого не нервировать.

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

← →
Юрий Зотов © (2007-06-12 01:37) [466]

> ferr © (12.06.07 01:18) [465]

ЛЮБАЯ синтаксически ВЕРНАЯ языковая конструкция "гадостью" не является по определению.

Гадостью является язык, позволяющий написать программу, результат исполнения которой зависит от стиля кодинга программиста.

← →
Германн © (2007-06-12 01:40) [467]

> ferr © (12.06.07 01:18) [465]
>
> > Скажите честно - Вы ПОНИМАЕТЕ, о чем идет речь в ЭТОЙ
> ветке?
>
> Мне казалось что да, жаль вот только я не понимаю смысла
> ЭТОЙ ветки.
>
> Пожалуй, я удалюсь из этой ветки, чтобы лишний раз никого
> не нервировать.
>
> Я лишь пытался высказать СВОЮ точку зрения. Она состояла
> в том, что на с++ может программировать лишь "воспитанный"
> человек, который не говорит компилятору всякие "гадости".
>
>

Имхо, эта твоя "точка зрения" совпадает с мнением большинства в этой ветке. Только акценты расставлены не так. Ты налегаешь на "квалификацию программиста", а многие прочие на "строгость языка и его компилятора". Но поскольку, изначально сабж был именно о втором, то и твои посты "несколько, как-то" идут лесом. Увы :)

← →
TohaNik © (2007-06-12 09:24) [468]

> Vga © (11.06.07 12:57) [444]
> Гм. AFAIK, поведение компилятора на выражении, в котором
> одна переменная инкрементируется более одного раза непредсказуем
> и зависит как минимум от компилятора (а С++ не дельфи, где
> компилятор ровно 1), а возможно и от придури одного и того
> же компилятора

Какие то бои без правил…
Да еще необходимость помнить о возможном визите к психиатру:)
Зона риска однако:)

← →
Однокамушкин (2007-06-12 09:42) [469]

> ferr © (12.06.07 01:18) [465]
> Я лишь пытался высказать СВОЮ точку зрения. Она состояла
> в том, что на с++ может программировать лишь "воспитанный"
> человек, который не говорит компилятору всякие "гадости".

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

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

> Юрий Зотов © (12.06.07 01:00) [464]
> Скажите честно - Вы ПОНИМАЕТЕ, о чем идет речь в ЭТОЙ ветке?

В этой ветке я уже один раз лоханулся, поскольку принял ее за предыдущую горячую ветку с обсуждением вопроса, нужно ли изучать си. Теперь я не ошибусь.
В этой ветке обсуждается статья, которая скорее всего была остроумной первоапрельской шуткой. Для тех, кто принимает ее всерьез, я могу высказать свое мнение: статья эта - откровенная ложь. Unix и си были выдуманы не в качестве розыгрыша, а для решения определенных программистских проблем.

Язык си был не альтернативой паскалю, а альтернативой ассемблеру. Его конструкции строились так, чтобы было легко написать хороший оптимизатор, чтобы программисты, пишущие на ассемблере компилятор или операционную систему могли большую часть кода написать на си. Даже стандарты языка менялись вместе с эволюцией процессора 8086 - я имею ввиду команды сдвига на величину больше чем 32 бита.

Как показала практика, язык оказался успешным. Программы, управляющие ядерным реактором, действительно пишут на си. Неопределенность никому не помешала.

Да и почему язык должен быть определенным? Если бы авторы си хотели бы сделать как лучше, они могли бы записать в стандарт определенный порядок вычисления параметров. Но они ведь оставили много таких неопределенностей. Здесь предполагается тандем программиста и оптимизатора. Программист знает, что такая неопределенность не скажется на его алгоритме, а оптимизатор может использовать эту неопределенность. Как бы то ни было, я несколько раз лично убеждался, что одна и та же программа написанная на паскале и на си, на си работает немного быстрее. И это естественно, паскаль дальше от железа, чем си, с другой стороны его синтаксис больше приспособлен для восприятия людьми не знающими ничего о командах процессора, а задачу сделать синтаксис удобным для оптимизатора авторы языка ИМХО вообще не ставили.

Разговоры же, что си является языком плохим или ненастоящим (первоапрельским розыгрышем) я нахожу несерьезными. Это подобно тому как православные христиане, уверяют что православие является истинным христианством, а остальное христианство ложное. В то время как православные составляют едва ли десятую часть христианского мира.

ИМХО, писать на Си - все равно что ездить с ручной коробкой передач... А паскале - с автоматической.
Кому-то нравится ручная т.к. они могут более оптимально расходовать топливо, более быстро разгоняться... кому-то автоматическая т.к. можно не напрягаться переключая передачи и нельзя случайно воткнуть не ту передачу.

> palva © (12.06.07 10:34) [470]

1. Статью, конечно же, никто всерьез не принимает.
2. История Си ни для кого не новость.
3. Язык программирования обязан быть определенным.

> YurikGL © (12.06.07 11:33) [471]

> ИМХО, писать на Си - все равно что ездить с ручной коробкой
> передач... А паскале - с автоматической.

Не совсем так. И там, и там коробка передач ручная. Но схема переключения передач Сишной коробки может вдруг сама по себе взять - и измениться. А у Дельфишной она гарантированно всегда одна и та же.

> 1. Статью, конечно же, никто всерьез не принимает.
Ваше
> Скажите честно - Вы ПОНИМАЕТЕ, о чем идет речь в ЭТОЙ ветке?
я понял как призыв вернуться к обсуждению сабжа.

2. История Си ни для кого не новость.
Опять слишком категоричное утверждение. Может быть, для кого-то и новость. Во всяком случае разоблачения сабжа в ветке я еще не видел.

3. Язык программирования обязан быть определенным.
А интересно, делфи этому условию удовлетворяет? Я подозреваю, что там тоже есть правильные синтаксические конструкции, которые не ведут к определенным действиям.

← →
etc (2007-06-12 12:16) [475]

а можно воочию убедиться в [444], т.е. "поведение компилятора на выражении, в котором одна переменная инкрементируется более одного раза непредсказуем"?
действительно интересно ...

> palva © (12.06.07 11:50) [474]

> А интересно, делфи этому условию удовлетворяет?

IMHO, полностью. Даже знаменитая конструкция
if ... then if ... then... else ...
тоже совершенно однозначна: else однозначно относится ко второму if. Причем согласно синтаксису самого языка, а не соглашениям, принятым разработчиками компилятора.

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

Пример?

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

> Юрий Зотов © (12.06.07 11:40) [473]
> Не совсем так. И там, и там коробка передач ручная. Но схема
> переключения передач Сишной коробки может вдруг сама по
> себе взять - и измениться. А у Дельфишной она гарантированно
> всегда одна и та же.

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

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

Ещё раз призываю оставить низкоуровневую оптимизацию компьютеру... не делайте за компьютер его работу, он ответной любезности не проявит и вашу за вас не сделает :))

>Юрий Зотов © (12.06.07 12:37)

>Пример?

Var i : Integer; b : boolean; v : Variant; begin b := true; i := 1; v:=true; v := i and v and b; ShowMessage(v); end;

Показывает "1" в D6. Но не знаю почему бы не показать "true".

> Alx2 © (12.06.07 13:09) [478]

Здесь нет никакой неоднозначности - должна показываться именно 1, а не true.

При вычислении выражений со смешанными типами младшие типы приводятся к старшим, а результат получает самый старший тип. В данном случае булевские b и v приводятся к типу i, результат выражения получает тип Integer, а вариант получает тип varInteger - и мы видим единицу. Все строго, все однозначно и все полностью соответствует спецификации.

Изменим код - заставим компилятор приводить Integer к Boolean:
var i: Integer; b: boolean; v: Variant; begin b := true; i := 1; v:=true; v := Boolean(i) and v and b; ShowMessage(v); end;
И мы видим уже не 1, а True. Снова никаких чудес - все три операнда в выражении имеют тип Boolean, этот же тип получает результат, а вариант получает тип varBoolean. Снова все строго, все однозначно и все полностью соответствует спецификации.

То есть, Ваш пример можно считать обратным - он четко подтвердил полную однозначность и полную предсказуемость результата. Все работает именно так, как и должно.

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

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