C>>>Ну а если программист — идиот, и пишет:
C>>>

for(size_t f=0;f<vec.size();f++)

C>>>в time-critical коде, то его надо увольнять.

Q>>А можно узнать почему? А то я боюсь, что меня, идиота, скоро уволят.

A>Как минимум в этом цикле на каждый проход вызывается vec.size(), а это означает вычисление входной точки, сам вызов, жонглирование регистрами и стеком и т.п.

О уважаемый опытный программист! Должен вам заметить, не все то, после чего стоят скобки, является функцией, для которой вычисляется входная точка и выполняется жонглирование регистрами, стеком и т.п. Иногда попадаются inline-функции. А в СТЛ их подавляющее большинство. Попробуй ради любопытства построить свою программу с динамическим подключением msvcp и найди с помощью Depends.exe сколько функций импортирует из него твоя программа. Их будет не больше десятка. Остальные (в том числе и size) — инлайновые. И вообще, сдается мне что вы плохо представляете возможности современных оптимизаторов. Если он догадается, что размер вектора в цикле не меняется, то он будет получен один раз в начале цикла.

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

DB>> Именно пользовательский интерфейс определяет используемые алгоритмы и структуры даннных, а не наоборот.

P>А аргументировать слабо?

Ответ частично д Братику, частично комментарием на этот пост...

Нет, действительно, бывают такие рабочие условия, когда дизайнеры нарисовали мега-супер-пупер-интерфейс (графика прёт из всех углов, видео всякое крутится, окошки в форме звёздочек, а управлять ими можно одним движением мыши, БЕЗ щелчков)... Вот, нарисовали такое, а задача — воплотить этот изврат в жизнь.

Тогда, быть может (но всё равно СИЛЬНО сомневаюсь), и появится необходимость в особом языке, а С++ не покатит по сложности (именно по сложности /массивности/ языковой — нечего придумывать ему глюки, живущие только в собственной необученной голове).

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

Я вот завтра пересяду скриптить на РНР, а всем остальным аргументирую почему их компилируемые языки — отстой. Да хоть сейчас могу начать!

1. Будущее за веб! Настоящий программист пишет именно для веб.
2. Для веб писать на компилируемых языках очень сложно, и на всех платформах есть отличия!
3. Выделять память очень опасно, могут пролезть злые какеры.
4. И вообще, интерпретатор ПХП уже висит процессом, а обычную программу ещё грузить.
5. В ваших Сях и Дельфах нет значка "$" перед переменной, а это опасно ошибками в программе!
6. РНР появился позже С++ и Паскаля, т.е. он совершеннее.
7. И хотел бы я посмотреть на ваших сях и дельфях на операции с массивами! Маразм!!!!
8. И строгая типизация не прокатит, а вдруг война и все типы надо поменять?
9. ....
....
N. Короче, настоящие программисты пишут на РНР.

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

Q>О уважаемый опытный программист! Должен вам заметить, не все то, после чего стоят скобки, является функцией, для которой вычисляется входная точка и выполняется жонглирование регистрами, стеком и т.п. Иногда попадаются inline-функции. А в СТЛ их подавляющее большинство. Попробуй ради любопытства построить свою программу с динамическим подключением msvcp и найди с помощью Depends.exe сколько функций импортирует из него твоя программа. Их будет не больше десятка. Остальные (в том числе и size) — инлайновые. И вообще, сдается мне что вы плохо представляете возможности современных оптимизаторов. Если он догадается, что размер вектора в цикле не меняется, то он будет получен один раз в начале цикла.

Уважаемый язвительный Верхний Ряд Клавиатуры! Во-первых, inline-код выполняется всё равно дольше одной операции сравнения. Во-вторых, на оптимизатор надейся, а сам не плошай. Может, я и правда так плохо знаю возможности современного оптимизатора, но я не стал бы давать гарантию, что он осознает необходимость вызвать size() один раз, особенно с учётом обращения где-то в цикле к тому же vec. Более того — оптимизаторов много. И более того — я бы не стал за счёт оптимизатора отвыкать думать.

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

