Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Дарней, Вы писали:

Д>>Ну это ты зря. Текущие проблемы — это только проблемы кривых реализаций

VD>Возможно. Вот бы на одну прямую глянуть.

Я бы тоже не прочь посмотреть

Здравствуйте, VladD2, Вы писали:

VD>Кстати, было бы куда лучше если бы можно было создавать наследников вэлью-типов.

Будут проблемы со срезкой.

Здравствуйте, Sinclair, Вы писали:

S>Верно, но только если опустить второй type:
S>

S>type MyType= type Integer;
S>

Согласен, но raskin упоминал нечто древне-паскалевское.

Здравствуйте, Трурль, Вы писали:
Т>Согласен, но raskin упоминал нечто древне-паскалевское.
Ой, этих паскалей... Причем между ними идет постоянный взаимообмен фичами. К тому же, вполне возможно что такая фича существовала со времен какого-нибудь TP7, только я о ней ничего не знал. В свое время напоролся в исходниках, и был шибко удивлен.

Здравствуйте, VladD2, Вы писали:

VD>Там компилятор был не причем. Там были махинации со своим пулом памяти и вручную вызывались деструкторы. Конструктор же вызывался дважды из-за прохода по памяти в одном из деструкторов (или еще где... уже не помню).
Те наплевал на все защиты С++, что-то наворотил шаловливыми ручками, а С++ виноват? Прэлесно!

Здравствуйте, VladD2, Вы писали:

VD>И что самое поскудное — это же совершенно корректный код .
И что это доказывает? В C# тоже можно написать unsafe и натворить тАкое
Если начал приводить что попало к чему попало, вызывать деструкторы руками так сам себе злобный буратино.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, FDSC, Вы писали:

FDS>>Здравствуйте, Cyberax, Вы писали:

S>Для этого придуманы различные паттерны. Если у вас два объекта требуют согласованного конфигурирования — сделайте класс "согласованный конфигуратор". Или примените шаблоны С++, чтобы попытка присвоить несовместимый вход к выходу была ошибкой компиляции.

А почему я должен писать код, когда компилятор может в принципе это сделать и без него?

S>Если подобных паттернов становится много, и их трудно контролировать — посмотрите в сторону DSL.

Вот именно, "посмотрите в сторону DSL". Почему бы это не реализовать прямо в компиляторе?


FDS>>Тут прикол в том, что я рад бы от него вообще избавиться. Assembler никогда не стоит выносить в отдельный файл. Если ассемблера много — лучше сразу всё на нём написать с использованием внешних модулей (я так делал).
S>Ассемблер вообще не нужен.

Особенно для тех микроконтроллеров, для которых нет других компиляторов.

FDS>>Amd64 то же совместимый с Intel x86. С Itamium наши пользователи никогда не работают. Да и Delph то же.
FDS>>В этом и прикол, нужно, что бы можно было оптимизировать код не уродуя его и прямо в нём.
S>Не нужно. Ты в курсе, почему из С++ убирают слово register? Да потому, что ранние компилеры забивали на него — не умели оптимизировать. А новые компиляторы забивают на наго потому, что у них больше информации об использовании переменной, чем у программиста. И они принимают значительно более обоснованные решения.
S>Что это означает? Что вместо возможности принуждать компилятор к определенному поведению, лучше наоборот — научить компилятор корректно оптимизировать. Современное состояние оптимизации настолько далеко ушло от знакомых мне со школы решений типа "выноса инварианта за цикл"... Сейчас компиляторы ухитряются инлайнить виртуальные вызовы!

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


FDS>>В некотрых приложениях сплошь и рядом (всё равно редко, но очень значительно). Особенно в Delphi.
S>Я, честно говоря, не понимаю вас. Если производительность критична — выкинь Delphi. Современные компиляторы промышленного уровня оптимизируют так, что ты запаришься их догонять. При этом все время рискуя вылететь за пределы кросс-процессорной совместимости, или внести трудноуловимую ошибку. Возможности оптимизации в Delphi находятся в противозачаточном состоянии. Поэтому работа с ним вредна для разработчиков time-critical приложений: они привыкают не доверять компилятору.

Производительность вообще не критична. Просто она иногда такой становится случайно. Десятый раз повторяю — не я выбираю средство разработки!

S>Не так давно я имел спор с таким Delphi/Asm специалистом. Его мнение о С++ было ниже плинтуса. Я предложил ему продемонстрировать это. Ок, он попытался нарисовать на асме банальный поиск в массиве интов: while(a[i++]!=test && i<length); return i. Конечно, VC++ 7.1 написал более длинный цикл. Ручной асм-код смотрелся намного красивше. Увы, при замерах скорости VC победил с разгромным счетом.

