Это нормально?

← →
vpbar © (2007-10-03 21:11) [0]

Щас роюсь в исходниках (blackbox) и увидел там ЭТО
if ( TextSize.cx >= ( TaskWidth - taskIconSize - 6 ) ) { drawLeft = false; DrawText(); } else { drawLeft = true; DrawText(); }
Меня удивило. Ладно неоптимально - некоторые компиляторы С могут это оптимизировать. Но даже писать такое мне лично - лень.
Ведь так
drawLeft=TextSize.cx < ( TaskWidth - taskIconSize - 6 ); DrawText();
короче и понятней.
Итересно от чего возникают такие перлы? Лень думать. Или просто исторически при эволюции кода.
И как часто такое встречается в реальном коде? Мне такое впервый раз попалось. Я правда в основном код компонентов и примеров на Делфи читал и там ляпы если и были, то по-интеллектуальнее.

← →
Delphi User (2007-10-03 21:29) [1]

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

← →
tesseract © (2007-10-03 22:00) [2]

> И как часто такое встречается в реальном коде? Мне такое
> впервый раз попалось. Я правда в основном код компонентов
> и примеров на Делфи читал и там ляпы если и были, то по-
> интеллектуальнее.

Я иногда такое оставляю. На будущее - для рефакторинга и читать приятнее. Да и откуда ты знаешь насколько эффективен оптимизатор Delphi ?

← →
homm © (2007-10-03 22:04) [3]

> Да и откуда ты знаешь насколько эффективен оптимизатор Delphi?

Оптимизатор дельфи эффективен на столько, что сразу за последней закрывающей скобкой в первой строке и перед «else» выдаст ошибку компиляции, т.к. межжду ними пусто :)

← →
tesseract © (2007-10-03 22:06) [4]

> Оптимизатор дельфи эффективен на столько, что сразу за последней
> закрывающей скобкой в первой строке и перед «else» выдаст
> ошибку компиляции, т.к. межжду ними пусто :)

Там ещё then не хватает, я заметил.

← →
homm © (2007-10-03 22:08) [5]

> [4] tesseract © (03.10.07 22:06)
> Там ещё then не хватает, я заметил.

Естественно, пусто = не хватает :)

← →
vpbar © (2007-10-03 22:13) [6]

>>tesseract © (03.10.07 22:00) [2]
if (barIcons && IconHop) { GetTextExtentPoint32(DBuffer, TaskName, strlen(TaskName), &TextSize); if ( TextSize.cx >= ( TaskWidth - taskIconSize - 6 ) ) { drawLeft = false; DrawText(); } else { drawLeft = true; DrawText(); } } else { DrawText(); } приятнее читать чем это???
if (barIcons && IconHop) { GetTextExtentPoint32(DBuffer, TaskName, strlen(TaskName), &TextSize); drawLeft=TextSize.cx < ( TaskWidth - taskIconSize - 6 ); }; DrawText();
Нуу. В первом случае придется подумать что DrawText() вызывается в любом случае. А во втором все понятнее, по моему.
>>Да и откуда ты знаешь насколько эффективен оптимизатор Delphi ?
Код смотрел который он генерит. В отношении эффективности оптимизатора Делфи в данном случае сиильно проигрывает тому же Visual C.
ЗЫ. А на будующее я тчательнее планирую интерфейсы и не оставляю ничего лишнего.
ЗЗЫ Ну почему в С++ нет аналога делфийского with...

← →
DVM © (2007-10-03 22:15) [7]

> Ну почему в С++ нет аналога делфийского with...

там и без него своих граблей полно

← →
vpbar © (2007-10-03 22:16) [8]

>>DVM © (03.10.07 22:15) [7]
Эт точно.
>>[3],[4]
Могу переписать пример на Делфи. Все равно от этого суть не изменится, только букв прибавится.

← →
tesseract © (2007-10-03 22:17) [9]

> В отношении эффективности оптимизатора Делфи в данном случае
> сиильно проигрывает тому же Visual C.

RSDN приводил совершенно другие результаты.

> Нуу. В первом случае придется подумать что DrawText() вызывается
> в любом случае. А во втором все понятнее, по моему.

нет, первый понятнее. Там алгоритм яснее - это запросто может быть закладка на добавление алгоритма. Ну или генератор такое выдал :-)

> ЗЗЫ Ну почему в С++ нет аналога делфийского with...

ЗЗЫ Ну почему в Delphi такой гемор с boolean....

> ЗЫ. А на будующее я тчательнее планирую интерфейсы и не
> оставляю ничего лишнего.