K>Ещё один недостаток (фича!) — это нелогичное поведение функции, когда для разных, но равных по сумме пар a и b, возвращается разное среднее арифметическое.

K>P.S. Впрочем всё это пустое, т.к. врядли в реальном проекте встретится функция типа int kaka (int a, int b){return (a+b)/2;}
Согласен простое деление с положительным остатком когда m/n = kn + r где r >= 0 спасает

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

Ш>Это слишком дорого и неудобно. Начнем с того, что такого понятия как переполнение в арифметике по модулю вообще не существует. И если я использую тип unsigned для вычислений по модулю 2^..., то мне эти исключения нафик не упали. В тех же случаях, когда переполнения должны быть учтены (яркий пример -- реализация длинной арифметики), это гораздо удобнее и эффективнее сделать имея на руках бит C. Исключения тут никак не катят.

Неудобно в С++, но не в C# и Java. Речь о переполнении в арифметике по модулю не шла. И опять-таки — насчёт эффективности. Мне вполне хватает.
P.S. Каждый остался при своём мнении

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

A>Как минимум в этом цикле на каждый проход вызывается vec.size(), а это означает вычисление входной точки, сам вызов, жонглирование регистрами и стеком и т.п.

Это ещё можно стерпеть. Я вот видел такое

while (list.size() > 0)
{
  // Обрабатываем и выкидываем по одному из очереди
}

И парень не дурак писал. Просто он старый дельфист. И это очень важное замечание.
Дело вот в чём. Программисты на С++ быстро приучаются к тому, что для работы с чем либо нужно сначала досконально изучить предмет, заглянуть "под капот", набить руку и потом за час написать. Код в итоге получается быстрый, красивый, но... дорогой и долгий. Часто очень дорогой и неприемлимо долгий для заказчика.
Матёрым же дельфийцам хватает пары часов, чтобы разобраться с первый раз увиденной либой. Да, у него exe-шник в 7 раз больше. Да грузится дольше. Да, работает чуть медленнее. Зато стоит не 5000$ а 1500$. Остальное заказчик с удовольствием потратит на новый проц, память и диск.

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

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

DB>Подозреваю, что Вы никогда не создавали на C++ развитого GUI. Все программисты на С++ как чумы избегают решения этой задачи. Они говорят, что это им скушно и неинтересно. Однако именно создание пользовательского интерфейса является наиболее важной, сложной и действительно интересной проблемой при создании системы. Именно пользовательский интерфейс определяет используемые алгоритмы и структуры даннных, а не наоборот. И именно для решение этой самой насущной задачи меньше всего подходит С++.

что-то я наверное совсем уже правильно понимать стал этот топик — там болдом выделено. это как вообще?? если я использую в ГУИ два лист-бокса для отображения каких-то данных, то я по такому определению должен заводить у себя два стринг массива что ли?? и все алгоритмы писать над строками, в них хранящихся?? это маразм, имхо, — каким образом и почему ГУИ вообще должен быть както определять внутреннюю реализцаию ?? "патаму шта из map не могу получить ключи" — не катит — нада както мочь это делать.

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

Вот и я думаю, че они избегают-то?
Тов. настоящие программисты, вы че избегаете?

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

N>Здравствуйте, d Bratik, Вы писали:

N>Вот и я думаю, че они избегают-то?
N>Тов. настоящие программисты, вы че избегаете?
Они не настоящие — они только прикидываются

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

AE>>12. За отсутствие менеджера конфигураций. Так чтобы сделать Debug и Release хотябы, и пользоваться просто переключая их.

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

Да меня не скорость и размер волнуют — просто в Debug-версии нужны особые фичи отладки например, что можно на уровне "IFDEF" выбросить из релиза. Так и делаю, о приходится вручную менять список CONDITIONS, а есть нежелательный "человеческий фактор".

AE>>14. За то что ошибочная работа встроенных функций ведет к генерированию исключения, а не возврату кода ошибки. При этом во многих случаях приходится писать просто try ... except end; чтобы пропустить эту фичу.
ABS>так нынче модно

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

