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

C>Более 15 лет пишу деловой и системный софт на С++ для Windows и Unix (Linux).

Аналогично.

C>Перечисленные проблемы никогда не были важными.

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

C>Исходя из своего опыта: у настоящих программистов другие проблемы.

Интересно, какие же?

C>P.S.:
C>С уважением отношусь к Delphi и C++ Builder,
C>но не встречал среди коллег, использующих данное ПО,
C>проектов хотя бы в 100 тысяч строк кода.
C>Согласитесь, весьма небольшой объем.

А я видел. Да и Вы видели — вспомните про многочисленые библиотеки компонентов к Delphi и C++ Builder. Хотя суть не в этом. В этих системах нет нужды в таком огромном количестве строк прикладного кода. Прикладные системы, основанные на них, получаются лаконичными, поскольку все необходимые вещи уже заложены в фундамент (в язык) и нет нужды загромождать свое решение кучей системного мусора.

C>P.P.S.:
C>К сожалению, Borland практически перестал развивать линию C++,
C>хотя, на мой взгляд, вплоть до Borland C++ 4.0, это был
C>лучший компилятор.

Проблема Borland, как и многих других програмистских фирм, в неправильной системе ценнностей. Большинство директоров этих фирм не понимают очевидной вещи — фирма — это ее ключевые компетенты, а не менеджмент, маркетинг, слоганы, бизнес-планы, техническая политика, технологии, процессы, ISO, CRM, бла-бла-бла. Поэтому с потерей Андерса Хайльсберга (и других) фирма Borland утратила свое лидерство и авторитет.

А нынешний успех M$ (и .NET) определяется именно переосмыслением роли личности в истории. Ее лозунг -- "кадры решают все", поэтому она вместо покупки успешных фирм скупает (уже скупила) всех их лучших специалистов и дает им право полностью определять и тактику, и стратегию и вообще управлять их бизнесом. Я никогда не симпатизировал MS до тех пор, пока в ней не появились такие люди, как Хайльсберг.

Я отвлекся от темы? Нет. Это имеет прямое отношение к тому, почему настоящие программисты (такие как Вирт, Хайльсберг и др ) избегают С++.

d Bratik пишет:

> C>Перечисленные проблемы никогда не были важными.
> Подозреваю, что Вы никогда не создавали на C++ развитого GUI.

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

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

QT, GTK, MFC.... 99% виндового софта, написанного на С++... ...FireFox....

Нет, не делают С++-программисты нормальных GUI — только НАСТАЯЩИЕ пацаны
делают GUI, и только на Дельфи.

> C>P.S.:
> C>С уважением отношусь к Delphi и C++ Builder,
> C>но не встречал среди коллег, использующих данное ПО,
> C>проектов хотя бы в 100 тысяч строк кода.
> C>Согласитесь, весьма небольшой объем.
> А я видел. Да и Вы видели — вспомните про многочисленые библиотеки
> компонентов к Delphi и C++ Builder.

Подчеркиваю _один_ продукт в 100 LOC.

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

Да, да, да. Поэтому от Дельфовых программистов и получаем все время
уродцев типа "Рассчета налогов", "Электронной бухгалтерии" и т.п.

У меня такой критерий: 99% _КАЧЕСТВЕННЫХ_ программ с богатым GUI
написаны именно на С++. На Дельфе я знаю только одну такую — TheBat!.

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

d Bratik пишет:

> А Вы интересовались, что в своей жизни сделал этот господин? За
> разработку языка взялся человек, который не сделал ни одной системы и
> не написал толком ни одного компилятора.

Ага, а что ТЫ сделал, чтобы его так критиковать? Можно ссылку на список
твоих международных премий?

> Его "компилятор" это front-end — препроцессор в С, причем не из
> нынешнего С++ с его шаблонами, а из старого С++, в котором кроме
> виртуальных методов, наследования классов и атрибутов
> public/protected/private больше ничего и не было.

Так потому и не было, что один человек фактически писал. Причем
компилятор С++ писался на самом С++.

> Даже компилятор до конца не довел, занимается каким-то
> консультированием... теоретик...