Маладой ещё. Один и тот же код можно в 50 проектах использовать, с мелочными варияциями.

← →
vpbar © (2007-10-03 22:34) [10]

>>tesseract © (03.10.07 22:17) [9]
>>RSDN приводил совершенно другие результаты.
Даа? А я там наоборот видел. Давай приведем ссылки .

>>нет, первый понятнее. Там алгоритм яснее - это запросто может быть закладка на добавление алгоритма. Ну или генератор такое выдал :-)
Кому как. (В смысле спорить не буду, но останусь при своем месте). Про генератор я тоже подумал - ему позволено такое выдавать. :)

>>Маладой ещё. Один и тот же код можно в 50 проектах использовать, с мелочными варияциями.
Ну не намного воложе тебя, но видимо метод Copy-Paste еще не достаточно освоил :)

← →
vpbar © (2007-10-03 22:40) [11]

Вот сравнение эффективности компиляторов http://www.rsdn.ru/summary/590.xml
В основном Делфи отстает от C

← →
DVM © (2007-10-03 22:43) [12]

Только вот Делфи компилирует за считанные секунды то, что С может компилировать час.

← →
sdubaruhnul (2007-10-03 22:46) [13]

Код:

drawLeft=TextSize.cx < ( TaskWidth - taskIconSize - 6 ); DrawText();

намекает, что развитие этой программы остановилось.

← →
celades © (2007-10-03 22:49) [14]

> Только вот Делфи компилирует за считанные секунды то, что
> С может компилировать час.
>

пользователю время компиляции безралично.

← →
vpbar © (2007-10-03 22:54) [15]

>>DVM © (03.10.07 22:43) [12]
Нуу не настолько медленее, но да. Но по моему лучше час подождать при компиляции, но получить более качественный код.
>>sdubaruhnul (03.10.07 22:46) [13]
Да. Видимо та этажерка условий что я приводил - намек на то что программе еще развиваться и развиваться.

Перефразирую анек, вспомнилось :)
"Недоделанный код - это еще ничего. Главное детей доделывайте. А то этот круг не разорвать."

← →
DVM © (2007-10-03 23:00) [16]

> пользователю время компиляции безралично.

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

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

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

← →
tesseract © (2007-10-03 23:10) [17]

> В основном Делфи отстает от C

Ты сказал "значительно".

← →
homm © (2007-10-03 23:11) [18]

> [16] DVM © (03.10.07 23:00)
> > пользователю время компиляции безралично.
>
> ему также безразлично, что какой то кусок программы будет
> выполняться 100 или 200 микросекунд.

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

← →
tesseract © (2007-10-03 23:25) [19]

> Зато ему важна скорость написания программы,

Ну delphi тут без конкуренции практически....

← →
DVM © (2007-10-03 23:32) [20]

> Ну delphi тут без конкуренции практически....

C# + MSVS ему конкурент, причем сильный.

← →
homm © (2007-10-03 23:34) [21]

> [20] DVM © (03.10.07 23:32)
> C# + MSVS ему конкурент, причем сильный.

Вот и скажи, как в нем пути настроить :)
http://delphimaster.net/view/15-1191439038/

← →
DVM © (2007-10-03 23:44) [22]

> Вот и скажи, как в нем пути настроить :)

Для MSVS2005:

Tools - Options - Projects and Solutions - VC++ Directories - Show Directories For (выбираешь нужное ниже добавляешь папки)

← →
antonn © (2007-10-03 23:46) [23]

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

серьезно, что ли?

← →
DVM © (2007-10-03 23:49) [24]

> серьезно, что ли?

Да, а что удивительного? Большой проект может и больше компилироваться со всеми зависимостями.

← →
antonn © (2007-10-03 23:55) [25]

ну большой проект понятие относительное. Я так подумал, что где дельфи компилит за считаные секундны там С может ночь гонять :)

← →
homm © (2007-10-04 00:14) [26]

> [22] DVM © (03.10.07 23:44)

Спасибо :)

← →
Zeqfreed © (2007-10-04 05:36) [27]

> DVM © (03.10.07 23:49) [24]

Проблем особых нет. 4 ядра, 8 Гб оперативки — 15 мин. компиляция сложного проекта :) Для ежедневных билдов самое оно, зато люди отвыкают от метода разработки «написал строку - запустил - посмотрел не сломалось ли».

← →
DVM © (2007-10-04 07:13) [28]

> зато люди отвыкают от метода разработки «написал строку
> - запустил - посмотрел не сломалось ли».

это да, у самого такая привычка