DB>Однако у меня все-таки есть некоторые сомнения по поводу того, что программа также хорошо выглядит в среде Solaris (на Sun-ах) и в среде Linux. Неужели и на солярке у Вас такие же красивые настраиваемые панельки инструментов? Я полазил по сайтам Stingray и MainSoft и не нашел там никаких билиотек визуальных компонентов для Sun Solaris.

Компоненты под всеми платформами одни и те же и выглядит все одинаково. Фишка не в спец. компонентах под Solaris, а в том, что MainSoft предоставляет софт, который позволяет испольнять MFC-ые приложения (включая Stingray) под Solaris-ом.

DB>Можно ли как-нибудь получить Ваш e-mail, чтобы поговорить подробнее?

Боюсь, что не получится ввиду того, что

1) портированием GUI-я занимаюсь не я.
2) есть соглашение о не разглашении.

Советую писать письма пряма в MainSoft. Только учтите, что решения от MainSoft-а больших денег стоят

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

C>>А GUI уже стал пупом Вселенной?

DB>Нет, просто мерилом истинности.

Старинная мужская забава программистов — мерять гуи

d Bratik пишет:

> Для меня откровение, что автор языка делает компилятор, не
> специфицировав синтаксис, не понимая проблем построения оптимизаторов
> и системного ПО.

Ссылку документ, где Страуструп в этом признается.

> C>И эти люди потом говорят про "компонентное программирование"....
> Компонентное программирование — это расширение функциональности без
> перекомпиляции. Разработчики шаблонов С++ видимо не понимали, какую
> это имеет ценность.

Они зато понимали ценность обобщенного программирования. А компонентные
программирование к отсутствию перкомпиляции большого отношения не имеет.

> C>Страуструп во время разработки компилятора вел параллельное подробное
> C>формальное описание языка. Ну а то что С++ не был разработан сразу и с
> C>нуля, а эволюционировал — это его достоинство (в отличие от
> непрактичных
> C>поздних творений Вирта).
> Не упоминайте имя великого мастера всуе.

Это клиника...

> C>Для тупых: std::map — это индексированная таблица, std::vector — это
> C>"массив", а std::hash_map — это хэш-таблица.
> Согласен, это для тупых

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

>>> Хэш-таблицы в STL плохие, своя "заточенная" реализация всегда
>>> уделывает стандартную, а отказ от шаблонов позволяет минимизировать
>>> двоичный код.
> C>Чем они плохие?
> Медленые

С чего бы? Всякие uBLAS с Фортраном по скорости почти сравниваются. А
вот полиморфные коллекции — дейстивительно медленные.

> приводят к дублированию кода.

Не больше чем нужно.

>>> Я уже молчу о том, что отсутствие контроля выхода за диапазоны делают
>>> класс vector полность бесполезным при создании API для расширения
>>> своей системы третьими разработчиками.
> C>Почему? (про vector::at я даже согласен на время забыть).
> Потому, что ошибка пользователя приводит к фатальным последствиям.

Так кто мешает руками проверять границы? Или еще можно заставить
пользователя использовать не обращение по индексу, а использовать
vector::at. Ну а с помощью константности я исключу еще больше ошибок.

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

> Странно, что это нужно объяснять. Вы когда-нибудь делали
> plugin-интерфейс к своей программе?

Прямо сейчас прилаживаю addin'ы....

>>> C>в поиске...
>>> Gadgets (Oberon), VCL (Delphi), FCL (.NET). К сожалению все это далеко
>>> от С++.
> C>Они _НЕ_ thread-safe!
> Они обеспечивают создание thread-safe кода.

Еще раз медленно: они *НЕ* являются потокобезопасными. Желающие могут
попробовать в VCL запустить поток и поманипулировать в нем данными в
окне другого потока.

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

qwertyuiop пишет:

> C>Ну а если программист — идиот, и пишет:
>
>for(size_t f=0;f<vec.size();f++)
>
> C>в time-critical коде, то его надо увольнять.
> А можно узнать почему? А то я боюсь, что меня, идиота, скоро уволят.