Может потому что уже не было смысла писать все одному?

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



> STL — полная лажа, годится только для быстрого клепания демо версий
> консольных программ.

)))))))))))))))))) Ага, дельфийские коллекции — верх совершенства.

Кстати, а как связаны STL и GUI????

> Qt (лучшая кросплатформенная библиотека визуальных компонентов на С++)
> — гадость — нет никакой защиты от исключений, нет нормальной
> многопоточности в GUI

Найди мне хоть одну распространенную thread-safe библиотеку GUI. Успехов
в поиске...

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

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

C>d Bratik пишет:

>> C>Перечисленные проблемы никогда не были важными.
>> Подозреваю, что Вы никогда не создавали на C++ развитого GUI.

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

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

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

C>QT, GTK, MFC.... 99% виндового софта, написанного на С++... ...FireFox....

Что из перечисленного Вы лично знаете достаточно глубоко и сами использовали в крупных проектах?

C>Нет, не делают С++-программисты нормальных GUI — только НАСТАЯЩИЕ пацаны
C>делают GUI, и только на Дельфи.

>> C>P.S.:
>> C>С уважением отношусь к Delphi и C++ Builder,
>> C>но не встречал среди коллег, использующих данное ПО,
>> C>проектов хотя бы в 100 тысяч строк кода.
>> C>Согласитесь, весьма небольшой объем.
>> А я видел. Да и Вы видели — вспомните про многочисленые библиотеки
>> компонентов к Delphi и C++ Builder.

C>Подчеркиваю _один_ продукт в 100 LOC.

Да, и не один такой продукт.

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

C>Да, да, да. Поэтому от Дельфовых программистов и получаем все время
C>уродцев типа "Рассчета налогов", "Электронной бухгалтерии" и т.п.

C>У меня такой критерий: 99% _КАЧЕСТВЕННЫХ_ программ с богатым GUI
C>написаны именно на С++. На Дельфе я знаю только одну такую — TheBat!.

d Bratik пишет:

>>> C>Перечисленные проблемы никогда не были важными.
>>> Подозреваю, что Вы никогда не создавали на C++ развитого GUI.
> C>А GUI уже стал пупом Вселенной?
> Нет, просто мерилом истинности.

Еще недавно больше всего софта было написано на Коболе

> C>QT, GTK, MFC.... 99% виндового софта, написанного на С++...
> ...FireFox....
> Что из перечисленного Вы лично знаете достаточно глубоко и сами
> использовали в крупных проектах?

Все. Проблемы возникали, естественно, но ни одна из них не была по
причине языка.

>>> А я видел. Да и Вы видели — вспомните про многочисленые библиотеки
>>> компонентов к Delphi и C++ Builder.
> C>Подчеркиваю _один_ продукт в 100 LOC.
> Да, и не один такой продукт.

Неужели целых ДВА??? Ссылки в студию....

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

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

BiТ>Здравствуйте, Кодт, Вы писали:

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

К>>>>Во-первых, про исключения при переполнении. А не пофиг ли, что будет исключение? Ведь факт переполнения можно выявить и другим способом,

K_O>>>Каким?

К>>Проверками предусловий, однако.