У меня хорошее мнение о качестве компиляции C++. Его очень трудно обогнать (я пробовал). Между прочим, Delphi то же обогнать не легко.
Найди программиста получше. Я тебе без цикла это напишу, с помощью строковых команд — VC точно хуже компилирует, уже пробовали.
Никогда не видел, что б ассемблер смотрелся намного красивее языка высокого уровня, даже если это C++.

Я могу сделать любой код на asm (если, конечно, я его могу сделать его вообще), исполняющийся столько же или быстрее кода C++, при этом не зная, как компилирует VC.

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


S>Что это означает? Что асм применяют сейчас почти только те, кто пользуется некачественным компилятором. Ребята, возьмите нормальный компайлер. Это сэкономит вам сотни часов бессмысленно потраченного времени.

Любой компилятор иногда становится некачественным. VС с MFC — малокачественные по сравнению с Delphi, кодга пишешь интерфейсное приложение — на Delphi просто ничего знать не нужно, что бы его написать, а в MFC ещё потрудиться надо, да ещё карты сообщений в коде по ногами путаются всё время.
Обычно, только C++ для МК всегда супер качественный — его действительно не обогнать.

Мне приходилось применять asm (правда, всего 2 раза), для создания более компактного и понятного кода.

Здравствуйте, FDSC, Вы писали:

FDS>А почему я должен писать код, когда компилятор может в принципе это сделать и без него?
ГМ. Я может, чего-то не уловил. Но компилятор в любом случае нуждается в информации о том, что тебе можно, а что нельзя. Написание этого кода — и есть такой рассказ компилятору.
FDS>Вот именно, "посмотрите в сторону DSL". Почему бы это не реализовать прямо в компиляторе?
Что именно?

FDS>Особенно для тех микроконтроллеров, для которых нет других компиляторов.
Не передергивай. Речь шла о совмещении кода на асм с другими компиляторами. Ты не на Delphi часом под микроконтроллеры пишешь?
FDS>Научить компилятор корректно оптимизировать очень трудно, а принудить его может почти каждый.
Уже. Друг мой, уже. И давно. На досуге попробуй порвать VC хотя бы 7. Уверяю тебя — устанешь. Даже если ты в уме помнишь latency для всех команд Pentium и кто там через какой пайп может ездить.
FDS>Производительность вообще не критична. Просто она иногда такой становится случайно. Десятый раз повторяю — не я выбираю средство разработки!
Очень странно. Сначала ты предлагаешь изобрести новое средство разработки. А когда тебе говорят: так вот же оно! Уже есть! Не надо ничего изобретать! Ты отказываешься от обсуждения, т.к. ты не выбираешь средство разработки. Что ж, сочувствую.

FDS>У меня хорошее мнение о качестве компиляции C++. Его очень трудно обогнать (я пробовал). Между прочим, Delphi то же обогнать не легко.
Легко. Как раз Delphi я тебе порву на раз-два. Особенно в математике. У них никогда не было толковой оптимизации плавающей запятой. Ну и про убогий инлайнинг тоже забывать не стоит.
FDS>Найди программиста получше. Я тебе без цикла это напишу, с помощью строковых команд — VC точно хуже компилирует, уже пробовали.
Попробуй еще раз. На VC 7.0 или 7.1. Убедишься в том, что строковые команды рулят не всегда.
FDS>Никогда не видел, что б ассемблер смотрелся намного красивее языка высокого уровня, даже если это C++.
Имеется в виду асм-код, сгенеренный компилятором.
FDS>Я могу сделать любой код на asm (если, конечно, я его могу сделать его вообще), исполняющийся столько же или быстрее кода C++, при этом не зная, как компилирует VC.
Это иллюзия. Оптический обман. В некоторых простых случаях ты действительно сделаешь код, исполняющийся на равных. В некоторых, еще более редких случаях, ты сможешь получить выигрышь за счет глобальных оптимизаций (которые С++ — компайлеру просто недоступны). Код, сгенерированный компилятором Intel, ты будешь догонять месяцами. А изучая дизассемблернуый код, будешь периодически всплескивать руками и говорить "не может быть! Это должно работать медленнее, чем у меня".
FDS>Это так же, как сравнивать программы, которые один компилятор скомпилировал с опцией оптимизации размера кода, а другой — с опцией оптимизации быстродействия.
Нет. Это как сравнивать программы, написанные человеком, который ничего не знал про MMX, SSE2, и параллельные конвейеры в x86, c программами, написанными экспертом.