Надо писать так:

size_t max=vec.size();
for(size_t f=0;f<max;f++)

Хотя большинство компиляторов и сами дооптимизируют до такого состояния,
но лучше все-таки перестраховаться.

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

Nose пишет:

> Вот и я думаю, че они избегают-то?
> Тов. настоящие программисты, вы че избегаете?

Закрытых библиотек и систем (т.е. с недоступными сырцами). Еще не очень
люблю динамические языки.

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

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

A>И более того — я бы не стал за счёт оптимизатора отвыкать думать.

Позволю напомнить три вещи
— Premature optimization is a root of evil. Дейкстра.
— Асимптотики сложности алгоритмов. vector::size() — O(1), и не такой уж здоровый у него коэффициент на фоне остального тела цикла.
— Профайлер.

Кодт пишет:

> A>И более того — я бы не стал за счёт оптимизатора отвыкать думать.
> Позволю напомнить три вещи
> — Premature optimization is a root of evil. Дейкстра.
> — Асимптотики сложности алгоритмов. vector::size() — O(1), и не такой
> уж здоровый у него коэффициент на фоне остального тела цикла.
> — Профайлер.

Я же написал: "time-critical"

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

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

>> A>И более того — я бы не стал за счёт оптимизатора отвыкать думать.
>> Позволю напомнить три вещи
>> — Premature optimization is a root of evil. Дейкстра.
>> — Асимптотики сложности алгоритмов. vector::size() — O(1), и не такой
>> уж здоровый у него коэффициент на фоне остального тела цикла.
>> — Профайлер.

C>Я же написал: "time-critical"

"Я же написал" — асимптотики сложности.
Если в обработчике прерывания выполнять цикл O(N), то не пофиг ли, будет размер вычислен единожды или на каждой итерации?
А если ну совсем никак, и нужно из кисоньки выжать капельку — то профайлер. Вдруг выяснится, что главный тормоз происходит, например, на блокировке критической секции, которой пользуются обработчик и основной поток. Отсюда последуют выводы о перепроектировании, и в меньшей степени — о переписывании.

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

DB>>Однако у меня все-таки есть некоторые сомнения по поводу того, что программа также хорошо выглядит в среде Solaris (на Sun-ах) и в среде Linux. Неужели и на солярке у Вас такие же красивые настраиваемые панельки инструментов? Я полазил по сайтам Stingray и MainSoft и не нашел там никаких билиотек визуальных компонентов для Sun Solaris.

_O_>Компоненты под всеми платформами одни и те же и выглядит все одинаково. Фишка не в спец. компонентах под Solaris, а в том, что MainSoft предоставляет софт, который позволяет испольнять MFC-ые приложения (включая Stingray) под Solaris-ом.

Я потом так и понял. Наверное практически все Ваши закачики сидят на Windows, а версия для Solaris делается для проформы (заказчиков можно по пальцам пересчитать).

DB>>Можно ли как-нибудь получить Ваш e-mail, чтобы поговорить подробнее?

_O_>Боюсь, что не получится ввиду того, что

_O_>1) портированием GUI-я занимаюсь не я.
_O_>2) есть соглашение о не разглашении.

_O_>Советую писать письма пряма в MainSoft. Только учтите, что решения от MainSoft-а больших денег стоят

И на том спасибо.

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

C>qwertyuiop пишет:

>> C>Ну а если программист — идиот, и пишет:
>>
>>for(size_t f=0;f<vec.size();f++)
>>
>> C>в time-critical коде, то его надо увольнять.
>> А можно узнать почему? А то я боюсь, что меня, идиота, скоро уволят.

C>Надо писать так:
C>

C>size_t max=vec.size();
C>for(size_t f=0;f<max;f++)
C>

C>Хотя большинство компиляторов и сами дооптимизируют до такого состояния,
C>но лучше все-таки перестраховаться.

Правильно писать именно так:
for(size_t i=0; i < vec.size(); ++i)
{
}

Чтобы понять, почему, рекомендую почитать вот это:
http://www.cas.mcmaster.ca/~emil/publications/reentrance