BiТ>А не логичнее(в таких языках как Java, C#) следующее:
BiТ>1)позволить переполнению произойти
BiТ>2)перехватить исключение и обернуть в свое исключение — однозначно идентифицирующее место возникновения
BiТ>3)внешний код разруливает ситуацию по своему усмотрению( в моих задачах это запись в журнал ошибок с детальной информацией о произошедшем и окончание вычислительной сессии с немедленным приведением системы в максимально безопасное логическое состояние && (в зависимости от режима работы, если в режиме реальной эксплуатации — создание новой вычислительной сессии, получение новой порции данных и их обработка, иначе если это отладочный режим — шотдаун и последующий разбор полётов).
BiТ>?

Гораздо логичнее и правильнее было бы возвращать бит C по требованию. Т.е. (для беззнаковых чисел)

struct Sum
 {
  unsigned sum;
  bool c;    
    
  operator unsigned() const { return sum; }
 };
 
Sum operator + (unsigned,unsigned); // встроенный в язык оператор

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

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

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

>> А Вы интересовались, что в своей жизни сделал этот господин? За
>> разработку языка взялся человек, который не сделал ни одной системы и
>> не написал толком ни одного компилятора.

C>Ага, а что ТЫ сделал, чтобы его так критиковать? Можно ссылку на список
C>твоих международных премий?

Для того, чтобы разбираться в музыке вовсе не нужно быть мировым композитором. Поэтому повернем вопрос в другую плоскость — кто же тогда может быть авторитетом. Отвечаю — Вирт, Хайльсберг и их единомышленники. Вирт с Хайлсбергом (отдельно друг от друга) сделали и язык, и компилятор, и платформу, и библиотеку визуальных компонентов, и среду разработки, и многое другое.

>> Его "компилятор" это front-end — препроцессор в С, причем не из
>> нынешнего С++ с его шаблонами, а из старого С++, в котором кроме
>> виртуальных методов, наследования классов и атрибутов
>> public/protected/private больше ничего и не было.

C>Так потому и не было, что один человек фактически писал. Причем
C>компилятор С++ писался на самом С++.

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

>> Даже компилятор до конца не довел, занимается каким-то
>> консультированием... теоретик...

C>Может потому что уже не было смысла писать все одному?

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



>> STL — полная лажа, годится только для быстрого клепания демо версий
>> консольных программ.

C>)))))))))))))))))) Ага, дельфийские коллекции — верх совершенства.

А что Вы тут разговор переводите на дельфийские коллекции? Я их в пример не ставил. Но уж если речь зашла, то они сделаны отлично, в расчете на использование в GUI. В них решена проблема перехвата уведомлений о вставке/удалении элементов, а также проблема повторной входимости. Я досконально изучал их работу при создании своих коллекций на С++.

C>Кстати, а как связаны STL и GUI????

Вот именно, что никак. Представьте, что у Вас есть программный интерфейс к своей системе (для создания plugin-ов и управления системой из скрипта) и в этом интерфейсе есть доступ к коллекциям. Так вот STL для этой задачи просто не годится. Коллекции STL вообще никуда не годятся ни по производительности (все версии STL, включая STLport), ни по гибкости, ни по безопасности. В высокопроизводительных программах нужны только массивы и хэш-таблицы. А все эти map-ы, set-ы и др. — баловство бездумное. Хэш-таблицы в STL плохие, своя "заточенная" реализация всегда уделывает стандартную, а отказ от шаблонов позволяет минимизировать двоичный код. Остается полезным лишь класс vector, который без маразмов тоже не обошелся. Например, во всех реализациях STL динамический массив внутри вектора представлен двумя указателями — указатель на первый элемент и указатель за последний элемент. Поэтому, самая частая операция, выполняемая с вектором, — получение количества элементов — всегда вичисляется как разность двух указателей. Вы мне скажите, что с вектором нужно работать с помощью итераторов, но пардон, вектор как раз нужен в программе из-за возможности адресации элементов по номеру и быстрого получения их количества. Я уже молчу о том, что отсутствие контроля выхода за диапазоны делают класс vector полность бесполезным при создании API для расширения своей системы третьими разработчиками.

>> Qt (лучшая кросплатформенная библиотека визуальных компонентов на С++)
>> — гадость — нет никакой защиты от исключений, нет нормальной
>> многопоточности в GUI

C>Найди мне хоть одну распространенную thread-safe библиотеку GUI. Успехов
C>в поиске...

Gadgets (Oberon), VCL (Delphi), FCL (.NET). К сожалению все это далеко от С++.

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

C>d Bratik пишет:

>>>> C>Перечисленные проблемы никогда не были важными.
>>>> Подозреваю, что Вы никогда не создавали на C++ развитого GUI.
>> C>А GUI уже стал пупом Вселенной?
>> Нет, просто мерилом истинности.

C>Еще недавно больше всего софта было написано на Коболе