FDS>Любой компилятор иногда становится некачественным. VС с MFC — малокачественные по сравнению с Delphi, кодга пишешь интерфейсное приложение — на Delphi просто ничего знать не нужно, что бы его написать, а в MFC ещё потрудиться надо, да ещё карты сообщений в коде по ногами путаются всё время.
На самом деле это не вполне так. Ты, скорее всего, опять же говоришь про VC 6.0. C тех пор случилось много нового.
FDS>Обычно, только C++ для МК всегда супер качественный — его действительно не обогнать.

FDS>Мне приходилось применять asm (правда, всего 2 раза), для создания более компактного и понятного кода.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, FDSC, Вы писали:

FDS>>А почему я должен писать код, когда компилятор может в принципе это сделать и без него?
S>ГМ. Я может, чего-то не уловил. Но компилятор в любом случае нуждается в информации о том, что тебе можно, а что нельзя. Написание этого кода — и есть такой рассказ компилятору.

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

FDS>>Вот именно, "посмотрите в сторону DSL". Почему бы это не реализовать прямо в компиляторе?
S>Что именно?

Встроить все технологии непосредственно в компилятор и язык, а не смотреть "в сторону".

FDS>>Особенно для тех микроконтроллеров, для которых нет других компиляторов.
S>Не передергивай. Речь шла о совмещении кода на асм с другими компиляторами. Ты не на Delphi часом под микроконтроллеры пишешь?

Издеваешся?

FDS>>Научить компилятор корректно оптимизировать очень трудно, а принудить его может почти каждый.
S>Уже. Друг мой, уже. И давно. На досуге попробуй порвать VC хотя бы 7. Уверяю тебя — устанешь. Даже если ты в уме помнишь latency для всех команд Pentium и кто там через какой пайп может ездить.

Я же сказал, не всегда компилятор лучше — чем новее компилятор, тем лучше он оптимизирует код, но в некоторых частных случаях всё равно плохо компилирует. Поменьше читай рекламных сообщений. Кстати, времена исполнения помнить совсем не обязательно.

FDS>>Производительность вообще не критична. Просто она иногда такой становится случайно. Десятый раз повторяю — не я выбираю средство разработки!
S>Очень странно. Сначала ты предлагаешь изобрести новое средство разработки. А когда тебе говорят: так вот же оно! Уже есть! Не надо ничего изобретать! Ты отказываешься от обсуждения, т.к. ты не выбираешь средство разработки. Что ж, сочувствую.

А, вот о чём! Согласен. Но в C++ нет некоторых возможностей Delphi — вот я и не могу перейти на него. Иначе бы все уже давно на Delphi плюнули.


FDS>>У меня хорошее мнение о качестве компиляции C++. Его очень трудно обогнать (я пробовал). Между прочим, Delphi то же обогнать не легко.
S>Легко. Как раз Delphi я тебе порву на раз-два. Особенно в математике. У них никогда не было толковой оптимизации плавающей запятой. Ну и про убогий инлайнинг тоже забывать не стоит.

М-м. Попробуй.

FDS>>Найди программиста получше. Я тебе без цикла это напишу, с помощью строковых команд — VC точно хуже компилирует, уже пробовали.
S>Попробуй еще раз. На VC 7.0 или 7.1. Убедишься в том, что строковые команды рулят не всегда.

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

FDS>>Никогда не видел, что б ассемблер смотрелся намного красивее языка высокого уровня, даже если это C++.
S>Имеется в виду асм-код, сгенеренный компилятором.

А-а-а. Да кто ж его смотрит то!

FDS>>Я могу сделать любой код на asm (если, конечно, я его могу сделать его вообще), исполняющийся столько же или быстрее кода C++, при этом не зная, как компилирует VC.
S>Это иллюзия. Оптический обман. В некоторых простых случаях ты действительно сделаешь код, исполняющийся на равных. В некоторых, еще более редких случаях, ты сможешь получить выигрышь за счет глобальных оптимизаций (которые С++ — компайлеру просто недоступны).

Как раз в "простых случаях" мне будет очень трудно сделать хороший код — это я знаю не понаслышке, возможно, даже отстану. Но в некоторых сложных — могу обогнать (главное — не забывайте надевать шлем).

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

S>Код, сгенерированный компилятором Intel, ты будешь догонять месяцами. А изучая дизассемблернуый код, будешь периодически всплескивать руками и говорить "не может быть! Это должно работать медленнее, чем у меня".