> Zeqfreed © (04.10.07 05:36) [27]
> 15 мин.
> Для ежедневных билдов самое оно

Ну... вообще-то и 8 часов проект собирался для ежедневных билдов - проблем не было. Главное за ночь успевать :)

> vpbar © (03.10.07 22:40) [11]
>
> Вот сравнение эффективности компиляторов http://www.rsdn.
> ru/summary/590.xml
> В основном Делфи отстает от C

Цитату можно мне в лицо? А то я дурень даже и близко сравнения компиляторов Д и С не вижу.

>>pasha_golub © (04.10.07 09:54) [31]
Ниже приведены их результаты и результаты выполнения нашего нового Float-теста.
Float-тест Компилятор Время VC7 1.62 bcc 2.55 C# 3.14 gcc 3.43 Delphi6 3.72 vc6 4.75 bcb 5.47 Java 5.73 Intel C++ 7.34 VB6 13.28

Таблица 1. Результаты нового Float-теста.

Расклад сил в новом тесте кардинально изменился. Лидером на сей раз стал VC7. Второе место, и это можно считать сенсацией, занял bcc. Он традиционно отставал во всех тестах (в том числе и в первом Float-тесте), но в новом тесте вырвался на вторую позицию, причем с очень недурным результатом. На третьем месте – C#. Интересно, что в этом тесте он показал лучший результат, если не производилась прекомпиляция утилитой ngen! Мы произвели отдельное тестирование с и без использования этой утилиты, а также привели результаты, полученные на бете 2 (с ngen). Эти результаты можно увидеть в таблице 3. В любом случае столь высокий показатель «управляемого» компилятора говорит о большом потенциале платформы .Net, да и управляемых платформ (вроде Java) в целом.

>>tesseract © (03.10.07 23:10) [17]
>>Ты сказал "значительно".
И где я это сказал?
Или ты имел ввиду это " В отношении эффективности оптимизатора Делфи в данном случае сиильно проигрывает тому же Visual C."
Но в этой строчке только то что написано. В данном (см[0]) случае оптимизатор делфи хуже чем Visual C. А именно, делфи не вынес общее код. Хотя можно было.
В других случаях делфи не сильно проигрывает, а иногда выигрывает, например, при работе с памятью. Но это заслуга не оптимизатора, а его менеждера памяти.
ЗЫ. Будет время сделаю сравнение кода генерируемого Delphi7, TurboDelphi, Visual Studio 2005 и MinGW.

ЗЗЫ Во как, стоило привести код на С++ сразу началось обсуждение кто лучше. Хотя язык к в данном вопросе значения мало имеет, ИМХО.

← →
jack128_ (2007-10-04 10:32) [35]

> А то я дурень даже и близко сравнения компиляторов Д и С
> не вижу.

не только с и д, но и джава и vb
http://www.rsdn.ru/article/devtools/perftest.xml

> Игорь Шевченко © (04.10.07 09:31) [30]
> DVM © (03.10.07 22:15) [7]
>
>
> > там и без него своих граблей полно
>
>
> Не больше чем в Паскале

А кто то сказал, что их там больше?

> А кто то сказал, что их там больше?

С++ по граблям лидирует однозначно, С - на втором месте, pascal не в 10-ке :-)

← →
Sandman31 (2007-10-04 11:17) [38]

jack128_ (04.10.07 10:32) [35]

Автор обзора совершенно не разбирается в java.

Для оптимизации теста в Java к классу был применен модификатор final. По умолчанию все методы в Java являются виртуальными.

...
Как бы то ни было, большинство программистов вообще не воспринимает всерьез ни Java, ни C#. Какие же доводы они приводят? Первый – эти языки (и сами платформы) значительно уступают «родному» коду в производительности. Второй – такие языки не универсальны, и с их помощью можно решать очень ограниченный круг задач.

Даешь программирование на ассемблере! :)

> Sandman31 (04.10.07 11:17) [38]
Но ведь в Java действительно обычные методы являются по умолчанию виртуальными.

> vpbar © (04.10.07 10:22) [32]

> Ниже приведены их результаты и результаты выполнения нашего
> нового Float-теста.

Так вопрос об оптимизаторе поднимался. Кроме float есть весомые аргументы?

> jack128_ (04.10.07 10:32) [35]
>
> http://www.rsdn.ru/article/devtools/perftest.xml

Жень по ссылке твоей:

> Выводы по тесту
> В этом тесте выиграл не самый быстрый компилятор, а средство
> разработки, в котором серьезно подошли к переписыванию функций
> управления памятью.

Это нормально? Найти похожие ветки