Так С++ — это и есть современный Кобол. Однако во времена Кобола GUI не было.

>> C>QT, GTK, MFC.... 99% виндового софта, написанного на С++...
>> ...FireFox....
>> Что из перечисленного Вы лично знаете достаточно глубоко и сами
>> использовали в крупных проектах?

C>Все. Проблемы возникали, естественно, но ни одна из них не была по
C>причине языка.

А как Вы обходились без событий (указателей на методы), без try..finally и др.?

>>>> А я видел. Да и Вы видели — вспомните про многочисленые библиотеки
>>>> компонентов к Delphi и C++ Builder.
>> C>Подчеркиваю _один_ продукт в 100 LOC.
>> Да, и не один такой продукт.

C>Неужели целых ДВА??? Ссылки в студию....

Что Вам скажут названия продуктов, которых Вы не видели? Ничего, поэтому приведу тех два продукта, которые Вы можете сами установить и посмотреть: Delphi, C++Builder.

d Bratik пишет:

>>>>> C>Перечисленные проблемы никогда не были важными.
>>>>> Подозреваю, что Вы никогда не создавали на C++ развитого GUI.
>>> C>А GUI уже стал пупом Вселенной?
>>> Нет, просто мерилом истинности.
> C>Еще недавно больше всего софта было написано на Коболе
> Так С++ — это и есть современный Кобол. Однако во времена Кобола GUI
> не было.

Современный КОБОЛ — это Java (кстати, больше всего компаний мигрируют с
Кобола именно на Яву). А [G]UI во времена КОБОЛа очень даже был.

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

> C>Все. Проблемы возникали, естественно, но ни одна из них не была по
> C>причине языка.
> А как Вы обходились без событий (указателей на методы), без
> try..finally и др.?

1. Указатели на методы вовсе необязательны для организации событий.
Смотри Swing в Java или WndProc в Винде.
2. Кто сказал, что в С++ нет указателей на методы?
3. try..finally мне успешно заменяют деструкторы и ON_BLOCK_EXIT из
Александреску.
4. Если сам не можешь (или не знаешь) обойтись без фичи ххх — это не
значит, что и другие не могут.

>>> Да, и не один такой продукт.
> C>Неужели целых ДВА??? Ссылки в студию....
> Что Вам скажут названия продуктов, которых Вы не видели? Ничего,
> поэтому приведу тех два продукта, которые Вы можете сами установить и
> посмотреть: Delphi, C++Builder.

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

Ссылки на крупные OpenSource продукты на С++, я думаю, приводить здесь
не надо.

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

d Bratik пишет:

> C>Ага, а что ТЫ сделал, чтобы его так критиковать? Можно ссылку на список
> C>твоих международных премий?
> Для того, чтобы разбираться в музыке вовсе не нужно быть мировым
> композитором. Поэтому повернем вопрос в другую плоскость — кто же
> тогда может быть авторитетом. Отвечаю — Вирт, Хайльсберг и их
> единомышленники. Вирт с Хайлсбергом (отдельно друг от друга) сделали и
> язык, и компилятор, и платформу, и библиотеку визуальных компонентов,
> и среду разработки, и многое другое.

Прекрасно, тогда обосновывай свои слова ссылками на этих деятелей....

> C>Так потому и не было, что один человек фактически писал. Причем
> C>компилятор С++ писался на самом С++.
> Это не был полноценный компилятор, это был препроцессор.

И что? Для тебя будет откровением, что _до_ _сих_ _пор_ многие языки
компилируются через С (compile via C). Таким обазом переиспользуется
существующая система. Кстати, даже компилятор С/C++ в GCC — это просто
препроцессоры, переводящие языки в RTL (Register Transfer Language). А
RTL потом препроцессится в машинный код (с помощью специального
шаблонного языка).

И эти люди потом говорят про "компонентное программирование"....

> Причем, даже этот убогий компилятор создавался при отсутствии
> формальной спецификации синтаксиса!

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

