Здравствуйте, Xentrax, Вы писали:
X>Язык С++ — для того, чтобы решать проблемы язка, а нормальный язык должен быть создан для того чтобы решать проблемы предметной области.
X>И если вам и мне интересно заниматься этим, то нашим работодателям — нет.
Жаль пост не в философии. Оценка была бы больше. А так очень точные и локоничные слова. Полностью согласен. Вот только мне уже не интересно заниматься его проблемами.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Кодт, Вы писали:
К>>Здравствуйте, d Bratik, Вы писали:
DB>>>Проблема шалонов не хреновой читаемости, а в том, что они unsafe — невозможно указать ограничений (constraints) для параметров. Шаблонов в своих программах можно избегать. Без сборщика мусора трудно, но существуют подходы (например, концепция владения), которые позволяют обойтись без него. А вот без остального действительно туго.
К>>Не умеешь писать с шаблонами — так прямо и скажи.
VD>Ну, это голословные наезды. Я вот вроде немного умею, но, что шаблоны создают не мло проблем. Но тут хоть ясно за что платить.
К>>Констрейнты в шаблонах делаются с лёгкостью необычайной.
VD>Это уже даже за гранью спорности. Видимо ты плохо понимашь, что такое констрэйны.
VD>В С++ проверки делаются только во время воплощения шаблона. VD>Констрэйны же накладывают ограничения на параметры шаблона.
Ага. Как только эти два предложения противоречат друг другу я не понимаю.
И вообще, прежде чем возражать, ты бы что ли познакомился с Concеpt Check в бусте.
VD>Сдается мне, что в следующей версии стандарта констрэйны добавят обязательно.
А зачем? Во-первых, существующий язык позволяет их реализовать. Соответственно, нет жесткой необходимости встраивать их в язык/компилятор.
Во-вторых, острой необходимости в использовании констрейнов нет. Фактически, их главное назначение -- улучшить диагностику и более явно описать требования к шаблонным параметрам.
К>>Как именно — не скажу, тебе это всё равно не пригодится.
VD>О. А еще меня тут пинают за подколки и уколки.
Да нет, Кодт имеет ввиду, что ты с плюсов сбежал, так что зачем оно тебе?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Кодт, Вы писали:
К>>1) От компилятора: прекомпиляция заголовков К>>2) От программиста: идиома pimpl К>>И всё будет летать.
VD>Летает обычно яжыком. А по жизни серьезный проект (более 3 метров кода) компилруется от десяти минут, до часов.
VD>Но я бы назвал галвным недостатком отсуствия модульности невозможность полноценной компонентной разработки.
Ну не надо своё невежество выдавать за недостаток языка. Отлично и на С, и C++ делается компонетная разработка.
Хорошо известный всем пример -- FAR. Посторен очень компонентно и модульно. И расширяется независимыми разработчиками.
VD> Вот это куда более неприятно. Приходится прибегать к разным КОМ-ам, а они в С++ ой как долеки от нормального программирования.
COM -- это вообще из другой оперы. Для компонентной разработки он не нужен вообще. Он нужен для интеграции компонентов, написаных на разных языках. Для того, чтобы это было возможно, необходим бинарный стандарт на испольнямые модули/динамические библиотеки.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, d Bratik, Вы писали:
DB>>Сударь, код совершенно коректный: "для всех элементов кроме последнего". В случае пустого вектора код работает бесконечно. Для демонстрации проблемы можно было бы завернуть цикл от последнего элемента до первого:
DB>>
DB>>std::vector<int> v;
DB>>for (std::vector<int>::size_type i = v.size() - 1; i >= 0; ++i)
DB>>{
DB>> ...
DB>>}
DB>>
VD>Вот это пример хороший.
SWW>>>А если бы v.size() было знаковым, разве этот код работал бы?
DB>>Да, причем совершенно корректно.
VD>Нет, уж. Он работал бы только при орпеделенном содержимом тела цикла (если там удалять элементы).
Здравствуйте, d Bratik, Вы писали:
DB>Вы наверное писали очень небольшие программы, без GUI.
О великий и могучий прости меня — всю свою сознательную жизнь я писал большие программы без GUI и не знал, что это плохо. Я попробую написать одну хоть самую маленькую гуёвую программу, при условии, что ты пощадишь меня и снизайдёшь своей сияющей благотатью до такого недостойного представителя отряда программистов на С++ без гуя!
DB>Для создания программ С++ подходит, но для создания систем — нет.
Кстати, а чем системы отличаются от программ... А то я не знаю
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Здравствуйте, Xentrax, Вы писали:
X>Здравствуйте, d Bratik
X>На самом деле, не такой он и плохой. Хороший даже, вон сколько всего понаписали. Сидят такие русские и украинские Рсдновцы и пишут, пишут. Шаблоны всякие используют, бусты с стлпортами, всяческие хитрые менеджеры памяти придумывают. Люди книжки пишут, ну типа "10001 совет, как не свернуть себе шею, пытаясь использовать StlPort 4.6.2 в EVC 3.0.". Деньги зарабатывают.
С некоторыми утверждениями не согласен, но в целом вы правы — язык требует реформирования. В основном в том, что касается ужесточения некоторых требований, устранения ряда противоречий и двойственности и отказ от наследственности pure C. Конкретизировать не буду дабы не плодить флейм — эти темы поднимались не раз, кто читает ветки C++ и Философию, встречает похожие обсуждения регулярно.
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Re[11]: Почему настоящие программисты избегают C++
Здравствуйте, Кодт, Вы писали:
К>Здравствуйте, nixite, Вы писали:
N>>для любителей signed int'ов:
N>>положим захотелось нам искать среднее двух чисел и написали мы функцию: N>>int kaka (int a, int b){return (a+b)/2;}
К>Братику: К>Во-первых, про исключения при переполнении. А не пофиг ли, что будет исключение? Ведь факт переполнения можно выявить и другим способом, но от факта нам ни горячо, ни холодно. Нам нужна корректная обработка, чтобы результат был, а не отлуп на удивление пользователю.
К>Вариант ответа: К>
К>int mid(int a, int b)
К>{
К> return a/2 + b/2 + (a%2 + b%2)/2;
К>}
К>
Здравствуйте, Кодт, Вы писали:
К>Обелиск, мои поздравления! К>(Хотя лично у меня к UML Suite, кажется, 1999 года — очень большие претензии. Впрочем, тут могла быть обоюдная кривизна рук).
UML Suite был куплен Telelogic-ом. Ранее он назывался COOL:Jex/ObjectTeam.
Telelogic его не разрабатывал.
Здравствуйте, Kh_Oleg, Вы писали:
K_O>Здравствуйте, _Obelisk_, Вы писали:
_O_>>>>Пишу на С++ шесть лет и ни разу перечисленные проблемы не являлись для меня проблемами. DB>>>Вы наверное писали очень небольшие программы, без GUI. Для создания программ С++ подходит, но для создания систем — нет.
_O_>>Отнюдь. Я, к примеру, один из разработчиков вот этого : http://www.telelogic.com/products/tau/developer/index.cfm. (список поддерживаемых фич тут _O_>>http://www.telelogic.com/products/tau/developer/features.cfm). Продукт, включая GUI, полностью написан на С++. Работает под Win, Linux, Solaris.
K_O>Скриншоты можно увидеть?
Во, сделал:
Душа обязана трудиться! (с) Н.Заболоцкий.
Re[4]: Только настоящие программисты пишут на С++! :)
Здравствуйте, Шахтер, Вы писали:
Ш>COM -- это вообще из другой оперы. Для компонентной разработки он не нужен вообще. Он нужен для интеграции компонентов, написаных на разных языках. Для того, чтобы это было возможно, необходим бинарный стандарт на испольнямые модули/динамические библиотеки.
Ну ну. Для экспорта классов из dll значит бинарного стандарта не нужно.
А в Delphi, например, есть же скомпилированные модули (*.dcu), правда модуль, скомпилированный в одной версии нельзя использовать в другой. Но все равно, от наличия таких модулей больше пользы, чем вреда, причем намного больше.
Здравствуйте, d Bratik, Вы писали:
DB>Здравствуйте, _Obelisk_, Вы писали:
DB>>>Вы наверное писали очень небольшие программы, без GUI. Для создания программ С++ подходит, но для создания систем — нет.
DB>Сайт выглядит очень профессионально. Интересно было бы взглянуть на внешний вид самой программы, а также узнать, на чем она написана (Qt?), и поддерживает ли она расширение своей функциональности на каком-нибудь языке программирования.
Qt не использовалась. GUI базируется на библиотеках от Stingray + собственные разработки. Портирование GUI-я под Unix/Linux осуществляется с использованием продукттов MainSoft-а. Расширения лучше всего писать на С++.
Душа обязана трудиться! (с) Н.Заболоцкий.
Re[11]: Почему настоящие программисты избегают C++
Здравствуйте, Kubera, Вы писали:
K>Здравствуйте, nixite, Вы писали:
N>>для любителей signed int'ов:
N>>положим захотелось нам искать среднее двух чисел и написали мы функцию: N>>int kaka (int a, int b){return (a+b)/2;}
N>>и всё вроде тип-топ, но вот тут сунули нам два числа (вполне корректных):
N>>int a = 2113929216; N>>int b = 2113929210;
N>>и что? а какое решение-то простое есть? ассемблер в три команды не предлогать, всё на с++ N>>p.s. я решение знаю, но не сказал бы что оно простое
K>Проблема переполнения остаётся и при использовании беззнаковых целых. А для int в данном случае решение есть и простое (не сказал бы что красивое, но...). Приводим a и b к long long, а после деления обратно к int.
боже мой какой изврат для этого случая
int kaka(int a, int b)
{
return a/2 + b/2;
}
При любых значениях a и b переполнения не возникает правда могут возникнуть ошибки округления хорошо учитываем четность
int kaka(int a, int b)
{
return a/2 + b/2 + (a%2 + b%2)/2;
}
Здравствуйте, VladD2, Вы писали:
К>>Констрейнты в шаблонах делаются с лёгкостью необычайной.
VD>Это уже даже за гранью спорности. Видимо ты плохо понимашь, что такое констрэйны. В С++ проверки делаются только во время воплощения шаблона. Констрэйны же накладывают ограничения на параметры шаблона. Сдается мне, что в следующей версии стандарта констрэйны добавят обязательно.
Здравствуйте, migel, Вы писали:
M>При любых значениях a и b переполнения не возникает правда могут возникнуть ошибки округления хорошо учитываем четность M>
M>int kaka(int a, int b)
M>{
M> return a/2 + b/2 + (a%2 + b%2)/2;
M>}
M>
А так очень точные и локоничные слова. Полностью согласен. Вот только мне уже не интересно заниматься его проблемами.
правда могут возникнуть ошибки округления 
хорошо учитываем четность 
Перекуём баги на фичи!