Где это я его буду догонять, на своём AMD Athlon?
Точно, бывает такое. Но программист, написавший компилятор от Intel, возможно, напишет ещё круче.

FDS>>Это так же, как сравнивать программы, которые один компилятор скомпилировал с опцией оптимизации размера кода, а другой — с опцией оптимизации быстродействия.
S>Нет. Это как сравнивать программы, написанные человеком, который ничего не знал про MMX, SSE2, и параллельные конвейеры в x86, c программами, написанными экспертом.

Значит ты взял не assembler-программиста. Тогда о чём вообще речь?

FDS>>Любой компилятор иногда становится некачественным. VС с MFC — малокачественные по сравнению с Delphi, кодга пишешь интерфейсное приложение — на Delphi просто ничего знать не нужно, что бы его написать, а в MFC ещё потрудиться надо, да ещё карты сообщений в коде по ногами путаются всё время.
S>На самом деле это не вполне так. Ты, скорее всего, опять же говоришь про VC 6.0. C тех пор случилось много нового.

Много нового, насколько я помню, случилось в .NET. А в VS for Windows, если только мастера изменились. В прочем, может я что-то важное упустил?!

Здравствуйте, Cyberax, Вы писали:

C>В С++ пишешь:
C>typedef boost::strong_typedef<int> NumberOfSymbolInString;

Оп-па! Сколько бустом пользуюсь, а на этот класс внимания не обращал... Буду, буду знать, спасибо.

FDSC wrote:

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

Врет. Строковые команды еще с 486 процессора работают медленнее.

> Много нового, насколько я помню, случилось в .NET. *А в VS for
> Windows, если только мастера изменились. В прочем, может я что-то
> важное упустил?!*

Ну да, а Мерседес отличается от ВАЗа только кузовом.

В VC7.1 (и тем более в VC8.0) компилятор намного лучше, чем в VC6.
Больше оптимизаций, лучше качество работы, меньше глюков. Ну и поддержка
Стандарта С++ почти полная.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Cyberax, Вы писали:

C>FDSC wrote:

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

C>Врет. Строковые команды еще с 486 процессора работают медленнее.

Минуточку. Медленнее чего? Приведи asm код, который работает быстрее, или хотя бы (если лень) опиши его. Впрочем, я посмотрю VC 7, может найду там что-нибудь интересное.

>> Много нового, насколько я помню, случилось в .NET. *А в VS for
>> Windows, если только мастера изменились. В прочем, может я что-то
>> важное упустил?!*

C>Ну да, а Мерседес отличается от ВАЗа только кузовом.

C>В VC7.1 (и тем более в VC8.0) компилятор намного лучше, чем в VC6.
C>Больше оптимизаций, лучше качество работы, меньше глюков. Ну и поддержка
C>Стандарта С++ почти полная.

И что из этого? Там что, появилась поддержка VCL? Я же говорю не про компилятор. Delphi позволяет разрабатывать приложения быстрее.

Здравствуйте, Трурль, Вы писали:

Т>

Т>type MyType is INTEGER;
Т>

А может быть ещё можно как-то расширить поведение или наоборот — урезать?

Здравствуйте, mihoshi, Вы писали:

M>

M>struct PositionInString{int Value;};
M>

M>Оно?

Если сюда все операторы ещё воткнуть, допустимые для целого числа — тогда оно.

Здравствуйте, Cyberax, Вы писали:

C>В С++ пишешь:
C>typedef boost::strong_typedef<int> NumberOfSymbolInString;

Любопытно... О какой версии буста идёт речь? В 1.30.2 ещё про strong_typedef ничего не слышно, а в 1.32.0 (которую только что скачал) нет класса boost::strong_typedef, но есть макрос BOOST_STRONG_TYPEDEF.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, WolfHound, Вы писали:

WH>>Вот только в С++ с этим проблем нет. Ибо деструкторы автоматические те за их вызовами следит компилятор.

VD>Гы-гы:
VD>

VD>class A
VD>{
VD>    A() { } // скрытый !!! :)
VD>public:
VD>    ~A()
VD>    {
VD>        printf("Goddammit! This is not supposed to happen!!!\n");
VD>    }
VD>};

VD>void main()
VD>{
VD>    for (int i = 0; i < 10; i++)
VD>        ((A*)&i)->~A();
VD>}
VD>

VD>И что самое поскудное — это же совершенно корректный код .

Страуструп говорит про такие случаи приблизительно так: C++ (в отличии от C89/-) защищает от случайного допущения ошибки, но не от преднамеренного жульничества.
P.S. Явный вызов деструктора это клиника, я бы не назвал это корректным кодом.