>>> STL — полная лажа, годится только для быстрого клепания демо версий
>>> консольных программ.
> C>)))))))))))))))))) Ага, дельфийские коллекции — верх совершенства.
> А что Вы тут разговор переводите на дельфийские коллекции? Я их в
> пример не ставил. Но уж если речь зашла, то они сделаны отлично, в
> расчете на использование в GUI.

)))))))))))))))))))))) )))) ROTFL............

> В них решена проблема перехвата уведомлений о вставке/удалении
> элементов, а также проблема повторной входимости. Я досконально изучал
> их работу при создании своих коллекций на С++.

Нда... Это уже в морг.

> C>Кстати, а как связаны STL и GUI????
> Вот именно, что никак. Представьте, что у Вас есть программный
> интерфейс к своей системе (для создания plugin-ов и управления
> системой из скрипта) и в этом интерфейсе есть доступ к коллекциям. Так
> вот STL для этой задачи просто не годится.

Почему (кроме вопросов ABI, в которых у Дельфт тоже проблемы)?

> Коллекции STL вообще никуда не годятся ни по производительности (все
> версии STL, включая STLport), ни по гибкости, ни по безопасности. В
> высокопроизводительных программах нужны только массивы и хэш-таблицы.
> А все эти map-ы, set-ы и др. — баловство бездумное.

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

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

Чем они плохие?

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

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

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

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

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

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

Почему? (про vector::at я даже согласен на время забыть).

> C>Найди мне хоть одну распространенную thread-safe библиотеку GUI.
> Успехов
> C>в поиске...
> Gadgets (Oberon), VCL (Delphi), FCL (.NET). К сожалению все это далеко
> от С++.

Они _НЕ_ thread-safe!

Из thread-safe библиотек я вспоминаю только ранний AWT в Java, однако
уже в Swing'е они отказались от потокобезопасности, и стали делать как
все — на основе очереди событий.

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

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

DB>Все эти "комментарии" лишний раз доказывают, что 99% всех программистов на С++ -- просто ламеры. Автор языка, кстати, попадает в эти 99%

А сам ты, "кул хацкер", для которого малейшее затруднение — нерешаемая проблемма.

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

C>d Bratik пишет:

>> C>Ага, а что ТЫ сделал, чтобы его так критиковать? Можно ссылку на список
>> C>твоих международных премий?
>> Для того, чтобы разбираться в музыке вовсе не нужно быть мировым
>> композитором. Поэтому повернем вопрос в другую плоскость — кто же
>> тогда может быть авторитетом. Отвечаю — Вирт, Хайльсберг и их
>> единомышленники. Вирт с Хайлсбергом (отдельно друг от друга) сделали и
>> язык, и компилятор, и платформу, и библиотеку визуальных компонентов,
>> и среду разработки, и многое другое.

C>Прекрасно, тогда обосновывай свои слова ссылками на этих деятелей....

>> C>Так потому и не было, что один человек фактически писал. Причем
>> C>компилятор С++ писался на самом С++.
>> Это не был полноценный компилятор, это был препроцессор.

C>И что? Для тебя будет откровением, что _до_ _сих_ _пор_ многие языки
C>компилируются через С (compile via C). Таким обазом переиспользуется
C>существующая система. Кстати, даже компилятор С/C++ в GCC — это просто
C>препроцессоры, переводящие языки в RTL (Register Transfer Language). А
C>RTL потом препроцессится в машинный код (с помощью специального
C>шаблонного языка).

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

C>И эти люди потом говорят про "компонентное программирование"....

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

>> Причем, даже этот убогий компилятор создавался при отсутствии
>> формальной спецификации синтаксиса!

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

Не упоминайте имя великого мастера всуе.

>>>> STL — полная лажа, годится только для быстрого клепания демо версий
>>>> консольных программ.
>> C>)))))))))))))))))) Ага, дельфийские коллекции — верх совершенства.
>> А что Вы тут разговор переводите на дельфийские коллекции? Я их в
>> пример не ставил. Но уж если речь зашла, то они сделаны отлично, в
>> расчете на использование в GUI.

C>)))))))))))))))))))))) )))) ROTFL............