Здравствуйте, FDSC, Вы писали:

FDS>Нет. Компилятор должен мне вывести граф возможных ситуаций в программе, а я сам посмотрю, что можно, что нельзя.
В проекте на 10 метров кода будет тАкой граф...

FDS>Я же сказал, не всегда компилятор лучше — чем новее компилятор, тем лучше он оптимизирует код, но в некоторых частных случаях всё равно плохо компилирует. Поменьше читай рекламных сообщений. Кстати, времена исполнения помнить совсем не обязательно.
На gamedev.ru бал здоровый флейм на эту тему. Толпа народа пыталась обогнать интеловский компилятор. Ни у кого не получилось даже догнать. Делай выводы.

FDS>А, вот о чём! Согласен. Но в C++ нет некоторых возможностей Delphi — вот я и не могу перейти на него. Иначе бы все уже давно на Delphi плюнули.
На дельфе хорошо только формочки клепать. А как язык дельфи отстает от С++ по всем параметрам.
В принципе есть тандартная связка формочки на VB6 + inproc COM cerver на С++.
В место VB6 можно взять дельфи.

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

FDS>Как раз в "простых случаях" мне будет очень трудно сделать хороший код — это я знаю не понаслышке, возможно, даже отстану. Но в некоторых сложных — могу обогнать (главное — не забывайте надевать шлем).
Ну-ну...
FDS>Насчёт глобальных оптимизаций — мы сейчас говорим имеено об оптимизациях на исполнения машинных команд, а не алгоритмов. Было бы неплохо, если б компилятор ещё и глобальные оптимизации делал — между прочим, мне такие приходилось делать — вполне доступные для компилятора.
Оптимизаторы становятся все умнее и умнее. Тут гдето пробегал тест в котором VC++8 обогнал VC++6 в несколько раз...
А сейчас в недрах мелкософта создается очень интересный оптимизатор который можно будет расширять своими правилами.

S>>Код, сгенерированный компилятором Intel, ты будешь догонять месяцами. А изучая дизассемблернуый код, будешь периодически всплескивать руками и говорить "не может быть! Это должно работать медленнее, чем у меня".
FDS>Где это я его буду догонять, на своём AMD Athlon?
Ну код интеловского компилятори и на атлонах работает не плохо...

FDS>Много нового, насколько я помню, случилось в .NET. А в VS for Windows, если только мастера изменились. В прочем, может я что-то важное упустил?!
Ну да так по мелочи... довили язык до 98%ного соответствия стандарту, улучшели оптимизатор...

tarkil wrote:

> C>В С++ пишешь:
> C>typedef boost::strong_typedef<int> NumberOfSymbolInString;
> Любопытно... О какой версии буста идёт речь? В 1.30.2 ещё про
> strong_typedef ничего не слышно, а в 1.32.0 (которую только что
> скачал) нет класса boost::strong_typedef, но есть макрос
> BOOST_STRONG_TYPEDEF.

У меня копия из CVS. У BOOST_STRONG_TYPEDEF есть один недостаток — в нем
определен оператор присваивания из исходного типа.

Выглядит он так:

template<class T> struct strong_typedef : boost::totally_ordered1< 
strong_typedef<T> >
{
    T t;
    explicit strong_typedef(const T t_) : t(t_) {};
    strong_typedef(){};
    strong_typedef(const strong_typedef & t_) : t(t_.t){}
    strong_typedef & operator=(const strong_typedef & rhs) { t = rhs.t; 
return *this;}
    operator T () const {return t; }
    operator T & () { return t; }
    bool operator==(const strong_typedef & rhs) const { return t == rhs.t; }
    bool operator<(const strong_typedef & rhs) const { return t < rhs.t; }
};

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Cyberax, Вы писали:

C>Когда же прекратят издеваться над школьниками....

Что Вы имеете в виду?

Здравствуйте, Cyberax, Вы писали:

C>У меня копия из CVS. У BOOST_STRONG_TYPEDEF есть один недостаток — в нем
C>определен оператор присваивания из исходного типа.

И конструктор. И оператор приведения к исходному типу. Ай-яй-яй...

C>Выглядит он так:
C>

C>template<class T> struct strong_typedef : boost::totally_ordered1< 
C>strong_typedef<T> > ...
C>

У этого класса есть большой минус — больше одного псевдонима int не сделаешь. Наверное, лучше из BOOST_STRONG_TYPEDEF изъять левые методы.