>> В них решена проблема перехвата уведомлений о вставке/удалении
>> элементов, а также проблема повторной входимости. Я досконально изучал
>> их работу при создании своих коллекций на С++.

C>Нда... Это уже в морг.

>> C>Кстати, а как связаны STL и GUI????
>> Вот именно, что никак. Представьте, что у Вас есть программный
>> интерфейс к своей системе (для создания plugin-ов и управления
>> системой из скрипта) и в этом интерфейсе есть доступ к коллекциям. Так
>> вот STL для этой задачи просто не годится.

C>Почему (кроме вопросов ABI, в которых у Дельфт тоже проблемы)?

>> Коллекции STL вообще никуда не годятся ни по производительности (все
>> версии STL, включая STLport), ни по гибкости, ни по безопасности. В
>> высокопроизводительных программах нужны только массивы и хэш-таблицы.
>> А все эти map-ы, set-ы и др. — баловство бездумное.

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

Согласен, это для тупых

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

C>Чем они плохие?

Медленые, приводят к дублированию кода.

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

C>Операция вычитания двух указателей — пара тактов, а такое представление
C>позволяет облегчить многие другие операции.

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

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

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

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

C>Почему? (про vector::at я даже согласен на время забыть).

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

>> C>Найди мне хоть одну распространенную thread-safe библиотеку GUI.
>> Успехов
>> C>в поиске...
>> Gadgets (Oberon), VCL (Delphi), FCL (.NET). К сожалению все это далеко
>> от С++.

C>Они _НЕ_ thread-safe!

Они обеспечивают создание thread-safe кода.

C>Из thread-safe библиотек я вспоминаю только ранний AWT в Java, однако
C>уже в Swing'е они отказались от потокобезопасности, и стали делать как
C>все — на основе очереди событий.

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

Ш>Гораздо логичнее и правильнее было бы возвращать бит C по требованию. Т.е. (для беззнаковых чисел)

Ш>К сожалению, это затрагивает основы языка и вряд ли можно сейчас внедрить.

ИМХО — отнюдь не логичнее. Делается неявное допущение о том, что вызывающий код в случае необходимости будет проверять на переполнение после операции. А ИМХО — в случае переполнения, если для вызываемого кода это критично(а это критично в очень многих случаях) — нужно генерировать исключение, чтобы вызываемый код явным образом обрабатывал эту ситуацию.

Пара вариантов при условии, что округление ответа ближе к нулю:

С условным оператором:

int kaka (int a, int b){
   if ((a>0 && b>0) || (a<0 && b<0))
        return (a-b)/2+b;
    else {
        return (a+b)/2;
    }
}

Без условного оператора:

int kaka (int a, int b){
    return (a/2+b/2)+((a&1)&(b&1));
}

Здравствуйте, d Bratik.

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

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

Ш>>Гораздо логичнее и правильнее было бы возвращать бит C по требованию. Т.е. (для беззнаковых чисел)

Ш>>К сожалению, это затрагивает основы языка и вряд ли можно сейчас внедрить.

BiТ>ИМХО — отнюдь не логичнее. Делается неявное допущение о том, что вызывающий код в случае необходимости будет проверять на переполнение после операции. А ИМХО — в случае переполнения, если для вызываемого кода это критично(а это критично в очень многих случаях) — нужно генерировать исключение, чтобы вызываемый код явным образом обрабатывал эту ситуацию.

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

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

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

C>QT, GTK, MFC.... 99% виндового софта, написанного на С++... ...FireFox....
C>Нет, не делают С++-программисты нормальных GUI — только НАСТАЯЩИЕ пацаны
C>делают GUI, и только на Дельфи.
C>Да, да, да. Поэтому от Дельфовых программистов и получаем все время
C>уродцев типа "Рассчета налогов", "Электронной бухгалтерии" и т.п.

Ой, щас чувствую меня ногами запинают, но молчать не могу: как противовес всем этим дельфевым "Расчетам налогов" и пр. можно привести 1С, которая АФАИК целиком написана на VC++. Как говорится "почувствуйте разницу".

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

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

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

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

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


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

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

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

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

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

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

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

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