Почему настоящие программисты избегают C++
От: d Bratik  
Дата: 17.02.05 12:14
Оценка: 15 (7) +4 -38 :))) :))) :))) :))) :))) :))) :))) :))) :))) :))) :))) :))) :))) :))) :))) :))) :))) :))) :))) :))
1.Отсутствие модулей. Имитация понятия модуль в виде пары h-файл – cpp-файл приводит к многочасовым компиляциям системы.

2.Использование целочисленных типов данных без знака (unsigned int) для номеров элементов и количественных значений в стандартной библиотеке stdc++. Приводит к следующим ошибкам:

std::vector<int> v;
// Следующий код работает бесконечно, поскольку (size_type)(-1) == 4 млрд.
for (std::vector<int>::size_type i = 0; v.size() - 1; ++i)
{
  ...
}


3.Отсутствие встроенной проверки на выход за диапазоны массива. Приводит к необходимости писать «обертки» для классов-контейнеров (в частности, для класса vector).

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

5.«Автоматизм» конструкторов и деструкторов для объектов, создаваемых динамически и имеющих виртуальные методы; работа виртуальных методов как не виртуальных при их вызове из конструкторов и деструкторов; отсутствие стандартного базового класса. Значительно затрудняет решение проблемы повторного входа в объекты (reentrance problem) при создании библиотек визуальных компонентов и систем GUI.

6.Отсутствие оператора try {…} finally {…}. Приводит к созданию программ, неустойчивых к исключительным ситуациям. Попытка имитировать этот оператор с помощью оператора try {…} catch {…} приводит к большой избыточности кода.


17.02.05 15:33: Перенесено из 'C/C++'
Re[13]: Почему настоящие программисты избегают C++
От: ansi  
Дата: 18.02.05 08:12
Оценка: 80 (30) +2 :))) :))) :))) :))) :))) :))) :))) :))) :))) :))) :))) :))) :))) :))) :))
Настящии праграмисты ни пишут на плюсах, патаму што:
1) Настаящии прграмиры нифига ни петрят в указателях. Эта очинь сложна. К таму жи они видут к частым багам (и указатили тожи ). И ваще хрен знаит што я тут написал:
int a = 10;
(&a)[a&a+~(a|a)+1])=*(&a+(a&~a)*(a^a)*(~(int)&a-(0xFFFFFFFF–(int)&a)));


2) У ниво слишкам многа всяких закарючик (сматри выше) вместа таких панятных слов как then, begin, end, and, or, not, .... Фик разбирешь што сам только што написал.

3) Я уш ни гаварю пра всякие праверки выхада за придел масива, исключения при пирипалнении. Если ни делать таких праверак, то прога ни будит карректно работать.

4) Такой код ни работаит для 2113929216 и 2113929210:
int mval(int a, int b) {
   return (a+b)/2;
}


5) Там есть биззнакавыи целыи, паэтаму мой код ни работаит. А са знакавыми он тожи не работаит, патаму шта пирипалнение праисходит.

6) И ваще, шаблоны – ацтой, патаму шта у них нет канстрайнтав.

7) И ваще, плюсы – ацтой, патаму шта я ни умею них писать


Настаящии праграмисты ни пишут на диезах, патаму што:
1) Там нет указатилей. Эта аграничиваит миня, ни дает мне полнава кантроля над ситуацией. А я крутой праграмер! Я умею писать указатили. Сматрити, што я магу на плюсах:
int a = 10;
(&a)[a&a+~(a|a)+1])=*(&a+(a&~a)*(a^a)*(~(int)&a-(0xFFFFFFFF–(int)&a)));


2) Я уш ни гаварю пра всякие праверки выхада за придел масива, исключения при пирипалнении. Если делать такии праверки, то прога будит очинь сильна тармазить.

3) Там нет шаблонав. Шаблоны – эта крута!

4) Такой код ни работаит для 2113929216 и 2113929210:
int mval(int a, int b) {
   return (a+b)/2;
}


5) Там есть биззнакавыи целыи, паэтаму мой код ни работаит. А са знакавыми он тожи не работаит, патаму шта пирипалнение праисходит.

6) И ваще он ни кампилируица, а интырпритируица. Карочи тармазит.

7) И ваще, диезы – ацтой, патаму шта ани ат мелкасофта.


Настаящии праграмиры ни пишут на паскалях, патаму шта:
1) Там очинь глупыи и никрасивыи указатили. Сматити, што я магу на плюсах:
int a = 10;
(&a)[a&a+~(a|a)+1])=*(&a+(a&~a)*(a^a)*(~(int)&a-(0xFFFFFFFF–(int)&a)));

Лучши бы их вабще убрали...

2) Накаляит писать пастаянна :=, then, begin, end, and, or, not, div, mod, .... Сматити выши как эта можна сделать на плюсах. И низя абъявить пирименную, где захочишь.

3) Я уш ни гаварю пра всякие праверки выхада за придел масива, исключения при пирипалнении. Если делать такии праверки, то прога будит очинь сильна тармазить. А если их ни делать, то прога ни будит карректно работать.

4) Там нет шаблонав. Шаблоны – эта крута!

5) Там есть биззнакавыи целыи, паэтаму мой код ни работаит. А са знакавыми он тожи не работаит, патаму шта пирипалнение праисходит.

6) Такой код ни работаит для 2113929216 и 2113929210:
function mval(a, b: Integer): Integer;
begin
   Result := (a+b) div 2;
end;


7) И ваще, паскали (ни путать с маскалями!) – ацтой, патаму шта ани жрут многа места и гинирируют многа retав.


Карочи, чиста канкретныи риальныи програмиры ваще ни на чем ни пишут. Ани тока пиво пьют и чипцы жрут!!!
Re: Почему настоящие программисты избегают C++
От: Amidlokos Россия  
Дата: 17.02.05 13:43
Оценка: 22 (8) :))) :))) :))) :))) :))) :))) :))) :))) :))) :))) :))) :))) :))
Здравствуйте, d Bratik, Вы писали:

Я поставил -1. Но ты, при желании, легко можешь преобразовать это значение в четыре миллиарда
WARNING: expression "to_be || !to_be" is always true
Re[2]: Почему настоящие программисты избегают C++
От: d Bratik  
Дата: 17.02.05 12:37
Оценка: -23 :))) :))) :))) :))) :))) :))) :))
Здравствуйте, UGN, Вы писали:

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

DB>>2.Использование целочисленных типов данных без знака (unsigned int) для номеров элементов и количественных значений в стандартной библиотеке stdc++. Приводит к следующим ошибкам:

UGN>
DB>>std::vector<int> v;
DB>>// Следующий код работает бесконечно, поскольку (size_type)(-1) == 4 млрд.
DB>>for (std::vector<int>::size_type i = 0; v.size() - 1; ++i)
UGN>^^^^^^
UGN>      Это вообще какой-то маразм
UGN>

UGN>Используй итераторы.
UGN>Если хочешь индексы, то пиши так:
UGN>
UGN>for (std::vector<int>::size_type i = 0; i < v.size(); ++i)
UGN>


DB>>3.Отсутствие встроенной проверки на выход за диапазоны массива. Приводит к необходимости писать «обертки» для классов-контейнеров (в частности, для класса vector).

UGN>А нафиг встроенная поддержка? Если сильно нужно используй STLport в debug режиме

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

UGN>А ты предлагаешь инициализировать память два раза: один раз нулями, потом актуальными начальными значениями?

DB>>6.Отсутствие оператора try {…} finally {…}. Приводит к созданию программ, неустойчивых к исключительным ситуациям. Попытка имитировать этот оператор с помощью оператора try {…} catch {…} приводит к большой избыточности кода.

UGN>Зачем он вообще нужен, этот finally? Делай все что нужно в деструкторах автоматических объектов

Все эти "комментарии" лишний раз доказывают, что 99% всех программистов на С++ -- просто ламеры. Автор языка, кстати, попадает в эти 99%
Re: Почему настоящие программисты избегают C++
От: Glоbus Украина  
Дата: 17.02.05 13:22
Оценка: 1 (1) +3 :))) :))) :))) :))) :))) :))) :))) :))) :)
Здравствуйте, d Bratik, Вы писали:

DB>1.Отсутствие модулей.

DB>2.Использование целочисленных типов данных без знака (unsigned int) для номеров элементов и количественных значений в стандартной библиотеке stdc++. Приводит к следующим ошибкам:


DB>3.Отсутствие встроенной проверки на выход за диапазоны массива.

DB>4.Отсутствие встроенных средств инициализации динамической памяти нулями при конструировании объектов оператором new.

DB>5.«Автоматизм» конструкторов и деструкторов

DB>6.Отсутствие оператора try {…} finally {…}.

Я мля не понял мля...!!! А где мля про шаблоны и их хреновую читаемость! А где утечки памяти при пользовании голых указателей! А где отсутсвие сборщика мусора мля!!! Че-то ты старик слабо подготовился, да еще с такими убогими примерами как std::vector::size()! Эй, там, граждане Рима, подготовьте нормально человека для критики плюсов!
Удачи тебе, браток!
Re: Почему настоящие программисты избегают C++
От: SchweinDeBurg Россия https://zarezky.spb.ru/
Дата: 17.02.05 12:32
Оценка: 18 (8) +14 :))) :))
На мой нескромный взгляд, стоило бы подобные утверждения хоть немного разбавлять "имхами". А то очень подмывает ответить цитатой из Булгакова:

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

[ posted via RSDN@Home 1.1.4 beta 4 r330 ]
- Искренне ваш, Поросенок Пафнутий
Re[3]: Почему настоящие программисты избегают C++
От: a  
Дата: 17.02.05 14:53
Оценка: 7 (3) +2 :))) :))) :))) :))) :))) :)))
Здравствуйте, d Bratik, Вы писали:

DB>Здравствуйте, Glоbus, Вы писали:

DB>Проблема шалонов не хреновой читаемости, а в том, что они unsafe — невозможно указать ограничений (constraints) для параметров. Шаблонов в своих программах можно избегать. Без сборщика мусора трудно, но существуют подходы (например, концепция владения), которые позволяют обойтись без него. А вот без остального действительно туго.

Проблема некоторых программистов не в их хреновых мозгах, а в том, что они unsafe — невозможно указать ограничений(constrains) для их логики. Таких программистов в своей жизни можно избегать. Без сборщика бреда трудно, но существуют подходы(например, концепция бана), которые позволяют обойтись без него. А вот без головы на плечах действительно туго.
Re[5]: Почему настоящие программисты избегают C++
От: Кодт Россия  
Дата: 21.02.05 10:46
Оценка: :))) :))) :))) :))) :))) :))) :))
Здравствуйте, d Bratik, Вы писали:

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

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

Старинная мужская забава программистов — мерять гуи
Перекуём баги на фичи!
Re[2]: Почему настоящие программисты избегают C++
От: d Bratik  
Дата: 17.02.05 12:48
Оценка: +1 -9 :))) :))) :)
Здравствуйте, SchweinDeBurg, Вы писали:

SDB>На мой нескромный взгляд, стоило бы подобные утверждения хоть немного разбавлять "имхами". А то очень подмывает ответить цитатой из Булгакова:

SDB>

SDB>и вы в присутствии двух людей с университетским образованием позволяете себе с развязностью совершенно невыносимой подавать какие-то советы космического масштаба и космической же глупости о том, как все поделить...
Когда по делу сказать нечего, начинают прикрываться цитатами и ссылаться на авторитетов.
Re: Почему настоящие программисты избегают C++
От: AlexEagle Украина http://www.vik.oil
Дата: 17.02.05 21:56
Оценка: 12 (6) +7 :)))
Здравствуйте, d Bratik, Вы писали:

DB>...настоящие программисты избегают C++

И предпочитают делфи где-то по следующим причинам:

1. За то что наследование используемых модулей не поддерживается.
Т.е. Если модуль А использует Модуль Б, и оба они используют модуль С,
то недостаточно прописать использование модуля с в Б, нужно это
использование обязательно и в А прописать.
2. За отсутствие шаблонов.
3. За отсутствие возможности создания автоматических объектов (все объекты изначально является указателем).
Соответственно приходистя вручную вызывать конструктор/деструктор (для чего и TRY..Finnaly)
4. За отсутствие множественного наследования
5. За отсутствие возможности перегрузки операций
6. За WITH благодаря которому код становится не читабельным до ужаса...
7. За дикую абстрактность от GUI модели, благодаря чему некоторые события не доступны,
некоторые не работают, а про главное окно приложения которое делит функционал с окном
Application я просто молчу. Хорошим примером поведения этой абстракности является функция MsgBox.
Можно ради интереса проследить что она делает (сколько вложенных вызовов). А еще класно
реализован Handle у компонентов — просто бестселлер, понял когда случайно вызвал в
деструкторе.
8. За жесткие ограничения на место описания переменных функции — между названием функции и началом блока
9. За невозможность смешивания переменных и функций класса при описании (вначале переменные а затем функции и не иначе)
10. За отсутвие удобных операторов типа +=, *=, -= и т.д. Про ++i и i++ я просто молчу.
11. За явное приведение типов. Особенно сильно "ЛЮБЯТ" за вызов функции Trunc для приведения вещественного в целому.
12. За отсутствие менеджера конфигураций. Так чтобы сделать Debug и Release хотябы, и пользоваться просто переключая их.
13. За дикий размер EXE, если конечно же не юзать пакаджи.
14. За то что ошибочная работа встроенных функций ведет к генерированию исключения, а не возврату кода ошибки. При этом во многих случаях приходится писать просто try ... except end; чтобы пропустить эту фичу.
15. За то что она не MDI. Это ужасно "УДОБНО". Приходится очищать рабочий стол перед открытием делфи, да и две запущенные — это головняк ("КРУТО"), поскольку никогда не знаешь в редакторе какой находишся. Иногда по ALT-TAB переключается только редактор, а главное окно нет.
16. За WITH благодаря которому дебаггер не показывае значение переменных типа with TComeCObject.Create(...) do Visible := TRUE;
Значение Visible — не увидишь никогда. Только если with SomeObject do SomeProperty := SomeValue; то в ТОЛЬКО окне свойств надо подставить SomeObject.SomeProperty и только тогда будет значение
17. За дебаггер который видит стек вызовов исключительно ограниченный модулями, пути которых включены в проект.
Так если в проект не подключить путь для просмотра (Project\Options\Search Path) C:\Program Files\Borland\Delphi6\Source\Vcl;C:\Program Files\Borland\Delphi6\Source\Rtl;C:\Program Files\Borland\Delphi6\Source\Rtl\Common;C:\Program Files\Borland\Delphi6\Source\Rtl\Sys;C:\Program Files\Borland\Delphi6\Source\Rtl\Win
то при возникновении события OnEnter у компонента на форме можно увидеть стек вызовов только с этой функцией.
НО!!!!!!!!!!!!! Если подключить пути то будет КУЧА!!!!!!! варнингов для делфевых модулей при компиляции, за которыми и "своих" не видно.
18. За отсутствие оператора "?". Есть только два псевдоаналога — варианты функции ifthen. При этом нормально работать можно со строкой и Integer-подобными значениями.
Когда речь идет об объекта то тогда запись выростает до TType(ifthen(...,Integer(Object1),(object2)) — грустно...
19. За компилятор, который хавает на ура запятую без указания последнего необязательного параметра функции.
Т.е. если function f(p1: Integer; b1: Boolean=false; B2: Boolean = false), то такое прокатит на ура — f(1,false,);
20. За директивы компилятора сделанные в стиле коментариев и мещающие коментированию текста их содержащего
21. За отсутствие нормального хелпа к системным функциям. Для того чтобы определить где находится описание сетевой
функции нужно выполнять поиск по каталогу сырцов. К примеру NetWkstaGetInfo которая вообще отсутствиет в
стандартных сырцах Ламерская система....
22. За то что значения дефолтовых параметров надо описывать и в описании функции/метода и в их реализации
23. За то что нельзя создать два пакета содержащие модули с одинаковыми названиями — среда не позволит, будет каждый раз ругаться что Пакет ХХХ использует модуль УУУ, который уже содержится в ХХ1 — это очень удобно, в с++ такого не добиться
24. За то что иногда невозможно открыть справку по F1, если модуль содержит ошибки.

Ну и как бы P.S.:
Все эти любимости собраны в 6-й версии делфи, поэтому если у кого одна из этих ужасно любимых фич не пойдет на другой версии — не расстраивайтей, всегдя найдется что полюбить в замен, на то это и делфи!

Ну и как бы P.P.S.:
Нисколько не хотел никого задеть кто пишет проги на делфи — у каждого свой вкус, ну и разные задачи требуют разных инструментов.
Re[9]: Почему настоящие программисты избегают C++
От: d Bratik  
Дата: 18.02.05 18:20
Оценка: +1 -5 :))) :))) :))
Здравствуйте, AlexEagle, Вы писали:

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

DB>>... есть кричащие проблемы, анализируя истоки которых приходишь к очень неутешительным выводам по поводу компетентности некоторых товарищей (Б.С.).

AE>Судя по постам, твоя компетентность не оставляет сомнений. Особенно мне "понравился" пост компетентность создателя С++

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

Язык-то кривой именно потому, что на нем систем толком не писали. Я лично не заню ни одной до конца профессиональной библиотеки на С++. STL — полная лажа, годится только для быстрого клепания демо версий консольных программ. Qt (лучшая кросплатформенная библиотека визуальных компонентов на С++) — гадость — нет никакой защиты от исключений, нет нормальной многопоточности в GUI, события (слоты-сигналы) сделаны вычурно и неэффективно. MFC — вообще ошибочна по своему дизайну (о переносимости молчу). Куда ни ткнись — бардак. Причем, истоки этого бардака не в библиотеках, а в самом языке.

Поскорее бы сдох этот Unix, этот Sun с его соляркой, чтобы пересесть на C# или на Delphi, или на Oberon наконец.
Re[15]: Почему настоящие программисты избегают C++
От: Блудов Павел Россия  
Дата: 21.02.05 07:13
Оценка: 6 (4) +5
Здравствуйте, Amidlokos, Вы писали:

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

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

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


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

А к чему я это всё? А к тому, что господин де Братик ошибся в выборе инструментария.
Ну согласитесь, если неудобно паять микросхемы паяльной лампой, если это раздражает, то нужно взять паяльник для микросхем и паять им. Он хорошо подходит для этой цели. Но паять им кастрюли тот ещё гимор.
А утверждать, что паяльник ацтой, потому что у него очевидные проблемы с кастрюлями это тоже самое, что утверждать, будто паяльная лампа ацтой, потому что у неё очевидные проблемы с микросхемами.
Re[4]: Почему настоящие программисты избегают C++
От: d Bratik  
Дата: 17.02.05 12:59
Оценка: :))) :))) :)))
Здравствуйте, jazzer, Вы писали:

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

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

J>А вот здесь Вы, батенька, нарушаете правила форума RSDN. В баню.

Да, тут я был слишком эмоционален. Сам ведь на С++ пишу
Re[5]: Почему настоящие программисты избегают C++
От: Kubera Россия  
Дата: 17.02.05 13:44
Оценка: +3 :))) :)))
Здравствуйте, d Bratik, Вы писали:

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

J>>А вот здесь Вы, батенька, нарушаете правила форума RSDN. В баню.

DB>Да, тут я был слишком эмоционален. Сам ведь на С++ пишу
Ой, мил человек, не надо! Не мучь себя и своих коллег!
Любая сложная технология неотличима от волшебства. (Артур Кларк)
Re[6]: Почему настоящие программисты избегают C++
От: Mr. None Россия http://mrnone.blogspot.com
Дата: 17.02.05 13:30
Оценка: 4 (2) +1 -1 :))) :)
Здравствуйте, d Bratik, Вы писали:

DB>Да что такое сегодня с руками...

Похоже, что не только сегодня...

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>


DB>Этот код ошибочен при любом количестве элементов в векторе.

Неправда — проверьте... при 0-ом размере вы не выполните ни одной итерации, потому что проверка условия выполняется перед каждой итерацией, в том числе и первой...
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Re: Почему настоящие программисты избегают C++
От: Xentrax Россия http://www.lanovets.ru
Дата: 17.02.05 19:40
Оценка: 11 (5) +1 -1
Здравствуйте, d Bratik

На самом деле, не такой он и плохой. Хороший даже, вон сколько всего понаписали. Сидят такие русские и украинские Рсдновцы и пишут, пишут. Шаблоны всякие используют, бусты с стлпортами, всяческие хитрые менеджеры памяти придумывают. Люди книжки пишут, ну типа "10001 совет, как не свернуть себе шею, пытаясь использовать StlPort 4.6.2 в EVC 3.0.". Деньги зарабатывают.

Только обычных программистов больше. Индусы, китайцы, японцы, русские и простые американцы — и им нужно не сублимировать ночами, изучая премудрости языка, а работу делать. И уйти с работы ранним вечером, потому что дома — жена и дети, и только в России 30 лет для программиста — это уже почти пенсия, а то как же он женатый будет 80 часов в неделю за компом сидеть.

Конкретно, в языке С++ есть недостатки. Эти недостатки известны, и к счастью, несмотря на ярых консерваторов на Рсдне, разработчики языка эти недостатки рано или поздно исправят, так как похоже до них доходит, что таки надо. А еще есть фирма MS, которая в C++/CLI уже много исправила

Но вы, господин d Bratik, много чего "веселого" написали.

Хотя по поводу времени компиляции согласен.
Это смешно, требовать использовать какие-то идиомы от 10 инусских выпускников университета города Columbus, OH. Они вам еще ВСЕ имеющиеся хедеры в CPP включат. Чего уж там, если ваш американский коллела, не зная как получить из указателя на базовый класс его наследника, запихивает функции и переменные в базовый класс, хотя имеют они смысл толкьо для наследника. И то все фигня, а когда сидящий через 3 метра наш родной русский программер делает на следующий день тоже самое, уже ни о каких идиомах речь не идет! А еще есть соседняя комната, код из которой вы иногда видите и даже портируете. Хе-хе.

Отсутствие finally — довольно дурацкая шутка создателей языка.
К сожалению, я последние 4 года не пишу с исключениями, так как в компиляторе нет для них поддержки (осталось еще год продержаться, дальше мы депрекейтим эту платформу), но finally я в свое время использовал в OPascal, и знаю, насколько это удобно. Конечно, все можно эмулировать, но только если finally код сокращает, то эмуляция — наоборот увеличивает, а уж понятности точно не добавляет.

Все остальное, конечно критики не выдерживает. Особенно отсутствие встроенной проверки при работе с указателями (ну типа массивами).


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

Когда нибудь приводили void* к указателю на один из базовых классов в множественном наследовании? А в массиве срезанные класы хранили? А пытались понять, почему вы не можете вызвать метод базового класса с одним типом параметра, когда вы написали перегрузку, а не переопределение? А пытались понять, почему функция map::erase в VC++ возвращает итератор, а в StlPort — void?

А еще есть странности реализации. Например, при портирвании dsp в vcproj в послденем wchar остается как unsigned short, а в новых проектах как честный тип. И фиг оно слинкуется! И когда вы найдете отличия в експотрах и импортах в бинарных файлах, фиг вы еще поймете, как это поправит.


Много можно говорить, но дело все в том, что

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

И если вам и мне интересно заниматься этим, то нашим работодателям — нет.
Re[11]: Почему настоящие программисты избегают C++
От: Amidlokos Россия  
Дата: 23.02.05 11:15
Оценка: 7 (3) +4
Здравствуйте, Kh_Oleg, Вы писали:

K_O>В Вилариба уже давно сменили стандартное свойство у стандартного контрола,
K_O>а в Вилабаджо все еще пишут свои классы для кнопочек.

Под шумок вылезли дельфисты, я верно понимаю?

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

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

K_O>Дело не в том, что мало печатать приходится, потому что визард генерит, а в том, что потом такое читать невозможно.

Ну почему все так категоричны? Так глобальны? Почему не пишут правду — "потом такое МНЕ читать невозможно". Ну, опыта и набитой руки не хватает, так зачем жабе-то давать себя душить?

WARNING: expression "to_be || !to_be" is always true
Re[4]: Почему настоящие программисты избегают C++
От: Кодт Россия  
Дата: 17.02.05 15:07
Оценка: 1 (1) +1 :))) :)
Здравствуйте, _Obelisk_, Вы писали:

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.

Да расслабься. Братик наверное пишет всякую бухгалтерскую шнягу (пардон, Систему) на дебилдере, вот у него и наболело — тем более, что в родственном дельфи есть try-finally и на конструкторы можно забивать, а в дебилдере нет.
Перекуём баги на фичи!
Re[11]: Почему настоящие программисты избегают C++
От: Kubera Россия  
Дата: 17.02.05 20:03
Оценка: 1 (1) +2 -2 :)
Здравствуйте, d Bratik, Вы писали:
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. я решение знаю, но не сказал бы что оно простое

DB>Решение состоит в том, что система должна генерировать исключение (exception) при переполнении. Отсутствие этой возможности я забыл добавить в качестве 7-го пункта в списке ошибок проектирования языка.

Функции, логика которых не предусматривает ошибочных ситуаций, не должны кидать исключений. А функция вычисления среднего арифметического относится как раз к таким. Т.е. предложенное тобой решение с генерацией исключения неверно.
Любая сложная технология неотличима от волшебства. (Артур Кларк)
Re[8]: Почему настоящие программисты избегают C++
От: Awaken Украина  
Дата: 25.02.05 09:25
Оценка: 1 (1) +5
C>То-то более 99% процентов кода на Земле — невизульного (т.е. не имеющий
C>отношения к UI).

выскажу совсем крамольную мысль.
для большинства программ где нужность гуя только для "достать данные из базы и показать на экране",
можно использовать веб-браузерный интерфейс со скриптами и серверными сценариями (ASP,JSP).
и никаких библиотек для С++ не надо.
а если ГУЙ нетривиальный как в CAD-системах — вряд ли какая-то из стандартных визуальных библиотек тут достаточна
(разве что в качестве минимального "каркаса" под собственный фреймворк)
Re: Почему настоящие программисты избегают C++
От: MozgC США http://nightcoder.livejournal.com
Дата: 17.02.05 13:15
Оценка: +4 -2
d Bratik, Ты просто еще молодой [censored]. И пусть мне щас вынесут предупреждение или забанят, но я уверен, что многие из овтечавших здесь и читавших эту ветку согласились бы со мной и про себя подумали то же самое, просто из-за правил и приличия побоялись написать.

Два дня в read-only за нарушение правил. И приличий. — МК
Re[9]: Почему настоящие программисты избегают C++
От: vog Россия [реклама удалена модератором]
Дата: 04.03.05 08:22
Оценка: +2 :))) :)
Здравствуйте, Pazak, Вы писали:


P>Любовница — это типа "для души"? Тогда однозначно python!

Такс, ветка явно скатывается в сторону извращений
[реклама удалена модератором]
Re[4]: Почему настоящие программисты избегают C++
От: d Bratik  
Дата: 09.03.05 16:13
Оценка: -2 :))) :)
Здравствуйте, retn, Вы писали:

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

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

R>Да ты юморист из Аншлага.

R>Блин спасибо тебе , было плохое настроение и голова разболелась,
R>прочитал некоторые твои посты и от доброго смеха всё прошло, а ведь ничего не помогало.

Это было бы смешно, если бы не было так грустно... У меня одна надежда — что MS, вылечившись сама, вылечит и других. Только вес такой фирмы может быть противопоставлен снобизму программистов на С++.

R>Тут еще в Железе один из учередителей АМД обясняет всем что такое Интел и всех несогласных кличет на рукопашную, во блин неделька.

Да, Интел процессоры проектировать не умеет. Надеюсь Бабаян их наконец уму-разуму научит.
Re[2]: Почему настоящие программисты избегают C++
От: VladD2 Российская Империя www.nemerle.org
Дата: 18.02.05 00:06
Оценка: :))) :))
Здравствуйте, ussr, Вы писали:

U>Еще один флейм C++ против C#. Достало.
U>Лучше вспомните в каком году вышел C++ и в каком C#.

О! Вот и появился C#. И ведь никто за язык не тянул.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Почему настоящие программисты избегают C++
От: d Bratik  
Дата: 22.02.05 17:14
Оценка: -3 :))
Здравствуйте, Awaken, Вы писали:

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

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

A>99% приложений под винду написаны на C++.
A>из того что использую каждый день — Visual Studio, MS Office, Adobe Photoshop, Discreet 3DS Max
A>лидеры в области коммерческого ПО почему-то не пишут на Дельфях хотя это проще и удобнее. неспроста
A>из того что я использую только TOAD на Дельфях.

И все же я пока не видел ни одной промышленной GUI бибилиотеки на С++, которая бы отдаленно приближалась по качеству к VCL и .NET Framework. Обыскал весь Интернет — таковой в природе нет. Qt более-менее ничего, но когда основательно начинаешь пользовать, начинаешь плеваться.
Re[7]: Почему настоящие программисты избегают C++
От: 4ertus2  
Дата: 19.03.05 19:44
Оценка: 3 (1) +1 :))
Я без сомнения чайник и, как мне тут объяснили, сноб (что бы это слово значило), а еще я хочу сказать одну глупость. Так вот, "ненастоящие программисты" пишут на С-подобных языках потому что

{
что-то_внутри
}

более понятная струкрура для мозга "ненастоящего программиста" чем

begin
что-то_между_началом_и_концом
end

особенно когда начал и концов много и они меджу другим началами и концами.
Язык программирования — это прежде всего язык общения, а уже потом технология. С-подобный синтаксис — лучший придуманняй на данный момент (или это тоже спорный вопрос?). Поддержка любого другого синтаксиса — маркетинговая необходимость всем понятно каких фирм.
Непривязанное к форме вечно.
Re[3]: Почему настоящие программисты избегают C++
От: jazzer Россия Skype: enerjazzer
Дата: 17.02.05 12:39
Оценка: 2 (2) +2
Здравствуйте, d Bratik, Вы писали:

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

А вот здесь Вы, батенька, нарушаете правила форума RSDN. В баню.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[25]: SEH и C++ синонимы или нет?
От: Владик Россия  
Дата: 01.06.05 13:00
Оценка: 1 (1) +3
Здравствуйте, Kh_Oleg, Вы писали:

K_O>Не знаю, что такое guard с функтором, но если он работает также, как и обычные guards — т.е. если finalization код вызывается в деструкторе некоторого объекта, но такой подход неприменим при создании exception-safe приложений.

Ты неправильно трактуешь саму концепцию finalization кода. Такой код по определению не может кидать исключений, которые можно осмысленно обработать — или это уже не finalization код. Например, классическая ошибка — пытаться в finalization коде делать commit транзакции, застартованной в initialization. commit должен вызываться в основном коде явно и явно обрабатываться его ошибки, а вот rollback — можно и в finalization (если транзакция не была успешно завершена). При этом если rollback кидает исключение, то значит все совсем плохо, и тут уж сделать что-то более осмысленное, чем запись в лог — вряд ли можно.

P.S. Что касается С++ c guard с функтором — никто не мешает тебе в деструкторе guard сделать try/catch на случай непредвиденного (rollback кидает исключение). В случае, если этого не сделать, насколько я знаю, будет вызван terminate() (а вовсе не undefined behavior). С terminate() тоже можно еще чего-то придумать (сам по себе вызов не означает завершение программы). Хотя на моей практике до такого не доходило. Так же как и особых проблем с исключениями в деструкторе я не припомню.
Как все запущенно...
Re[2]: Почему настоящие программисты избегают C++
От: Garrrrr  
Дата: 17.02.05 12:33
Оценка: +3 :)
Здравствуйте, ansi, Вы писали:

A>Мля. Во я дурак! Пашол учица на чиста риальнава праграмиста!!!

согласен
[нагло своровано]
ам/кг
Re[3]: Почему настоящие программисты избегают C++
От: SWW Россия  
Дата: 17.02.05 12:54
Оценка: +2 :))
DB>Когда по делу сказать нечего, начинают прикрываться цитатами и ссылаться на авторитетов.

Интересный профиль у вас, сударь: первое сообщение "Почему настоящие программисты избегают C++"
Re[2]: Почему настоящие программисты избегают C++
От: Mr. None Россия http://mrnone.blogspot.com
Дата: 17.02.05 13:37
Оценка: :))) :)
Здравствуйте, Glоbus, Вы писали:

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

G> Я мля не понял мля...!!! А где мля про шаблоны и их хреновую читаемость! А где утечки памяти при пользовании голых указателей! А где отсутсвие сборщика мусора мля!!! Че-то ты старик слабо подготовился, да еще с такими убогими примерами как std::vector::size()! Эй, там, граждане Рима, подготовьте нормально человека для критики плюсов!


Да запросто
Читать для начала: от сих
Автор: IT
Дата: 26.04.01
 и до сих
Автор: IvanZ
Дата: 16.02.05
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Re[3]: Почему настоящие программисты избегают C++
От: Garrrrr  
Дата: 17.02.05 14:05
Оценка: +2 :))
Здравствуйте, d Bratik, Вы писали:

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

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

_O_>>Пишу на С++ шесть лет и ни разу перечисленные проблемы не являлись для меня проблемами.

DB>Вы наверное писали очень небольшие программы, без GUI. Для создания программ С++ подходит, но для создания систем — нет.

Братва, вы в курсе? Вы все балуетесь, а не серьезными вещами занимаетесь.
Поувольнять вас всех, недоучек! ))))))
P.S.: www.kde.org вот тебе серьезная система с гуи.
Re[2]: Почему настоящие программисты избегают C++
От: d Bratik  
Дата: 17.02.05 14:18
Оценка: -2 :))
Здравствуйте, Glоbus, Вы писали:

G> Я мля не понял мля...!!! А где мля про шаблоны и их хреновую читаемость! А где утечки памяти при пользовании голых указателей! А где отсутсвие сборщика мусора мля!!! Че-то ты старик слабо подготовился, да еще с такими убогими примерами как std::vector::size()! Эй, там, граждане Рима, подготовьте нормально человека для критики плюсов!

Проблема шалонов не хреновой читаемости, а в том, что они unsafe — невозможно указать ограничений (constraints) для параметров. Шаблонов в своих программах можно избегать. Без сборщика мусора трудно, но существуют подходы (например, концепция владения), которые позволяют обойтись без него. А вот без остального действительно туго.
Re[3]: Почему настоящие программисты избегают C++
От: Кодт Россия  
Дата: 17.02.05 14:36
Оценка: +3 :)
Здравствуйте, d Bratik, Вы писали:

DB>Проблема шалонов не хреновой читаемости, а в том, что они unsafe — невозможно указать ограничений (constraints) для параметров. Шаблонов в своих программах можно избегать. Без сборщика мусора трудно, но существуют подходы (например, концепция владения), которые позволяют обойтись без него. А вот без остального действительно туго.

Не умеешь писать с шаблонами — так прямо и скажи.

Констрейнты в шаблонах делаются с лёгкостью необычайной. Как именно — не скажу, тебе это всё равно не пригодится.
Перекуём баги на фичи!
Re[3]: Только настоящие программисты пишут на С++! :)
От: Шахтер Интернет  
Дата: 18.02.05 03:42
Оценка: +2 -1 :)
Здравствуйте, VladD2, Вы писали:

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

К>>1) От компилятора: прекомпиляция заголовков
К>>2) От программиста: идиома pimpl
К>>И всё будет летать.

VD>Летает обычно яжыком. А по жизни серьезный проект (более 3 метров кода) компилруется от десяти минут, до часов.

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

Ну не надо своё невежество выдавать за недостаток языка. Отлично и на С, и C++ делается компонетная разработка.

Хорошо известный всем пример -- FAR. Посторен очень компонентно и модульно. И расширяется независимыми разработчиками.

VD> Вот это куда более неприятно. Приходится прибегать к разным КОМ-ам, а они в С++ ой как долеки от нормального программирования.

COM -- это вообще из другой оперы. Для компонентной разработки он не нужен вообще. Он нужен для интеграции компонентов, написаных на разных языках. Для того, чтобы это было возможно, необходим бинарный стандарт на испольнямые модули/динамические библиотеки.
... << RSDN@Home 1.1.0 stable >>
В XXI век с CCore.
Копай Нео, копай -- летать научишься. © Matrix. Парадоксы
Re[11]: Почему настоящие программисты избегают C++
От: d Bratik  
Дата: 20.02.05 14:39
Оценка: -3 :)
Здравствуйте, 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). К сожалению все это далеко от С++.
Re[11]: Почему настоящие программисты избегают C++
От: Pazak Россия  
Дата: 23.02.05 20:50
Оценка: +3 :)
Здравствуйте, Kh_Oleg, Вы писали:


K_O>В Вилариба уже давно сменили стандартное свойство у стандартного контрола,
K_O>а в Вилабаджо все еще пишут свои классы для кнопочек.

Завтра Виллариба понадобится сделать кнопку транспарентной и они будут горевать о том, что у копонента TButton нет свойства AlphaTransparency?
Ку...
Re[11]: Почему настоящие программисты избегают C++
От: _alm_ Украина  
Дата: 24.02.05 11:21
Оценка: +4
Здравствуйте, d Bratik, Вы писали:

DB>Стандартный шрифт на кнопках — MS Sans Serif, размером 8 pt.

У-у-у. Как все запущено.... Какой шрифт называется "стандартным" ? Класса окна ? Диалога, описанный в RC файле ? Тот, который возвращает SystemParametersInfo() с параметром SPI_GETNONCLIENTMETRICS ? Или тот, который прописан как дефолтовая пропертя в какой-ньть рисовалке интерфейса ?

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

Понятно теперь, откуда эти интерфейсные уродцы берутся, у которых вся морда перекашивается при смене dpi шрифтов на экране. Тебе в голову никогда не приходило, что если у человека зрение слабое, то у него, соответственно, и установки схемы стоят такие, что шрифтов в 8 пунктов просто нет нигде ?

DB>Ну и наконец, взгляните на окно Интернет-обозревателя, в котором Вы сейчас пыхтя строчите свой ответ. Вас не смущает, что кнопочки «Найти ответ», «Предпросмотр» и «Отправить» имеют совсем нестандартный размер. Это конечно HTML-документ, но почему мне нельзя сделать такие кнопки в своей программе?

А кто мешает ? Религия не позволяет ? Я знаю как минимум 2 С++ UI библиотеки в которых есть подобная фича. Ссылок не будет — обе внутрифирменные. Одна — сильно разросшаяся MFC, вторая — с нуля писанная. Так может, дело все-таки не в языке программы, а в радиусе кривизны рук проектировщика ГУЯ ?
Re[20]: Почему настоящие программисты избегают C++
От: Pazak Россия  
Дата: 28.02.05 05:56
Оценка: :))) :)
Здравствуйте, Alex Reyst, Вы писали:

DB>>Я сам доктор, между делом студентов лечу. Бесплатно избавляю от синдрома страуструпа, комплекса "best industry practice", а также GUI- и DBMS-фобий. Так что обращайтесь
AR>Бесплатная медицина — хреновая медицина. Как минимум на территории бывшего СССР .

Да уж... От GUI-фобии избавишься, так чего доброго GUIфилию подцепишь...
Ку...
Re[8]: Почему настоящие программисты избегают C++
От: vog Россия [реклама удалена модератором]
Дата: 04.03.05 07:23
Оценка: +1 :)))
Здравствуйте, transglucator, Вы писали:

T>жена — Pascal
T>проститутка — C++
T>любовница — ?

На самом деле до сих пор поддерживаю один проект на Дельфях, просто в лом переписывать, а юзеры периодически просыпаються и просят сделать им очередные приблуды. И вот каждый раз я сжимаю зубы и говорю сам себе — Леха, вспомни — begin-end, begin-end, скобки сегодня не катят
[реклама удалена модератором]
Re: Почему настоящие программисты избегают C++
От: alnsn Великобритания http://nasonov.blogspot.com
Дата: 17.02.05 15:51
Оценка: 8 (3)
Здравствуйте, d Bratik, Вы писали:

> bla-bla-bla ...

http://www.catb.org/~esr/writings/taoup/html/ten-thousand.html
Re[15]: Почему настоящие программисты избегают C++
От: Kubera Россия  
Дата: 18.02.05 16:42
Оценка: 4 (2) +1
Здравствуйте, Кодт, Вы писали:

N>>насчёт ошибочности согласен, но и a/2 + b/2 + (a%2 + b%2)/2 не подарок явно!

К>Почему же не подарок? Деление округляет к меньшему по модулю, а остаток — знаковый.
Неподароком может стать замена (a+b)/2 на a/2 + b/2 + (a%2 + b%2)/2, так как поведение a/2 + b/2 + (a%2 + b%2)/2 отличается от поведения (a+b)/2. Это видно на случаях, где a=2k, b=-2k+2n+1, k > n >= 0 (или a=-2k, b=2k-2n-1). Возму случай a=2k, b=-2k+2n+1, тогда:

(a + b)/2 = (2k — 2k + 2n + 1)/2 = (2n + 1)/2, т.е. n

a/2 + b/2 + (a%2 + b%2)/2 = 2k/2 + (-2k + 2n + 1)/2 + (0 — 1)/2, здесь (-2k + 2n + 1)/2 будет преобразовано к -k + n + 1, а не k + n, из-за округления к меньшему по модулю. В итоге результат будет n + 1, а не n.

Пример:
a=100, b=-77
(a + b)/2 = 11
a/2 + b/2 + (a%2 + b%2)/2 = 12

Однако при a=101, b=-78
(a + b)/2 = 11
a/2 + b/2 + (a%2 + b%2)/2 = 11

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

P.S. Впрочем всё это пустое, т.к. врядли в реальном проекте встретится функция типа int kaka (int a, int b){return (a+b)/2;}
Любая сложная технология неотличима от волшебства. (Артур Кларк)
Re[16]: Почему настоящие программисты избегают C++
От: Блудов Павел Россия  
Дата: 22.02.05 05:19
Оценка: 1 (1) +2
Здравствуйте, d Bratik, Вы писали:

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

Уважаемый де Братик!
Я открою Вам страшный секрет. Расскажу, как Ваш пример написал бы не "настоящий программист, избегающий С++", а лох какой-нибудь.
Замечу, что постановка задачи "пройтись по всем элементам кроме последнего" подразумевает наличие хотя бы одного элемента. Проход без последнего элемента по пустому контейнеру есть вопрос спорный, и лучше бы его обработать отдельно. Т.е. примерно так:

if (!vec.empty())
{
    std::for_each(vec.begin(), vec.end() - 1, WhateverYouWant());
}
else
{
    // А тут или ничего, или assert, или throw, или запись в лог в конце концов.
}


Так что C++ нормальной язык, просто Вы не умеете его готовить.
Re: Почему настоящие программисты избегают C++
От: elcste  
Дата: 17.02.05 12:26
Оценка: +3
Как говорилось в известном анекдоте про Вовочку, — "да, Иван Иваныч, мне бы ваши проблемы..."
Re[4]: Почему настоящие программисты избегают C++
От: d Bratik  
Дата: 17.02.05 13:15
Оценка: -1 :))
Здравствуйте, SWW, Вы писали:

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

SWW>>>А что это за чушь написал здесь настоящий программист?
V>>Понятно что До тех пор, пока в векторе не один элемент, делай...

SWW>Кхм, интересно... Человек приводит заведомо неправильный код и говорит: С++ плохой язык потому что на нем можно написать неправильную программу — вот, видите, я же смог!

Сударь, код совершенно коректный: "для всех элементов кроме последнего". В случае пустого вектора код работает бесконечно. Для демонстрации проблемы можно было бы завернуть цикл от последнего элемента до первого:

std::vector<int> v;
for (std::vector<int>::size_type i = v.size() - 1; i >= 0; ++i)
{
  ...
}


Этот код ошибочен при любом количестве элементов в векторе.

SWW>А если бы v.size() было знаковым, разве этот код работал бы?

Да, причем совершенно корректно.
Re[2]: Почему настоящие программисты избегают C++
От: d Bratik  
Дата: 17.02.05 14:02
Оценка: -1 :))
Здравствуйте, _Obelisk_, Вы писали:

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

_O_>Пишу на С++ шесть лет и ни разу перечисленные проблемы не являлись для меня проблемами.

Вы наверное писали очень небольшие программы, без GUI. Для создания программ С++ подходит, но для создания систем — нет.
Re[3]: Почему настоящие программисты избегают C++
От: ZeusSon  
Дата: 17.02.05 15:21
Оценка: :)))
Здравствуйте, achp, Вы писали:

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

A>
DB>>i < v.size() - 1
A>


A>Элементарно переписывается так:

A>
A>i + 1 < v.size()
A>


A>Просто нужно кумекалкой соображать
Ну ты загнул.... Для кумекалки же надо еще ее инициализировать... А она просто нулями забита..
Re[6]: Почему настоящие программисты избегают C++
От: vog Россия [реклама удалена модератором]
Дата: 18.02.05 20:03
Оценка: :)))
Здравствуйте, Kubera, Вы писали:

DB>>Да, тут я был слишком эмоционален. Сам ведь на С++ пишу
K>Ой, мил человек, не надо! Не мучь себя и своих коллег!

Позвольте вставить свое Э )
Помню, как-то давно один молодой чел спрашивал на каком-то форуме, что ему выбрать для изучения — Паскаль или С++
Выдал я ему совет примерно такой — Паскаль — как строгая жена, все время в одной позе, зато почти безопасно. А с++ — проститутка, делай с ней что захочешь, но за последствия отвечаешь сам ))) Вот мне больше по душе как-то шлюхи, хотя на Дельфях тоже приходиться иногда.
[реклама удалена модератором]
Re[3]: Почему настоящие программисты избегают C++
От: Cyberax Марс  
Дата: 19.02.05 14:08
Оценка: +3
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)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[6]: Почему настоящие программисты избегают C++
От: d Bratik  
Дата: 20.02.05 14:51
Оценка: -1 :))
Здравствуйте, 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.
Re[13]: Почему настоящие программисты избегают C++
От: d Bratik  
Дата: 20.02.05 20:14
Оценка: -1 :))
Здравствуйте, 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>все — на основе очереди событий.
Re[15]: Почему настоящие программисты избегают C++
От: d Bratik  
Дата: 21.02.05 19:53
Оценка: -3
Здравствуйте, 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
Re[14]: Почему настоящие программисты избегают C++
От: VladD2 Российская Империя www.nemerle.org
Дата: 21.02.05 23:03
Оценка: +1 -2
Здравствуйте, Kubera, Вы писали:

K>Функция вычисления среднего арифметического не должна бросать исключений. Это нонсенс , если вместо среднего арифметического при определённых входных параметрах функция будет выкидывать ошибку! А вот её реализация обязана учитывать переполнение, точнее избегать его. Влад, с чем ты не согласен?

Попробую более доходчиво:
Функция не учитывающая переполенеие уже ошибочна.

Так понянее?
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Почему настоящие программисты избегают C++
От: vdimas Россия  
Дата: 22.02.05 09:35
Оценка: +3
Здравствуйте, VladD2, Вы писали:

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

K>>Функции, логика которых не предусматривает ошибочных ситуаций, не должны кидать исключений. А функция вычисления среднего арифметического относится как раз к таким. Т.е. предложенное тобой решение с генерацией исключения неверно.

VD>Функция не учитывающая переполенеие уже ошибочна.

Результат усреднения не может содержать переполнения
Re[7]: Почему настоящие программисты избегают C++
От: Cyberax Марс  
Дата: 22.02.05 17:38
Оценка: +1 :))
d Bratik пишет:

> A>99% приложений под винду написаны на C++.
> A>из того что использую каждый день — Visual Studio, MS Office, Adobe
> Photoshop, Discreet 3DS Max
> A>лидеры в области коммерческого ПО почему-то не пишут на Дельфях хотя
> это проще и удобнее. неспроста
> A>из того что я использую только TOAD на Дельфях.
> И все же я пока не видел ни одной промышленной GUI бибилиотеки на С++,
> которая бы отдаленно приближалась по качеству к VCL и .NET Framework.
> Обыскал весь Интернет — таковой в природе нет.

MFC, WTL, raw WinAPI, GTK. _Качество_ у них ничуть не хуже.

А к интуитивности использования _библиотека_ отношение имеет весьма
слабое, важна среда. Тот же Glade для GTK позволяет интуитивно рисовать
интерфейсы на чистом С.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[9]: Почему настоящие программисты избегают C++
От: The Lex Украина  
Дата: 23.02.05 15:31
Оценка: +1 :))
Здравствуйте, d Bratik, Вы писали:

DB>Под качеством я имел в виду не степень отлаженности, а уровень технического совершенства. Чтобы понять разницу, попробуйте, используя эти библиотеки, создать окно с обычной кнопкой OK, текст которой написан нестандартным шрифтом. Сколько нужно потратить на это времени?

10 баллов! Первый признак дельфиста: "окно с обычной кнопкой OK, текст которой написан нестандартным шрифтом"! "Повбывав бы!" (к)
Голь на выдумку хитра, однако...
Re[17]: Почему настоящие программисты избегают C++
От: olegkr  
Дата: 25.02.05 15:36
Оценка: +1 -1 :)
Здравствуйте, Cyberax, Вы писали:

C>Разделение на модель-вид-контроллер не заставляет "плодить классы". Как
C>раз наоборот.
C>Анонимные классы — это аналог делегатов, а не следствие MVC.

Ага, только для обработки одного event-а нужно писать либо отдельный, либо анонимный класс. Хочешь обработать нажатия кнопки — пиши класс, наследуемый от ActionListener-a, даже если кнопка одна. Хочешь обработать нажатие клавиши, пиши класс от KeyAdapter-а. Особенно приятно, что интерфейсы содержат не один callback, а несколько, и приходится использовать адаптеры с заглушками. Крайне "удобно". Небольшой, но типичный пример.

btnOK.addActionListener(new ActionListener()
{
    public void actionPerformed(ActionEvent ae)
    {
        ...
    }
});


И понеслось... В итоге — или код инициализации забит обработчиками, либо куча доп.классов.

...
this.btnOK.Click += new System.EventHandler(this.btnOK_Click);
...
private void btnOK_Click(object sender, EventArgs e)
{
    ...
}


Наглядно видно, что подписка на событие и сам обработчик разделены. Причем не надо городить отдельных классов (при желании можно и отдельный класс сделать).

C>Да, нужно помнить параметры FormLayout'а.... Чрезвычайно
C>сложнозапоминаемые, настолько, что даже автокомплит совсем не поможет. И
C>ведь еще даже документацию просмотреть придется. Нет, это не для ВБистов.

Для примера, GridBagConstraints(int gridx, int gridy, int gridwidth, int gridheight, double weightx, double weighty, int anchor, int fill, Insets insets, int ipadx, int ipady)
Читаемость куска кода, использующего данную конструкцию просто изумительная. Да и вообще, весело разбираться в чужом коде на свинге, с целью переместить кнопочку "отсуда-сюда". Работа для настоящих интеллектуалов, дотнет отдыхает, комплит помогает.
Про документацию я вообще умалчиваю. Такое не может называться полноценной документацией.

C>Чтобы потом все юзеры плевались от неправильно масштабируемых (или
C>вообще немасштабируемых) форм.

Anchor-ы решают сию задачу в 9 из 10 случаев. Для оставшегося одного можно использовать и самописный лайаут менеджер. Не велика задача.

C>У меня она вызывает отвращение. Интерфейсы не выделены, наследование
C>используется сверх меры

Ценность интерфейсов в винформах сомнительная, благодаря наличию евентов. Это в свинге без интерфейсов никуда.

C>Хотя МС в этот раз поступила честно — пакет называется WinForms, так как
C>ни на что большее, чем формочки, он не способен.

Вот только одна беда. На винформах не проблема написать professional-looking GUI, а на свинге это вызывает немалые затруднения. Фактически, любой прилично-выглядящий ГУИ, типа эклипса — самопис.

C>Руки, значит, не так работают. IDEA написана на Свинге, однако летает
C>даже на старых машинах.

Если бы летала... Впрочем, возможно я просто привык к шустрому VS.NET вот и ворчу. В принципе, поработав пару месяцев можно привыкнуть.
Re[6]: Почему настоящие программисты избегают C++
От: ansi  
Дата: 10.03.05 09:41
Оценка: +1 :))
Здравствуйте, AlexEagle, Вы писали:

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

DB>>Это было бы смешно, если бы не было так грустно... У меня одна надежда — что MS, вылечившись сама, вылечит и других. Только вес такой фирмы может быть противопоставлен [i]снобизму программистов на С++[/i].

AE>так вот где корень зла...
Это точно. Диагноз ясен: синдром .NET.
Re[23]: SEH и C++ синонимы или нет?
От: Владик Россия  
Дата: 31.05.05 09:12
Оценка: +3
Здравствуйте, Kh_Oleg, Вы писали:

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

И тем не менее, по факту он им является Как раз потому, что не заточен под всякие SEH и т.п. platform-specific. Тебе уже популярно объяснили, что finally в C++ нужен не более, чем goto (если еще не понял — воспользуйся поиском по сайту, эта тема неоднократно обсуждалась). Разница только в том, что goto в языке официально есть (пресловутая совметимость с С этому не последняя причина), а finally — нет. Но это не мешает большинсву программистов всячески избегать применения goto или принципиально обходится без него (при этом не напрягаясь). Код, не загроможденный лестницами try/finally, выглядит намного понятнее, а на тот единичный случай, когда совсем влом писать отдельный и очень специфичный guard для выполнения какого-либо финализирующего действия — можно воспользоваться обобщенным guard'ом с функтором.
Как все запущенно...
Re[11]: Почему настоящие программисты избегают C++
От: Mr. None Россия http://mrnone.blogspot.com
Дата: 24.02.05 09:33
Оценка: 4 (2)
Здравствуйте, d Bratik, Вы писали:

DB>Прежде, чем Вы броситесь это обосновывать, подумайте, почему в .NET Framework, который делался намного позже Windows и MFC, все совсем не так и ОЧЕНЬ напоминает VCL?

Потому что ещё раньше VCL и .NET Framework был Visual Basic, и всё, что есть в VCL, очень напоминает именно VB...
А я вот например на заре Windows 95 видел ещё и Visual Assembler, до сих пор где-то у меня валяется, так вот было это ещё до VCL и опять таки очень похоже на Visual Basic... А ещё раньше графического интерфейса Windows были переносимые на разные платформы библиотеки пользовательского интерфейса IrfanViews, Motif и т.д. Так вот они были написаны именно на плюсах... А ещё есть xWindows и Open Windows для *NIX систем, первые их реализации вообще были написаны на C и задолго до Windows 95... А ещё был графический пользовательский интерфейс под MacOS, появившийся за долго до того, как Borland популяризовала Pascal и написала Delphy и он жил и прекрасно себя чувствовал, не зная, что он не может так себя чувствовать, потому что написан ни на паскале, ни на C#... а он всё равно жил, протому что не знал и знать был вовсе не обязан... А ещё есть Smalltalk, со своей библиотекой, включающей в том числе и GUI, если бы видели это чудо, вас бы несколько недель мучали кошмары, потому что там всё совсем не так как в паскале, шарпе, плюсах или чистом C... там даже можно вызывать функции которых не существует... Но ничего — живёт и кто-то даже это использует... А ещё есть Фортран-80, где нет объектов и динамической памяти... А ещё есть Self, где есть объекты, но нет классов. А ещё есть Volcano (объектный пролог), где вообще нет типов в привычном понимании, но есть объекты, и вообще чтобы на нём писать надо иметь мозг повёрнутый в ином направлении... спросите у С. Ю. Губанова — я ему рассказывал... Так что может кончим этот никуда не ведущий флейм?
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Re[4]: Почему настоящие программисты избегают C++
От: Sinclair Россия https://github.com/evilguest/
Дата: 22.02.05 05:29
Оценка: 3 (1) +1
Здравствуйте, AlikGut, Вы писали:

AG> что-то я наверное совсем уже правильно понимать стал этот топик — там болдом выделено. это как вообще?? если я использую в ГУИ два лист-бокса для отображения каких-то данных, то я по такому определению должен заводить у себя два стринг массива что ли?? и все алгоритмы писать над строками, в них хранящихся?? это маразм, имхо, — каким образом и почему ГУИ вообще должен быть както определять внутреннюю реализцаию ?? "патаму шта из map не могу получить ключи" — не катит — нада както мочь это делать.
Братик имеет в виду, что проектирование системы в идеальном случае должно быть устроено вот так:
— сначала идет исследование предметной области и определение проблематики.
— затем архитектор придумывает решение поставленной задачи в виде точного описания наблюдаемого поведения системы. С точки зрения наших западных коллег, на этом и заканчивается архитектура. Все остальное — банальный инженерный труд по реализации спецификаций.
— выполняется прототипирование документированного наблюдаемого поведения, и все сценарии использования тестируются на удобство и практичность
— решение корректируется в соответствии с результатами прототипирования
— выбирается адекватная платформа (языки, технологии, API)
— разрабатывается модель реализации системы в выбранной платформе
— в соответствии с моделью выстраиваются алгоритмы и структуры (интерфейсы и классы, или функции, или таблицы и хранимые процедуры — depends)
— проводится QA.

В случае, если значительная часть наблюдаемого поведения системы включает взаимодействие с пользователем, то конечно же вопросы UI выходят на первый план. К слову, это вовсе не обязательно — есть огромное количество задач, где взаимодействия с человеком не требуется. Берем любой RFC с IETF — он отлично документирует наблюдаемое поведение системы в терминах команд, параметров, состояний и т.п. И среди этого есть очень и очень сложные задачи, на фоне которых самый сложный GUI смотрится блекло.
К счастью, реально сложные требования к поведению софта встречаются в природе достаточно редко.

Одним из самых распространенных способов сделать плохое приложение является разработка в приближении полного отсутствия пользователя. А уж потом делаются мучительные попытки приклеить адекватный GUI к неудачно выбранной модели.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[7]: Почему настоящие программисты избегают C++
От: Rebus83 Россия  
Дата: 05.03.05 18:35
Оценка: 3 (1) :)
Здравствуйте, VladD2, Вы писали:

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

VD>>>Цссс. А то ведь флэйм получится.
R>>Аааа... так это был ещё не?..

VD>Блин, мы тут Оберонциков перевоспитываем в дотнетчиков, а ты весь воспитательный процесс ломаешь.
Не надо их перевоспитывать. Слишком редко они нынче встречаются. Ещё совсем исчезнут...
... << RSDN@Home 1.1.4 beta 4 rev. 303>> Вокруг тишина
Какая странная планета! — подумал Маленький принц. — Совсем сухая,
вся в иглах и соленая. И у людей не хватает воображения. Они только
повторяют то, что им скажешь...
Re: Только настоящие программисты пишут на С++! :)
От: Кодт Россия  
Дата: 17.02.05 12:58
Оценка: 1 (1) :)
Здравствуйте, d Bratik, Вы писали:

DB>1.Отсутствие модулей. Имитация понятия модуль в виде пары h-файл – cpp-файл приводит к многочасовым компиляциям системы.

1) От компилятора: прекомпиляция заголовков
2) От программиста: идиома pimpl
И всё будет летать.

DB>2.Использование целочисленных типов данных без знака (unsigned int) для номеров элементов и количественных значений в стандартной библиотеке stdc++. Приводит к следующим ошибкам:

DB>
DB>std::vector<int> v;
DB>// Следующий код работает бесконечно, поскольку (size_type)(-1) == 4 млрд.
DB>for (std::vector<int>::size_type i = 0; v.size() - 1; ++i)
DB>{
DB>  ...
DB>}
DB>

Здесь вообще какой-то пьяный бред написан. При чём тут знаковость/беззнаковость?

DB>3.Отсутствие встроенной проверки на выход за диапазоны массива. Приводит к необходимости писать «обертки» для классов-контейнеров (в частности, для класса vector).

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

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

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

DB>5.«Автоматизм» конструкторов и деструкторов для объектов, создаваемых динамически и имеющих виртуальные методы; работа виртуальных методов как не виртуальных при их вызове из конструкторов и деструкторов; отсутствие стандартного базового класса. Значительно затрудняет решение проблемы повторного входа в объекты (reentrance problem) при создании библиотек визуальных компонентов и систем GUI.

DB>6.Отсутствие оператора try {…} finally {…}. Приводит к созданию программ, неустойчивых к исключительным ситуациям. Попытка имитировать этот оператор с помощью оператора try {…} catch {…} приводит к большой избыточности кода.

Вот именно автоматизм конструкторов/деструкторов позволяет обходиться без finally. Причём обходиться очень избирательно.
Пример
Foo *x = NULL;
Bar *y = NULL;
Buz *z = NULL;
__try
{
  x = make_foo();
  y = make_bar();
  z = make_buz();

  work(x,y,z);
}
__finally
{
  // дофига ручной работы
  if(z) free_buz(z); z = NULL;
  if(y) free_bar(y); y = NULL;
  if(x) free_foo(x); x = NULL;
}

////////////////////////

shared_ptr<Foo> x;
shared_ptr<Bar> y;
shared_ptr<Buz> z;

// блок try-finally вообще не нужен!

x = shared_ptr<Foo>( make_foo(), free_foo );
y = shared_ptr<Bar>( make_bar(), free_bar );
z = shared_ptr<Buz>( make_buz(), free_buz );

work(x,y,z);
Перекуём баги на фичи!
Re[10]: Почему настоящие программисты избегают C++
От: screw_cms Россия ICQ: 168185721
Дата: 17.02.05 22:08
Оценка: 1 (1) +1
Здравствуйте, nixite, Вы писали:


MN>>Да согласен — ваша правда... это я поторопился... но как-то у меня такой проблемы никогда не было... наверное потому, что для работы с контейнерами C++ всегда использовал итераторы, а для доступа к массивам в стиле pure C использовал знаковый int и никогда не путал эти понятия между собой, чего и вам советую... ну или если вы моему совету не внемлите, то обращайтесь к С. Ю. Губанову — он вам других советов надаёт

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. я решение знаю, но не сказал бы что оно простое


int kakashka( int a, int b )
{
return (a>>1 + b>>1) + ( ((a&1)&&(b&1))?1:0 );
}
When in doubt, use brute force. © Ken Thompson

Re[10]: Почему настоящие программисты избегают C++
От: Кодт Россия  
Дата: 17.02.05 22:59
Оценка: 1 (1) +1
Здравствуйте, 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;
}
Перекуём баги на фичи!
Re[6]: Почему настоящие программисты избегают C++
От: achp  
Дата: 22.02.05 11:03
Оценка: 1 (1) +1
Здравствуйте, VladD2, Вы писали:

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

Я не вижу здесь ничего "неинтуитивного". В конце концов, с точки зрения математики конструкция
x = x + 1;

тоже не блещет интуитивностью.

Я с правилами машинной арифметики освоился, теперь они для меня вполне интуитивны. Более того, я активно эксплуатирую свойства беззнаковой арифметики по модулю 2^n. Конечно, некоторые конструкции приходится "сооружать" и проверять на листочке бумаги, но от этого пока никто не помирал; бумажечка под рукой — вещь вообще полезная.

VD>Ну, а почему в C++ и C# имеются беззнаковыи и переполнения совершенно понятно. Погоня за эффектиностью. Если плевать на нее, то можно было бы просто ввести тип int который не имел бы размеров и ограничеий (как в Руби и Питоне). А для контроля значений вообще лучше подошел бы тип с ограничениями. Но это не эффективно.

О чём и речь. В погоне за дешёвенькой "интуитивностью" с точки зрения разработчика не стоит заходить слишком далеко, иначе никаких суперкомпьютеров не хватит.
Я кончил, джентльмены, мне остается только поблагодарить вас за внимание.
Re[17]: Почему настоящие программисты избегают C++
От: Cyberax Марс  
Дата: 28.02.05 05:23
Оценка: 1 (1) +1
d Bratik пишет:

> C>ТАКИХ нет. VCL — НЕпотокобезопасна, пора бы уже знать. Естественно, ее
> C>можно использовать в многотредовом окружении, точно так же как и: MFC,
> C>WTL, WinAPI, QT, GTK и прочие. То есть маршалируя графические вызовы в
> C>нужный поток или используя только их потокобезопасное подмножество.
> Вы хоть раз Qt на Солярке пускали? Там Qt (по собственнной вине и по
> вине X11) по определению с многопоточностью не дружит (впрочем,
> разработчики Солярки вообще с головой не дружат, так что создателям Qt
> есть на кого пальцем тыкать).

Ррррррррр..... Да _НИ_ _ОДНА_ распространенная GUI не дружит с
многопоточностью по очень простой причине — ВСЕ они построены на
концепции очереди сообщений (событий, сигналов). Но при этом _ЛЮБУЮ_
современную GUI-систему можно использовать в многопоточной среде, приняв
соответствующие меры.

> C>Ну а в качестве exception-safe — чем MFC или WTL не нравится?
> В моем инструментальном ящике этому отстою нету места. Если мне нужно
> будет сделать программу для Windows, я не раздумывая возьму Delphi и
> VCL (или нынче уже VS.NET с WinForms). Если передо мной цель — сделать
> программу для Solaris и Linux (и в последнюю очередь Windows), то я
> возьму Qt.

Да я и не сомневался...

Ксати, VCL построена на стандартном WinAPI, почти вся ее
функциональность — это лишь достаточно тонкая обертка над виндовыми
вызовами. Только вот VCL пытается (плохо) скрыть свое родство с WinAPI,
а WTL использует это родство себе на выгоду.

>>> Я ставлю проблемы.
> C>Какие? Которых нет?
> Для того, чтобы понять, что проблемы есть и проблемы серьезнейшие,
> нужно принять определенную систему ценностей. После многих лет
> программирования я принял систему ценностей Вирта и проповедую ее.

А, все понятно. Теоретик, оторванный от практики.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[7]: Почему настоящие программисты избегают C++
От: ansi  
Дата: 17.02.05 13:41
Оценка: +1 :)
А ты бы по-простецки писал int i = v.size(); и проблем бы не было.
Короче вывод готов: C++ и d Bratik, так же, как и женщина за рулем, есть эквивалент мартышки с гранатой...
Re[7]: Почему настоящие программисты избегают C++
От: d Bratik  
Дата: 17.02.05 13:42
Оценка: +2
Здравствуйте, Mr. None, Вы писали:

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

DB>>Да что такое сегодня с руками...

MN>Похоже, что не только сегодня...

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>>


DB>>Этот код ошибочен при любом количестве элементов в векторе.

MN>Неправда — проверьте... при 0-ом размере вы не выполните ни одной итерации, потому что проверка условия выполняется перед каждой итерацией, в том числе и первой...

Вот так думает каждый здравомыслящий человек, но увы, переменная i не имеет знака, следовательно значение -1 для нее автоматически преобразуется в 4 млрд... и цикл продолжается.
Re[8]: Почему настоящие программисты избегают C++
От: Mr. None Россия http://mrnone.blogspot.com
Дата: 17.02.05 13:48
Оценка: +2
Здравствуйте, d Bratik, Вы писали:

DB>Вот так думает каждый здравомыслящий человек, но увы, переменная i не имеет знака, следовательно значение -1 для нее автоматически преобразуется в 4 млрд... и цикл продолжается.

Да согласен — ваша правда... это я поторопился... но как-то у меня такой проблемы никогда не было... наверное потому, что для работы с контейнерами C++ всегда использовал итераторы, а для доступа к массивам в стиле pure C использовал знаковый int и никогда не путал эти понятия между собой, чего и вам советую... ну или если вы моему совету не внемлите, то обращайтесь к С. Ю. Губанову — он вам других советов надаёт
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Re: Почему настоящие программисты избегают C++
От: Pazak Россия  
Дата: 17.02.05 15:56
Оценка: :))
Здравствуйте, d Bratik, Вы писали:

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

Э-э-э-э.... Гм... Реальные пацаны объекты ничем кроме нулей, видать, не инициализируют.
Ку...
Re: Почему настоящие программисты избегают C++
От: Awaken Украина  
Дата: 17.02.05 16:26
Оценка: +2
Здравствуйте, d Bratik, Вы писали:

почитал всю ветку — давно так не ржал
это в юмор!
Re[4]: Почему настоящие программисты избегают C++
От: d Bratik  
Дата: 17.02.05 18:07
Оценка: :))
Здравствуйте, _Obelisk_, Вы писали:

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.

Сайт выглядит очень профессионально. Интересно было бы взглянуть на внешний вид самой программы, а также узнать, на чем она написана (Qt?), и поддерживает ли она расширение своей функциональности на каком-нибудь языке программирования.
Re[3]: Почему настоящие программисты избегают C++
От: VladD2 Российская Империя www.nemerle.org
Дата: 18.02.05 00:06
Оценка: +2
Здравствуйте, d Bratik, Вы писали:

DB>Вы наверное писали очень небольшие программы, без GUI. Для создания программ С++ подходит, но для создания систем — нет.

Учитывая, что Винды вообще на С написаны — это конечно серьезное заявление.

С++ подходит для всего. Ну, почти для всего. Так что вопрос только в цене. Уж очень дорого приходится платить за С++-разработку. В итоге или море глюков, или задержки выхода, или и то и другое.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Почему настоящие программисты избегают C++
От: alnsn Великобритания http://nasonov.blogspot.com
Дата: 18.02.05 08:32
Оценка: :))
Здравствуйте, VladD2, Вы писали:

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

K>>Функции, логика которых не предусматривает ошибочных ситуаций, не должны кидать исключений. А функция вычисления среднего арифметического относится как раз к таким. Т.е. предложенное тобой решение с генерацией исключения неверно.

VD>Функция не учитывающая переполенеие уже ошибочна.

Очень серьезные дяди писали на серьезном языке Ada, где есть исключения по переполнению. Результат здесь.
Re[7]: Почему настоящие программисты избегают C++
От: Cyberax Марс  
Дата: 20.02.05 15:13
Оценка: +2
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)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[12]: Почему настоящие программисты избегают C++
От: Cyberax Марс  
Дата: 20.02.05 15:28
Оценка: +2
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)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[4]: Почему настоящие программисты избегают C++
От: Amidlokos Россия  
Дата: 21.02.05 06:59
Оценка: :))
Здравствуйте, Pazak, Вы писали:

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

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

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

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

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

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

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

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

WARNING: expression "to_be || !to_be" is always true
Re[14]: Почему настоящие программисты избегают C++
От: Cyberax Марс  
Дата: 21.02.05 11:01
Оценка: +2
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)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[17]: Почему настоящие программисты избегают C++
От: Кодт Россия  
Дата: 21.02.05 11:38
Оценка: +1 :)
Здравствуйте, Amidlokos, Вы писали:

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

Позволю напомнить три вещи
— Premature optimization is a root of evil. Дейкстра.
— Асимптотики сложности алгоритмов. vector::size() — O(1), и не такой уж здоровый у него коэффициент на фоне остального тела цикла.
— Профайлер.
Перекуём баги на фичи!
Re[7]: Почему настоящие программисты избегают C++
От: VladD2 Российская Империя www.nemerle.org
Дата: 22.02.05 22:23
Оценка: -2
Здравствуйте, achp, Вы писали:

A>Во всех случаях, когда я сталкивался с необходимостью контролировать переполнение, сам факт переполнения был вещью ожидаемой, не катастрофической для хода вычислений и, хоть и требовал специальной обработки, не служил поводом для исключения. Мне важней было бы иметь некую операцию, скажем, сложения, которая, уподобляясь команде АЛУ, не только бы давала результат, но и формировала бы логический признак — флаг переноса, а не исключение.

Просто там где ты не ожидал переполнения у тебя были глюки. Я же не даром привел простой пример:
a - b

казалось бы... что тут ожидать? Ан нет тебе может быть.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Почему настоящие программисты избегают C++
От: d Bratik  
Дата: 23.02.05 09:35
Оценка: -1 :)
Здравствуйте, Cyberax, Вы писали:

C>d Bratik пишет:

>> A>99% приложений под винду написаны на C++.
>> A>из того что использую каждый день — Visual Studio, MS Office, Adobe
>> Photoshop, Discreet 3DS Max
>> A>лидеры в области коммерческого ПО почему-то не пишут на Дельфях хотя
>> это проще и удобнее. неспроста
>> A>из того что я использую только TOAD на Дельфях.
>> И все же я пока не видел ни одной промышленной GUI бибилиотеки на С++,
>> которая бы отдаленно приближалась по качеству к VCL и .NET Framework.
>> Обыскал весь Интернет — таковой в природе нет.

C>MFC, WTL, raw WinAPI, GTK. _Качество_ у них ничуть не хуже.

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

C>А к интуитивности использования _библиотека_ отношение имеет весьма
C>слабое, важна среда. Тот же Glade для GTK позволяет интуитивно рисовать
C>интерфейсы на чистом С.

Если образцом для подражания Вы считаете "raw WinAPI" (а также GTK и MFC), то нам не о чем больше спорить.
Re[12]: Почему настоящие программисты избегают C++
От: Kh_Oleg  
Дата: 23.02.05 11:57
Оценка: :))
Здравствуйте, Cyberax, Вы писали:

>> C>CPrettyButton — это моя кнопочка, которая умеет менять свой шрифт,
>> C>цвета, работать как push-like-button и т.п.
>> В Вилариба уже давно сменили стандартное свойство у стандартного
>> контрола,
>> а в Вилабаджо все еще пишут свои классы для кнопочек.

C>Нет, Вилабаджо уже давным-давно знают про сайт
C>http://www.codeproject.com/ и уже давно скачали кучу всяких контролов
C>(там есть и поддержка изменения шрифтов:
C>http://codeproject.com/wtl/wtlwindowfont.asp).

Вот мы и приехали к тому, откуда начали — нету для С++ нормальных библиотек для GUI.
Потому что для элемнтарных действий надо что-то откуда-то качать или
писать экраны кода.
Re[13]: Почему настоящие программисты избегают C++
От: Cyberax Марс  
Дата: 23.02.05 12:06
Оценка: +2
Kh_Oleg пишет:

> C>Нет, Вилабаджо уже давным-давно знают про сайт
> C>http://www.codeproject.com/ и уже давно скачали кучу всяких контролов
> C>(там есть и поддержка изменения шрифтов:
> C>http://codeproject.com/wtl/wtlwindowfont.asp).
> Вот мы и приехали к тому, откуда начали — нету для С++ нормальных
> библиотек для GUI.
> Потому что для элемнтарных действий надо что-то откуда-то качать или
> писать экраны кода.

А какие проблемы скачать контрол?

WTL по своей сути — это barebone-система, дающая самый минимум
функциональности (и маленькие исполняемые файлы, соответственно), на
которой уже можно строить почти что угодно. И мне нафиг не нужно, чтобы
в дистрибутив WTL включались всякие красивоукрашенные кнопочки и т.п.

А вот как Дельфисты выпадают в осадок, когда нужно сделать что-то
нетривиальное и не находится нужный контрол — я прекрасно знаю.

Вот в GTK ничего качать не надо — там у виджетов можно явно назначать
шрифты.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[14]: Почему настоящие программисты избегают C++
От: Kh_Oleg  
Дата: 23.02.05 12:44
Оценка: -1 :)
Здравствуйте, Cyberax, Вы писали:

>> C>Нет, Вилабаджо уже давным-давно знают про сайт
>> C>http://www.codeproject.com/ и уже давно скачали кучу всяких контролов
>> C>(там есть и поддержка изменения шрифтов:
>> C>http://codeproject.com/wtl/wtlwindowfont.asp).
>> Вот мы и приехали к тому, откуда начали — нету для С++ нормальных
>> библиотек для GUI.
>> Потому что для элемнтарных действий надо что-то откуда-то качать или
>> писать экраны кода.

C>А какие проблемы скачать контрол?
А проблемы в том, что скачать контрол — это самая простая часть Марлезонского балета.
Еще надо убедиться, что он работает правильно, стабильно и надежно.
Если это не тривиальная кнопочка, то время поиска и тестирования нужного компонента
может поставить под угрозу весь проект.

А какие проблемы самому написать? — скажет мой оппонент. — Вечно эти
дельфисты (хотя причем здесь Delphi, разве я его упоминал?) ни черта писать не умеют,
а только требуют: "Дайте мне компоненту".

Вот тут упоминали, что куча продуктов (Office, Adobe family, etc.) написана на С++. Написана, но в каждом
случае разработчикам приходилось писать свой framework конкретно под свой продукт (или семейство продуктов).

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

Вывод: для С++ нет нормальной (надежной и полнофункциональной) библиотеки для GUI.

C>WTL по своей сути — это barebone-система, дающая самый минимум
C>функциональности (и маленькие исполняемые файлы, соответственно), на
C>которой уже можно строить почти что угодно. И мне нафиг не нужно, чтобы
C>в дистрибутив WTL включались всякие красивоукрашенные кнопочки и т.п.
Ассемблер предоставляет еще большие возможности, а программы на нем получаются еще меньше,
так что это отнюдь не достоинство данной библиотеки.
Re[17]: Почему настоящие программисты избегают C++
От: Amidlokos Россия  
Дата: 23.02.05 13:53
Оценка: +2
Здравствуйте, Kh_Oleg, Вы писали:

K_O>Можно ли взглянуть на следующие визуальные компоненты, написанные на С++:
K_O>1. TreeView, который не поперхнется от ста тысяч элементов и не будет
K_O> причиной даже полусекундной задержки при отображении на экране, а также
K_O> массивных вставках и удалениях. Сортировка тоже нужна.
K_O>2. ListView с аналогичными требованиями.
K_O>3. PropertyEditor.

Хочешь сказать, этим требованиям удовлетворяет VCL-ный tree и list?

C>>Нет. Базовый MFC используется почти везде в новых продуктах. А вот в
K_O>Ссылки в студию.

Зачем ссылки, Spy натрави на окошко...

K_O>Наша сказка хороша — начинай сначала. Только что подробно разобрали, почему конкретно
K_O>MFC нельзя использовать для разработки

Гхм... я прослушал. Ещё раз, пожалуйста.
WARNING: expression "to_be || !to_be" is always true
Re[23]: Почему настоящие программисты избегают C++
От: Amidlokos Россия  
Дата: 23.02.05 16:23
Оценка: +1 :)
Здравствуйте, Kh_Oleg, Вы писали:

A>>Кроме того — ну, а где (повторю это любимое слово) ссылка-то на этот дельфовский суперкомпонент?
K_O>VirtualTreeview
K_O>XtraVerticalGrid Это PropertyEditor.

В случае с первым — и на каком скриншоте видно более 10000 нодов без тормозов? А главное — где при этом видно, что всей обработкой занимается контрол?

А второе — так это ж вроде .NET? А такое там уже есть в WinForms...

З.Ы. Информация для размышления — нажми Win+R, вбей "regedit", нажми enter и полюбуйся на такой TreeView. Уверяю, это не Delphi
WARNING: expression "to_be || !to_be" is always true
Re[8]: Почему настоящие программисты избегают C++
От: achp  
Дата: 24.02.05 06:08
Оценка: :))
Здравствуйте, VladD2, Вы писали:

VD>Просто там где ты не ожидал переполнения у тебя были глюки.

О! Теперь я знаю, что такое Remote Debugger. Точнее, кто такой.
Я кончил, джентльмены, мне остается только поблагодарить вас за внимание.
Re[2]: Почему настоящие программисты избегают C++
От: Кирпа В.А. Украина  
Дата: 24.02.05 08:57
Оценка: -2
Здравствуйте, AlexEagle, Вы писали:

И еще наверное любят Делфи за отсуствие операции целочисленного деления
PS
Предлагаю этот список вынести на отдельную страничку форума Пусть любители Делфи читают и гордятся
!0xDEAD
Re[11]: Почему настоящие программисты избегают C++
От: AndrewJD США  
Дата: 24.02.05 09:25
Оценка: +2
Здравствуйте, d Bratik, Вы писали:

DB>Объясните, какого черта в Windows и в MFC для обычного окна и окна диалога существуют разные классы объектов?!
Для удобства. Тем более что диалог наследуется от окна и расширяет его функциональность.

DB>Ведь отличие лишь в модальности, т.е. в режиме показа.
Это утверждение не соответствует действительности.

DB>Прежде, чем Вы броситесь это обосновывать, подумайте, почему в .NET Framework, который делался намного позже Windows и MFC, все совсем не так и ОЧЕНЬ напоминает VCL?
А вот мне например напоминает VB . Учитывая, что ниша VB на рынке гораздо больше, чем у дельфей и это продукт от MS, можно вполне уверено говорить о наследии VB в .NET Framework
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Re[25]: Почему настоящие программисты избегают C++
От: Cyberax Марс  
Дата: 24.02.05 11:43
Оценка: +1 :)
Kh_Oleg пишет:

> A>А второе — так это ж вроде .NET? А такое там уже есть в WinForms...
> А это только мои оппоненты кричат: "Delphi! Delphi!". Я лишь показал,
> что на нормальной платформе, будь то Delphi или .NET есть нормальные
> инструменты для работы, а С++ этого лишен.
> Но для VCL версия там также имеется.

Учимся ращличать язык и платформу. Хотя, конечно, дельфистам этого не
понять — они навечно обречены перетаскивать контролы на формочке.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[8]: Почему настоящие программисты избегают C++
От: d Bratik  
Дата: 25.02.05 12:03
Оценка: -1 :)
Здравствуйте, Awaken, Вы писали:


DB>>И все же я пока не видел ни одной промышленной GUI бибилиотеки на С++, которая бы отдаленно приближалась по качеству к VCL и .NET >Framework. Обыскал весь Интернет — таковой в природе нет. Qt более-менее ничего, но когда основательно начинаешь пользовать, начинаешь >плеваться.

A>дался тебе этот ГУЙ! в любой мало мальски сложной программе гуй это 1-10% всей задачи.
A>я как-то участвовал в разработке музыкального редактора. это система распознавания и визуализации нотных записей , как положено
A>на линейках нотного стана, каждая нота на своей высоте. самое сложное тут это не нарисовать эти ноты — а алгоритмы как их представить
A>в виде векторной графики, масштабировать, сериализовать в двоичные файлы , и т.д.
A>писано все было на VC++ 6.0 и MFC, и впоследствие портировано на Макинтош.
A>это я к тому что в сложной задаче на первом месте алгоритмы, а не библиотеки примитивов (они сводятся к набору достаточно низкоуровневых функций, которые можно — и нужно — изолировать в отдельный слой и абстрагировать от основной логике)

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

GUI (framework) — это огромная архитектурная сложность.
Re[16]: Почему настоящие программисты избегают C++
От: d Bratik  
Дата: 26.02.05 18:03
Оценка: -1 :)
Здравствуйте, Cyberax, Вы писали:

C>d Bratik пишет:

>> G>чего они от тебя НЕ ждут (ведь ты же не имеешь привычки кидать
>> исключения из деструктора?)
>> G>И вообще, многопоточность — это отдельная песня. С каждой
>> библиотекой можно работать в многопоточной среде, просто надо соблюдать
>> G>ряд правил для этого. STL вон тоже не многопоточная если на то пошло...
>> Речь идет о моногопоточном, exception-safe GUI. Мне это позарез нужно.
>> Таких библиотек (промышленных) только две: .NET framework и VCL (там
>> все хуже, но все равно есть).

C>ТАКИХ нет. VCL — НЕпотокобезопасна, пора бы уже знать. Естественно, ее
C>можно использовать в многотредовом окружении, точно так же как и: MFC,
C>WTL, WinAPI, QT, GTK и прочие. То есть маршалируя графические вызовы в
C>нужный поток или используя только их потокобезопасное подмножество.

Вы хоть раз Qt на Солярке пускали? Там Qt (по собственнной вине и по вине X11) по определению с многопоточностью не дружит (впрочем, разработчики Солярки вообще с головой не дружат, так что создателям Qt есть на кого пальцем тыкать).

C>Ну а в качестве exception-safe — чем MFC или WTL не нравится?

В моем инструментальном ящике этому отстою нету места. Если мне нужно будет сделать программу для Windows, я не раздумывая возьму Delphi и VCL (или нынче уже VS.NET с WinForms). Если передо мной цель — сделать программу для Solaris и Linux (и в последнюю очередь Windows), то я возьму Qt.

>> Я ставлю проблемы.

C>Какие? Которых нет?

Для того, чтобы понять, что проблемы есть и проблемы серьезнейшие, нужно принять определенную систему ценностей. После многих лет программирования я принял систему ценностей Вирта и проповедую ее.
Re[19]: Почему настоящие программисты избегают C++
От: Cyberax Марс  
Дата: 28.02.05 05:18
Оценка: +1 :)
d Bratik пишет:

> A>И тебя вылечат...
> Я сам доктор, между делом студентов лечу. Бесплатно избавляю от
> синдрома страуструпа, комплекса "best industry practice", а также GUI-
> и DBMS-фобий. Так что обращайтесь

Нда... А потом еще люди жалуются на качество IT-образования в Росиии....

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[8]: Почему настоящие программисты избегают C++
От: Pazak Россия  
Дата: 04.03.05 07:58
Оценка: +1 :)
Здравствуйте, transglucator, Вы писали:

T>жена — Pascal
T>проститутка — C++
T>любовница — ?

Любовница — это типа "для души"? Тогда однозначно python!
Ку...
Re[10]: Почему настоящие программисты избегают C++
От: Pazak Россия  
Дата: 21.03.05 22:15
Оценка: :))
Здравствуйте, AVC, Вы писали:

AVC>>>Ответ: Неадкватность языков и компиляторов, использованных в написании операционной системы (C и C++). [/q]
P>>Плохому танцору... Кстати интересно, неужели в MS не нашлось ни одного человека, знаюцего про Оберон? Сомневаюсь... Видать показался еще более "неадекватным".
AVC>Угу. Показался настолько неадекватным, что Microsoft начала настоящую "охоту" на "оберонщиков".

Боюсь ты не понял "глубины вопроса" На момент написания Windows (не .Net, а именно Windows, старой доброй надстройки над DOS) Оберон вроде уже существовал. Однако мелкософтом оказался невостребован, заюзали C/C++. На момент написания Win95 — уж точно оберон не просто был, а был уже довольно хорошо раскручен. И снова — мимо кассы, не заинтересовал, решили придерживаться старой испытанной технологии. Но стоп, ведь кроме нее была еще New Technology a/k/a Win NT, казалось бы там-то сам бог велел использовать все самое прогрессивное, включая язык? Да нет, и тут — старый добрый C[++]... Теперь вот надо понимать MS спохватились и решили отказаться от пережитков? ИМХО поздновато, больше похоже на попытку списать свои старые ошибки на "неудачный компилятор" и заодно попиарить свои новые технологии. А насчет того, что оберонщиков юзали при написании .Net — разве ж я возражаю? Было бы странно, если б не юзали — как-никак академический проект с многолетней историей. Одного того, что они уже набили много шишек — достаточно чтоб взять их в проект, за одного битого, как известно, двух небитых дают.

AVC>Среди представленных летом 2000г. 12 компиляторов для .NET было 2 Оберона: Oberon-2 и Component Pascal. (Поговаривают, что только они и работали без ошибок. )

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


AVC>Уже говорилось, что программисты на Си++ — снобы и зазнайки.
AVC>Разве неверно говорилось?

ХЗ, я на нем не программирую. Во всяком случае профессионально.
Ку...
Re[8]: Почему настоящие программисты избегают C++
От: Erop Россия  
Дата: 20.05.05 06:19
Оценка: +1 -1
Здравствуйте, AVC, Вы писали:

AVC>См. страничку:
AVC>http://www.inr.ac.ru/~info21/blackbox/disciplina/arr_bounds_checks.htm
AVC>Вот выдержка:

Вопрос: Что мешает Майкрософт компилировать Windows XP с включенной опцией контроля выхода за границы массивов?
AVC>Ответ: Неадкватность языков и компиляторов, использованных в написании операционной системы (C и C++).
Мне кажется, что эта цитата доказывает степень адекватности того самого представителя науки, который школе
Всё-таки C разработали именно дл янаписания операционки. Трудно найти более подходящие языки для этой области
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[18]: А всё-так чем же pascal дгчше для GUI библиотек-то?
От: Kh_Oleg  
Дата: 26.05.05 12:21
Оценка: -1 :)
Здравствуйте, Пацак, Вы писали:

E>>>Наверное в паскалеподобных языках есть что-то, что позволяет писать афигительные GUI библиотеки. Интересно что же это такое?
K_O>>События,

П>Ето не фича языка, это фича ОСи (если имеются в виду всякие WM_PAINT) или фича библиотеки (если имеются в виду всякие OnClick). Во всяком случае никто не помешал реализовать ту же идеологию в совершенно непаскалеподобном builder'е.

Ну, во-первых, не следует путать сообщения Windows и события. Во-вторых, события — это для Win32 именно фича языка, которую на С++ реализовать нормально невозможно. Чтобы С++Buildere реализовать события пришлось измененить язык. Тот С++, который там используется со стандартом несовместим.

K_O>>try...finally,
П>А гуи тут при чем?

try...finally обеспечивает гарантированный вызов finalization кода даже в тех случаях, когда в блоке try произошла исключительная ситуация. Причем в блоке finalization допускается возникновение еще одной исключительной ситуации, что недопустимо в С++ если использовать для этой цели scope guards. Причем здесь GUI? А притом, что нормальный GUI немыслим без многопоточности. Где многопоточность — там и объекты синхронизации. И вот тут finally очень помогает.

K_O>>информация о типах...

П>И что, таки только в паскалях есть?
Еще есть на платформах Java и .NET. Но для Win32 — только в Delphi.
Re[22]: поддержка компонентной разработки
От: Sinclair Россия https://github.com/evilguest/
Дата: 30.05.05 03:52
Оценка: +2
Здравствуйте, Erop, Вы писали:

E>А если я правильно понимаю, кто такая "поддержка компонентной разработки", то это в основном требования к среде, а не к языку.
Нет, это в основном требования к языку. В язык встроены:
— паттерн Factory в виде комбинации указатель на класс/виртуальный конструктор.
— паттерн Observer в виде замыканий, или event handler в терминологии Delphi
— генерация метаданных, пригодных для подсистемы сериализации
Таким образом, язык помогает разрабатывать компоненты, поддерживаемые средой. Я в курсе, что аналоги можно построить на С++. Правда, они будут более многословны.
E>Таки я не понимаю, что же не так в C++ именно с компонентной разоработкой
Ну, я тебе сочувствую. Мне лень пересказывать все эти флеймы. В С++ отсутствуют метаданные, нет встроенных средств динамической линковки, шаблоны только-только начинают уметь существовать в бинарном виде... А ты все не понимаешь, что же там не так. Для понимания достаточно посмотреть на стоимость реализации IDispatch на С++. А это как раз та самая компонентная разработка без поддержки со стороны языка. Даже самые суперрешения все равно требуют многословных описаний, применения макросов и прочих малоприятных приемов.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[29]: Почему настоящие программисты избегают C++
От: Erop Россия  
Дата: 01.06.05 22:10
Оценка: +1 -1
Здравствуйте, AVC, Вы писали:

AVC>Вот мнение астрономов, авторов книги "Астрономия на персональном компьютере":

Здесь надо сказать, что по сравнению с другими языками C++ имеет много недостатков, которые затрудняют разработку сложных научных программ. В частности, у него слабая поддержка одномерных и многомерных массивов, нет локальных процедур, неудачная концепция модуля, не поддерживается проверка индексов массивов, а также выполняется неконтролируемое преобразование типов.
Ну я согласен, что у C++ много недостатков. Главный из них -- программирование на нём требует изучения как это делать. Так что он плохо подходит для физиков или биологов. Но я, как выч. матьематик, сообщу, что программирование для людей этих специальностей обычно по многим причинам мало подходит

А если делать большой проект на C++, то есть некоторая уверенность, что удастся разрешить все проблемы, потому что у тебя есть все силы и средства для этого. От того так эту самую преславутую гибкость в купе с мощью и любят. Хотя это и влечёт за собой то, что разработка на C++ требует наличия инструкции
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[20]: Почему настоящие программисты избегают C++
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 03.06.05 10:13
Оценка: +1 :)
Здравствуйте, Sinclair, Вы писали:

E>>А вот будет ли этот index out of bounds exception менее пагубным -- еще вопрос.
S>Никаких вопросов. Проход по памяти -> обрушение процесса. Для десктоп-приложения index out of bounds — не менее смертелен, потому как если он не обработан (а он нифига не обработан), то инварианты нарушены, и с вероятностью 70% любое следующее действие пользователя приведет к наведенной ошибке. Остается только маленький шанс, что "сохранить изменения" все еще будет доступно

Не всегда. Если в C++ мы ошиблись с индексом всего на единичку, то с большой вероятностью мы ничего не убъем. А вот в C#/Java out of range 100% гарантирован

E>>Так что проблема в использовании магических констант (что от языка не зависит), а уже следствия в разных языках могут быть разные. И не обязательно в C++ они будут самыми катострофическими, имхо.
S>А вот на сервере в неуправляемой среде проход по памяти проносится по всем потокам как метеор, оставляя неконтролируемые разрушения для всех пользователей.

Это если мы идем по хипу и в большом диапазоне. А ведь в C/C++ память может и на стеке выделяться. И тогда мы за рамки одного потока можем и не выйти.

S>Управляемое приложение уронит одну пользовательскую сессию; более того — в steteless модели это затронет только один текущий request. Пользователь давит back в браузере и продолжает работать. Подобный сбой в неуправляемом коде может убить весь сервер.

Если сервер написан на отдельных cgi, то не убъет.

Я это к тому, что ошибки выхода за пределы своей памяти в C++ опасны как раз не потому, что они вызывают мнгновенный сбой. А потому, что они этот сбой могут провоцировать в будущем, в какой-то почти случайный момент времени.

А исходный посыл в том, что если на C++ писать нормально (без hardcoding-а магичесих чисел в том числе), то и проблем особых не будет. Плюс к тому, программирование на C++ действительно дисциплинирует. И после C++ можно без проблем программировать на чем угодно, включая C# и Java. А вот обратное не верно, ибо C++ разгильдяйства и раздолбайства не прощает.

SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[5]: Почему настоящие программисты избегают C++
От: _Obelisk_ Россия http://www.ibm.com
Дата: 18.02.05 06:44
Оценка: 3 (1)
Здравствуйте, 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[26]: Почему настоящие программисты избегают C++
От: Kh_Oleg  
Дата: 03.03.05 15:40
Оценка: 3 (1)
Здравствуйте, Cyberax, Вы писали:

>> C>Имена, фамилии, явки учеников Вирта, создавших .NET (точнее
>> слизавших ее
>> C>архитектуру с Java) ....
>> Например, Шиперски (Sziperski) — один из основателей Oberon Microsystems.

C>И? Гугл выдает на нее 10000 ссылок, и даже сайта на английском у них нет.
Есть, искал плохо:
Clemens Szyperski at Microsoft Research

>> Поправочка: именно Java слизана с Оберона.
C>Java ни с чего не слизана — она весьма отличается от Оберона (одно лишь
C>наличие GC и системы пакетов — не признак слизанности).

Ну а вот что говорят инженеры из Sun Microsystems, Robert Griesemer & Srdjan Mitrovic:

Not coincidentally, the compilers developed by Niklaus Wirth for Modula-2 and Oberon followed a similar guideline [achievement of 80% of the performance of the server VM with 20% of the effort]. We have studied those compilers extensively and have borrowed ideas literally.

Статья называется "A compiler for the Java HotSpot(tm) Virtual Machine". К сожалению в онлайне текст это статьи найти не смог, только реквизиты. Опубликована в книге "The School of Niclaus Wirth: The Art of Simplicity".
Re[12]: Почему настоящие программисты избегают C++
От: ddanila Россия  
Дата: 18.02.05 13:10
Оценка: 1 (1)
N>В стандарте C++ нет типа long long ! это всё мелгомягкие дополнения :) решения есть но ещё кривее :))

6.1.2.5 Types

3 There are five standard signed integer types,
designated as signed char, short int, int, long int, and
long long int. (These and other types may be designated in
several additional ways, as described in 6.5.2.) There may
also be implementation-defined extended signed integer
types.25 The standard and extended signed integer types are
collectively called just signed integer types.

Re[16]: Почему настоящие программисты избегают C++
От: Amidlokos Россия  
Дата: 21.02.05 07:09
Оценка: 1 (1)
Здравствуйте, qwertyuiop, Вы писали:

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

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

WARNING: expression "to_be || !to_be" is always true
Re[12]: Почему настоящие программисты избегают C++
От: The Lex Украина  
Дата: 24.02.05 11:07
Оценка: 1 (1)
Здравствуйте, sc, Вы писали:

sc>В Windows все элементы гуи, окна, это судя по названию...


А теперь "фишка": а вот в Дельфи не все элементы гуи являются окнами Windows!

Классно, да?! Пишешь-пишешь "под Виндоуз", а потом — раз! — а Виндоуза-то тут и нету-то! И весь опытъ под Виндоуз — очень правильный и очень полезный, потому как очень правильно, полезно и предсказуемо работоспособный вот уже который год на всех подручных "Виндоузах" (ладно: здесь embedded не в счет...) — идет коту под хвост, потому как есть "правильная реализация библиотеки GUI"...
Голь на выдумку хитра, однако...
Re[27]: Почему настоящие программисты избегают C++
От: _Obelisk_ Россия http://www.ibm.com
Дата: 24.02.05 13:02
Оценка: 1 (1)
Здравствуйте, Kh_Oleg, Вы писали:

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

A>>И вместе с тем попрошу себе не противоречить C/С++? Без сомнения! Сделан офигительный интерфейс? Сделан! Так что и этот пример вполне подойдёт, разве что не в номинации "MFC"...
K_O>Не подойдет. Бибилиотеку для создания такого "офогительного" интерфейса MS разработчикам не предосталяет. Речь шла не о GUI на С++, а о библиотеке для GUI на С++.

Никто никогда никому не даст библиотеку делающию "офигительный" интрефейс. Если кто-то такую библиотеку предоставил, то либо она будет стоит БОЛЬШИХ денег, либо ее производитель может сделать еще более "офигительный" интерфейс, не реализуемый данной библиотекой, либо библиотека решает не все задачи.
"Офигительный" интерфейс — это конкурентное преимущество, им так просто не разбрасываются.


Душа обязана трудиться! (с) Н.Заболоцкий.
Re[18]: Почему настоящие программисты избегают C++
От: Кодт Россия  
Дата: 25.02.05 17:08
Оценка: 1 (1)
Здравствуйте, Cyberax, Вы писали:

>> Другое дело, что заставлять несколько потоков драться за один
>> графический контекст — это маразм...

C>Еще очень забавный опыт: создать в одном потоке дочернее окно с
C>родителем в другом потоке.

Вот только что опыт ставил. Результат — мрачный, но (через пень-колоду) работает.
Перекуём баги на фичи!
Re[26]: Почему настоящие программисты избегают C++
От: AVC Россия  
Дата: 03.03.05 17:24
Оценка: 1 (1)
Здравствуйте, Cyberax, Вы писали:

C>AVC пишет:
>> Поправочка: именно Java слизана с Оберона.

C>Java ни с чего не слизана — она весьма отличается от Оберона (одно лишь
C>наличие GC и системы пакетов — не признак слизанности).

Не только GC.
Я просто беру и сопоставляю конструкции Оберона и Java.
Почти один в один!
В Си++ есть объединения (union). В Обероне — нет. В Java — тоже нет.
Применение instanceof в Java — полная копия Обероновского IS.
И так с десяток заимствованных свойств, причем самых важных, существенных, деляющих Java "надежным языком".
Дома где-то пылится список "случайных совпадений".
Я когда разбирался с этим вопросом, просто взял и сопоставил конструкции языков.
И все стало ясно.

>> По поводу того, как используется Оберон, см. хотя бы презентации,
>> представленные на дне Оберона в ЦЕРНе:
>> http://cern.ch/oberon.day
C>Больше всего посмеялся над: "*Benchmark:* Component Pascal vs C++ in a
C>real-world physics problem"...

Ну что же, давайте посмеемся вместе.
Когда-то Вы уверяли, что сами видели компилятор Си++, умещающийся в 20K. Вы и сейчас будете это утверждать?
В конце 90-х по результатам тестов компилятор XDS обскакал все компиляторы Си++.
Я проверил на тех компиляторах Си++, что есть у меня. Правда.
Вы уверяете, что MSVC 8 (beta) в 12 (!) раз эффективнее, чем MSVC 6.0.
У меня пока нет этой версии, но я в это не верю. (А кто верит?)
Теперь по существу дела. Почему Оберон в ЦЕРНе. Читаем:
http://www.inr.ac.ru/~info21/info/fvtjmlc2003r.htm

В лаборатории CERN [26], начиная с 1994 была сделана попытка создать стандартную платформу для программирования на основе C++ в рамках мега-проекта LHC (Large Hadron Collider — Большой Адронный Коллайдер; 2006-2020).
Нет нужды объяснять, что C++ не может обеспечить решение перечисленных выше проблем из-за критических дефектов дизайна и экстравагантной сложности. В коллективах физиков даже имели место конфликты по поводу C++, и ряд специалистов не спешит переключаться на чрезмерно сложный C++, предпочитая пока оставаться с фортраном. Фактический провал C++ иллюстрируется разработанной в CERN библиотекой ROOT для анализа и визуализации данных [18]; библиотека, написанная на C++, печально известна своей способностью генерировать фатальные ошибки.[3]

Очевидно, продуманный минимализм средств является ключевым требованием, если мы хотим, чтобы язык программирования мирно «уживался» в мозгу исследователей со всей необходимой физикой, математикой и проч. знаниями.


[3] В марте 2003 достаточно несложная прикладная программа, использующая ROOT (под управлением ОС Linux), для обработки и довольно простой визуализации данных по космическим лучам сгенерировала три ошибки типа segment violation за менее чем пять минут демонстрации. Другой пример: многоопытный и весьма уважаемый программист сменила специализацию, чтобы не иметь дела с постоянно «грохающимся» программным обеспечением, написанным на C++, работа с которым напоминает работу на больших ЭВМ советского производства в 80-х гг., когда ЕС-1060 «зависала» каждые 15-30 минут.


В общем, как пишет Метцелер,

C is a good bug generator.


Во время дискуссии об Обероне я приводил ряд "багов" прямо "с места происшествия".
С тех пор их количество возрасло.

>> Обратите внимание, например, на такие презентации
>> http://ftkachov.home.cern.ch/ftkachov/talks/ftkachov.pdf
>> (использование Оберона в РАН)
>> http://www.amadeus-3.com/cern/background.pdf (тот самый Метцелер, в
>> одиночку создавший множество программ для ряда крупнейших компаний: Du
>> Pont, Deutsche Bank и т.д.)

C>Мы сейчас тоже создаем программы для Porsche и Du Pont. И что из этого?

Разница в том, что у Вас — "мы", а там человек может сказать — "я".

>> Впрочем, сколько бы я не привел аргументов, Вы их проигнорируете, так
>> как, по Вашему собственному признанию, Вы — фанат Си++.
C>Я скорее антифанат Pascal-подобных языков...
C>Мне нравятся еще OCaml, Haskell и даже Java и C#.

Java и C# идут по стопам Оберона.
Значит ли это, что Вам просто не нравится присать BEGIN и END?

>> Вообще-то, я думал, что пустые словопрения по поводу Оберона закончились.
>> Лично я перешел к практическому использованию этого языка. (DLL сейчас
>> пишу именно на Обероне.)
>> Жизнь продолжает подбрасывать мне примеры, что Си++ снижает надежность
>> программ и производительность программистов. Но если уж Си++ *так*
>> нравится, то ради Бога — дело Ваше.
C>У меня примеры обратные — где всякие экзотические "надежные" языки типа
C>Python'а валили проект.

А что, Python — надежный язык?
Я просто не в курсе.

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

Хоар
Re[24]: Почему настоящие программисты избегают C++
От: AVC Россия  
Дата: 11.03.05 17:15
Оценка: 1 (1)
Здравствуйте, Cyberax, Вы писали:

>> Кстати, Вы вот в Интернет на форумы ходите, а поди даже не знаете, что
>> телефонные станции и спутники связи, через которые Ваш трафик идет, на
>> Модуле-2 работают. И когда на самолете летите, не знает, что авионика
>> тоже на Модуле-2 работает.

C>ССЫЛКИ, ССЫЛКИ, ССЫЛКИ, ССЫЛКИ! Где? Вот уж не верю я, что на
C>коммерческих спутниках связи используется Модула-2. Знаю, что
C>используется Ада и С, про Модулу-2 не слышал.

Вот ссылка:
http://www.inr.ac.ru/~info21/info/koltashev.jpg

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

Хоар
Re[8]: Почему настоящие программисты избегают C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 14.03.05 17:09
Оценка: 1 (1)
Здравствуйте, AVC, Вы писали:


AVC>Однако, в этом же интервью Хейлсберг говорит:

Одно из ключевых отличий С# от других языков, в частности Java, в том, что мы пытались как можно больше приблизиться к C++. C# наследует большинство операторов, ключевых слов и выражений напрямую из С++.

Вот и пойми их загадочные неславянские души...
Имеется ввиду такие фичи как перегрузка операторов, адресная арифметика в унсэйв режиме, аналог вариантной записи через аттрибуты FieldOffset, введение дженериков. Если первые три фичи используются редко, то дженерики появились и в Яве.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Re[13]: Почему настоящие программисты избегают C++
От: AlexEagle Украина http://www.vik.oil
Дата: 28.03.05 07:50
Оценка: 1 (1)
Здравствуйте, Eugeny__, Вы писали:

E__>...можно ли себе где-нибудь скачать?

Фантастика на 2-м этаже
Re[7]: C++ как язвк поэта
От: Erop Россия  
Дата: 20.05.05 06:15
Оценка: 1 (1)
Здравствуйте, AVC, Вы писали:

AVC>То, что большинство (конечно, не все) программистов на Си++ — "снобы", это правда.
AVC>Я общаюсь практически только с Си++никами (т.к. сам пишу на Си++), так что могу это подтвердить, исходя из опыта.

А может просто не попёрло с коллегами?
Лично я знаю много людей, которые программируют на C++, правда они не воспринимают его как что-то такое важное для них лично. Обычные люди. Разные. Снобов тоже видал. Обычно они очень любят итераторы, шаблоны, Александреску, те, кто знают, любят boost (ил инаоборот ненавидят) и плодят какой-то очень сложный для понимания средним программистом на C++ код.
Правда я не стал бы их называть "настоящие программисты", потому что такой программист -- это в первую очередь хороший инженер.

Мне кажется, что такойц программист в первую очередь должен ценить два свойства кода:
1) Простота.
2) Лбой человек подойдёт и разберётся и поймёт, например, как багу поправить, или как к своей задаче адаптировать.

А "гибкость" и "красота" ценностями не являются. Ну а если являются, то это скорее ворма литературы илит поэзии.
Такие "поэтические программисты" обычно снобы. Но разве они настоящие?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re: Почему настоящие программисты избегают C++
От: UGN  
Дата: 17.02.05 12:23
Оценка: +1
Здравствуйте, d Bratik, Вы писали:

DB>2.Использование целочисленных типов данных без знака (unsigned int) для номеров элементов и количественных значений в стандартной библиотеке stdc++. Приводит к следующим ошибкам:

DB>std::vector<int> v;
DB>// Следующий код работает бесконечно, поскольку (size_type)(-1) == 4 млрд.
DB>for (std::vector<int>::size_type i = 0; v.size() - 1; ++i)
^^^^^^
      Это вообще какой-то маразм

Используй итераторы.
Если хочешь индексы, то пиши так:
for (std::vector<int>::size_type i = 0; i < v.size(); ++i)


DB>3.Отсутствие встроенной проверки на выход за диапазоны массива. Приводит к необходимости писать «обертки» для классов-контейнеров (в частности, для класса vector).

А нафиг встроенная поддержка? Если сильно нужно используй STLport в debug режиме

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

А ты предлагаешь инициализировать память два раза: один раз нулями, потом актуальными начальными значениями?

DB>6.Отсутствие оператора try {…} finally {…}. Приводит к созданию программ, неустойчивых к исключительным ситуациям. Попытка имитировать этот оператор с помощью оператора try {…} catch {…} приводит к большой избыточности кода.

Зачем он вообще нужен, этот finally? Делай все что нужно в деструкторах автоматических объектов
Re: Почему настоящие программисты избегают C++
От: Kh_Oleg  
Дата: 17.02.05 13:05
Оценка: +1
Здравствуйте, d Bratik, Вы писали:

DB>1.Отсутствие модулей.
DB>2.Использование целочисленных типов данных без знака (unsigned int) для номеров элементов и количественных значений в стандартной библиотеке stdc++.
DB>3.Отсутствие встроенной проверки на выход за диапазоны массива.
DB>4.Отсутствие встроенных средств инициализации динамической памяти нулями при конструировании объектов оператором new.
DB>5.«Автоматизм» конструкторов и деструкторов для объектов, создаваемых динамически и имеющих виртуальные методы;
DB>6.Отсутствие оператора try {…} finally {…}. Приводит к созданию программ, неустойчивых к исключительным ситуациям.
7. Наличием большого количества синтаксических ловушек, вроде
const double PI = 3,1415;

или той, что описана вот здесь
Автор: Кодт
Дата: 17.02.05
Re: Почему настоящие программисты избегают C++
От: d Bratik  
Дата: 17.02.05 13:20
Оценка: :)
DB>
DB>std::vector<int> v;
DB>// Следующий код работает бесконечно, поскольку (size_type)(-1) == 4 млрд.
DB>for (std::vector<int>::size_type i = 0; v.size() - 1; ++i)
DB>{
DB>  ...
DB>}
DB>


Очепятка вышла, прошу прощения. Должно быть:

std::vector<int> v;
// Следующий код работает бесконечно, поскольку (size_type)(-1) == 4 млрд.
for (std::vector<int>::size_type i = 0; i < v.size() — 1; ++i)
{
...
}

Цикл "для всех элементов кроме последнего".
Re[5]: Почему настоящие программисты избегают C++
От: SWW Россия  
Дата: 17.02.05 13:55
Оценка: +1
DB>Этот код ошибочен при любом количестве элементов в векторе.

SWW>>А если бы v.size() было знаковым, разве этот код работал бы?

DB>Да, причем совершенно корректно.

Ну, начнем с того, что первый пример был такой:
for (std::vector<int>::size_type i = 0; v.size() - 1; ++i)

проверка условия написана как v.size()-1, что означает продолжение цикла при ненулевом значении выражения. При пустом векторе значение этого выражение -1, что есть такой же не-ноль, как и 4 млрд.

Что же касается второго примера
DB>
DB>std::vector<int> v;
DB>for (std::vector<int>::size_type i = v.size() - 1; i >= 0; ++i)
DB>{
DB>  ...
DB>}
DB>

то на это могу сказать только одно: настоящий программист знает, чем отличаются знаковые и беззнаковые переменные. И вообще
SWW>>Человек приводит заведомо неправильный код и говорит: С++ плохой язык потому что на нем можно написать неправильную программу — вот, видите, я же смог!
Re[3]: Почему настоящие программисты избегают C++
От: Glоbus Украина  
Дата: 17.02.05 17:46
Оценка: :)
Здравствуйте, d Bratik, Вы писали:



DB>Проблема шалонов не хреновой читаемости, а в том, что они unsafe — невозможно указать ограничений (constraints) для параметров.

Нельзя ограничения установить??? Мояяяяяя девочкааааааа...

DB>Шаблонов в своих программах можно избегать.

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

DB>Без сборщика мусора трудно, но существуют подходы (например, концепция владения),

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

DB>которые позволяют обойтись без него. А вот без остального действительно туго.

Ну уж как пить дать...
Ваще хорошо ты, братан, задвинул, внушаеть
Удачи тебе, браток!
Re[10]: Почему настоящие программисты избегают C++
От: d Bratik  
Дата: 17.02.05 18:24
Оценка: -1
Здравствуйте, nixite, Вы писали:

MN>>Да согласен — ваша правда... это я поторопился... но как-то у меня такой проблемы никогда не было... наверное потому, что для работы с контейнерами C++ всегда использовал итераторы, а для доступа к массивам в стиле pure C использовал знаковый int и никогда не путал эти понятия между собой, чего и вам советую... ну или если вы моему совету не внемлите, то обращайтесь к С. Ю. Губанову — он вам других советов надаёт

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. я решение знаю, но не сказал бы что оно простое

Решение состоит в том, что система должна генерировать исключение (exception) при переполнении. Отсутствие этой возможности я забыл добавить в качестве 7-го пункта в списке ошибок проектирования языка.
Re[10]: Почему настоящие программисты избегают C++
От: davenger  
Дата: 17.02.05 19:44
Оценка: :)
Здравствуйте, nixite, Вы писали:


MN>>Да согласен — ваша правда... это я поторопился... но как-то у меня такой проблемы никогда не было... наверное потому, что для работы с контейнерами C++ всегда использовал итераторы, а для доступа к массивам в стиле pure C использовал знаковый int и никогда не путал эти понятия между собой, чего и вам советую... ну или если вы моему совету не внемлите, то обращайтесь к С. Ю. Губанову — он вам других советов надаёт

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. я решение знаю, но не сказал бы что оно простое


Ну зачем же ставить заведомо нерешаемые задачи?
Над такими лучшие умы человечества бьются не один десяток лет, а Вы хотите чтоб Вам на каком-то инетрнет-форуме всё разрулили.
Re: Почему настоящие программисты избегают C++
От: VladD2 Российская Империя www.nemerle.org
Дата: 18.02.05 00:06
Оценка: :)
Здравствуйте, d Bratik, Вы писали:

DB>
DB>std::vector<int> v;
DB>// Следующий код работает бесконечно, поскольку (size_type)(-1) == 4 млрд.
DB>for (std::vector<int>::size_type i = 0; v.size() - 1; ++i)
DB>{
DB>  ...
DB>}
DB>


Что-то я никак не въеду в смысл операции "v.size() — 1". Даже если это будет int, то, например, со зрачением "v.size() = 2" мы получаем проход по памяти, так как "v.size() — 1 == 1".

Проблемы с беззнаковыми целыми и отсуствием контроля переолнения конечно есть. Но пример не к черту.

ЗЫ

Ты не перечислил и 10 процентов граблей.

И вообще ты не понял тонкую душу Страуструпа. Он изобретал язык который позволил бы постоянно тренировать мозг и нервы.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Почему настоящие программисты избегают C++
От: VladD2 Российская Империя www.nemerle.org
Дата: 18.02.05 00:06
Оценка: +1
Здравствуйте, Kubera, Вы писали:

K>Функции, логика которых не предусматривает ошибочных ситуаций, не должны кидать исключений. А функция вычисления среднего арифметического относится как раз к таким. Т.е. предложенное тобой решение с генерацией исключения неверно.

Функция не учитывающая переполенеие уже ошибочна.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Только настоящие программисты пишут на С++! :)
От: VladD2 Российская Империя www.nemerle.org
Дата: 18.02.05 00:06
Оценка: +1
Здравствуйте, Кодт, Вы писали:

К>1) От компилятора: прекомпиляция заголовков
К>2) От программиста: идиома pimpl
К>И всё будет летать.

Летает обычно яжыком. А по жизни серьезный проект (более 3 метров кода) компилруется от десяти минут, до часов.

Но я бы назвал галвным недостатком отсуствия модульности невозможность полноценной компонентной разработки. Вот это куда более неприятно. Приходится прибегать к разным КОМ-ам, а они в С++ ой как долеки от нормального программирования.

К>Здесь вообще какой-то пьяный бред написан. При чём тут знаковость/беззнаковость?

Согласен. Но вопрос поднят верно.

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

В любом кроме С/С++. В нем это всего лишь проход по памяти. А аварии может и не быть. Можно считать это достоинством.

К>Нет, это требует сознательной инициализации.
К>Не инициализированная переменная — логический баг.

Не. Не логический. Физический! И еще какой!!! Ой не одну ночь я провел ловя такие баги. Они самые забавные. Сейчас правда по проще стала. Средства контроля стали по приличнее. А раньше был мрак.

К>Вот именно автоматизм конструкторов/деструкторов позволяет обходиться без finally.

Ага. Позволяет. Только процентов 70% программистов плюют на это позволение. За примером далеко ходить не надо. Вот пример подобного кода
Автор(ы): Алексей Ширшов
Дата: 09.11.2003
Печать в WTL не так хорошо развита и проработана, как в других библиотеках. Статья рассказывает, как преодолеть недостатки этой библиотеки, используя ее гибкость и открытую структуру.
 среди топовых РСДН-еров.

Плюс еще не нужно забывать о проблемах двойных исключений.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Почему настоящие программисты избегают C++
От: VladD2 Российская Империя www.nemerle.org
Дата: 18.02.05 00:06
Оценка: +1
Здравствуйте, Glоbus, Вы писали:

G> Я мля не понял мля...!!! А где мля про шаблоны и их хреновую читаемость! А где утечки памяти при пользовании голых указателей! А где отсутсвие сборщика мусора мля!!! Че-то ты старик слабо подготовился, да еще с такими убогими примерами как std::vector::size()! Эй, там, граждане Рима, подготовьте нормально человека для критики плюсов!

Я плякаль, мля.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Почему настоящие программисты избегают C++
От: VladD2 Российская Империя www.nemerle.org
Дата: 18.02.05 00:06
Оценка: +1
Здравствуйте, Кодт, Вы писали:

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

DB>>Проблема шалонов не хреновой читаемости, а в том, что они unsafe — невозможно указать ограничений (constraints) для параметров. Шаблонов в своих программах можно избегать. Без сборщика мусора трудно, но существуют подходы (например, концепция владения), которые позволяют обойтись без него. А вот без остального действительно туго.

К>Не умеешь писать с шаблонами — так прямо и скажи.

Ну, это голословные наезды. Я вот вроде немного умею, но, что шаблоны создают не мло проблем. Но тут хоть ясно за что платить.

К>Констрейнты в шаблонах делаются с лёгкостью необычайной.

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

К>Как именно — не скажу, тебе это всё равно не пригодится.

О. А еще меня тут пинают за подколки и уколки.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Почему настоящие программисты избегают C++
От: screw_cms Россия ICQ: 168185721
Дата: 18.02.05 05:37
Оценка: :)
Здравствуйте, Кодт, Вы писали:

К>Здравствуйте, 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;
К>}
К>


Баян! http://www.rsdn.ru/Forum/Message.aspx?mid=1032467&amp;only=1
When in doubt, use brute force. © Ken Thompson

Re[11]: Почему настоящие программисты избегают C++
От: migel  
Дата: 18.02.05 07:22
Оценка: +1
Здравствуйте, 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;
}


Хотя могу и ошибиться
... << RSDN@Home 1.1.4 beta 4 rev. 324>>
Re[5]: Почему настоящие программисты избегают C++
От: Кодт Россия  
Дата: 18.02.05 07:57
Оценка: :)
Здравствуйте, VladD2, Вы писали:

К>>Констрейнты в шаблонах делаются с лёгкостью необычайной.

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

template<int k> // k - нечётное
enable_if_c< (k%2==1), int > kx1_problem(int x) { return x%2 ? k*x+1 : x/2; }

struct void_type {};
template<class T> // T - наследник CObject
class foo : enable_if< is_base_and_derived<CObject,T>, void_type >
{
}


К>>Как именно — не скажу, тебе это всё равно не пригодится.

VD>О. А еще меня тут пинают за подколки и уколки.

Да, чево-то я вчера злой был
Перекуём баги на фичи!
Re[3]: Почему настоящие программисты избегают C++
От: alnsn Великобритания http://nasonov.blogspot.com
Дата: 18.02.05 08:07
Оценка: :)
Здравствуйте, Gaperton, Вы писали:

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

A>>http://www.catb.org/~esr/writings/taoup/html/ten-thousand.html
G>Великолепно. Но оофтоп.

TMPFILE=`mktemp /tmp/tao.XXXXXX` && wget http://www.catb.org/~esr/writings/taoup/html/ten-thousand.html -O $TMPFILE && sed 's/\<C\>/C++/g' $TMPFILE | w3m -T text/html

и будет в тему
Re[14]: Почему настоящие программисты избегают C++
От: Kh_Oleg  
Дата: 18.02.05 09:06
Оценка: +1
Здравствуйте, alnsn, Вы писали:

VD>>Функция не учитывающая переполенеие уже ошибочна.

A>Очень серьезные дяди писали на серьезном языке Ada, где есть исключения по переполнению. Результат здесь.

Читаем...

The internal SRI software exception was caused during execution of a data conversion from 64-bit floating point to 16-bit signed integer value. The floating point number which was converted had a value greater than what could be represented by a 16-bit signed integer. This resulted in an Operand Error. The data conversion instructions (in Ada code) were not protected from causing an Operand Error, although other conversions of comparable variables in the same place in the code were protected.

The error occurred in a part of the software that only performs alignment of the strap-down inertial platform. This software module computes meaningful results only before lift-off. As soon as the launcher lifts off, this function serves no purpose.

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

На самом деле ошибка была в том, что разработчики не предусмотрели такую ситуацию и не защитились от нее.
Re[12]: Почему настоящие программисты избегают C++
От: Кодт Россия  
Дата: 18.02.05 09:47
Оценка: +1
Здравствуйте, Kh_Oleg, Вы писали:

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

K_O>Каким?

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

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

Вот так?
int mid(int a, int b) throw() // наружу мы ничего не кидаем
{
  try // попробуем быстрый, но небезопасный способ...
  {
    return (a+b)/2;
  }
  catch(overflow_error& ex) // облажались? тогда попробуем по-другому...
  {
    return a/2+b/2+(a%2+b%2)/2;
  }
}

Здесь, очевидно, использование метода облажались-переделали — это извращение.
А на каких практических задачах он эффективен?

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

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

Разумеется, бывают.
Просто — исключения (в любом виде: объектно-ориентированные, структурные, сигналы) не являются "серебряной пулей"! Нельзя бездумно молиться на них, а тем более — пользоваться где ни попадя.
Перекуём баги на фичи!
Re[13]: Почему настоящие программисты избегают C++
От: Kubera Россия  
Дата: 18.02.05 14:18
Оценка: +1
Здравствуйте, VladD2, Вы писали:

K>>Функции, логика которых не предусматривает ошибочных ситуаций, не должны кидать исключений. А функция вычисления среднего арифметического относится как раз к таким. Т.е. предложенное тобой решение с генерацией исключения неверно.

VD>Функция не учитывающая переполенеие уже ошибочна.

Функция вычисления среднего арифметического не должна бросать исключений. Это нонсенс , если вместо среднего арифметического при определённых входных параметрах функция будет выкидывать ошибку! А вот её реализация обязана учитывать переполнение, точнее избегать его. Влад, с чем ты не согласен?
Любая сложная технология неотличима от волшебства. (Артур Кларк)
Re[7]: Почему настоящие программисты избегают C++
От: d Bratik  
Дата: 18.02.05 16:29
Оценка: :)
Здравствуйте, Шахтер, Вы писали:

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

DB>>Да что такое сегодня с руками...

Ш>Во-во. Руки лечи. А ещё глаза.

Примечательно, что никто не простил мне опечаток. Причем именно на них и накинулись со всей злобой.


Я привел список именно тех проблем, которые прочувствовал сам на собственных программах. На счет сборщика мусора -- да, его нужно было поставить на первое место (деинициализация должна быть отделена от освобождения памяти, как в Oberon и .NET), но эту проблему мне удалось побороть (правда, ценой определенного housekeeping-инга). Но есть кричащие проблемы, анализируя истоки которых приходишь к очень неутешительным выводам по поводу компетентности некоторых товарищей (Б.С.).
Re[5]: Почему настоящие программисты избегают C++
От: Cyberax Марс  
Дата: 19.02.05 14:48
Оценка: :)
d Bratik пишет:

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

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

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

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

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

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

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[10]: Почему настоящие программисты избегают C++
От: Aibyss  
Дата: 20.02.05 21:25
Оценка: +1
Пара вариантов при условии, что округление ответа ближе к нулю:

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

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));
}
Re[15]: Почему настоящие программисты избегают C++
От: qwertyuiop Российская Империя  
Дата: 21.02.05 06:58
Оценка: +1
C>>>Ну а если программист — идиот, и пишет:
C>>>
for(size_t f=0;f<vec.size();f++)

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

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

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

О уважаемый опытный программист! Должен вам заметить, не все то, после чего стоят скобки, является функцией, для которой вычисляется входная точка и выполняется жонглирование регистрами, стеком и т.п. Иногда попадаются inline-функции. А в СТЛ их подавляющее большинство. Попробуй ради любопытства построить свою программу с динамическим подключением msvcp и найди с помощью Depends.exe сколько функций импортирует из него твоя программа. Их будет не больше десятка. Остальные (в том числе и size) — инлайновые. И вообще, сдается мне что вы плохо представляете возможности современных оптимизаторов. Если он догадается, что размер вектора в цикле не меняется, то он будет получен один раз в начале цикла.
Я отвечаю за свои слова, а не за то как вы их интерпретируете!
Re[14]: Почему настоящие программисты избегают C++
От: Cyberax Марс  
Дата: 21.02.05 11:07
Оценка: -1
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)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[19]: Почему настоящие программисты избегают C++
От: Кодт Россия  
Дата: 21.02.05 12:45
Оценка: +1
Здравствуйте, Cyberax, Вы писали:

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

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

"Я же написал" — асимптотики сложности.
Если в обработчике прерывания выполнять цикл O(N), то не пофиг ли, будет размер вычислен единожды или на каждой итерации?
А если ну совсем никак, и нужно из кисоньки выжать капельку — то профайлер. Вдруг выяснится, что главный тормоз происходит, например, на блокировке критической секции, которой пользуются обработчик и основной поток. Отсюда последуют выводы о перепроектировании, и в меньшей степени — о переписывании.
Перекуём баги на фичи!
Re[6]: Почему настоящие программисты избегают C++
От: achp  
Дата: 22.02.05 11:03
Оценка: +1
Здравствуйте, VladD2, Вы писали:

A>>Что касается Си и Си++, то, на мой взгляд, это их недостаток, что отсутствуют переносимые средства обнаружения переполнений. Но и такие, как checked в Си-Шарпе не очень-то полезны.

VD>Да как раз очнь даже полезны. Это компромис между надежность и скорость. Я в любой момент включив одну галку в VS могу получить приложение с контролем переполения и убедиться что хотя бы нет явных ошибок. Ну, а далее если есть проблемы то могу подумать как их проще устранить. Если скорость не важна, то ввести проверку. Если важна, или недопустимы вылеты, то делать ручной контроль.

Во всех случаях, когда я сталкивался с необходимостью контролировать переполнение, сам факт переполнения был вещью ожидаемой, не катастрофической для хода вычислений и, хоть и требовал специальной обработки, не служил поводом для исключения. Мне важней было бы иметь некую операцию, скажем, сложения, которая, уподобляясь команде АЛУ, не только бы давала результат, но и формировала бы логический признак — флаг переноса, а не исключение.
Я кончил, джентльмены, мне остается только поблагодарить вас за внимание.
Re[6]: Почему настоящие программисты избегают C++
От: d Bratik  
Дата: 22.02.05 17:05
Оценка: :)
Здравствуйте, Cyberax, Вы писали:

C>Скорее оно начинает тормозить из-за того, что у GUI-программистов кривые
C>руки.

Скорее всего нету никаких GUI-программистов. Просто есть программисты, которые не разбираются в проблемах GUI.

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

Если БД не соответствует запросам (в прямом и переносном смысле) пользователя, то она не соответствует предметной области.

C> GUI обычно проектируется с такой же
C>целью (и обычно является далеко не самой главной частью).

Большое заблуждение.
Re[7]: Почему настоящие программисты избегают C++
От: Cyberax Марс  
Дата: 22.02.05 17:40
Оценка: +1
d Bratik пишет:

> C>Скорее оно начинает тормозить из-за того, что у GUI-программистов
> кривые
> C>руки.
> Скорее всего нету никаких GUI-программистов. Просто есть программисты,
> которые не разбираются в проблемах GUI.

Я и говорю — криворукие программисты. Если программист не способен
нормально доставать дерево из базы, то он, скорее всего, криворук.

> C>Обычно схема БД проектируется и оптимизируется так, чтобы
> C>соответствовать предметной области.
> Если БД не соответствует запросам (в прямом и переносном смысле)
> пользователя, то она не соответствует предметной области.

Ну значит у вас там БД не так спроектировали. И причем здесь GUI?

> C> GUI обычно проектируется с такой же
> C>целью (и обычно является далеко не самой главной частью).
> Большое заблуждение.

То-то более 99% процентов кода на Земле — невизульного (т.е. не имеющий
отношения к UI).

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[10]: Почему настоящие программисты избегают C++
От: Kh_Oleg  
Дата: 23.02.05 10:36
Оценка: :)
Здравствуйте, Cyberax, Вы писали:

>> Чтобы понять разницу, попробуйте, используя эти библиотеки, создать
>> окно с обычной кнопкой OK, текст которой написан нестандартным
>> шрифтом. Сколько нужно потратить на это времени?

C>1. Рисуем диалог с кнопкой ОК (идентификатор IDD_OKDIALOG).
C>2. Пишем класс диалога:
C>
C>class OkDialog : public CDialogImpl<OkDialog>, public 
C>CDialogResize<OkDialog>
C>{
C>    CPrettyButton btn; //Mine
C>public:
C>    enum { IDD = IDD_OKDIALOG};

C>    BEGIN_MSG_MAP(OkDialog)
C>        MESSAGE_HANDLER(WM_INITDIALOG, OnInitDialog)
C>    END_MSG_MAP()

C>    BEGIN_DLGRESIZE_MAP(OkDialog)
C>        DLGRESIZE_CONTROL(IDOK, DLSZ_MOVE_X|DLSZ_MOVE_Y)
C>    END_DLGRESIZE_MAP()

C>    LRESULT OnInitDialog(UINT /*uMsg*/, WPARAM /*wParam*/, LPARAM 
C>/*lParam*/, BOOL& /*bHandled*/)
C>    {
C>        // Init dialog resizing
C>        DlgResize_Init();
C>        btn.SubclassWindow(GetDlgItem(IDOK)); //Mine
C>        btn.SetFont(...); //Mine
C>    }
C>};
C>

C>CPrettyButton — это моя кнопочка, которая умеет менять свой шрифт,
C>цвета, работать как push-like-button и т.п.

В Вилариба уже давно сменили стандартное свойство у стандартного контрола,
а в Вилабаджо все еще пишут свои классы для кнопочек.

C>Большая часть кода в данном диалоге генерируется визардом (или
C>cut&paste'ом), мои три строчки отмечены. Размер скомпиленой программы —
C>16Кб.

Дело не в том, что мало печатать приходится, потому что визард генерит, а в том, что потом такое читать невозможно.
Re[11]: Почему настоящие программисты избегают C++
От: Cyberax Марс  
Дата: 23.02.05 11:22
Оценка: +1
Kh_Oleg пишет:

> C>CPrettyButton — это моя кнопочка, которая умеет менять свой шрифт,
> C>цвета, работать как push-like-button и т.п.
> В Вилариба уже давно сменили стандартное свойство у стандартного
> контрола,
> а в Вилабаджо все еще пишут свои классы для кнопочек.

Нет, Вилабаджо уже давным-давно знают про сайт
http://www.codeproject.com/ и уже давно скачали кучу всяких контролов
(там есть и поддержка изменения шрифтов:
http://codeproject.com/wtl/wtlwindowfont.asp).

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

> C>Большая часть кода в данном диалоге генерируется визардом (или
> C>cut&paste'ом), мои три строчки отмечены. Размер скомпиленой программы —
> C>16Кб.
> Дело не в том, что мало печатать приходится, потому что визард
> генерит, а в том, что потом такое читать невозможно.

Читается это элементарно. Кстати, этот пример я набрал руками в Студии,
без всяких визардов (я ими не пользуюсь из принципа).

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[18]: Почему настоящие программисты избегают C++
От: Kh_Oleg  
Дата: 23.02.05 14:09
Оценка: :)
Здравствуйте, Amidlokos, Вы писали:

K_O>>Можно ли взглянуть на следующие визуальные компоненты, написанные на С++:
K_O>>1. TreeView, который не поперхнется от ста тысяч элементов и не будет
K_O>> причиной даже полусекундной задержки при отображении на экране, а также
K_O>> массивных вставках и удалениях. Сортировка тоже нужна.
K_O>>2. ListView с аналогичными требованиями.
K_O>>3. PropertyEditor.

A>Хочешь сказать, этим требованиям удовлетворяет VCL-ный tree и list?
Я лишь хочу обосновать пункт из самого первого поста ветки: не существует нормальной GUI библиотеки на С++.
Qt самая лучшая из всех, но и ее нормальной назвать нельзя.

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

C>>>Нет. Базовый MFC используется почти везде в новых продуктах. А вот в
K_O>>Ссылки в студию.

A>Зачем ссылки, Spy натрави на окошко...
И куда смотреть? На класс окна?
Re[20]: Почему настоящие программисты избегают C++
От: Kh_Oleg  
Дата: 23.02.05 14:45
Оценка: :)
Здравствуйте, Cyberax, Вы писали:

>> C>Начнем с того, что дерево со 100000 одновременно видимых элементов не
>> C>будет удобно использовать.
>> Я бы даже сказал, что 10^5 ты и не отобразишь на экране. Нет, одновременно
>> видно столько, сколько видно, скажем 100. Но вот, сотрировка, поиск,
>> скроллинг
>> от первого к последнему по всем ста тысячам, быстрые вставки и
>> удаления должны быть.

C>Сортировку, поиск и скроллинг должно делать само приложение — дерево
C>просто отображает результаты. Вставка и удаление в стандартном списке
C>работают достаточно быстро.

Ути-пути, само приложение!
Когда-то и автомобиль считался роскошью, а теперь это — средство передвижения.

>>>> 3. PropertyEditor.
C>А, понял. Мы используем самодельный (требования специфичные) на основе
C>list view.
Требования у всех специфичные. Только для Delphi такой компонент существует, а для С++ — до сих пор нет.

>> Ждем-с...
C>Ищу...
Re[21]: Почему настоящие программисты избегают C++
От: Cyberax Марс  
Дата: 23.02.05 14:48
Оценка: +1
Kh_Oleg пишет:

> C>Сортировку, поиск и скроллинг должно делать само приложение — дерево
> C>просто отображает результаты. Вставка и удаление в стандартном списке
> C>работают достаточно быстро.
> Ути-пути, само приложение!

Да. Само приложение, хотя 10^5 записей и дерево сможет отсортировать.

>>>>> 3. PropertyEditor.
> C>А, понял. Мы используем самодельный (требования специфичные) на основе
> C>list view.
> Требования у всех специфичные. Только для Delphi такой компонент
> существует, а для С++ — до сих пор нет.

И для С++ существует, причем не в одном варианте. Мы же не с 0 свой
контрол писали.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[21]: Почему настоящие программисты избегают C++
От: Amidlokos Россия  
Дата: 23.02.05 15:02
Оценка: :)
Здравствуйте, Kh_Oleg, Вы писали:

K_O>Ути-пути, само приложение!
K_O>Когда-то и автомобиль считался роскошью, а теперь это — средство передвижения.

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

Кроме того — ну, а где (повторю это любимое слово) ссылка-то на этот дельфовский суперкомпонент? Где пример программы с десятком тысяч node-ов?

K_O>Требования у всех специфичные. Только для Delphi такой компонент существует, а для С++ — до сих пор нет.

Дружно падаем дельфе в ноги. Попутно замечая, что забыли порыться на codeproject-е...

здесь (нужно ещё и текст прочитать, там пара ссылок),
здесь,
здесь, в конце концов...
WARNING: expression "to_be || !to_be" is always true
Re[12]: Почему настоящие программисты избегают C++
От: The Lex Украина  
Дата: 23.02.05 15:36
Оценка: +1
Здравствуйте, Amidlokos, Вы писали:

K_O>>В Вилариба уже давно сменили стандартное свойство у стандартного контрола,
K_O>>а в Вилабаджо все еще пишут свои классы для кнопочек.

A>Под шумок вылезли дельфисты, я верно понимаю?

A>Ребята, отдыхайте и радуйтесь. Я, например, всё равно не пользуюсь программами с нестандартными контролами (их создание — подход студента, охреневшего от полного повиновения такой дорогой и умной машины), так что праздник в Вилларибе может продолжаться — юзер не потревожит.

Супер! От себя добавлю: хреневшего от полного повиновения такой дорогой, умной, и мощной машиной и осознания технических возможностей всей этой мощи и болесного осознания собственной неполноценности в виду невозможности полезного применения всей этой мощи!

A>Код смены шрифта стандартной кнопки — лишний. Спросите любого спеца по гуям. Так что, когда нужно, не грех и специализированный класс написать.

Дельфисты не "спрашивают любого специалиста по гуям" — а зачем!? они де и сами специалисты!

K_O>>Дело не в том, что мало печатать приходится, потому что визард генерит, а в том, что потом такое читать невозможно.

A>Ну почему все так категоричны? Так глобальны? Почему не пишут правду — "потом такое МНЕ читать невозможно". Ну, опыта и набитой руки не хватает, так зачем жабе-то давать себя душить?

A>

Точно!
Голь на выдумку хитра, однако...
Re[22]: Почему настоящие программисты избегают C++
От: Kh_Oleg  
Дата: 23.02.05 15:56
Оценка: +1
Здравствуйте, Amidlokos, Вы писали:

A>Кроме того — ну, а где (повторю это любимое слово) ссылка-то на этот дельфовский суперкомпонент?
VirtualTreeview
XtraVerticalGrid Это PropertyEditor.

K_O>>Требования у всех специфичные. Только для Delphi такой компонент существует, а для С++ — до сих пор нет.
A>Дружно падаем дельфе в ноги. Попутно замечая, что забыли порыться на codeproject-е...

A>здесь (нужно ещё и текст прочитать, там пара ссылок),
Это даже не поделка, это недоделка! У этого бедняги в описании компонента третьим пунктом идет:

"A Big Bug. <skipped> I don’t know what cause that. Maybe someone can tell me or solve it. I will really appreciate him/her very much.! You Can?"


Еще кандидаты есть?
Re[23]: Почему настоящие программисты избегают C++
От: Amidlokos Россия  
Дата: 23.02.05 16:13
Оценка: :)
Здравствуйте, Kh_Oleg, Вы писали:

K_O>Еще кандидаты есть?

Я взял три штуки наугад. Сам я ими не пользовался, и толком не прочитал — выбрал три ссылки по краткому описанию. Если копать, то там есть очень много всего — только из свежего список на пяток экранов.

Сейчас параллельно пытаюсь работать так что покопаться детально не могу... Но если грянет вдруг война, т.е. если мне вдруг в работе понадобится такой контрол, то я УВЕРЕН, что найду его.
WARNING: expression "to_be || !to_be" is always true
Re[25]: Почему настоящие программисты избегают C++
От: Amidlokos Россия  
Дата: 23.02.05 16:49
Оценка: +1
Здравствуйте, Kh_Oleg, Вы писали:

K_O>Вот поэтому нечего приводить в пример MS Office, говоря, что его GUI написан на С++.
K_O>Да, написан, но у всякого ли проекта есть бюджет, равный микрософтовскому, чтобы
K_O>позволить себе роскошь писать все самому?

Да, пример плохой, потому как старичка Офиса писали слишком давно, и много старых решений вынудило мелкософт к "особому пути" развития этого пакета. Почти то же и со студией. А ещё — эти два пакета во многом являются "полигонами" для обкатки и внедрения в массы новых идей.

И вместе с тем попрошу себе не противоречить C/С++? Без сомнения! Сделан офигительный интерфейс? Сделан! Так что и этот пример вполне подойдёт, разве что не в номинации "MFC"...

А MFC... InstallShield Pro, ACDSee, FlashGet (и ReGet), интерфейс к Agnitum Outpost, настроечные экраны Worms World Party (как ни странно). И это только то, что мне вспомнилось "из ранее ковырянного" или попалось на глаза.

Кроме того, простой вопрос: если дельфа такая замечательная, то что ж бедняжки-простачки по всему миру предпочитают писать собственные гуёвые классы на C++ (WinRAR, Opera)? Видать, о дельфе не слыхали, или денежки на лицензию не хватает?
WARNING: expression "to_be || !to_be" is always true
Re[10]: Почему настоящие программисты избегают C++
От: d Bratik  
Дата: 23.02.05 23:24
Оценка: :)
Здравствуйте, Pazak, Вы писали:

DB>>Под качеством я имел в виду не степень отлаженности, а уровень технического совершенства. Чтобы понять разницу, попробуйте, используя эти библиотеки, создать окно с обычной кнопкой OK, текст которой написан нестандартным шрифтом. Сколько нужно потратить на это времени?

P>Можно узнать, а на фига оно нужно? Любая GUI ограничена какими-то рамками, в пределах которых программирование легко и интуитивно, а за пределами — приходится извращаться. Соответственно, первым кандидатом на "упрощение" становятся наиболее часто востребованные действия, а те, что вотребованы редко — остаются на уровне "сделай сам". Так вот я с трудо могу представить, для чего в программах в массовом порядке нужно было бы менять шрифт на кнопочках. ИМХО это скорее редкое исключение, чем правило. Соответственно и автоматизация ему нужна постольку-поскольку, в отличие, например, от грамотной реализации layout'ов копонентов на форме.

Стандартный шрифт на кнопках — MS Sans Serif, размером 8 pt. Для людей с не очень хорошим зрением этот шрифт довольно мелкий, поэтому в программах, где важна простота и понятность (мультимедиа-программы, программы для детей, программы для домохозяек), этот шрифт иногда в массовом порядке заменяют на шрифт Arial 11 pt. При этом важно, чтобы настройки рабочего стола никак не менялись. Пример не на пустом месте — это было обязательное требование к одной из моих мультимедиа-программ (хотя я сам предпочитаю стандартный размер кнопок). В итоге программа выигрывала на фоне других программ и самой Windows — в сочетание с другими эффектами создавалось эмоциональное впечатление отсутствия казености при одновременной строгости.

Ну и наконец, взгляните на окно Интернет-обозревателя, в котором Вы сейчас пыхтя строчите свой ответ. Вас не смущает, что кнопочки «Найти ответ», «Предпросмотр» и «Отправить» имеют совсем нестандартный размер. Это конечно HTML-документ, но почему мне нельзя сделать такие кнопки в своей программе?

Богатство выбора (в Delphi) порождает много путей проявить свою безвкусицу, однако речь ведь не об этом.
Re[11]: Почему настоящие программисты избегают C++
От: Pazak Россия  
Дата: 24.02.05 06:23
Оценка: +1
Здравствуйте, d Bratik, Вы писали:

DB>Стандартный шрифт на кнопках — MS Sans Serif, размером 8 pt. Для людей с не очень хорошим зрением этот шрифт довольно мелкий, поэтому в программах, где важна простота и понятность (мультимедиа-программы, программы для детей, программы для домохозяек), этот шрифт иногда в массовом порядке заменяют на шрифт Arial 11 pt. При этом важно, чтобы настройки рабочего стола никак не менялись.

Слабовидящие — однозначно изменят шифт во всей системе. Что, если они и 11pt не видят, а только начиная от 14pt? Тогда программой с жестко зашитым Arial 11pt он просто не смогут пользоваться. Развлекательные программы для домохозяек — согласен, но там зачастую и покруче извращения бывают, чуть ли не как в игрушках. Смысла ради этого заносить все эти "фенечки" в библиотеку — я лично не вижу. Хотя средства для этого, конечно быть должны. Кому нужно поизвращаться — тот пусть и извращается как ему хочется.

DB>Ну и наконец, взгляните на окно Интернет-обозревателя, в котором Вы сейчас пыхтя строчите свой ответ. Вас не смущает, что кнопочки «Найти ответ», «Предпросмотр» и «Отправить» имеют совсем нестандартный размер.

Кнопочки как кнопочки. Даже шрифт на них такой же, как и у основного текста, только потемнее. Возможно это из-за моих настроек шрифтов в мозилле, но сбрасывать их ради проверки в дефолтные — немного ломает.

DB>Это конечно HTML-документ, но почему мне нельзя сделать такие кнопки в своей программе?

Да можно-то оно, конечно, можно. Просто хочется узнать зачем?
Ку...
Re[26]: Почему настоящие программисты избегают C++
От: Kh_Oleg  
Дата: 24.02.05 07:43
Оценка: :)
Здравствуйте, Amidlokos, Вы писали:

A>И вместе с тем попрошу себе не противоречить C/С++? Без сомнения! Сделан офигительный интерфейс? Сделан! Так что и этот пример вполне подойдёт, разве что не в номинации "MFC"...
Не подойдет. Бибилиотеку для создания такого "офогительного" интерфейса MS разработчикам не предосталяет. Речь шла не о GUI на С++, а о библиотеке для GUI на С++.
Re[3]: Почему настоящие программисты избегают C++
От: AlexEagle Украина http://www.vik.oil
Дата: 24.02.05 12:22
Оценка: +1
Здравствуйте, Кирпа В.А., Вы писали:

КВА>И еще наверное любят Делфи за отсуствие операции целочисленного деления
Это не DIV и MOD по случаю? А то они там есть

КВА>Предлагаю этот список вынести на отдельную страничку форума Пусть любители Делфи читают и гордятся
Я такую веду локально для гордости за используемый язык программирования. Ну и плюс эта будет. а вообще все замечания и дополнения можно слать на мыло в профайле
Re[14]: Почему настоящие программисты избегают C++
От: d Bratik  
Дата: 24.02.05 16:15
Оценка: :)
Здравствуйте, _Obelisk_, Вы писали:

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

_O_>>>Программа не на MFC. MFC глубоко похоронен в недрах Stingray-я + нашего собственного framework-а поверх Stingray-я. Потом GUI здесь отнюдь не самая
_O_>>>сложная часть продукта.
_O_>>>Собирается все из исходников на разных платформах одновременно и единообразно. Просто на на Linux-е/Solaris-е GUI линкуется с библиотеками от MainSoft-а. А эмуляция MFC — задача MainSoft-а, не наша. Все, что не GUI, вообще не использует ничего Windows-specific.

DB>>Вы меня вконец запутали. Что же представляет собой Ваш собственный framework? И наконец, сокраментальный вопрос: нельзя ли взглянуть краем глаза на скриншот с Sun Solaris-а (на SPARK-е)?

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

Туманно все как-то Через какой API этот собственный framework что-либо рисует? Через GDI, через MFC-шные классы-оболочки над GDI?

_O_>Во, скриншот для Linux-а, делал через Reflection. (на Solaris-е будет тоже самое).

Не-е-е, такой ответ не устраивает Пока сам воочию не увижу скриншот с солярки, не поверю Подозреваю, что программе Вашей требуется эмулятор Wine, которого на солярке нет. Я же не просто так спрашивал, сколько у Вас реальных пользователей на Solaris
Re[5]: Почему настоящие программисты избегают C++
От: Rebus83 Россия  
Дата: 24.02.05 17:04
Оценка: :)
Здравствуйте, VladD2, Вы писали:


P>>Сейчас оберонисты прибегут
VD>Цссс. А то ведь флэйм получится.
Аааа... так это был ещё не?..
... << RSDN@Home 1.1.4 beta 4 rev. 303>> Вокруг тишина
Какая странная планета! — подумал Маленький принц. — Совсем сухая,
вся в иглах и соленая. И у людей не хватает воображения. Они только
повторяют то, что им скажешь...
Re[22]: Почему настоящие программисты избегают C++
От: Awaken Украина  
Дата: 25.02.05 08:41
Оценка: +1
Здравствуйте, Cyberax, Вы писали:

C>Kh_Oleg пишет:

>> C>Сортировку, поиск и скроллинг должно делать само приложение — дерево
>> C>просто отображает результаты. Вставка и удаление в стандартном списке
>> C>работают достаточно быстро.
>> Ути-пути, само приложение!

C>Да. Само приложение, хотя 10^5 записей и дерево сможет отсортировать.

пихать 10^5 записей в гуйный контрол это уже кривой дизайн. за такое по рукам надо
данные дерева должны быть в невизуальном контейнере, и только малая часть визуализируется по мере
необходимости
Re[14]: Почему настоящие программисты избегают C++
От: Cyberax Марс  
Дата: 25.02.05 14:05
Оценка: +1
olegkr пишет:

> C>Кстати добавлю: WinForms — это действительно работа дельфиста. Такую
> C>уродливую систему могли написать только они.
> C>Нет чтоб сделать как Swing в Java...
> Свят-свят-свят! Не надо нам, дотнетчикам, свингов, упаси боже!

Да я знаю. Большинство винформистов предпочитают VBшный стиль: без
разделения вида и модели, без нормальных layout'ов (anchor'ы — это
уродство), с абсолютно кривой иерархией наследования.

Зато "интуитивно", блин.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[15]: Почему настоящие программисты избегают C++
От: olegkr  
Дата: 25.02.05 14:29
Оценка: -1
Здравствуйте, Cyberax, Вы писали:

C>Да я знаю. Большинство винформистов предпочитают VBшный стиль: без
C>разделения вида и модели, без нормальных layout'ов (anchor'ы — это
C>уродство), с абсолютно кривой иерархией наследования.

Абсолютно точно. Не надо нам нафиг этих разделений, вынуждающих плодить классы, как на дрожжах, даже в примитивных формах. Ага, анонимные классы помогают... до тех пор пока они не станут занимать половину всего кода и найти начало и конец становится затруднительно
Layout тоже нам нах не надо. Когда для того, что бы спозиционировать как тебе надо (а не лайауту) контролы, нужно ломать голову и вкладывать один лайаут в другой, одновременно вспоминая многочисленные параметры конструкторов и прочую мутотень... Нее, я лучше в визуальном дизайнере (каковые для свинга имеются, но работают, мягко говоря глюкаво) их мышкой накидаю за пять минут и займусь более полезной работой. Хотя не спорю, иногда лайауту нужны... в одной форме из ста. Но терпеть неудобства от них в 99 формах — я пас. Вам нравится — велкам. У нас разные понятия прекрасного.
А вот чего ради ты приплел иерархия? Тут я даже теряюсь. Ни в свинге, ни в дотнете, оная иерархия как-то не вызывала никаких чувств у меня.
Ну а тормознутось и убогость (даже если поставить WinXP-шную темку) получаемого в свинге интерфейса, думаю всем известна. Блин, ну какого хрена этот свинг плодит кучу объектов внутри себя, что в сочетании с особенностями джавовского GC вызывают периодические подвисания... долго искал лекарство от этой болезни, не нашел, может в java 1.5 получше дело обстоит.
Re[16]: Почему настоящие программисты избегают C++
От: Cyberax Марс  
Дата: 25.02.05 14:52
Оценка: +1
olegkr пишет:

> C>Да я знаю. Большинство винформистов предпочитают VBшный стиль: без
> C>разделения вида и модели, без нормальных layout'ов (anchor'ы — это
> C>уродство), с абсолютно кривой иерархией наследования.
> Абсолютно точно. Не надо нам нафиг этих разделений, вынуждающих
> плодить классы, как на дрожжах, даже в примитивных формах.

Разделение на модель-вид-контроллер не заставляет "плодить классы". Как
раз наоборот.

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

Анонимные классы — это аналог делегатов, а не следствие MVC.

> Layout тоже нам нах не надо. Когда для того, что бы спозиционировать
> как тебе надо (а не лайауту) контролы, нужно ломать голову и
> вкладывать один лайаут в другой, одновременно вспоминая многочисленные
> параметры конструкторов и прочую мутотень...

Да, нужно помнить параметры FormLayout'а.... Чрезвычайно
сложнозапоминаемые, настолько, что даже автокомплит совсем не поможет. И
ведь еще даже документацию просмотреть придется. Нет, это не для ВБистов.

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

Чтобы потом все юзеры плевались от неправильно масштабируемых (или
вообще немасштабируемых) форм.

> Хотя не спорю, иногда лайауту нужны... в одной форме из ста.

В 9 из 10.

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

У меня она вызывает отвращение. Интерфейсы не выделены, наследование
используется сверх меры

> Ну а тормознутось и убогость (даже если поставить WinXP-шную темку)
> получаемого в свинге интерфейса, думаю всем известна.

Мне, лично, плевать на конкретную реализацию Свинга — я говорю об общих
принципах проектирования (кстати, в Mac OS X Свинг использует родной
графический движок и неотличим от остальных приложений).

Хотя МС в этот раз поступила честно — пакет называется WinForms, так как
ни на что большее, чем формочки, он не способен.

> Блин, ну какого хрена этот свинг плодит кучу объектов внутри себя, что
> в сочетании с особенностями джавовского GC вызывают периодические
> подвисания... долго искал лекарство от этой болезни, не нашел, может в
> java 1.5 получше дело обстоит.

Руки, значит, не так работают. IDEA написана на Свинге, однако летает
даже на старых машинах.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[14]: Почему настоящие программисты избегают C++
От: Кодт Россия  
Дата: 25.02.05 15:11
Оценка: +1
Здравствуйте, Awaken, Вы писали:

A>объясни в какой такой ОС существует многопоточный GUI?
A>в винде он однопоточный по определению (для этого и очередь сообщений)

Вот в винде он как раз многопоточный (для этого и существуют очереди сообщений у потоков).
И этим пользуются разные подпольные компоненты — DDE, OLE.
А вот делать именно user interface многопоточным в рамках одного приложения — это, как правило, больше проблем, чем выгод. Хотя ничего невозможного здесь нет, и WinAPI (в отличие от других платформ и обёрток) вполне справляется.
Перекуём баги на фичи!
Re[20]: Почему настоящие программисты избегают C++
От: Cyberax Марс  
Дата: 25.02.05 16:45
Оценка: :)
olegkr пишет:

> C>Пришли к соглашению: WinForms для примитивных форм. С чем я согласен.
> Ага, а свинг — для кривых форм и любителей потрахать мозги себе и
> юзеру. Согласен.

Нет, Свинг — для профессиональных GUI-программистов, которые могут
обойтись и без редактора формочек.

> C>Ссылки, плиз.
> Наследуешься от класса LayoutEngine и вперед.

Ага, конечно. Еще бы WM_SIZE посоветовал обрабатывать.

Готовые взаимозаменяемые Layout'ы где? Тот в МСной статье — фигня.
Особенно понравилось:
===========
*Layout mode interaction*
Currently, having *Spring*, *FillContainer*, and *SizeMode* set
generates some odd behavior. This should be cleaned up so that the
layout code becomes more fault-tolerant.
===========

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[18]: Почему настоящие программисты избегают C++
От: d Bratik  
Дата: 27.02.05 21:07
Оценка: :)
Здравствуйте, Amidlokos, Вы писали:

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

C>>>Ну а в качестве exception-safe — чем MFC или WTL не нравится?

DB>>В моем инструментальном ящике этому отстою нету места. Если мне нужно будет сделать программу для Windows, я не раздумывая возьму Delphi и VCL (или нынче уже VS.NET с WinForms). Если передо мной цель — сделать программу для Solaris и Linux (и в последнюю очередь Windows), то я возьму Qt.

A>Народ, дэ братику программ для виндовоза не давать, ему хватит!

DB>>Для того, чтобы понять, что проблемы есть и проблемы серьезнейшие, нужно принять определенную систему ценностей. После многих лет программирования я принял систему ценностей Вирта и проповедую ее.

A>И тебя вылечат...

Я сам доктор, между делом студентов лечу. Бесплатно избавляю от синдрома страуструпа, комплекса "best industry practice", а также GUI- и DBMS-фобий. Так что обращайтесь
Re[19]: Почему настоящие программисты избегают C++
От: Alex Reyst Россия  
Дата: 28.02.05 05:32
Оценка: :)
Здравствуйте, d Bratik, Вы писали:

DB>Я сам доктор, между делом студентов лечу. Бесплатно избавляю от синдрома страуструпа, комплекса "best industry practice", а также GUI- и DBMS-фобий. Так что обращайтесь

Бесплатная медицина — хреновая медицина. Как минимум на территории бывшего СССР .
Все, что здесь сказано, может и будет использоваться против меня...
Re[24]: Почему настоящие программисты избегают C++
От: Cyberax Марс  
Дата: 28.02.05 09:09
Оценка: -1
Kh_Oleg пишет:

> C>>Да. Само приложение, хотя 10^5 записей и дерево сможет отсортировать.
> A>пихать 10^5 записей в гуйный контрол это уже кривой дизайн. за такое
> по рукам надо
> A>данные дерева должны быть в невизуальном контейнере, и только малая
> часть визуализируется по мере
> A>необходимости
> Умница! Вот только VirtualTreeView делает это за меня. И визуализирует
> "по мере необходимости",
> избавляя от многих забот.

Даже SysTreeView32 это умеет

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[20]: Почему настоящие программисты избегают C++
От: d Bratik  
Дата: 01.03.05 22:38
Оценка: :)
Здравствуйте, Cyberax, Вы писали:

C>d Bratik пишет:

>> C>Ррррррррр..... Да _НИ_ _ОДНА_ распространенная GUI не дружит с
>> C>многопоточностью по очень простой причине — ВСЕ они построены на
>> C>концепции очереди сообщений (событий, сигналов). Но при этом _ЛЮБУЮ_
>> C>современную GUI-систему можно использовать в многопоточной среде,
>> приняв
>> C>соответствующие меры.
>> Тогда Вы может быть мне расскажите, какие меры нужно принять, чтобы
>> организовать многопоточное рисование (требуется просто фоновое
>> рисование двух картинок) в Qt-программе, работающей на Солярисе?

C>Рисовать картинки в разных потоках, передавать обновленные картинки в
C>GUI-тред, а в GUI-треде их показывать.

В Qt рисование (любое, даже картинки) в потоке небезопасно, если в это время выполняется цикл обработки сообщений

C>Кстати, рисование средствами какой библиотеки производится?

X11. Она не многопоточна

>> Или под "соответствующими мерами" понимается также смена оконного
>> менеджера, библиотеки графического вывода и операционной системы?

C>Нет, понимается синхронизация и маршаллирование вызовов.

>> C>А, все понятно. Теоретик, оторванный от практики.
>> Это кто, Вирт, что ли? С его практикой может сравниться только
>> практика Хайльсберга (и то с натяжкой). Стыдно этого не знать.

C>Чего? Как практиков я уважаю: Кернигана и Ритчи (создателей языка С), Б.
C>Страуструпа, Алана Кея (с натяжкой) и многих других.

C>Вот Вирта в этом списке нет, так как я не помню хороших его практических
C>творений: Pascal годен только для обучения, Oberon не входит даже в
C>сотню самых распространенных языков, а Дельфи делалась и вовсе без Вирта
C>(наверное поэтому и получилось сравнительно удачной). Я не спорю, что
C>Вирт сделал много для развития теории (как и Дональд Кнут), но вот для
C>практики....

Это невежество простительно лишь для студента первого курса. Вирт системы делал, а языки Pascal, Modula, Oberon — лишь побочный продукт его деятельности. Именно Виртом и его командой были придуманы и реализованы (в операционной системе Oberon) все самые лучшие технические идеи, которые спустя несколько десятилетий были внедрены в .NET: высокоуровневый байт-код, динамическая компиляция, автоматическая сборка мусора, контроль типов во время выполнения программы, полная информация о типах в исполняемых модулях, расширяемость программ без их перекомпиляции и многое другое. Вирт собственноручно проектировал язык, программировал компилятор, операционную систему, графическую библиотеку визуальных компонентов и др. Проблема Вирта лишь в том, что он слишком сильно (на 20-30 лет) опередил свое время.

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

Страуструп вообще ничего практического не сделал.
Re[21]: Почему настоящие программисты избегают C++
От: Pazak Россия  
Дата: 02.03.05 07:09
Оценка: +1
Здравствуйте, d Bratik, Вы писали:

DB>Именно Виртом и его командой были придуманы и реализованы (в операционной системе Oberon) все самые лучшие технические идеи, которые спустя несколько десятилетий были внедрены в .NET:

Знающие люди поправят, но ИМХО...

DB>высокоуровневый байт-код,

...был в smalltalk...

DB>динамическая компиляция,

...была в smalltalk...

DB>автоматическая сборка мусора,

...вроде тоже была.

DB>Вирт собственноручно проектировал язык, программировал компилятор, операционную систему, графическую библиотеку визуальных компонентов и др. Проблема Вирта лишь в том, что он слишком сильно (на 20-30 лет) опередил свое время.
DB>Кернигана и Ритчи — неплохие ребята, но до Вирта им как до луны. Да, они тоже делали язык, компилятор и операционную систему, поэтому их есть за что уважать (хотя все их творения уже давно морально устарели).
DB>Страуструп вообще ничего практического не сделал.

Угу, вот только "морально устаревшие творения K&R+S" продолжают успешно применяться, а Виртовские "опредившие время" системы так и остались по большому счету на уровне "интересных для изучения". А разговор-то идет о практике. Ты вот, например, сейчас под какой осью эту мессагу читаешь? Под Oberon-based или все-таки под написанными на С[++] виндами/линухом?
Ку...
Re[21]: Почему настоящие программисты избегают C++
От: Cyberax Марс  
Дата: 02.03.05 08:16
Оценка: +1
d Bratik пишет:

> C>Рисовать картинки в разных потоках, передавать обновленные картинки в
> C>GUI-тред, а в GUI-треде их показывать.
> В Qt рисование (любое, даже картинки) в потоке небезопасно, если в это
> время выполняется цикл обработки сообщений

Сам-то понял что сказал? Рисовать из обработчика событий — абсолютно
безопасно, так как они работают в GUI-потоке.

А вот рисовать в соседнем потоке на окно в текущем потоке — нельзя
(точнее можно, но будут глюки). Поэтому графические вызовы нужно
перенаправлять в GUI-поток. В простейшем случае это делается так
(псевдокод):
shared_ptr<Image> curImage;
Window window;

void slowPictureRenderer()
{
    while(true)
    {
        shared_ptr<Image> img=new Image();
        //Draw cycle
        curImage=img;
        SendMessage(window,ON_UPDATE_WINDOW);
    }
}

void Window::UpdateWindow()
{
    //Render curImage
}

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

> C>Кстати, рисование средствами какой библиотеки производится?
> X11. Она не многопоточна

Она не _потокобезопасна_, но вполне многопоточна.

> C>Вот Вирта в этом списке нет, так как я не помню хороших его
> практических
> C>творений: Pascal годен только для обучения, Oberon не входит даже в
> C>сотню самых распространенных языков, а Дельфи делалась и вовсе без
> Вирта
> C>(наверное поэтому и получилось сравнительно удачной). Я не спорю, что
> C>Вирт сделал много для развития теории (как и Дональд Кнут), но вот для
> C>практики....
> Это невежество простительно лишь для студента первого курса. Вирт
> системы делал, а языки Pascal, Modula, Oberon — лишь побочный продукт
> его деятельности.

КАКИЕ системы? Ссылки, пожалуйста.

> Именно Виртом и его командой были придуманы

ЧЕГО? Все это придумал Вирт???

Стыдно доктору проявлять такую безграмотность.

The first complete Lisp compiler, written in Lisp, was implemented in
1962 <http://en.wikipedia.org/wiki/1962&gt; by Tim Hart and Mike Levin. (AI
Memo 39
<ftp://publications.ai.mit.edu/ai-publications/pdf/AIM-039.pdf&gt; (/ftp://publications.ai.mit.edu/ai-publications/pdf/AIM-039.pdf/),
767 kB PDF) This compiler introduced the Lisp model of incremental
compilation, in which compiled and interpreted functions can intermix
freely. The language used in Hart and Levin's memo is much closer to
modern Lisp style than McCarthy's earlier code.


А теперь это надо сравнить с датой изобретения Oberon'а (поздние 80-е)...

> реализованы (в операционной системе Oberon) все самые лучшие
> технические идеи, которые спустя несколько десятилетий были внедрены в
> .NET: высокоуровневый байт-код

Было в Smalltalk'е и Лиспе еще в 70-х годах

> динамическая компиляция

Smalltalk, Lisp, Basic

> автоматическая сборка мусора

Lisp — в 62 году.

> контроль типов во время выполнения программы

Lisp — в 62 году.

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

А тут со Smalltalk'ом вообще ничего не сравнится.

> Вирт собственноручно проектировал язык, программировал компилятор,
> операционную систему, графическую библиотеку визуальных компонентов и
> др. Проблема Вирта лишь в том, что он слишком сильно (на 20-30 лет)
> опередил свое время.

Скорее он отстал лет на 10-15. Появись его творения в начале 70-х —
тогда может быть и были бы популярны. А в 80-х годах они уже не были ни
новыми, ни особо привлекательными.

> Кернигана и Ритчи — неплохие ребята, но до Вирта им как до луны. Да,
> они тоже делали язык, компилятор и операционную систему, поэтому их
> есть за что уважать (хотя все их творения уже давно морально устарели).

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

> Страуструп вообще ничего практического не сделал.

Всего-то, изобрел С++....

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[6]: Почему настоящие программисты избегают C++
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.03.05 22:47
Оценка: :)
Здравствуйте, Rebus83, Вы писали:

VD>>Цссс. А то ведь флэйм получится.
R>Аааа... так это был ещё не?..

Блин, мы тут Оберонциков перевоспитываем в дотнетчиков, а ты весь воспитательный процесс ломаешь.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[24]: Почему настоящие программисты избегают C++
От: d Bratik  
Дата: 07.03.05 17:36
Оценка: :)
Здравствуйте, Кодт, Вы писали:

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

DB>>Речь идет не об интерпретируемом байт-коде, а о промежуточном языке (Intermediate Language — IL) и динамической компиляции. Языки Lisp и Smalltalk по природе своей интерпретируемы. Сделать все это эффективно в императивном языке, на котором написать потом операционную систему удалось только Вирту и Ко.

К>Lisp может быть компилируемым. Smalltalk — тоже.
К>В самом простом виде, можно оттранслировать байткод в команды реального процессора.

Я сказал "императивный", а хотел сказать "строго типизированный". Ни Lisp, ни Smalltalk строго типизироваными не являются. Для выполнения Lisp- и Smalltalk-программ по определению нужна виртуальная машина и интерпретация.

Оттранслировать байт-код в команды процессора конечно можно, но большого толка от этого не будет, ибо архитектуры виртуальных машин Lisp и Smalltalk сильно отличаются от аппаратной архитектуры современных компьютеров. Поэтому программы на Lisp и Smalltalk всегда будут сильно уступать по производительности программам, написанным на Oberon, Pascal, C/C++ и др. строго типизированных императивных языках.
Re[4]: Почему настоящие программисты избегают C++
От: ansi  
Дата: 10.03.05 09:42
Оценка: +1
Здравствуйте, retn, Вы писали:
R>Тут еще в Железе один из учередителей АМД обясняет всем что такое Интел и всех несогласных кличет на рукопашную, во блин неделька.
Читал, читал... Часов эдак на N жизнь себе продлил!
Re[6]: Почему настоящие программисты избегают C++
От: AVC Россия  
Дата: 14.03.05 13:52
Оценка: :)
Здравствуйте, 4ertus2, Вы писали:

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

DB>>Это было бы смешно, если бы не было так грустно... У меня одна надежда — что MS, вылечившись сама, вылечит и других. Только вес такой фирмы может быть противопоставлен снобизму программистов на С++.

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

То, что большинство (конечно, не все) программистов на Си++ — "снобы", это правда.
Я общаюсь практически только с Си++никами (т.к. сам пишу на Си++), так что могу это подтвердить, исходя из опыта.

4>Отказаться сегодня от С++ — значит отказаться от огромной базы исходников (в том числе и открытых). Опять же, весь разговор проходит на ЯВУ и из предположения что продукт должен работать сносно. Вполне возможны ситуации, когда вашему приложению мешают работать нормалльно: переполняют все, что только можно, инжектируют всякие гадости. И вы предлагаете пересаживаться на неизвестную технологию только ради "концепции Вирта"?

Как раз "концепция Вирта" и позволяет бороться с такими "гадостями".
Хотя никакой отдельной "концепции Вирта", ИМХО, не существует.
А существует старая добрая школа структурного программирования (Дейкстра, Хоар, Вирт и т.д.)
Что же касается "отказа от базы исходников", то это старый и сомнительный аргумент.
Например, у меня коды на Си++ и Обероне работают совместно и даже дружно.

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

Хоар
Re[7]: Почему настоящие программисты избегают C++
От: AVC Россия  
Дата: 14.03.05 16:23
Оценка: :)
Немного дополню свой ответ.

4>>Отказаться сегодня от С++ — значит отказаться от огромной базы исходников (в том числе и открытых). Опять же, весь разговор проходит на ЯВУ и из предположения что продукт должен работать сносно. Вполне возможны ситуации, когда вашему приложению мешают работать нормалльно: переполняют все, что только можно, инжектируют всякие гадости. И вы предлагаете пересаживаться на неизвестную технологию только ради "концепции Вирта"?
AVC>Как раз "концепция Вирта" и позволяет бороться с такими "гадостями".
AVC>Хотя никакой отдельной "концепции Вирта", ИМХО, не существует.
AVC>А существует старая добрая школа структурного программирования (Дейкстра, Хоар, Вирт и т.д.)
AVC>Что же касается "отказа от базы исходников", то это старый и сомнительный аргумент.
AVC>Например, у меня коды на Си++ и Обероне работают совместно и даже дружно.

Как раз на тему переполнений и прочей "гадости".
См. страничку:
http://www.inr.ac.ru/~info21/blackbox/disciplina/arr_bounds_checks.htm
Вот выдержка:

Вопрос: Что мешает Майкрософт компилировать Windows XP с включенной опцией контроля выхода за границы массивов?
Ответ: Неадкватность языков и компиляторов, использованных в написании операционной системы (C и C++).

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

Хоар
Re[8]: Почему настоящие программисты избегают C++
От: AlexEagle Украина http://www.vik.oil
Дата: 21.03.05 09:50
Оценка: :)
Здравствуйте, 4ertus2, Вы писали:

4>Я без сомнения чайник и,....

Я бы тебе не советовал лезть в такие ветки.. Дело в том что если у тебя действительно мало опыта — то рискуешь быть завален "аргументами" на которое не найдется что ответить и не дай бог еще примешь их за "чистую монету"...

Лучше почитывай и анализируй если уж заинтересовался бесполезнешими из споров
Re[8]: Почему настоящие программисты избегают C++
От: Михаил  
Дата: 22.03.05 04:51
Оценка: +1
Здравствуйте, AVC, Вы писали:

AVC>Как раз на тему переполнений и прочей "гадости".
AVC>См. страничку:
AVC>http://www.inr.ac.ru/~info21/blackbox/disciplina/arr_bounds_checks.htm
AVC>Вот выдержка:

Вопрос: Что мешает Майкрософт компилировать Windows XP с включенной опцией контроля выхода за границы массивов?
AVC>Ответ: Неадкватность языков и компиляторов, использованных в написании операционной системы (C и C++).

 Представь себе, случилось. Вся операционка (драйвера, ядро, утилиты — все-все) переписана на свервысоконадежном языке. Попробуй оценить, сколько тысяч раз в секунду будет выполняться проверка выхода счетчика за свои границы, правильности строки и т.п. Там много чего придется ежесекундно проверять!
В твоем любимом компиляторе тоже все счетчики сначала сами проверятся, а потом уже до твоих доберутся.
И можно развить идею. Зачем тормозить на полпути?
Во всех деревьях также необходимо проверять, что ветки указывают на правильный адрес, а не куда попало. Также обязательно следить, чтобы случайно не образовалось циклических ссылок и дубликатов ключей.
Запретить null terminated string, всегда следить на уровне ОС, чтобы длина строки вдруг не превысила бы размер выделенного ей блока памяти.
Много чего можно придумать, чтобы надежно защититься от глупых ошибок и страшных дырок.
...А отсюда наливаем, когда рецепт написан совсем неразборчиво...
Re[8]: Почему настоящие программисты избегают C++
От: Erop Россия  
Дата: 20.05.05 06:07
Оценка: :)
Здравствуйте, transglucator, Вы писали:

T>жена — Pascal
T>проститутка — C++
T>любовница — ?

любовница -- коды PDP11 например. И потрахаешься в волю и пользы никакой
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[11]: Почему настоящие программисты избегают C++
От: Erop Россия  
Дата: 20.05.05 06:37
Оценка: +1
Здравствуйте, d Bratik, Вы писали:

N>>int a = 2113929216;
N>>int b = 2113929210;


DB>Решение состоит в том, что система должна генерировать исключение (exception) при переполнении. Отсутствие этой возможности я забыл добавить в качестве 7-го пункта в списке ошибок проектирования языка.

Такая возможность в C++ есть. Роди себе класс "целое с проверкой переполнения" и будет тебе счастье.
Проблема в том, что этого не очень поддерживает железо. А всё + на переполнение проверять всё-таки жалко.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[18]: Почему настоящие программисты избегают C++
От: Cyberax Марс  
Дата: 23.05.05 17:08
Оценка: +1
Erop wrote:

> А на читабельность всем уже и наплевать?
> Я не очень понимаю для решения каких именно задач заточен STL.
> Мне так кажется, что никаких. Такой классный универсальный всемогутер.
> Зато типа красивый.

Для любых Контейнеры в STL сделаны очень гибко, их можно использовать
почти под что угодно. А если сюда добавить еще и boost...

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[16]: А всё-так чем же pascal дгчше для GUI библиотек-то?
От: Kh_Oleg  
Дата: 26.05.05 08:52
Оценка: :)
Здравствуйте, Erop, Вы писали:

E>Кроме того вообще не ясна логика. Наверное в паскалеподобных языках есть что-то, что позволяет писать афигительные GUI библиотеки. Интересно что же это такое?

События, try...finally, информация о типах...
Re[20]: А всё-так чем же pascal дгчше для GUI библиотек-то?
От: Kh_Oleg  
Дата: 27.05.05 06:23
Оценка: -1
Здравствуйте, AlexEagle, Вы писали:

K_O>>try...finally обеспечивает гарантированный вызов finalization кода даже в тех случаях, когда в блоке try произошла исключительная ситуация. Причем в блоке finalization допускается возникновение еще одной исключительной ситуации, что недопустимо в С++ если использовать для этой цели scope guards. Причем здесь GUI? А притом, что нормальный GUI немыслим без многопоточности. Где многопоточность — там и объекты синхронизации. И вот тут finally очень помогает.

AE>Что насчет __try... __finally в с++ ? Хотя это и MS-specific но все же...
Здесь MS-specific, в Builder'e — Borland specific, но все равно приходится менять язык С++. А что делать для Linux'a и прочих unix'ов?


K_O>>>>информация о типах...
AE>Что насчет RUNTIME_CLASS и проч.. ?
Это не только MS, это уже MFC-specific.

Все эти изменения в языке или макросы в библиотеках — все это заплатки, свидетельствующие о кривизне языка С++.
Re[23]: А всё-так чем же pascal дгчше для GUI библиотек-то?
От: AlexEagle Украина http://www.vik.oil
Дата: 27.05.05 11:27
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

C>>Лучшая GUI-либа, ИМХО, это QT.
S>Если учитывать стороннние компоненты, типа DevExpress, которые построены только благодаря языку и библиотеке Delphi, то, имхо, QT тихо умрет от зависти. Могу ошибаться.

Имхо, DevExpress подавятся кросплатформенностью от QT
Re[21]: Я тоже не люблю гибкость :)
От: Erop Россия  
Дата: 29.05.05 22:04
Оценка: :)
Здравствуйте, Kh_Oleg, Вы писали:

K_O>Все эти изменения в языке или макросы в библиотеках — все это заплатки, свидетельствующие о кривизне языка С++.

Забавно, а вот приверженцы C++, обычно, возможность вводить в язык новые синтаксические кончтрукции при помощи макросов и хитрых шаблонов и перегруженных операторов, называют гибкостью и считают одним из огромных достоинств языка

Так что по этому поводу спорить толку нет. Кому-то нарвится, чтобы в языке были зафиксированы стандартные средства на удовлетворение каждой нужды, а кому-то нравится гибкость. Впринципе в случае стандартной задачи и хорошего владения инструментом рулит первый подход В слкчае, риска того, что задача вдруг станет нестандартной -- второй.

Но я всё равно не понял при чём тут GUI
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[24]: SEH и C++ синонимы или нет?
От: Kh_Oleg  
Дата: 31.05.05 09:42
Оценка: -1
Здравствуйте, Владик, Вы писали:

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

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

В>И тем не менее, по факту он им является Как раз потому, что не заточен под всякие SEH и т.п. platform-specific. Тебе уже популярно объяснили, что finally в C++ нужен не более, чем goto (если еще не понял — воспользуйся поиском по сайту, эта тема неоднократно обсуждалась). Разница только в том, что goto в языке официально есть (пресловутая совметимость с С этому не последняя причина), а finally — нет. Но это не мешает большинсву программистов всячески избегать применения goto или принципиально обходится без него (при этом не напрягаясь). Код, не загроможденный лестницами try/finally, выглядит намного понятнее, а на тот единичный случай, когда совсем влом писать отдельный и очень специфичный guard для выполнения какого-либо финализирующего действия — можно воспользоваться обобщенным guard'ом с функтором.

Не знаю, что такое guard с функтором, но если он работает также, как и обычные guards — т.е. если finalization код вызывается в деструкторе некоторого объекта, но такой подход неприменим при создании exception-safe приложений.
Re[5]: Почему настоящие программисты избегают C++
От: Erop Россия  
Дата: 03.06.05 06:02
Оценка: +1
Здравствуйте, johny5, Вы писали:

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

Казалось бы, от чего не доверять тогда стандартным контролам?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[15]: Почему настоящие программисты избегают C++
От: AVC Россия  
Дата: 04.06.05 22:52
Оценка: -1
Здравствуйте, Михаил, Вы писали:

М>
М>inline void body(int* const a, const int i)
М>{
М>      a[i]=0;
М>}
М>void InitArray(int * const a, const int n)
М>{
М>    int i;

М>    for (i = 0; i < n; ++i)
М>        body(a, i);
М>}
М>


М>Хотя не знаю, кому в голову такое написать придет .
М>Однако, если в body лежит кусок кода в 100К размером (куча вложенных функций) — это будет уже совсем не лишнее. Хотя inline желательно будет убрать.
М>Второе решение — использовать защищенный класс, в котором есть оператор [] и в нем проверка.
М>void InitArray(CProtectedArrayOfInt a, const int n)

Честно говоря, я не понял какую именно проблему Вы решаете этими двумя способами.
Особенно первым.
Что касается второго, то в нем предлагается создать класс, содержащий run-time проверки индекса массива.
Это похвальная попытка скомпенсировать отсутствие в языке строгой типизации.
Предположу, что в определении класса CProtectedArrayOfInt можно найти примерно следующее:
private:
    int *p;
    size_t size;

Так вот, я просто хочу обратить Ваше внимание на то, что для компилятора p и size — по прежнему две отдельные переменные, не имеющие между собой ничего общего. Если при реализации класса CProtectedArrayOfInt Вы (не дай Бог! ) допустите ошибку, компилятор ничем не сможет Вам помочь.

AVC>>Как видите, Си не может бороться даже с явно бредовым кодом.

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

Я не буду критиковать asm. Хотя бы потому, что последние годы я пишу компиляторы Си и ассемблеры для новых процессоров, и C вместе с asm меня кормят.
(Кстати, этот опыт последних лет свидетельствует, что программисты, пишущие на Си, проявляют повышенный интерес к отладчику, т.к. зачастую не в состоянии найти ошибку в своих программах без его помощи.)
Также согласен с Вами относительно идеологии Си. Кажется, главное из правил Spirit of C начинается так: "Не мешай программисту..."
Но вот в чем я с Вами не согласен, так это в понимании "высокоуровневости" языков программирования.
На мой взгляд, язык Си (равно как и Си++ в этом случае), не способный передать в подпрограмму даже информацию о размерности массива, не может считаться высокоуровневым.
Весь смысл высокоуровневости — позволить компилятору гарантировать определенные свойства программ, например — безопасность типов (type safety).
С моей стороны это вовсе не эстетская критика.
Я полагаю, что только прирожденный душегуб согласится писать сложное ПО, отвечающее за безопасность людей, на низкоуровневых языках, подобных Си и Си++.

М>>>С помощью ОС динамически массив наращивать?
М>>>Как вообще предлагается работать с _большими_ массивами переменной длины? Которые могут быть и намного больше размера оперативки. Как такой массив обработать редактором, например.
AVC>>Так же как и в Си++: создайте класс.
М>Ирония осталась непонятой .
М>Ну, вот такая проблемка есть у драйверов: им совсем некогда динамически память выделять. Байты от устройства потеряются. Или блокировка на ресурсы возникнет в многозадачной среде. Зачем ring0 придумали — поинтересуйтесь!

Мне приходилось писать ПО, работающее автономно в очень жестком real-time, причем в системе безопасности.
Память под буфера отводилась заранее, а затем управлялась маленьким специализированным "распределителем памяти".
Не вижу никакого преимущества у Си/Си++ по сравнению с Обероном в данном случае.

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

Хоар
Re[16]: Почему настоящие программисты избегают C++
От: Cyberax Марс  
Дата: 05.06.05 11:35
Оценка: +1
AVC wrote:

> Честно говоря, я не понял *какую именно* проблему Вы решаете этими
> двумя способами.
> Особенно первым.
> Что касается второго, то в нем предлагается создать класс, содержащий
> run-time проверки индекса массива.
> Это похвальная попытка скомпенсировать отсутствие в языке строгой
> типизации.

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

> Так вот, я просто хочу обратить Ваше внимание на то, что *для
> компилятора* p и size — по прежнему две отдельные переменные, не
> имеющие между собой ничего общего. Если при реализации класса
> CProtectedArrayOfInt Вы (не дай Бог! ) допустите ошибку, компилятор
> ничем не сможет Вам помочь.

А чем мне в этом случае поможет Оберон? В нем будет абсолютно такая же
ситуация.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[7]: Почему настоящие программисты избегают C++
От: lepsai  
Дата: 25.06.05 00:18
Оценка: +1
Здравствуйте, d Bratik, Вы писали:

DB>И все же я пока не видел ни одной промышленной GUI бибилиотеки на С++, которая бы отдаленно приближалась по качеству к VCL и .NET Framework. Обыскал весь Интернет — таковой в природе нет. Qt более-менее ничего, но когда основательно начинаешь пользовать, начинаешь плеваться.

ну ну... Расскажите нам Уважаемый, что же Вам не понравилсоь в Qт. От чего же пришлось плевацья? Было бы очен интересно умного человека послушать, к тому же и настоящего программиста...
Re: Почему настоящие программисты избегают C++
От: Poirot Россия  
Дата: 17.02.05 12:22
Оценка:
Здравствуйте, d Bratik, Вы писали:

DB>1.Отсутствие модулей. Имитация понятия модуль в виде пары h-файл – cpp-файл приводит к многочасовым компиляциям системы.

DB>2.Использование целочисленных типов данных без знака (unsigned int) для номеров элементов и количественных значений в стандартной библиотеке stdc++. Приводит к следующим ошибкам:

DB>
DB>std::vector<int> v;
DB>// Следующий код работает бесконечно, поскольку (size_type)(-1) == 4 млрд.
DB>for (std::vector<int>::size_type i = 0; v.size() - 1; ++i)
DB>{
DB>  ...
DB>}
DB>


DB>3.Отсутствие встроенной проверки на выход за диапазоны массива. Приводит к необходимости писать «обертки» для классов-контейнеров (в частности, для класса vector).

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

DB>5.«Автоматизм» конструкторов и деструкторов для объектов, создаваемых динамически и имеющих виртуальные методы; работа виртуальных методов как не виртуальных при их вызове из конструкторов и деструкторов; отсутствие стандартного базового класса. Значительно затрудняет решение проблемы повторного входа в объекты (reentrance problem) при создании библиотек визуальных компонентов и систем GUI.

DB>6.Отсутствие оператора try {…} finally {…}. Приводит к созданию программ, неустойчивых к исключительным ситуациям. Попытка имитировать этот оператор с помощью оператора try {…} catch {…} приводит к большой избыточности кода.
Видимо понятие настоящего программиста у нас различное. Тут что-то чедовек занимается системами типа Делфи, Джава, где это как раз-таки есть.
Насчёт первого могу согласится, но только отчасти.
Re: Почему настоящие программисты избегают C++
От: ansi  
Дата: 17.02.05 12:30
Оценка:
Мля. Во я дурак! Пашол учица на чиста риальнава праграмиста!!!
Re[2]: Почему настоящие программисты избегают C++
От: Poirot Россия  
Дата: 17.02.05 12:32
Оценка:
Здравствуйте, ansi, Вы писали:

A>Мля. Во я дурак! Пашол учица на чиста риальнава праграмиста!!!
И меня с собой возми ТОжа хачу быть чистА рЭальным пац.. ой прохраммистом
Re: Почему настоящие программисты избегают C++
От: SWW Россия  
Дата: 17.02.05 12:41
Оценка:
DB>
DB>for (std::vector<int>::size_type i = 0; v.size() - 1; ++i)
DB>


А что это за чушь написал здесь настоящий программист?
Re[2]: Почему настоящие программисты избегают C++
От: Vamp Россия  
Дата: 17.02.05 12:44
Оценка:
SWW>А что это за чушь написал здесь настоящий программист?
Понятно что До тех пор, пока в векторе не один элемент, делай...
Да здравствует мыло душистое и веревка пушистая.
Re[3]: Почему настоящие программисты избегают C++
От: SWW Россия  
Дата: 17.02.05 12:51
Оценка:
Здравствуйте, Vamp, Вы писали:

SWW>>А что это за чушь написал здесь настоящий программист?
V>Понятно что До тех пор, пока в векторе не один элемент, делай...

Кхм, интересно... Человек приводит заведомо неправильный код и говорит: С++ плохой язык потому что на нем можно написать неправильную программу — вот, видите, я же смог!

А если бы v.size() было знаковым, разве этот код работал бы?
Re: Почему настоящие программисты избегают C++
От: Poirot Россия  
Дата: 17.02.05 12:56
Оценка:
Здравствуйте, d Bratik, Вы писали:

Это чистой воды развод. если человек реально уверен в том, что он говорит в данной ветке, чтож я сочувствую...
Фактов не видно. Определение "Настоящего программиста" не было. Даже Страуструпу(апу) Ж) досталось
Re[3]: Почему настоящие программисты избегают C++
От: Mr. None Россия http://mrnone.blogspot.com
Дата: 17.02.05 13:08
Оценка:
Здравствуйте, d Bratik, Вы писали:

DB>Автор языка, кстати, попадает в эти 99%

А вот вы ему это сами скажите здесь
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Re[5]: Почему настоящие программисты избегают C++
От: d Bratik  
Дата: 17.02.05 13:23
Оценка:
Да что такое сегодня с руками...

DB>
DB>std::vector<int> v;
DB>for (std::vector<int>::size_type i = v.size() - 1; i >= 0; ++i)
DB>{
DB>  ...
DB>}
DB>


Должно быть

std::vector<int> v;
for (std::vector<int>::size_type i = v.size() - 1; i >= 0; --i)
{
  ...
}
Re: Почему настоящие программисты избегают C++
От: _Obelisk_ Россия http://www.ibm.com
Дата: 17.02.05 13:28
Оценка:
Здравствуйте, d Bratik, Вы писали:

Пишу на С++ шесть лет и ни разу перечисленные проблемы не являлись для меня проблемами.


Душа обязана трудиться! (с) Н.Заболоцкий.
Re[2]: Почему настоящие программисты избегают C++
От: achp  
Дата: 17.02.05 13:59
Оценка:
Здравствуйте, d Bratik, Вы писали:

DB>i < v.size() - 1


Элементарно переписывается так:

i + 1 < v.size()


Просто нужно кумекалкой соображать.
Я кончил, джентльмены, мне остается только поблагодарить вас за внимание.
Re[3]: Почему настоящие программисты избегают C++
От: ddanila Россия  
Дата: 17.02.05 14:06
Оценка:
DB>Вы наверное писали очень небольшие программы, без GUI. Для создания программ С++ подходит, но для создания систем — нет.

Кирпичи ещё из C++ плохие получаются...

-- Сучка Карло, -- прикопил Буратино, -- а как же я пойду в школу без тёлки?

-- Эге, ты прав, малыш...

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

-- Вот тебе азбука. Учись на похмелье.

-- Пятидневка Карло, а где твоя куртка?

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

Re[3]: Почему настоящие программисты избегают C++
От: _Obelisk_ Россия http://www.ibm.com
Дата: 17.02.05 14:52
Оценка:
Здравствуйте, d Bratik, Вы писали:

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

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

_O_>>Пишу на С++ шесть лет и ни разу перечисленные проблемы не являлись для меня проблемами.

DB>Вы наверное писали очень небольшие программы, без GUI. Для создания программ С++ подходит, но для создания систем — нет.

Отнюдь. Я, к примеру, один из разработчиков вот этого : http://www.telelogic.com/products/tau/developer/index.cfm. (список поддерживаемых фич тут
http://www.telelogic.com/products/tau/developer/features.cfm). Продукт, включая GUI, полностью написан на С++. Работает под Win, Linux, Solaris.


Душа обязана трудиться! (с) Н.Заболоцкий.
Re[2]: Почему настоящие программисты избегают C++
От: BioUnit Россия  
Дата: 17.02.05 14:53
Оценка:
Здравствуйте, Amidlokos, Вы писали:

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

A>Я поставил -1. Но ты, при желании, легко можешь преобразовать это значение в четыре миллиарда

М-да... Не смеялся так со времен Гриненко...

А на чем пишут "настоящие программисты" ?
Re: Почему настоящие программисты избегают C++
От: ussr  
Дата: 17.02.05 15:04
Оценка:
Еще один флейм C++ против C#. Достало.
Лучше вспомните в каком году вышел C++ и в каком C#.
Re[4]: Почему настоящие программисты избегают C++
От: Kh_Oleg  
Дата: 17.02.05 15:17
Оценка:
Здравствуйте, _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.

Скриншоты можно увидеть?
Re[6]: Почему настоящие программисты избегают C++
От: _wind_ Россия  
Дата: 17.02.05 15:19
Оценка:
Здравствуйте, 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>>


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>


К слову, этот цикл работает за время O(v.size()^2).
С уважением,
Денис
Re[8]: Почему настоящие программисты избегают C++
От: _wind_ Россия  
Дата: 17.02.05 15:20
Оценка:
Здравствуйте, ansi, Вы писали:

A>А ты бы по-простецки писал int i = v.size(); и проблем бы не было.
A>Короче вывод готов: C++ и d Bratik, так же, как и женщина за рулем, есть эквивалент мартышки с гранатой...

С уважением,
Денис
Re[4]: Почему настоящие программисты избегают C++
От: _wind_ Россия  
Дата: 17.02.05 15:29
Оценка:
Здравствуйте, ZeusSon, Вы писали:

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

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

A>>
DB>>>i < v.size() - 1
A>>


A>>Элементарно переписывается так:

A>>
A>>i + 1 < v.size()
A>>


A>>Просто нужно кумекалкой соображать
ZS>Ну ты загнул.... Для кумекалки же надо еще ее инициализировать... А она просто нулями забита..
С уважением,
Денис
Re: Почему настоящие программисты избегают C++
От: WFrag США  
Дата: 17.02.05 16:11
Оценка:
Здравствуйте, d Bratik!


А чего не избегают настоящие программисты?
RSDN@Home 1.1.4 beta 3 r297, играет silent
Re[9]: Почему настоящие программисты избегают C++
От: nixite  
Дата: 17.02.05 17:51
Оценка:
MN>Да согласен — ваша правда... это я поторопился... но как-то у меня такой проблемы никогда не было... наверное потому, что для работы с контейнерами C++ всегда использовал итераторы, а для доступа к массивам в стиле pure C использовал знаковый int и никогда не путал эти понятия между собой, чего и вам советую... ну или если вы моему совету не внемлите, то обращайтесь к С. Ю. Губанову — он вам других советов надаёт

для любителей signed int'ов:

положим захотелось нам искать среднее двух чисел и написали мы функцию:
int kaka (int a, int b){return (a+b)/2;}

и всё вроде тип-топ, но вот тут сунули нам два числа (вполне корректных):

int a = 2113929216;
int b = 2113929210;

и что? а какое решение-то простое есть? ассемблер в три команды не предлогать, всё на с++
p.s. я решение знаю, но не сказал бы что оно простое
Re[4]: Почему настоящие программисты избегают C++
От: Glоbus Украина  
Дата: 17.02.05 17:55
Оценка:
Здравствуйте, ZeusSon, Вы писали:

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

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

A>>
DB>>>i < v.size() - 1
A>>


A>>Элементарно переписывается так:

A>>
A>>i + 1 < v.size()
A>>


A>>Просто нужно кумекалкой соображать
ZS>Ну ты загнул.... Для кумекалки же надо еще ее инициализировать... А она просто нулями забита..

Удачи тебе, браток!
Re[2]: Почему настоящие программисты избегают C++
От: Gaperton http://gaperton.livejournal.com
Дата: 17.02.05 18:45
Оценка:
Здравствуйте, alnsn, Вы писали:

A>http://www.catb.org/~esr/writings/taoup/html/ten-thousand.html
Великолепно. Но оофтоп.
Re[10]: Почему настоящие программисты избегают C++
От: Kubera Россия  
Дата: 17.02.05 19:48
Оценка:
Здравствуйте, 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. я решение знаю, но не сказал бы что оно простое

Проблема переполнения остаётся и при использовании беззнаковых целых. А для int в данном случае решение есть и простое (не сказал бы что красивое, но...). Приводим a и b к long long, а после деления обратно к int.

Пример (Windows):
#include "stdafx.h"
using namespace std;

int Aver(int a, int b);

int _tmain(int argc, _TCHAR* argv[])
{
    int a = 0, b = 0;

    cout << "a? ";
    cin >> a;

    cout << "b? ";
    cin >> b;

    cout << "(" << a << " + " << b << ") / 2 = " << Aver(a,b) << endl;

    return 0;
}

int Aver(int a, int b)
{
    return static_cast<int>((static_cast<long long>(a) + static_cast<long long>(b))/2);
}

ИМХО, твой пример со средним арифметическим неудачный. Что же касается знаковых индексов в векторе, то они нецелесообразны по двум причинам:
1. дополнительная ошибочная ситуация с отрицательным индексом
2. размер массива уменьшается в два раза (по сравнение с таким же знаковым типом)
Любая сложная технология неотличима от волшебства. (Артур Кларк)
Re[5]: Почему настоящие программисты избегают C++
От: Кодт Россия  
Дата: 17.02.05 23:00
Оценка:
Здравствуйте, d Bratik, Вы писали:

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

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.

DB>Сайт выглядит очень профессионально. Интересно было бы взглянуть на внешний вид самой программы, а также узнать, на чем она написана (Qt?), и поддерживает ли она расширение своей функциональности на каком-нибудь языке программирования.

Обелиск, мои поздравления!
(Хотя лично у меня к UML Suite, кажется, 1999 года — очень большие претензии. Впрочем, тут могла быть обоюдная кривизна рук).
Перекуём баги на фичи!
Re[4]: Почему настоящие программисты избегают C++
От: VladD2 Российская Империя www.nemerle.org
Дата: 18.02.05 00:06
Оценка:
Здравствуйте, SWW, Вы писали:

SWW>Кхм, интересно... Человек приводит заведомо неправильный код и говорит: С++ плохой язык потому что на нем можно написать неправильную программу — вот, видите, я же смог!

SWW>А если бы v.size() было знаковым, разве этот код работал бы?

Я так понимаю остальные замечания возражений не вызвали.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Почему настоящие программисты избегают C++
От: VladD2 Российская Империя www.nemerle.org
Дата: 18.02.05 00:06
Оценка:
Здравствуйте, 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>


Вот это пример хороший.

SWW>>А если бы v.size() было знаковым, разве этот код работал бы?

DB>Да, причем совершенно корректно.

Нет, уж. Он работал бы только при орпеделенном содержимом тела цикла (если там удалять элементы).
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Почему настоящие программисты избегают C++
От: VladD2 Российская Империя www.nemerle.org
Дата: 18.02.05 00:06
Оценка:
Здравствуйте, d Bratik, Вы писали:

DB>Решение состоит в том, что система должна генерировать исключение (exception) при переполнении. Отсутствие этой возможности я забыл добавить в качестве 7-го пункта в списке ошибок проектирования языка.

Еще раз повторюсь. Ты еще штук 100 проблем не описал. Многие из них можно объяснить погоней за скоростью (как с переполнением), многие наследием С, ну, и чое что можно списать на нерадивость и упертость Страуструпа и комитета.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Почему настоящие программисты избегают C++
От: VladD2 Российская Империя www.nemerle.org
Дата: 18.02.05 00:06
Оценка:
Здравствуйте, achp, Вы писали:


A>Элементарно переписывается так:

Переписывается все что хочешь. Вот только когда баг найдется. Люди лепят баги не специально.

A>Просто нужно кумекалкой соображать.

Вот такие самоуверенные обычно первыми по граблям и ходят.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Почему настоящие программисты избегают C++
От: VladD2 Российская Империя www.nemerle.org
Дата: 18.02.05 00:06
Оценка:
Здравствуйте, d Bratik, Вы писали:

DB>Проблема шалонов не хреновой читаемости, а в том, что они unsafe — невозможно указать ограничений (constraints) для параметров. Шаблонов в своих программах можно избегать. Без сборщика мусора трудно, но существуют подходы (например, концепция владения), которые позволяют обойтись без него. А вот без остального действительно туго.

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

Ну, да C++/CLI / МС++ тут частично спасают.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Почему настоящие программисты избегают C++
От: VladD2 Российская Империя www.nemerle.org
Дата: 18.02.05 00:06
Оценка:
Здравствуйте, Xentrax, Вы писали:

X>Язык С++ — для того, чтобы решать проблемы язка, а нормальный язык должен быть создан для того чтобы решать проблемы предметной области.

X>И если вам и мне интересно заниматься этим, то нашим работодателям — нет.

Жаль пост не в философии. Оценка была бы больше. А так очень точные и локоничные слова. Полностью согласен. Вот только мне уже не интересно заниматься его проблемами.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Почему настоящие программисты избегают C++
От: Шахтер Интернет  
Дата: 18.02.05 03:42
Оценка:
Здравствуйте, VladD2, Вы писали:

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

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

DB>>>Проблема шалонов не хреновой читаемости, а в том, что они unsafe — невозможно указать ограничений (constraints) для параметров. Шаблонов в своих программах можно избегать. Без сборщика мусора трудно, но существуют подходы (например, концепция владения), которые позволяют обойтись без него. А вот без остального действительно туго.

К>>Не умеешь писать с шаблонами — так прямо и скажи.

VD>Ну, это голословные наезды. Я вот вроде немного умею, но, что шаблоны создают не мло проблем. Но тут хоть ясно за что платить.

К>>Констрейнты в шаблонах делаются с лёгкостью необычайной.

VD>Это уже даже за гранью спорности. Видимо ты плохо понимашь, что такое констрэйны.

VD>В С++ проверки делаются только во время воплощения шаблона.
VD>Констрэйны же накладывают ограничения на параметры шаблона.

Ага. Как только эти два предложения противоречат друг другу я не понимаю.

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

VD>Сдается мне, что в следующей версии стандарта констрэйны добавят обязательно.

А зачем? Во-первых, существующий язык позволяет их реализовать. Соответственно, нет жесткой необходимости встраивать их в язык/компилятор.
Во-вторых, острой необходимости в использовании констрейнов нет. Фактически, их главное назначение -- улучшить диагностику и более явно описать требования к шаблонным параметрам.

К>>Как именно — не скажу, тебе это всё равно не пригодится.

VD>О. А еще меня тут пинают за подколки и уколки.

Да нет, Кодт имеет ввиду, что ты с плюсов сбежал, так что зачем оно тебе?
... << RSDN@Home 1.1.0 stable >>
В XXI век с CCore.
Копай Нео, копай -- летать научишься. © Matrix. Парадоксы
Re[6]: Почему настоящие программисты избегают C++
От: Шахтер Интернет  
Дата: 18.02.05 04:10
Оценка:
Здравствуйте, 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>Нет, уж. Он работал бы только при орпеделенном содержимом тела цикла (если там удалять элементы).

Ты внимательно прочитал этот код?
... << RSDN@Home 1.1.0 stable >>
В XXI век с CCore.
Копай Нео, копай -- летать научишься. © Matrix. Парадоксы
Re[6]: Почему настоящие программисты избегают C++
От: Шахтер Интернет  
Дата: 18.02.05 04:10
Оценка:
Здравствуйте, 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>>


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>
... << RSDN@Home 1.1.0 stable >>
В XXI век с CCore.
Копай Нео, копай -- летать научишься. © Matrix. Парадоксы
Re[7]: Почему настоящие программисты избегают C++
От: Шахтер Интернет  
Дата: 18.02.05 04:10
Оценка:
Здравствуйте, _wind_, Вы писали:

__>Здравствуйте, 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>>>


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>>


__>К слову, этот цикл работает за время O(v.size()^2).

Не угадал. Условие цикла всегда истинно.
... << RSDN@Home 1.1.0 stable >>
В XXI век с CCore.
Копай Нео, копай -- летать научишься. © Matrix. Парадоксы
Re[3]: Почему настоящие программисты избегают C++
От: Mr. None Россия http://mrnone.blogspot.com
Дата: 18.02.05 05:13
Оценка:
Здравствуйте, d Bratik, Вы писали:

DB>Вы наверное писали очень небольшие программы, без GUI.

О великий и могучий прости меня — всю свою сознательную жизнь я писал большие программы без GUI и не знал, что это плохо. Я попробую написать одну хоть самую маленькую гуёвую программу, при условии, что ты пощадишь меня и снизайдёшь своей сияющей благотатью до такого недостойного представителя отряда программистов на С++ без гуя!


DB>Для создания программ С++ подходит, но для создания систем — нет.

Кстати, а чем системы отличаются от программ... А то я не знаю
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Re[2]: Почему настоящие программисты избегают C++
От: Mr. None Россия http://mrnone.blogspot.com
Дата: 18.02.05 05:23
Оценка:
Здравствуйте, Xentrax, Вы писали:

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

X>На самом деле, не такой он и плохой. Хороший даже, вон сколько всего понаписали. Сидят такие русские и украинские Рсдновцы и пишут, пишут. Шаблоны всякие используют, бусты с стлпортами, всяческие хитрые менеджеры памяти придумывают. Люди книжки пишут, ну типа "10001 совет, как не свернуть себе шею, пытаясь использовать StlPort 4.6.2 в EVC 3.0.". Деньги зарабатывают.

С некоторыми утверждениями не согласен, но в целом вы правы — язык требует реформирования. В основном в том, что касается ужесточения некоторых требований, устранения ряда противоречий и двойственности и отказ от наследственности pure C. Конкретизировать не буду дабы не плодить флейм — эти темы поднимались не раз, кто читает ветки C++ и Философию, встречает похожие обсуждения регулярно.
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Re[6]: Почему настоящие программисты избегают C++
От: _Obelisk_ Россия http://www.ibm.com
Дата: 18.02.05 06:34
Оценка:
Здравствуйте, Кодт, Вы писали:

К>Обелиск, мои поздравления!
К>(Хотя лично у меня к UML Suite, кажется, 1999 года — очень большие претензии. Впрочем, тут могла быть обоюдная кривизна рук).

UML Suite был куплен Telelogic-ом. Ранее он назывался COOL:Jex/ObjectTeam.
Telelogic его не разрабатывал.


Душа обязана трудиться! (с) Н.Заболоцкий.
Re[4]: Только настоящие программисты пишут на С++! :)
От: stalcer Россия  
Дата: 18.02.05 06:52
Оценка:
Здравствуйте, Шахтер, Вы писали:

Ш>COM -- это вообще из другой оперы. Для компонентной разработки он не нужен вообще. Он нужен для интеграции компонентов, написаных на разных языках. Для того, чтобы это было возможно, необходим бинарный стандарт на испольнямые модули/динамические библиотеки.

Ну ну. Для экспорта классов из dll значит бинарного стандарта не нужно.
А в Delphi, например, есть же скомпилированные модули (*.dcu), правда модуль, скомпилированный в одной версии нельзя использовать в другой. Но все равно, от наличия таких модулей больше пользы, чем вреда, причем намного больше.
... << RSDN@Home 1.1.3 stable >>
Re[5]: Почему настоящие программисты избегают C++
От: _Obelisk_ Россия http://www.ibm.com
Дата: 18.02.05 06:55
Оценка:
Здравствуйте, d Bratik, Вы писали:

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

DB>>>Вы наверное писали очень небольшие программы, без GUI. Для создания программ С++ подходит, но для создания систем — нет.

DB>Сайт выглядит очень профессионально. Интересно было бы взглянуть на внешний вид самой программы, а также узнать, на чем она написана (Qt?), и поддерживает ли она расширение своей функциональности на каком-нибудь языке программирования.

Скриншот я привел тут
http://www.rsdn.ru/Forum/Message.aspx?mid=1032696&amp;only=1
Автор: _Obelisk_
Дата: 18.02.05


Qt не использовалась. GUI базируется на библиотеках от Stingray + собственные разработки. Портирование GUI-я под Unix/Linux осуществляется с использованием продукттов MainSoft-а. Расширения лучше всего писать на С++.


Душа обязана трудиться! (с) Н.Заболоцкий.
Re[3]: Почему настоящие программисты избегают C++
От: Pazak Россия  
Дата: 18.02.05 07:36
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>О! Вот и появился C#. И ведь никто за язык не тянул.

Сейчас оберонисты прибегут
Ку...
Re[12]: Почему настоящие программисты избегают C++
От: Кодт Россия  
Дата: 18.02.05 07:59
Оценка:
Здравствуйте, screw_cms, Вы писали:

_>Баян! http://www.rsdn.ru/Forum/Message.aspx?mid=1032467&amp;only=1

Не баян! kakashka неправильно работает на отрицательных аргументах.
Даю маячок: чему равно (-1)>>1 ?
Перекуём баги на фичи!
Re[12]: Почему настоящие программисты избегают C++
От: Кодт Россия  
Дата: 18.02.05 08:02
Оценка:
Здравствуйте, 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>


M>Хотя могу и ошибиться

А вот это уже баян см. выше по ветке
Перекуём баги на фичи!
Re[13]: Почему настоящие программисты избегают C++
От: migel  
Дата: 18.02.05 08:12
Оценка:
Здравствуйте, Кодт, Вы писали:


К>А вот это уже баян см. выше по ветке
Неа ниже
просто я тодыть не все прочитал.
а так искринне извинямшись
... << RSDN@Home 1.1.4 beta 4 rev. 324>>
Re[11]: Почему настоящие программисты избегают C++
От: Kh_Oleg  
Дата: 18.02.05 08:54
Оценка:
Здравствуйте, Кодт, Вы писали:

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

Каким?

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

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

Бывают ситуации, когда корректная обработка невозможна и результат недостижим. В этом случае надо сообщить об этом вызывающей функции. Исключения не позволили бы прозевать такую ошибку.
Re[7]: Почему настоящие программисты избегают C++
От: AlikGut  
Дата: 18.02.05 09:14
Оценка:
Здравствуйте, Шахтер, Вы писали:

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>>Вот это пример хороший.

Ш>Ты внимательно прочитал этот код?

канешна — этож плюсы. а нормальный не плюсовый компилер и сам в состоянии понять что нада декремент делать!! ессно что на плюсах работать не будет

AlikGut, #337311300

Running da RSDN@Home v1.1.3; Winamp:Motherboard — Dead SoundBlaster

Будьте проще, и к Вам потянутся тысячи. (С) Монетный двор РФ.

Re[8]: Почему настоящие программисты избегают C++
От: Sergey Россия  
Дата: 18.02.05 09:22
Оценка:
Hello, AlikGut!
You wrote on Fri, 18 Feb 2005 09:14:05 GMT:

DB>>>> 
 DB>>>> std::vector<int> v;
 DB>>>> for (std::vector<int>::size_type i = v.size() - 1; i >= 0;
 DB>>>> ++i) { ... }


A> канешна — этож плюсы. а нормальный не плюсовый компилер и сам в
A> состоянии понять что нада декремент делать!! ессно что на плюсах
A> работать не будет

Интересно, как в этой ситуации может помочь декремент?

With best regards, Sergey.
Posted via RSDN NNTP Server 1.9
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[11]: Почему настоящие программисты избегают C++
От: nixite  
Дата: 18.02.05 09:39
Оценка:
Здравствуйте, Kubera, Вы писали:

K>Проблема переполнения остаётся и при использовании беззнаковых целых. А для int в данном случае решение есть и простое (не сказал бы что красивое, но...). Приводим a и b к long long, а после деления обратно к int.

В стандарте C++ нет типа long long ! это всё мелгомягкие дополнения решения есть но ещё кривее
Re[11]: Почему настоящие программисты избегают C++
От: nixite  
Дата: 18.02.05 09:43
Оценка:
Здравствуйте, screw_cms, Вы писали:

_>int kakashka( int a, int b )
_>{
_>return (a>>1 + b>>1) + ( ((a&1)&&(b&1))?1:0 );
_>}

оно самое, только вот код со всеми супер оптимизациями займёт раз в 10 больше чем простой и глупый код в три команды на ассеблере — печально, ведь это один из самых низкоуровневых из высокоуровневых языков
Re[12]: Почему настоящие программисты избегают C++
От: Кодт Россия  
Дата: 18.02.05 09:57
Оценка:
Здравствуйте, nixite, Вы писали:

_>>int kakashka( int a, int b )
_>>{
_>>return (a>>1 + b>>1) + ( ((a&1)&&(b&1))?1:0 );
_>>}

N>оно самое, только вот код со всеми супер оптимизациями займёт раз в 10 больше чем простой и глупый код в три команды на ассеблере — печально, ведь это один из самых низкоуровневых из высокоуровневых языков

1) Как я уже говорил, этот код неправильный.

2) Если какой-то процессор эффективно и без переполнения позволяет находить среднее арифметическое, и оно очень востребовано — то можно написать ассемблерную вставку.
; запретить INTO
cli

mov eax, _a_
add eax, _b_
ror eax, 1

; восстановить
sti
Перекуём баги на фичи!
Re[13]: Почему настоящие программисты избегают C++
От: nixite  
Дата: 18.02.05 10:21
Оценка:
К>2) Если какой-то процессор эффективно и без переполнения позволяет находить среднее арифметическое, и оно очень востребовано — то можно написать ассемблерную вставку.
К>
К>; запретить INTO
К>cli

К>mov eax, _a_
К>add eax, _b_
К>ror eax, 1

К>; восстановить
К>sti
К>


а зачем CLI и STI то в этом случае?
насчёт ошибочности согласен, но и a/2 + b/2 + (a%2 + b%2)/2 не подарок явно!
Re[13]: Почему настоящие программисты избегают C++
От: Kh_Oleg  
Дата: 18.02.05 10:21
Оценка:
Здравствуйте, Кодт, Вы писали:

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

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

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

К>Вот так?
К>
К>int mid(int a, int b) throw() // наружу мы ничего не кидаем
К>{
К>  try // попробуем быстрый, но небезопасный способ...
К>  {
К>    return (a+b)/2;
К>  }
К>  catch(overflow_error& ex) // облажались? тогда попробуем по-другому...
К>  {
К>    return a/2+b/2+(a%2+b%2)/2;
К>  }
К>}
К>

К>Здесь, очевидно, использование метода облажались-переделали — это извращение.
К>А на каких практических задачах он эффективен?

На тех, для которых известно, что переполнение возникает очень редко.
Re[13]: Почему настоящие программисты избегают C++
От: nixite  
Дата: 18.02.05 10:28
Оценка:
К>Вот так?
К>
К>int mid(int a, int b) throw() // наружу мы ничего не кидаем
К>{
К>  try // попробуем быстрый, но небезопасный способ...
К>  {
К>    return (a+b)/2;
К>  }
К>  catch(overflow_error& ex) // облажались? тогда попробуем по-другому...
К>  {
К>    return a/2+b/2+(a%2+b%2)/2;
К>  }
К>}
К>

К>Здесь, очевидно, использование метода облажались-переделали — это извращение.
К>А на каких практических задачах он эффективен?

думаю что он эффективен там где не учитывается возможность переполнения а она происходит, пример как раз (a+b)/2 -- это типичная ошибка для программиста, там где не ткнули носом что он не прав, а сколько времени уйдёт у не опытного (а может и у опытного) чтобы понять в чём дело-то, ведь (a+b)/2 это как правло не вся программа, а случай переполнения скорее всго вообще не возникнет на этапе разработки и тестирования в российских условиях, когда проверяют только тыканьем кнопок. Особенно когда вы делаете не гуи или ещё какие задачи простые и не очень, а что-то вычислительное, учесть все переполнение иногда бывает сверх-издевательством.

может ещё DBC обсудим по ходу этого обсуждения (DBC = design by contracts, см. Eiffel)
Re[15]: Почему настоящие программисты избегают C++
От: alnsn Великобритания http://nasonov.blogspot.com
Дата: 18.02.05 11:41
Оценка:
Здравствуйте, Kh_Oleg, Вы писали:

K_O>Читаем...
K_O>

K_O>The internal SRI software exception was caused during execution of a data conversion from 64-bit floating point to 16-bit signed integer value. The floating point number which was converted had a value greater than what could be represented by a 16-bit signed integer. This resulted in an Operand Error. The data conversion instructions (in Ada code) were not protected from causing an Operand Error, although other conversions of comparable variables in the same place in the code were protected.

K_O>The error occurred in a part of the software that only performs alignment of the strap-down inertial platform. This software module computes meaningful results only before lift-off. As soon as the launcher lifts off, this function serves no purpose.

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

K_O>На самом деле ошибка была в том, что разработчики не предусмотрели такую ситуацию и не защитились от нее.

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

PS я неудачно выбрал пост для размещения ссылки. В этом обсуждении есть более хорошие места для нее
Re[9]: Почему настоящие программисты избегают C++
От: AlikGut  
Дата: 18.02.05 11:46
Оценка:
Здравствуйте, Sergey, Вы писали:

S>Интересно, как в этой ситуации может помочь декремент?

никак — но с ним будет в тыщу раз круче — один раз оно всетаки отработает а Вы, читайте самую самую нижнюю строчку в моей подписи

AlikGut, #337311300

Running da RSDN@Home v1.1.3; Winamp:Motherboard — Dead SoundBlaster

Будьте проще, и к Вам потянутся тысячи. (С) Монетный двор РФ.

Re[13]: Почему настоящие программисты избегают C++
От: BiТ  
Дата: 18.02.05 12:03
Оценка:
Здравствуйте, Кодт, Вы писали:

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

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

K_O>>Каким?

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

А не логичнее(в таких языках как Java, C#) следующее:
1)позволить переполнению произойти
2)перехватить исключение и обернуть в свое исключение — однозначно идентифицирующее место возникновения
3)внешний код разруливает ситуацию по своему усмотрению( в моих задачах это запись в журнал ошибок с детальной информацией о произошедшем и окончание вычислительной сессии с немедленным приведением системы в максимально безопасное логическое состояние && (в зависимости от режима работы, если в режиме реальной эксплуатации — создание новой вычислительной сессии, получение новой порции данных и их обработка, иначе если это отладочный режим — шотдаун и последующий разбор полётов).
?
Re[14]: Почему настоящие программисты избегают C++
От: Кодт Россия  
Дата: 18.02.05 12:23
Оценка:
Здравствуйте, nixite, Вы писали:

N>а зачем CLI и STI то в этом случае?

А, действительно, незачем. Это я забыл нафиг ассемблер.
Чтобы получить прерывание по переполнению, нужно самому вставлять инструкцию INTO после вычислений.
Извините.

N>насчёт ошибочности согласен, но и a/2 + b/2 + (a%2 + b%2)/2 не подарок явно!

Почему же не подарок? Деление округляет к меньшему по модулю, а остаток — знаковый.
Перекуём баги на фичи!
Re[10]: Почему настоящие программисты избегают C++
От: Sergey Россия  
Дата: 18.02.05 13:03
Оценка:
Hello, AlikGut!
You wrote on Fri, 18 Feb 2005 11:46:11 GMT:

S>> Интересно, как в этой ситуации может помочь декремент?

A> никак — но с ним будет в тыщу раз круче — один раз оно всетаки
A> отработает

Оно по-любому будет работать пока батарейки не сядут

A> а Вы, читайте самую самую нижнюю строчку в моей подписи
А мне через текстовый NNTP подписей не видно.

With best regards, Sergey.
Posted via RSDN NNTP Server 1.9
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[13]: Почему настоящие программисты избегают C++
От: ddanila Россия  
Дата: 18.02.05 13:21
Оценка:
Странно, в том тексте стандарта С++, что у меня есть, упоминания о "long long int" действительно нету. А в стандарте C — есть.
Но в любом случае это не расширения Microsoft, так как поддерживаются и gcc, например.
Скорее всего, это просто ещё не "переползло" окончательно из стандарта С в С++, но переползёт обязательно — куда же без стандартного типа long long int?
Re[4]: Почему настоящие программисты избегают C++
От: achp  
Дата: 18.02.05 13:32
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Переписывается все что хочешь. Вот только когда баг найдется. Люди лепят баги не специально.

Если я пишу unsigned n, то я всегда должен осознавать, какие правила арифметики будут применяться к n. Написание int n также не всегда позволяет избежать "задумчивости".

VD>Вот такие самоуверенные обычно первыми по граблям и ходят.

Машинная арифметика — это не то же самое, что общепринятая арифметика. Это фундаментально важно понимать. Есть языки программирования, которые стремятся "затушевать" эту разницу; тем не менее, языки вроде Си++ и Си-Шарпа, опирающиеся именно на машинную арифметику, почему-то находят большее применение. Если, имея unsigned n1, n2, пишешь n1 — n2, нужно четко понимать, что получится, будь n1 < n2.

Есть приложения, в которых существенно важной является арифметика по модулю 2^n; тогда естественный выбор — беззнаковые типы.

Что касается Си и Си++, то, на мой взгляд, это их недостаток, что отсутствуют переносимые средства обнаружения переполнений. Но и такие, как checked в Си-Шарпе не очень-то полезны.
Я кончил, джентльмены, мне остается только поблагодарить вас за внимание.
Re[6]: Почему настоящие программисты избегают C++
От: d Bratik  
Дата: 18.02.05 16:00
Оценка:
Здравствуйте, _Obelisk_, Вы писали:

DB>>Сайт выглядит очень профессионально. Интересно было бы взглянуть на внешний вид самой программы, а также узнать, на чем она написана (Qt?), и поддерживает ли она расширение своей функциональности на каком-нибудь языке программирования.

_O_>Скриншот я привел тут
_O_>http://www.rsdn.ru/Forum/Message.aspx?mid=1032696&amp;only=1
Автор: _Obelisk_
Дата: 18.02.05


_O_>Qt не использовалась. GUI базируется на библиотеках от Stingray + собственные разработки. Портирование GUI-я под Unix/Linux осуществляется с использованием продукттов MainSoft-а. Расширения лучше всего писать на С++.

Дизайн сделан со вкусом, как говорится, снимаю чепчик

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

Можно ли как-нибудь получить Ваш e-mail, чтобы поговорить подробнее?
Re[8]: Почему настоящие программисты избегают C++
От: AlexEagle Украина http://www.vik.oil
Дата: 18.02.05 16:37
Оценка:
Здравствуйте, d Bratik, Вы писали:

DB>... есть кричащие проблемы, анализируя истоки которых приходишь к очень неутешительным выводам по поводу компетентности некоторых товарищей (Б.С.).

Судя по постам, твоя компетентность не оставляет сомнений. Особенно мне "понравился" пост компетентность создателя С++
Re[12]: Почему настоящие программисты избегают C++
От: Kubera Россия  
Дата: 18.02.05 16:49
Оценка:
Здравствуйте, migel, Вы писали:

K>>Проблема переполнения остаётся и при использовании беззнаковых целых. А для int в данном случае решение есть и простое (не сказал бы что красивое, но...). Приводим a и b к long long, а после деления обратно к int.
M>боже мой какой изврат для этого случая
Да изврат, зато проще некуда...

M>
M>int kaka(int a, int b)
M>{
M>    return a/2 + b/2;
M>}
M>


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>

M>Хотя могу и ошибиться
Поведение от (a+b)/2 отличается, подробнее см. здесь
Автор: Kubera
Дата: 18.02.05
.
Любая сложная технология неотличима от волшебства. (Артур Кларк)
Re: Почему настоящие программисты избегают C++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 18.02.05 16:54
Оценка:
Здравствуйте, d Bratik,

Наконец-то на RSDN появляется всамделишный Anti-C++ evanhelism.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[12]: Почему настоящие программисты избегают C++
От: Kubera Россия  
Дата: 18.02.05 17:07
Оценка:
Здравствуйте, nixite, Вы писали:

K>>Проблема переполнения остаётся и при использовании беззнаковых целых. А для int в данном случае решение есть и простое (не сказал бы что красивое, но...). Приводим a и b к long long, а после деления обратно к int.

N>В стандарте C++ нет типа long long ! это всё мелгомягкие дополнения решения есть но ещё кривее
А ты спрашивал про простое, а не универсальное или мультиплатформенное решение.
P.S. Я могу ошибаться, но, кажется, CodeWarrior и gcc стали раньше VC поддерживать long long, у VC сначало появился __int64.
Любая сложная технология неотличима от волшебства. (Артур Кларк)
Re[5]: Почему настоящие программисты избегают C++
От: nixite  
Дата: 18.02.05 17:16
Оценка:
Здравствуйте, achp, Вы писали:

A>Машинная арифметика — это не то же самое, что общепринятая арифметика. Это фундаментально важно понимать. Есть языки программирования, которые стремятся "затушевать" эту разницу; тем не менее, языки вроде Си++ и Си-Шарпа, опирающиеся именно на машинную арифметику, почему-то находят большее применение. Если, имея unsigned n1, n2, пишешь n1 — n2, нужно четко понимать, что получится, будь n1 < n2.

мне кажется если была перенесена такая арифметика как есть, то нужны и полные средства работы с этой арифметикой, такие какие предоставляет ассемблер. (правда ассемблер ассемблеру рознь, но пусть будет хотябы x86)
Re[7]: Почему настоящие программисты избегают C++
От: nixite  
Дата: 18.02.05 17:17
Оценка:
Здравствуйте, d Bratik, Вы писали:

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

мне тоже интересно, может новую ветку открыть о качественном портировании в Linux/Solaris из под виндовс и библиотеках GUI под них.
Re[16]: Почему настоящие программисты избегают C++
От: nixite  
Дата: 18.02.05 17:26
Оценка:
Здравствуйте, Kubera, Вы писали:

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

конечно так в лоб врядли встретишь, но (a+b)/2 довольно частaя операция, и схожие с ними, а предположить что кто-то сунет в функцию не съедобное рядовому программисту часто не доводится и потому он смотрит и недоумевает что же происходит в формуле с 10-ом операций, формула то абсолютно верная... (c т.з. обычной математики?). суровая реальность
Re[10]: Почему настоящие программисты избегают C++
От: AlexEagle Украина http://www.vik.oil
Дата: 18.02.05 19:34
Оценка:
Здравствуйте, d Bratik, Вы писали:

AE>>Судя по постам, твоя компетентность не оставляет сомнений. Особенно мне "понравился" пост компетентность создателя С++

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

"Обидеть поэта может всякий! А вот понять его тонкую чуствительную натуру..." (с) не мое


DB>Поскорее бы сдох этот Unix, этот Sun с его соляркой, чтобы пересесть на C# или на Delphi, или на Oberon наконец.

Я угадал
Автор: AlexEagle
Дата: 18.02.05
Re[11]: Почему настоящие программисты избегают C++
От: SWW Россия  
Дата: 18.02.05 20:36
Оценка:
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. я решение знаю, но не сказал бы что оно простое

Таких "проблем" я могу привести массу, причем гораздо менее экзотических, но это не значит что нужно валить все на С++
Как например написать функцию, вычисляющую среднее двух углов? Тестовый пример: 359 градусов и 1 градус. Но это еще легко, а как вычислить среднее десяти углов?

p.s. я тоже решение знаю, и оно достаточно простое
Re[2]: Почему настоящие программисты избегают C++
От: AlexBS Украина  
Дата: 19.02.05 05:55
Оценка:
Здравствуйте, AlexEagle, Вы писали:

AE>И предпочитают делфи где-то по следующим причинам:

AE>8. За жесткие ограничения на место описания переменных функции — между названием функции и началом блока
+ и допуск совпадения имен переменных и типов. т.е конструкция
var
Word : Integer;
вполне допустима. но, понятно, что работать с такой переменной будет крайне сложно

AE>9. За невозможность смешивания переменных и функций класса при описании (вначале переменные а затем функции и не иначе)
... и необходимость четкого совпадения имен переменных в параметрах методов класса.

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

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

AE>15. За то что она не MDI. Это ужасно "УДОБНО". Приходится очищать рабочий стол перед открытием делфи, да и две запущенные — это головняк ("КРУТО"), поскольку никогда не знаешь в редакторе какой находишся. Иногда по ALT-TAB переключается только редактор, а главное окно нет.
А если на главное окно попадает фокус и в редакторе активный модуль без формы, то с клавиатуры сфокусировать редактор невозможно.

AE>16. За WITH благодаря которому дебаггер не показывае значение переменных типа with TComeCObject.Create(...) do Visible := TRUE;
AE> Значение Visible — не увидишь никогда. Только если with SomeObject do SomeProperty := SomeValue; то в ТОЛЬКО окне свойств надо подставить SomeObject.SomeProperty и только тогда будет значение
Да... от WITH толку столько же, как и от комментариев на китайском — вроде все есть, а к чему относится, непонятно.

AE>24. За то что иногда невозможно открыть справку по F1, если модуль содержит ошибки.

А на счет справки (хе-хе, Delphi7)..... Если курсор стоит в пустом месте, F1 просто не работает.


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

Например, ReadProcessMemory
function ReadProcessMemory(hProcess: THandle; const lpBaseAddress: Pointer; lpBuffer: Pointer; nSize: DWORD; var lpNumberOfBytesRead: DWORD): BOOL; stdcall;

Ну нахрена мне всегда(!!) заводить бесполезную переменную для параметра var lpNumberOfBytesRead: DWORD, когда она в 99% случаях просто ненужна!
А таких функций уйма!
Re[3]: Почему настоящие программисты избегают C++
От: nixite  
Дата: 19.02.05 06:12
Оценка:
Здравствуйте, AlexBS, Вы писали:

ABS>На последок хотелось бы заметить про идиотский var в описаниях функций, где он зачастую просто мешает!
ABS>Например, ReadProcessMemory
ABS>
ABS>function ReadProcessMemory(hProcess: THandle; const lpBaseAddress: Pointer; lpBuffer: Pointer; nSize: DWORD; var lpNumberOfBytesRead: DWORD): BOOL; stdcall;
ABS>

ABS>Ну нахрена мне всегда(!!) заводить бесполезную переменную для параметра var lpNumberOfBytesRead: DWORD, когда она в 99% случаях просто ненужна!
ABS>А таких функций уйма!

для таких случаев объявление строится не через var (что полагает обязательную передачу параметра), а через lpNumberOfBytesRead: ^DWORD (а точнее pdword = ^dword). то что у вас некорректно функция объявлена не вина языка.
Re[4]: Почему настоящие программисты избегают C++
От: AlexBS Украина  
Дата: 19.02.05 06:21
Оценка:
Здравствуйте, nixite, Вы писали:

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

ABS>>
ABS>>function ReadProcessMemory(hProcess: THandle; const lpBaseAddress: Pointer; lpBuffer: Pointer; nSize: DWORD; var lpNumberOfBytesRead: DWORD): BOOL; stdcall;
ABS>>


N>для таких случаев объявление строится не через var (что полагает обязательную передачу параметра), а через lpNumberOfBytesRead: ^DWORD (а точнее pdword = ^dword). то что у вас некорректно функция объявлена не вина языка.

К сожалению, эта функция описана в Windows.pas, а не у меня.

P.S. Var использую только перед begin, т.к это единственное место, где без него не обойтись.
Re: Почему настоящие программисты избегают C++
От: csvb  
Дата: 19.02.05 07:56
Оценка:
Здравствуйте, d Bratik, Вы писали:

DB>1.Отсутствие модулей. Имитация понятия модуль в виде пары h-файл – cpp-файл приводит к многочасовым компиляциям системы.

DB>2.Использование целочисленных типов данных без знака (unsigned int) для номеров элементов и количественных значений в стандартной библиотеке stdc++. Приводит к следующим ошибкам:

DB>
DB>std::vector<int> v;
DB>// Следующий код работает бесконечно, поскольку (size_type)(-1) == 4 млрд.
DB>for (std::vector<int>::size_type i = 0; v.size() - 1; ++i)
DB>{
DB>  ...
DB>}
DB>


DB>3.Отсутствие встроенной проверки на выход за диапазоны массива. Приводит к необходимости писать «обертки» для классов-контейнеров (в частности, для класса vector).

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

DB>5.«Автоматизм» конструкторов и деструкторов для объектов, создаваемых динамически и имеющих виртуальные методы; работа виртуальных методов как не виртуальных при их вызове из конструкторов и деструкторов; отсутствие стандартного базового класса. Значительно затрудняет решение проблемы повторного входа в объекты (reentrance problem) при создании библиотек визуальных компонентов и систем GUI.

DB>6.Отсутствие оператора try {…} finally {…}. Приводит к созданию программ, неустойчивых к исключительным ситуациям. Попытка имитировать этот оператор с помощью оператора try {…} catch {…} приводит к большой избыточности кода.


Более 15 лет пишу деловой и системный софт на С++ для Windows и Unix (Linux).
Перечисленные проблемы никогда не были важными.
Исходя из своего опыта: у настоящих программистов другие проблемы.
P.S.:
С уважением отношусь к Delphi и C++ Builder,
но не встречал среди коллег, использующих данное ПО,
проектов хотя бы в 100 тысяч строк кода.
Согласитесь, весьма небольшой объем.
P.P.S.:
К сожалению, Borland практически перестал развивать линию C++,
хотя, на мой взгляд, вплоть до Borland C++ 4.0, это был
лучший компилятор.
Re[2]: Почему настоящие программисты избегают C++
От: d Bratik  
Дата: 19.02.05 13:34
Оценка:
Здравствуйте, 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 до тех пор, пока в ней не появились такие люди, как Хайльсберг.

Я отвлекся от темы? Нет. Это имеет прямое отношение к тому, почему настоящие программисты (такие как Вирт, Хайльсберг и др ) избегают С++.
Re[10]: Почему настоящие программисты избегают C++
От: Cyberax Марс  
Дата: 19.02.05 14:21
Оценка:
d Bratik пишет:

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

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

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

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

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

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

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



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

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

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

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

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

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[4]: Почему настоящие программисты избегают C++
От: d Bratik  
Дата: 19.02.05 14:44
Оценка:
Здравствуйте, 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!.
Re[14]: Почему настоящие программисты избегают C++
От: Шахтер Интернет  
Дата: 19.02.05 17:28
Оценка:
Здравствуйте, 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); // встроенный в язык оператор


К сожалению, это затрагивает основы языка и вряд ли можно сейчас внедрить.
... << RSDN@Home 1.1.0 stable >>
В XXI век с CCore.
Копай Нео, копай -- летать научишься. © Matrix. Парадоксы
Re[3]: Почему настоящие программисты избегают C++
От: Программер  
Дата: 20.02.05 15:35
Оценка:
Здравствуйте, d Bratik, Вы писали:

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

А сам ты, "кул хацкер", для которого малейшее затруднение — нерешаемая проблемма.
Re[15]: Почему настоящие программисты избегают C++
От: BiТ  
Дата: 20.02.05 20:46
Оценка:
Здравствуйте, Шахтер, Вы писали:

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

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

ИМХО — отнюдь не логичнее. Делается неявное допущение о том, что вызывающий код в случае необходимости будет проверять на переполнение после операции. А ИМХО — в случае переполнения, если для вызываемого кода это критично(а это критично в очень многих случаях) — нужно генерировать исключение, чтобы вызываемый код явным образом обрабатывал эту ситуацию.
От модератора
От: Kupaev Россия www.rsdn.ru
Дата: 20.02.05 21:39
Оценка:
Здравствуйте, d Bratik.

Завязываем с оверквоттингом!
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Re[16]: Почему настоящие программисты избегают C++
От: Шахтер Интернет  
Дата: 20.02.05 22:10
Оценка:
Здравствуйте, BiТ, Вы писали:

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

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

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

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

Это слишком дорого и неудобно. Начнем с того, что такого понятия как переполнение в арифметике по модулю вообще не существует. И если я использую тип unsigned для вычислений по модулю 2^..., то мне эти исключения нафик не упали. В тех же случаях, когда переполнения должны быть учтены (яркий пример -- реализация длинной арифметики), это гораздо удобнее и эффективнее сделать имея на руках бит C. Исключения тут никак не катят.
... << RSDN@Home 1.1.0 stable >>
В XXI век с CCore.
Копай Нео, копай -- летать научишься. © Matrix. Парадоксы
Re[4]: Почему настоящие программисты избегают C++
От: Pazak Россия  
Дата: 21.02.05 05:40
Оценка:
Здравствуйте, Cyberax, Вы писали:

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

Ой, щас чувствую меня ногами запинают, но молчать не могу: как противовес всем этим дельфевым "Расчетам налогов" и пр. можно привести 1С, которая АФАИК целиком написана на VC++. Как говорится "почувствуйте разницу".
Ку...
Re[13]: Почему настоящие программисты избегают C++
От: qwertyuiop Российская Империя  
Дата: 21.02.05 05:41
Оценка:
C>Ну а если программист — идиот, и пишет:
C>
for(size_t f=0;f<vec.size();f++)

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

А можно узнать почему? А то я боюсь, что меня, идиота, скоро уволят.
Я отвечаю за свои слова, а не за то как вы их интерпретируете!
Re[3]: Почему настоящие программисты избегают C++
От: Pazak Россия  
Дата: 21.02.05 05:42
Оценка:
Здравствуйте, d Bratik, Вы писали:


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

А аргументировать слабо?
Ку...
Re[14]: Почему настоящие программисты избегают C++
От: Amidlokos Россия  
Дата: 21.02.05 06:38
Оценка:
Здравствуйте, qwertyuiop, Вы писали:

C>>Ну а если программист — идиот, и пишет:
C>>
for(size_t f=0;f<vec.size();f++)

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

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

Как минимум в этом цикле на каждый проход вызывается vec.size(), а это означает вычисление входной точки, сам вызов, жонглирование регистрами и стеком и т.п.
WARNING: expression "to_be || !to_be" is always true
Re[16]: Почему настоящие программисты избегают C++
От: migel  
Дата: 21.02.05 07:09
Оценка:
Здравствуйте, Kubera, Вы писали:

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

K>P.S. Впрочем всё это пустое, т.к. врядли в реальном проекте встретится функция типа int kaka (int a, int b){return (a+b)/2;}
Согласен простое деление с положительным остатком когда m/n = kn + r где r >= 0 спасает
... << RSDN@Home 1.1.4 beta 4 rev. 324>>
Re[17]: Почему настоящие программисты избегают C++
От: BiТ  
Дата: 21.02.05 07:10
Оценка:
Здравствуйте, Шахтер, Вы писали:

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

Неудобно в С++, но не в C# и Java. Речь о переполнении в арифметике по модулю не шла. И опять-таки — насчёт эффективности. Мне вполне хватает.
P.S. Каждый остался при своём мнении
Re[3]: Почему настоящие программисты избегают C++
От: AlikGut  
Дата: 21.02.05 07:17
Оценка:
Здравствуйте, d Bratik, Вы писали:

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

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

AlikGut, #337311300

Running da RSDN@Home v1.1.3; Winamp:Motherboard — Dead SoundBlaster

Будьте проще, и к Вам потянутся тысячи. (С) Монетный двор РФ.

Re: Почему настоящие программисты избегают C++
От: Nose Россия  
Дата: 21.02.05 08:29
Оценка:
Здравствуйте, d Bratik, Вы писали:

Вот и я думаю, че они избегают-то?
Тов. настоящие программисты, вы че избегаете?
Re[2]: Почему настоящие программисты избегают C++
От: bopka  
Дата: 21.02.05 08:33
Оценка:
Здравствуйте, Nose, Вы писали:

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

N>Вот и я думаю, че они избегают-то?
N>Тов. настоящие программисты, вы че избегаете?
Они не настоящие — они только прикидываются
Re[3]: Почему настоящие программисты избегают C++
От: AlexEagle Украина http://www.vik.oil
Дата: 21.02.05 08:57
Оценка:
Здравствуйте, AlexBS, Вы писали:

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

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

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

AE>>14. За то что ошибочная работа встроенных функций ведет к генерированию исключения, а не возврату кода ошибки. При этом во многих случаях приходится писать просто try ... except end; чтобы пропустить эту фичу.
ABS>так нынче модно
Re[7]: Почему настоящие программисты избегают C++
От: _Obelisk_ Россия http://www.ibm.com
Дата: 21.02.05 09:04
Оценка:
Здравствуйте, d Bratik, Вы писали:

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

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

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

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

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

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


Душа обязана трудиться! (с) Н.Заболоцкий.
Re[2]: Почему настоящие программисты избегают C++
От: Cyberax Марс  
Дата: 21.02.05 11:10
Оценка:
Nose пишет:

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

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

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[18]: Почему настоящие программисты избегают C++
От: Cyberax Марс  
Дата: 21.02.05 11:52
Оценка:
Кодт пишет:

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

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

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[8]: Почему настоящие программисты избегают C++
От: d Bratik  
Дата: 21.02.05 16:31
Оценка:
Здравствуйте, _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-а больших денег стоят

И на том спасибо.
Re[4]: Почему настоящие программисты избегают C++
От: d Bratik  
Дата: 21.02.05 20:21
Оценка:
Здравствуйте, AlikGut, Вы писали:

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

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

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

Привожу простой пример. Программисты обычно сначала проектируют модель данных в БД (таблицы, реляционные связи и т.д.), а потом только берутся за пользовательский интерфейс. И оказывается, что какие-то данные пользователю лучше всего представлять в виде дерева. При попытке построить дерево все начинает жутко тормозить, из-за того, что модель данных в пользовательском интерфейсе совершенно не согласуется с моделью данных в БД.

Эта проблема наблюдается сплошь и рядом, причем в самых серьезных продуктах и системах. Она часто решается путем отказа от удобств в GUI, который работает не так, как удобно пользователю, а так, как удобно программисту.
Re[14]: Почему настоящие программисты избегают C++
От: VladD2 Российская Империя www.nemerle.org
Дата: 21.02.05 23:03
Оценка:
Здравствуйте, alnsn, Вы писали:

A>Очень серьезные дяди писали на серьезном языке Ada, где есть исключения по переполнению. Результат здесь.

Ошибки бываю всегда и везде. Да и ссылку мог бы дать на русском. Она во все новости попала.

Кстати, котрольк переполнения есть и в менее пуретанских и более перспективных языках (в том же Шарпе).
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Почему настоящие программисты избегают C++
От: VladD2 Российская Империя www.nemerle.org
Дата: 21.02.05 23:03
Оценка:
Здравствуйте, Шахтер, Вы писали:

Ш>Ты внимательно прочитал этот код?

Да, с "++" он не прав. Но он же следующим постом извинился же за это?

В общем, если не докапываться до частностей, то притензию можно принять. Так как проблема действительно может возникнуть, а смысла в использовании беззнаковых целых небыло.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Почему настоящие программисты избегают C++
От: VladD2 Российская Империя www.nemerle.org
Дата: 21.02.05 23:03
Оценка:
Здравствуйте, achp, Вы писали:

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

VD>>Переписывается все что хочешь. Вот только когда баг найдется. Люди лепят баги не специально.

A>Если я пишу unsigned n, то я всегда должен осознавать, какие правила арифметики будут применяться к n. Написание int n также не всегда позволяет избежать "задумчивости".

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

Это точно так же как с неиниыилизированными переменными. Конечно всегда нужно помнить о необходимости их инициализации. Но это не интуитивно и чревато банальными, но трудными в поиске ошибками.

VD>>Вот такие самоуверенные обычно первыми по граблям и ходят.

A>Машинная арифметика — это не то же самое, что общепринятая арифметика.
A> Это фундаментально важно понимать. Есть языки программирования, которые стремятся "затушевать" эту разницу; тем не менее, языки вроде Си++ и Си-Шарпа, опирающиеся именно на машинную арифметику, почему-то находят большее применение. Если, имея unsigned n1, n2, пишешь n1 — n2, нужно четко понимать, что получится, будь n1 < n2.

Заметь в коллекций из фрэймворка используются int и long, а не их беззнаковые аналоги. Это сделано именно исходя из интуитивности и удобства. Так что языки тут в общем-то не причем. Тут уже виноваты те кто проектировал библиотеки.

Ну, а почему в C++ и C# имеются беззнаковыи и переполнения совершенно понятно. Погоня за эффектиностью. Если плевать на нее, то можно было бы просто ввести тип int который не имел бы размеров и ограничеий (как в Руби и Питоне). А для контроля значений вообще лучше подошел бы тип с ограничениями. Но это не эффективно.

Тем не мее в Шапр хотя бы введена возможность контроля переполения (ключи компилятора плюс операторы и предложения checker/unchecker. В С++ же нет ничего. И вся отвественность польностью лежит на программисте. Это не хорошо, по-моему.


A>Что касается Си и Си++, то, на мой взгляд, это их недостаток, что отсутствуют переносимые средства обнаружения переполнений. Но и такие, как checked в Си-Шарпе не очень-то полезны.

Да как раз очнь даже полезны. Это компромис между надежность и скорость. Я в любой момент включив одну галку в VS могу получить приложение с контролем переполения и убедиться что хотя бы нет явных ошибок. Ну, а далее если есть проблемы то могу подумать как их проще устранить. Если скорость не важна, то ввести проверку. Если важна, или недопустимы вылеты, то делать ручной контроль.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Почему настоящие программисты избегают C++
От: VladD2 Российская Империя www.nemerle.org
Дата: 21.02.05 23:03
Оценка:
Здравствуйте, nixite, Вы писали:

N>мне кажется если была перенесена такая арифметика как есть, то нужны и полные средства работы с этой арифметикой, такие какие предоставляет ассемблер. (правда ассемблер ассемблеру рознь, но пусть будет хотябы x86)

Согласен. Возможно было бы разумно иметь опреторы выполняющие действия с контролем переполения. Но это могло бы сильно усложнить язык.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Почему настоящие программисты избегают C++
От: VladD2 Российская Империя www.nemerle.org
Дата: 21.02.05 23:06
Оценка:
Здравствуйте, Шахтер, Вы писали:

Re[4]: Только настоящие программисты пишут на С++! :)
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Почему настоящие программисты избегают C++
От: VladD2 Российская Империя www.nemerle.org
Дата: 21.02.05 23:06
Оценка:
Здравствуйте, Pazak, Вы писали:

VD>>О! Вот и появился C#. И ведь никто за язык не тянул.

P>Сейчас оберонисты прибегут

Цссс. А то ведь флэйм получится.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Почему настоящие программисты избегают C++
От: ss_sa  
Дата: 22.02.05 01:03
Оценка:
Здравствуйте, AlexBS, Вы писали:

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

Настоящие програмисты юзают MAKEFILE и рулят эти конфиги как хотят.

AE>>15. За то что она не MDI. Это ужасно "УДОБНО". Приходится очищать рабочий стол перед открытием делфи, да и две запущенные — это головняк ("КРУТО"), поскольку никогда не знаешь в редакторе какой находишся. Иногда по ALT-TAB переключается только редактор, а главное окно нет.
ABS>А если на главное окно попадает фокус и в редакторе активный модуль без формы, то с клавиатуры сфокусировать редактор невозможно.

Настоящие програмисты юзают командную строку и редактор типа FAR. Так круче.

AE>>16. За WITH благодаря которому дебаггер не показывае значение переменных типа with TComeCObject.Create(...) do Visible := TRUE;
AE>> Значение Visible — не увидишь никогда. Только если with SomeObject do SomeProperty := SomeValue; то в ТОЛЬКО окне свойств надо подставить SomeObject.SomeProperty и только тогда будет значение

Хм... А че и в асемблере не видно. Или дебагер асма не поддерживает?

ABS>Да... от WITH толку столько же, как и от комментариев на китайском — вроде все есть, а к чему относится, непонятно.

WITH это дела вкуса.


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

ABS>Например, ReadProcessMemory
ABS>
ABS>function ReadProcessMemory(hProcess: THandle; const lpBaseAddress: Pointer; lpBuffer: Pointer; nSize: DWORD; var lpNumberOfBytesRead: DWORD): BOOL; stdcall;
ABS>

ABS>Ну нахрена мне всегда(!!) заводить бесполезную переменную для параметра var lpNumberOfBytesRead: DWORD, когда она в 99% случаях просто ненужна!
ABS>А таких функций уйма!

Вот здесь делфи не причем это фича Винды

BOOL ReadProcessMemory(
HANDLE hProcess,
LPCVOID lpBaseAddress,
LPVOID lpBuffer,
SIZE_T nSize,
SIZE_T* lpNumberOfBytesRead
);

В C++ тоже достает заводить переменые для допустим
ReadFile(..., LPDWORD lpNumberOfBytesRead, ....)

Кстати переменые иногда можно и не заводить а передать указатель NULL.
В дельфи наверное так: ReadProcessMemory(THandle,lpBase,lpBuffer,nSize,nil);

Чтите MSDN, он рулез!
... << RSDN@Home 1.1.3 stable >>
Re[4]: Почему настоящие программисты избегают C++
От: AlexBS Украина  
Дата: 22.02.05 01:24
Оценка:
Здравствуйте, ss_sa, Вы писали:

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

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

_>Настоящие програмисты юзают MAKEFILE и рулят эти конфиги как хотят.

Причем здесь MAKEFILE? Разговор про делфи. Причем на тему полезности Debug/Release конфигураций, а не на счет управления ими.

AE>>>15. За то что она не MDI. Это ужасно "УДОБНО". Приходится очищать рабочий стол перед открытием делфи, да и две запущенные — это головняк ("КРУТО"), поскольку никогда не знаешь в редакторе какой находишся. Иногда по ALT-TAB переключается только редактор, а главное окно нет.
ABS>>А если на главное окно попадает фокус и в редакторе активный модуль без формы, то с клавиатуры сфокусировать редактор невозможно.

_>Настоящие програмисты юзают командную строку и редактор типа FAR. Так круче.
Еще раз повторюсь, к делфи никакого отношения не имеет. Иначе идет под хвост вся крутость проектирования GUI, на что делает упор автор топика,

AE>>>16. За WITH благодаря которому дебаггер не показывае значение переменных типа with TComeCObject.Create(...) do Visible := TRUE;
AE>>> Значение Visible — не увидишь никогда. Только если with SomeObject do SomeProperty := SomeValue; то в ТОЛЬКО окне свойств надо подставить SomeObject.SomeProperty и только тогда будет значение

_>Хм... А че и в асемблере не видно. Или дебагер асма не поддерживает?

это ты к чему?

ABS>>Да... от WITH толку столько же, как и от комментариев на китайском — вроде все есть, а к чему относится, непонятно.

_>WITH это дела вкуса.

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


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

ABS>>Например, ReadProcessMemory
ABS>>
ABS>>function ReadProcessMemory(hProcess: THandle; const lpBaseAddress: Pointer; lpBuffer: Pointer; nSize: DWORD; var lpNumberOfBytesRead: DWORD): BOOL; stdcall;
ABS>>

ABS>>Ну нахрена мне всегда(!!) заводить бесполезную переменную для параметра var lpNumberOfBytesRead: DWORD, когда она в 99% случаях просто ненужна!
ABS>>А таких функций уйма!

_>Вот здесь делфи не причем это фича Винды

_>BOOL ReadProcessMemory(
_> HANDLE hProcess,
_> LPCVOID lpBaseAddress,
_> LPVOID lpBuffer,
_> SIZE_T nSize,
_> SIZE_T* lpNumberOfBytesRead
_>);

_>В C++ тоже достает заводить переменые для допустим
_>ReadFile(..., LPDWORD lpNumberOfBytesRead, ....)

_>Кстати переменые иногда можно и не заводить а передать указатель NULL.
_>В дельфи наверное так: ReadProcessMemory(THandle,lpBase,lpBuffer,nSize,nil);

_>Чтите MSDN, он рулез!

Спасибо за урок про переменные, но к сожалению ReadProcessMemory(THandle,lpBase,lpBuffer,nSize,nil) при таком описании не прокатит — загляни в Object Pascal Language Reference — он рулез
Re[5]: Почему настоящие программисты избегают C++
От: ss_sa  
Дата: 22.02.05 02:17
Оценка:
Здравствуйте, AlexBS, Вы писали:

_>>Настоящие програмисты юзают MAKEFILE и рулят эти конфиги как хотят.

ABS>Причем здесь MAKEFILE? Разговор про делфи. Причем на тему полезности Debug/Release конфигураций, а не на счет управления ими.

Ну в С++ Builder этот MAKEFILE генерировался из меню и соответственно ключами компилятора можно было много чего нарулить, вот нашел старый Делфи 2.0 там этого действительно нет.

Делфи-

ABS>>>А если на главное окно попадает фокус и в редакторе активный модуль без формы, то с клавиатуры сфокусировать редактор невозможно.

_>>Настоящие програмисты юзают командную строку и редактор типа FAR. Так круче.
ABS>Еще раз повторюсь, к делфи никакого отношения не имеет. Иначе идет под хвост вся крутость проектирования GUI, на что делает упор автор топика,

По опыту проектирование GUI занимает от силы 10% програмирования, долго ли кнопочки накидать на форму, хотя в Дельфи конечно удобно програмировать GUI.

AE>>>> Значение Visible — не увидишь никогда. Только если with SomeObject do SomeProperty := SomeValue; то в ТОЛЬКО окне свойств надо подставить SomeObject.SomeProperty и только тогда будет значение

_>>Хм... А че и в асемблере не видно. Или дебагер асма не поддерживает?

ABS>это ты к чему?

А к тому что в если переключить дебаггер в асм то можно любую переменную найти.
Turbo Debugger | View | CPU

ABS>>>Да... от WITH толку столько же, как и от комментариев на китайском — вроде все есть, а к чему относится, непонятно.

_>>WITH это дела вкуса.

ABS>Безусловно, только большенство делфи-программистов ставят его на первые места в список самых крутых фичь делфи.

Ну как говорится каждому свое


_>>Кстати переменые иногда можно и не заводить а передать указатель NULL.
_>>В дельфи наверное так: ReadProcessMemory(THandle,lpBase,lpBuffer,nSize,nil);


ABS>Спасибо за урок про переменные, но к сожалению ReadProcessMemory(THandle,lpBase,lpBuffer,nSize,nil) при таком описании не прокатит — загляни в Object Pascal Language Reference — он рулез

nil ведь нулевой указатель?

Вообще то я подразумевал не описание а программу:

var
hProcess: THandle;
lpBaseAddress: Pointer;
lpBuffer: Pointer;
nSize: DWORD;

hProcess=OpenProcess(...);
lpBaseAddress=$dddddd;
nSize=1000;
lpBuffer=LocalAlloc(??,nSize);
ReadProcessMemory(THandle,lpBase,lpBuffer,nSize,nil);

Вобщем давно я просил паскаль тогда еще и дельфи не было )
... << RSDN@Home 1.1.3 stable >>
Re[6]: Почему настоящие программисты избегают C++
От: AlexBS Украина  
Дата: 22.02.05 02:35
Оценка:
Здравствуйте, ss_sa, Вы писали:

AE>>>>> Значение Visible — не увидишь никогда. Только если with SomeObject do SomeProperty := SomeValue; то в ТОЛЬКО окне свойств надо подставить SomeObject.SomeProperty и только тогда будет значение

_>>>Хм... А че и в асемблере не видно. Или дебагер асма не поддерживает?

ABS>>это ты к чему?

_>А к тому что в если переключить дебаггер в асм то можно любую переменную найти.
_>Turbo Debugger | View | CPU

Да не в этом дело. Показывает то оно и так, только WITH сбивает область видимости, т.к. IDE не может проследить, относится ли идентификатор под курсором каким либо образом к WITH-объекту. Вот поэтому ничего не показывает.



_>>>Кстати переменые иногда можно и не заводить а передать указатель NULL.
_>>>В дельфи наверное так: ReadProcessMemory(THandle,lpBase,lpBuffer,nSize,nil);

_>nil ведь нулевой указатель?

_>Вообще то я подразумевал не описание а программу:

_>var
_>hProcess: THandle;
_>lpBaseAddress: Pointer;
_>lpBuffer: Pointer;
_>nSize: DWORD;

_>hProcess=OpenProcess(...);
_>lpBaseAddress=$dddddd;
_>nSize=1000;
_>lpBuffer=LocalAlloc(??,nSize);
_>ReadProcessMemory(THandle,lpBase,lpBuffer,nSize,nil);

_>Вобщем давно я просил паскаль тогда еще и дельфи не было )

Так нельзя, т.к. nil — константа, а по описанию требуется переменная (об этом говорит кейворд var). Я про это и говорю, что при таком дурацком описании хеадеров функций невозможно забить нулем ненужный параметер, а обязательно заводить переменную!

Лечатся то такие ситуации очень просто, например путем замены var lpNumberOfBytesRead: DWORD на const lpNumberOfBytesRead: PDWORD. Но основная проблема в том, что эта функция (как и все остальные) описана в Windows.pas, т.е. поменять ее никак нельзя.
Re[7]: Почему настоящие программисты избегают C++
От: Sinclair Россия https://github.com/evilguest/
Дата: 22.02.05 05:29
Оценка:
Здравствуйте, AlexBS, Вы писали:

ABS>Лечатся то такие ситуации очень просто, например путем замены var lpNumberOfBytesRead: DWORD на const lpNumberOfBytesRead: PDWORD. Но основная проблема в том, что эта функция (как и все остальные) описана в Windows.pas, т.е. поменять ее никак нельзя.
Ну можно, можно поменять. Сделай свой импорт — ничего сверхестественного в Windows нет. И для счастья достаточно написать свой модуль в uses после Windows — правила перекрытия идентификаторов в Pascal обеспечат нужный результат.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[8]: Почему настоящие программисты избегают C++
От: AlexBS Украина  
Дата: 22.02.05 06:49
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

ABS>>Лечатся то такие ситуации очень просто, например путем замены var lpNumberOfBytesRead: DWORD на const lpNumberOfBytesRead: PDWORD. Но основная проблема в том, что эта функция (как и все остальные) описана в Windows.pas, т.е. поменять ее никак нельзя.
S>Ну можно, можно поменять. Сделай свой импорт — ничего сверхестественного в Windows нет. И для счастья достаточно написать свой модуль в uses после Windows — правила перекрытия идентификаторов в Pascal обеспечат нужный результат.

Это все и так понятно. Другое дело в самом подходе к хеадерам. Т.е. если мне понадобятся (просто к примеру) 100 подобных функций, то мне что, их все переопределять?

Вообше, зачем делать этот долбанный var в хеадере функци, которая импортируется из винды?
Re[9]: Почему настоящие программисты избегают C++
От: _Obelisk_ Россия http://www.ibm.com
Дата: 22.02.05 07:12
Оценка:
Здравствуйте, d Bratik, Вы писали:

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

Ошибаетесь Большинство сидит под Linux-ом (особенно Telecom сектор). Под Solaris-ом тоже много, но они постепенно мигрируют под Linux.
Но вообще, в проектах народ сидит одновременно под разными системами. Что-то удобней делать в одной системе, что-то в другой.


Душа обязана трудиться! (с) Н.Заболоцкий.
Re[10]: Почему настоящие программисты избегают C++
От: d Bratik  
Дата: 22.02.05 08:30
Оценка:
Здравствуйте, _Obelisk_, Вы писали:

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

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

_O_>Ошибаетесь Большинство сидит под Linux-ом (особенно Telecom сектор). Под Solaris-ом тоже много, но они постепенно мигрируют под Linux.
_O_>Но вообще, в проектах народ сидит одновременно под разными системами. Что-то удобней делать в одной системе, что-то в другой.

Неужели большинство именно под Linux-ом, а не под WIndows-ом? Вы переспросите отдел маркетинга. И сколько в процентном отношении пользователей сидит на Solaris?

Еще пару вопросов. Интересно, как выполняется поддержка и разработка новых версий? Ведь программа-то на MFC. Это значит, что сначала появляется версия под Windows. Потом эта версия портируется под Linux, на котором есть Wine (эмулятор WinAPI). А как же делается Solaris-версия? Как там эмулируется WinAPI и MFC? И если действительно как-то эмулируется, то как обстоят дела, если пользовательский интерфейс использует multi-threading?

Может нам отдельную тему организовать, посвященную вопросам кросс-платформенной разработки на С++.
Re[16]: Почему настоящие программисты избегают C++
От: jazzer Россия Skype: enerjazzer
Дата: 22.02.05 09:26
Оценка:
Здравствуйте, d Bratik, Вы писали:

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

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

ха-ха, реентерабельность, значит?
типа за время выполнения тела цикла количество элементов контейнера изменится?

А каким боком предполагается узнавать, где именно он изменился, чтобы не обрабатывать элементы дважды и не оставлять новые необработанными?
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[5]: Почему настоящие программисты избегают C++
От: Cyberax Марс  
Дата: 22.02.05 10:19
Оценка:
d Bratik пишет:

> Привожу простой пример. Программисты обычно сначала проектируют модель
> данных в БД (таблицы, реляционные связи и т.д.), а потом только
> берутся за пользовательский интерфейс. И оказывается, что какие-то
> данные пользователю лучше всего представлять в виде дерева. При
> попытке построить дерево все начинает жутко тормозить

С чего бы? Из-за запросов на каждый клик мышки? Так это сами виноваты.

> из-за того, что модель данных в пользовательском интерфейсе совершенно
> не согласуется с моделью данных в БД.

Скорее оно начинает тормозить из-за того, что у GUI-программистов кривые
руки.

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

Какая проблема? Торможение дерева?

Обычно схема БД проектируется и оптимизируется так, чтобы
соответствовать предметной области. GUI обычно проектируется с такой же
целью (и обычно является далеко не самой главной частью).

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[9]: Почему настоящие программисты избегают C++
От: AlexEagle Украина http://www.vik.oil
Дата: 22.02.05 10:47
Оценка:
Здравствуйте, AlexBS, Вы писали:

ABS>Вообше, зачем делать этот долбанный var в хеадере функци, которая импортируется из винды?

Саша, ну что за глупые вопросы? Ответы ты и так знаешь ( Гладиолус кстати не на последнем месте в очереди ответов). Ты еще спроси почему там не все функции и virtual keys определены...
Re[4]: Почему настоящие программисты избегают C++
От: Awaken Украина  
Дата: 22.02.05 11:02
Оценка:
C>QT, GTK, MFC.... 99% виндового софта, написанного на С++... ...FireFox....

MS Office, IE, все продукта Adobe написаны на C++. и все они с весьма навороченным гуем.
а на ДЕльфе я всего одну коммерческую программу не являюуюся "поделкой" знаю — это TOAD
(оболочка для Oracle баз данных)
Re[5]: Почему настоящие программисты избегают C++
От: Awaken Украина  
Дата: 22.02.05 11:06
Оценка:
Здравствуйте, Pazak, Вы писали:

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

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

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

99% приложений под винду написаны на C++.
из того что использую каждый день — Visual Studio, MS Office, Adobe Photoshop, Discreet 3DS Max
лидеры в области коммерческого ПО почему-то не пишут на Дельфях хотя это проще и удобнее. неспроста
из того что я использую только TOAD на Дельфях.
Re[11]: Почему настоящие программисты избегают C++
От: _Obelisk_ Россия http://www.ibm.com
Дата: 22.02.05 12:34
Оценка:
Здравствуйте, d Bratik, Вы писали:


DB>Неужели большинство именно под Linux-ом, а не под WIndows-ом? Вы переспросите отдел маркетинга. И сколько в процентном отношении пользователей сидит на Solaris?

У нас продукты главным образом ориентированы на серьезные и крупные компании в секторах Military/Aerospace и Telecom: Motorola, Nokia, Sony-Ericcson, Lucent, Lookhead Martin Corp, Bae Systems, Thales, etc. Здесь на виндах свет клином не сошелся.

DB>Еще пару вопросов. Интересно, как выполняется поддержка и разработка новых версий? Ведь программа-то на MFC. Это значит, что сначала появляется версия под Windows. Потом эта версия портируется под Linux, на котором есть Wine (эмулятор WinAPI). А как же делается Solaris-версия? Как там эмулируется WinAPI и MFC? И если действительно как-то эмулируется, то как обстоят дела, если пользовательский интерфейс использует multi-threading?

Программа не на MFC. MFC глубоко похоронен в недрах Stingray-я + нашего собственного framework-а поверх Stingray-я. Потом GUI здесь отнюдь не самая
сложная часть продукта.
Собирается все из исходников на разных платформах одновременно и единообразно. Просто на на Linux-е/Solaris-е GUI линкуется с библиотеками от MainSoft-а. А эмуляция MFC — задача MainSoft-а, не наша. Все, что не GUI, вообще не использует ничего Windows-specific.


Душа обязана трудиться! (с) Н.Заболоцкий.
Re[11]: Почему настоящие программисты избегают C++
От: Кодт Россия  
Дата: 22.02.05 12:42
Оценка:
Здравствуйте, d Bratik, Вы писали:

DB>Может нам отдельную тему организовать, посвященную вопросам кросс-платформенной разработки на С++.

Какие проблемы! Хотите, эту ветку (начиная отсюда
Автор: _Obelisk_
Дата: 17.02.05
) отделю?
Перекуём баги на фичи!
Re[12]: Почему настоящие программисты избегают C++
От: d Bratik  
Дата: 22.02.05 17:27
Оценка:
Здравствуйте, _Obelisk_, Вы писали:


DB>>Неужели большинство именно под Linux-ом, а не под WIndows-ом? Вы переспросите отдел маркетинга. И сколько в процентном отношении пользователей сидит на Solaris?

_O_>У нас продукты главным образом ориентированы на серьезные и крупные компании в секторах Military/Aerospace и Telecom: Motorola, Nokia, Sony-Ericcson, Lucent, Lookhead Martin Corp, Bae Systems, Thales, etc. Здесь на виндах свет клином не сошелся.

Список внушает, но на вопрос не отвечает Я просто немного усомнился, что у Вас больше пользователей на Linux, чем на Windows. И я предположил, что пользователей на Solaris, во много-много раз меньше.

DB>>Еще пару вопросов. Интересно, как выполняется поддержка и разработка новых версий? Ведь программа-то на MFC. Это значит, что сначала появляется версия под Windows. Потом эта версия портируется под Linux, на котором есть Wine (эмулятор WinAPI). А как же делается Solaris-версия? Как там эмулируется WinAPI и MFC? И если действительно как-то эмулируется, то как обстоят дела, если пользовательский интерфейс использует multi-threading?

_O_>Программа не на MFC. MFC глубоко похоронен в недрах Stingray-я + нашего собственного framework-а поверх Stingray-я. Потом GUI здесь отнюдь не самая
_O_>сложная часть продукта.
_O_>Собирается все из исходников на разных платформах одновременно и единообразно. Просто на на Linux-е/Solaris-е GUI линкуется с библиотеками от MainSoft-а. А эмуляция MFC — задача MainSoft-а, не наша. Все, что не GUI, вообще не использует ничего Windows-specific.

Вы меня вконец запутали. Что же представляет собой Ваш собственный framework? И наконец, сокраментальный вопрос: нельзя ли взглянуть краем глаза на скриншот с Sun Solaris-а (на SPARK-е)?
Re[12]: Почему настоящие программисты избегают C++
От: d Bratik  
Дата: 22.02.05 17:28
Оценка:
Здравствуйте, Кодт, Вы писали:

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

DB>>Может нам отдельную тему организовать, посвященную вопросам кросс-платформенной разработки на С++.

К>Какие проблемы! Хотите, эту ветку (начиная отсюда
Автор: _Obelisk_
Дата: 17.02.05
) отделю?

Давайте.
Re[9]: Почему настоящие программисты избегают C++
От: Cyberax Марс  
Дата: 23.02.05 10:06
Оценка:
d Bratik пишет:

>>> И все же я пока не видел ни одной промышленной GUI бибилиотеки на С++,
>>> которая бы отдаленно приближалась по качеству к VCL и .NET Framework.
>>> Обыскал весь Интернет — таковой в природе нет.
> C>MFC, WTL, raw WinAPI, GTK. _Качество_ у них ничуть не хуже.
> Под качеством я имел в виду не степень отлаженности, а уровень
> технического совершенства.

Мне, например, WTL нравится больше чем все остальные GUIшные либы для
Винды. Потому что в WTL я сам легко могу управлять роутингом сообщений.

> Чтобы понять разницу, попробуйте, используя эти библиотеки, создать
> окно с обычной кнопкой OK, текст которой написан нестандартным
> шрифтом. Сколько нужно потратить на это времени?

1. Рисуем диалог с кнопкой ОК (идентификатор IDD_OKDIALOG).
2. Пишем класс диалога:
class OkDialog : public CDialogImpl<OkDialog>, public 
CDialogResize<OkDialog>
{
    CPrettyButton btn; //Mine
public:
    enum { IDD = IDD_OKDIALOG};

    BEGIN_MSG_MAP(OkDialog)
        MESSAGE_HANDLER(WM_INITDIALOG, OnInitDialog)
    END_MSG_MAP()

    BEGIN_DLGRESIZE_MAP(OkDialog)
        DLGRESIZE_CONTROL(IDOK, DLSZ_MOVE_X|DLSZ_MOVE_Y)
    END_DLGRESIZE_MAP()

    LRESULT OnInitDialog(UINT /*uMsg*/, WPARAM /*wParam*/, LPARAM 
/*lParam*/, BOOL& /*bHandled*/)
    {
        // Init dialog resizing
        DlgResize_Init();
        btn.SubclassWindow(GetDlgItem(IDOK)); //Mine
        btn.SetFont(...); //Mine
    }
};

CPrettyButton — это моя кнопочка, которая умеет менять свой шрифт,
цвета, работать как push-like-button и т.п.

Большая часть кода в данном диалоге генерируется визардом (или
cut&paste'ом), мои три строчки отмечены. Размер скомпиленой программы —
16Кб.

> C>А к интуитивности использования _библиотека_ отношение имеет весьма
> C>слабое, важна среда. Тот же Glade для GTK позволяет интуитивно рисовать
> C>интерфейсы на чистом С.
> Если образцом для подражания Вы считаете "raw WinAPI" (а также GTK и
> MFC), то нам не о чем больше спорить.

Да, мне очень нравится WinAPI. Более правильную _низкоуровневую_ GUIшную
либу я видел только на Маках. GTK мне тоже очень нравится, хотя это уже
и не низкоуровневая библиотека.

MFC мне нравится не особо, но в ней очень много функциональности.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[15]: Почему настоящие программисты избегают C++
От: Cyberax Марс  
Дата: 23.02.05 12:56
Оценка:
Kh_Oleg пишет:

>>> Вот мы и приехали к тому, откуда начали — нету для С++ нормальных
>>> библиотек для GUI.
>>> Потому что для элемнтарных действий надо что-то откуда-то качать или
>>> писать экраны кода.
> C>А какие проблемы скачать контрол?
> А проблемы в том, что скачать контрол — это самая простая часть
> Марлезонского балета.
> Еще надо убедиться, что он работает правильно, стабильно и надежно.

И это делается в большинстве случаев веьсма просто — так как такие
контролы являются просто тонкими надстройками над WinAPI.

> Если это не тривиальная кнопочка, то время поиска и тестирования
> нужного компонента
> может поставить под угрозу весь проект.

А нетривиальные _визуальные_ контролы нужны бывают очень редко.
Единственное, что вспоминается — это таблички бывают сравнительно часто
нужны. А с невизуальными библиотеками в С/С++ проблем никогда не было (в
том числе и с тщательно протестированными).

> Вот тут упоминали, что куча продуктов (Office, Adobe family, etc.)
> написана на С++. Написана, но в каждом
> случае разработчикам приходилось писать свой framework конкретно под
> свой продукт (или семейство продуктов).

Нет. Базовый MFC используется почти везде в новых продуктах. А вот в

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

Давно уже не так, если не важна портируемость (кстати, Дельфи тоже
никуда не портируется — Kylix лучше и не вспоминать).

А вот с переносимостью GUI — плохо. Прежде всего потому, что на разных
платформах разные идеологии и методы построения GUI. Тот же Word для
Маков, например, выглядит совсем не так, как его виндовый аналог.

> Вывод: для С++ нет нормальной (надежной и полнофункциональной)
> библиотеки для GUI.

Есть. MFC, Stringray, и т.п.

Вот портируемых маловато пока.

> C>WTL по своей сути — это barebone-система, дающая самый минимум
> C>функциональности (и маленькие исполняемые файлы, соответственно), на
> C>которой уже можно строить почти что угодно. И мне нафиг не нужно, чтобы
> C>в дистрибутив WTL включались всякие красивоукрашенные кнопочки и т.п.
> Ассемблер предоставляет еще большие возможности, а программы на нем
> получаются еще меньше,
> так что это отнюдь не достоинство данной библиотеки.

Ассемблер использовать сложно, в отличие от WTL.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[16]: Почему настоящие программисты избегают C++
От: Kh_Oleg  
Дата: 23.02.05 13:33
Оценка:
Здравствуйте, Cyberax, Вы писали:

>> Если это не тривиальная кнопочка, то время поиска и тестирования
>> нужного компонента
>> может поставить под угрозу весь проект.

C>А нетривиальные _визуальные_ контролы нужны бывают очень редко.
C>Единственное, что вспоминается — это таблички бывают сравнительно часто
C>нужны. А с невизуальными библиотеками в С/С++ проблем никогда не было (в
C>том числе и с тщательно протестированными).

Можно ли взглянуть на следующие визуальные компоненты, написанные на С++:
1. TreeView, который не поперхнется от ста тысяч элементов и не будет
причиной даже полусекундной задержки при отображении на экране, а также
массивных вставках и удалениях. Сортировка тоже нужна.
2. ListView с аналогичными требованиями.
3. PropertyEditor.

>> Вот тут упоминали, что куча продуктов (Office, Adobe family, etc.)
>> написана на С++. Написана, но в каждом
>> случае разработчикам приходилось писать свой framework конкретно под
>> свой продукт (или семейство продуктов).

C>Нет. Базовый MFC используется почти везде в новых продуктах. А вот в
Ссылки в студию.

>> Вывод: для С++ нет нормальной (надежной и полнофункциональной)
>> библиотеки для GUI.
C>Есть. MFC, Stringray, и т.п.

Наша сказка хороша — начинай сначала. Только что подробно разобрали, почему конкретно
MFC нельзя использовать для разработки, и тут на тебе опять.
Если больше аргументов нет, то дискуссию пора прекратить.
Re[17]: Почему настоящие программисты избегают C++
От: Cyberax Марс  
Дата: 23.02.05 13:43
Оценка:
Kh_Oleg пишет:

> C>А нетривиальные _визуальные_ контролы нужны бывают очень редко.
> C>Единственное, что вспоминается — это таблички бывают сравнительно часто
> C>нужны. А с невизуальными библиотеками в С/С++ проблем никогда не
> было (в
> C>том числе и с тщательно протестированными).
> Можно ли взглянуть на следующие визуальные компоненты, написанные на С++:
> 1. TreeView, который не поперхнется от ста тысяч элементов и не будет
> причиной даже полусекундной задержки при отображении на экране, а также
> массивных вставках и удалениях. Сортировка тоже нужна.

Начнем с того, что дерево со 100000 одновременно видимых элементов не
будет удобно использовать. Ну а так: SysTreeView в WinAPI Common
Controls и его обертки CTreeView в WTL/MFC.

> 2. ListView с аналогичными требованиями.

SysListView с обертками CListView.

> 3. PropertyEditor.

То есть?

> C>Нет. Базовый MFC используется почти везде в новых продуктах. А вот в
> Ссылки в студию.

Сайт MSа, сейчас найду...

> C>Есть. MFC, Stringray, и т.п.
> Наша сказка хороша — начинай сначала. Только что подробно разобрали,
> почему конкретно
> MFC нельзя использовать для разработки, и тут на тебе опять.

Я услышал только один аргумент: не кроссплатформенная. Ну так оно
никогда таким и не планировалось.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[18]: Почему настоящие программисты избегают C++
От: Kh_Oleg  
Дата: 23.02.05 13:53
Оценка:
Здравствуйте, Cyberax, Вы писали:

>> C>А нетривиальные _визуальные_ контролы нужны бывают очень редко.
>> C>Единственное, что вспоминается — это таблички бывают сравнительно часто
>> C>нужны. А с невизуальными библиотеками в С/С++ проблем никогда не
>> было (в
>> C>том числе и с тщательно протестированными).
>> Можно ли взглянуть на следующие визуальные компоненты, написанные на С++:
>> 1. TreeView, который не поперхнется от ста тысяч элементов и не будет
>> причиной даже полусекундной задержки при отображении на экране, а также
>> массивных вставках и удалениях. Сортировка тоже нужна.

C>Начнем с того, что дерево со 100000 одновременно видимых элементов не
C>будет удобно использовать.
Я бы даже сказал, что 10^5 ты и не отобразишь на экране. Нет, одновременно
видно столько, сколько видно, скажем 100. Но вот, сотрировка, поиск, скроллинг
от первого к последнему по всем ста тысячам, быстрые вставки и удаления должны быть.

>> 3. PropertyEditor.
Неужто никогда не видел и не пользовался? В VisualStudio нажимаем F4 — вот оно и нужно.
Где взять?

>> C>Нет. Базовый MFC используется почти везде в новых продуктах. А вот в
>> Ссылки в студию.
C>Сайт MSа, сейчас найду...
Ждем-с...
Re[19]: Почему настоящие программисты избегают C++
От: Cyberax Марс  
Дата: 23.02.05 14:22
Оценка:
Kh_Oleg пишет:

> C>Начнем с того, что дерево со 100000 одновременно видимых элементов не
> C>будет удобно использовать.
> Я бы даже сказал, что 10^5 ты и не отобразишь на экране. Нет, одновременно
> видно столько, сколько видно, скажем 100. Но вот, сотрировка, поиск,
> скроллинг
> от первого к последнему по всем ста тысячам, быстрые вставки и
> удаления должны быть.

Сортировку, поиск и скроллинг должно делать само приложение — дерево
просто отображает результаты. Вставка и удаление в стандартном списке
работают достаточно быстро.

>>> 3. PropertyEditor.
> Неужто никогда не видел и не пользовался? В VisualStudio нажимаем F4 —
> вот оно и нужно.
> Где взять?

А, понял. Мы используем самодельный (требования специфичные) на основе
list view.

>>> C>Нет. Базовый MFC используется почти везде в новых продуктах. А вот в
>>> Ссылки в студию.
> C>Сайт MSа, сейчас найду...
> Ждем-с...

Ищу...

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[19]: Почему настоящие программисты избегают C++
От: Cyberax Марс  
Дата: 23.02.05 14:27
Оценка:
Kh_Oleg пишет:

> A>Хочешь сказать, этим требованиям удовлетворяет VCL-ный tree и list?
> Я лишь хочу обосновать пункт из самого первого поста ветки: не
> существует нормальной GUI библиотеки на С++.
> Qt самая лучшая из всех, но и ее нормальной назвать нельзя.

Эту ветку следует переформулировать так: не существует нормальной
GUI-библиотеки (вообще).

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

Для Дельфи нет вопроса о портируемости (так как нет портируемости). А
подобных непортабельных решений для MFC — тонны.

> A>Зачем ссылки, Spy натрави на окошко...
> И куда смотреть? На класс окна?

Да. Скорее всего будет "SysTreeView".

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[20]: Почему настоящие программисты избегают C++
От: Kh_Oleg  
Дата: 23.02.05 14:39
Оценка:
Здравствуйте, Cyberax, Вы писали:

>> A>Зачем ссылки, Spy натрави на окошко...
C>Да. Скорее всего будет "SysTreeView".
SysTreeView32. Только это говорит о том, что используется стандартный компонент операционной системы,
но никак не MFC.

А ссылки ждем-с...
Re[21]: Почему настоящие программисты избегают C++
От: Cyberax Марс  
Дата: 23.02.05 14:45
Оценка:
Kh_Oleg пишет:

>>> A>Зачем ссылки, Spy натрави на окошко...
> C>Да. Скорее всего будет "SysTreeView".
> SysTreeView32. Только это говорит о том, что используется стандартный
> компонент операционной системы,
> но никак не MFC.

Кхе-кхе.... MFCшный CTreeView является просто тонкой оберткой для
SysTreeView32.

> А ссылки ждем-с...

Найти не могу, куда она запропастилась, блин???

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[21]: Почему настоящие программисты избегают C++
От: Amidlokos Россия  
Дата: 23.02.05 15:11
Оценка:
Здравствуйте, Kh_Oleg, Вы писали:

K_O>SysTreeView32. Только это говорит о том, что используется стандартный компонент операционной системы,
K_O>но никак не MFC.

Однако же и совсем никак не TTreeView. Дельфийский класс так и называется — TTreeView и производные... MFC ищется ещё и просмотром зависимостей/сообщений, а также поиском классов AfxNNN.
WARNING: expression "to_be || !to_be" is always true
Re[11]: Почему настоящие программисты избегают C++
От: mister-AK Россия  
Дата: 23.02.05 15:15
Оценка:
Здравствуйте, Aibyss, Вы писали:

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

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

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


Абсолютно согласен — этим программистам далеко до математиков и перпендикулярно физикам!
Из-за такой ерунды они такую <b>kakashka</b> в <b>МИД</b>
Автор: Кодт
Дата: 18.02.05
превратили!!! 


int ERUNDA (int a, int b){
  try
  {
    return (a+b)/2;
  }
  catch(overflow_error& ex)
  {
    return (a-b)/2+b;
  }
}

Re[12]: web(
От: mister-AK Россия  
Дата: 23.02.05 15:23
Оценка:
Пырдон, <b>kakashka</b>
Автор: screw_cms
Дата: 18.02.05
 потерялась
Re[17]: Почему настоящие программисты избегают C++
От: The Lex Украина  
Дата: 23.02.05 15:27
Оценка:
Здравствуйте, Kh_Oleg, Вы писали:

K_O>Можно ли взглянуть на следующие визуальные компоненты, написанные на С++:
K_O>1. TreeView, который не поперхнется от ста тысяч элементов и не будет
K_O> причиной даже полусекундной задержки при отображении на экране, а также
K_O> массивных вставках и удалениях. Сортировка тоже нужна.

Дельфист... RTFM Win32 Common Controls API!

K_O>2. ListView с аналогичными требованиями.

см. п.п. 1.

K_O>3. PropertyEditor.

А в чем, собственно, проблема? Нет ActiveX который можно настроить в Design Time? Если очень надо — можно найти — не проблема — делал. Если не очень надо, но хотелось бы — можно сделать — делал. И первый и второй случаи — коммерческие разработки — в практическом применении уже "некоторое время"...

Empedded? Было дело: коммерческие разработки — GUI в том числе — межплатформеннопереносимые тоже — не всегда C++ — частично взаимодействие со старым и не очень кодом на C, а также на "чем-то третьем"...

>>> Вот тут упоминали, что куча продуктов (Office, Adobe family, etc.)
>>> написана на С++. Написана, но в каждом
>>> случае разработчикам приходилось писать свой framework конкретно под
>>> свой продукт (или семейство продуктов).

C>>Нет. Базовый MFC используется почти везде в новых продуктах. А вот в
K_O>Ссылки в студию.

>>> Вывод: для С++ нет нормальной (надежной и полнофункциональной)
>>> библиотеки для GUI.
C>>Есть. MFC, Stringray, и т.п.

Вы имеете в виду платформу Win32 или вообще некую абстрактную "нормальную (надежную и полнофункциональную) библиотеку для GUI"?

K_O>Наша сказка хороша — начинай сначала. Только что подробно разобрали, почему конкретно
K_O>MFC нельзя использовать для разработки, и тут на тебе опять.

Так ведь никто и не заставляет... Коммерческие интересы и бизнес не в счет...

K_O>Если больше аргументов нет, то дискуссию пора прекратить.

Да ее и начинать смысла не имело, однако для этого-то как раз и создан этот раздел форумов, чтобы можно было написать с извращенным удовольствием: дельфисты! (к)
Голь на выдумку хитра, однако...
Re[22]: Почему настоящие программисты избегают C++
От: Kh_Oleg  
Дата: 23.02.05 15:58
Оценка:
Здравствуйте, Amidlokos, Вы писали:

K_O>>SysTreeView32. Только это говорит о том, что используется стандартный компонент операционной системы,
K_O>>но никак не MFC.

A>Однако же и совсем никак не TTreeView. Дельфийский класс так и называется — TTreeView и производные... MFC ищется ещё и просмотром зависимостей/сообщений, а также поиском классов AfxNNN.
Ни в winword.exe, ни в devenv.exe ничего подобного нет!
Re[23]: Почему настоящие программисты избегают C++
От: Cyberax Марс  
Дата: 23.02.05 16:03
Оценка:
Kh_Oleg пишет:

> A>Однако же и совсем никак не TTreeView. Дельфийский класс так и
> называется — TTreeView и производные... MFC ищется ещё и просмотром
> зависимостей/сообщений, а также поиском классов AfxNNN.
> Ни в winword.exe, ни в devenv.exe ничего подобного нет!

В winword'е и devenv'е исторически используется своя библиотека виджетов.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[24]: Почему настоящие программисты избегают C++
От: Kh_Oleg  
Дата: 23.02.05 16:08
Оценка:
Здравствуйте, Cyberax, Вы писали:

>> A>Однако же и совсем никак не TTreeView. Дельфийский класс так и
>> называется — TTreeView и производные... MFC ищется ещё и просмотром
>> зависимостей/сообщений, а также поиском классов AfxNNN.
>> Ни в winword.exe, ни в devenv.exe ничего подобного нет!

C>В winword'е и devenv'е исторически используется своя библиотека виджетов.
Ссылок, значит, не нашли...

Вот поэтому нечего приводить в пример MS Office, говоря, что его GUI написан на С++.
Да, написан, но у всякого ли проекта есть бюджет, равный микрософтовскому, чтобы
позволить себе роскошь писать все самому?
Re[25]: Почему настоящие программисты избегают C++
От: Cyberax Марс  
Дата: 23.02.05 16:13
Оценка:
Kh_Oleg пишет:

> C>В winword'е и devenv'е исторически используется своя библиотека
> виджетов.
> Ссылок, значит, не нашли...

Дома в кэше поищу. Точно помню, что была.

> Вот поэтому нечего приводить в пример MS Office, говоря, что его GUI
> написан на С++.

Еще Mozilla есть

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

Просто Оффис начинал писаться еще тогда, когда MFC не было. Ну а потом
переводить на другую библиотеку им не было большого смысла. Хотя как раз
MFC очень многое переняла из оффиса.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[9]: Почему настоящие программисты избегают C++
От: Pazak Россия  
Дата: 23.02.05 20:50
Оценка:
Здравствуйте, d Bratik, Вы писали:

DB>Под качеством я имел в виду не степень отлаженности, а уровень технического совершенства. Чтобы понять разницу, попробуйте, используя эти библиотеки, создать окно с обычной кнопкой OK, текст которой написан нестандартным шрифтом. Сколько нужно потратить на это времени?

Можно узнать, а на фига оно нужно? Любая GUI ограничена какими-то рамками, в пределах которых программирование легко и интуитивно, а за пределами — приходится извращаться. Соответственно, первым кандидатом на "упрощение" становятся наиболее часто востребованные действия, а те, что вотребованы редко — остаются на уровне "сделай сам". Так вот я с трудо могу представить, для чего в программах в массовом порядке нужно было бы менять шрифт на кнопочках. ИМХО это скорее редкое исключение, чем правило. Соответственно и автоматизация ему нужна постольку-поскольку, в отличие, например, от грамотной реализации layout'ов копонентов на форме.
Ку...
Re[21]: Почему настоящие программисты избегают C++
От: Pazak Россия  
Дата: 23.02.05 21:02
Оценка:
Здравствуйте, Kh_Oleg, Вы писали:

K_O>Требования у всех специфичные. Только для Delphi такой компонент существует, а для С++ — до сих пор нет.

Я, конечно, дико извиняюсь, но что, C++ Builder — это уже не C++?
Ку...
Re[22]: Почему настоящие программисты избегают C++
От: Amidlokos Россия  
Дата: 23.02.05 21:48
Оценка:
Здравствуйте, Pazak, Вы писали:

P>Я, конечно, дико извиняюсь, но что, C++ Builder — это уже не C++?

НЕТ. Это Дельфа, только синтаксис подкрутили... В худшую сторону.

Туда ни одну либу и ни один хедер просто так не перетащишь... Помню, была в нём зверская ФИЧА — его научили компилить OWL и MFC... Ага, щас Скомпилил один такой без багов.

Так что сей продукт, ИМХО, можно благополучно забыть (что, АФАИК, практически уже сделано самим борландом). Впрочем, при крайней необходимости предпочту его дельфе.
WARNING: expression "to_be || !to_be" is always true
Re[10]: Почему настоящие программисты избегают C++
От: d Bratik  
Дата: 23.02.05 23:39
Оценка:
Здравствуйте, The Lex, Вы писали:

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

DB>>Под качеством я имел в виду не степень отлаженности, а уровень технического совершенства. Чтобы понять разницу, попробуйте, используя эти библиотеки, создать окно с обычной кнопкой OK, текст которой написан нестандартным шрифтом. Сколько нужно потратить на это времени?

TL> 10 баллов! Первый признак дельфиста: "окно с обычной кнопкой OK, текст которой написан нестандартным шрифтом"! "Повбывав бы!" (к)

Я уже привык к этой реакции обиженных Си-плюс-плюс-ом. Если Вам не нравится этот пример вот Вам другой. Объясните, какого черта в Windows и в MFC для обычного окна и окна диалога существуют разные классы объектов?! Ведь отличие лишь в модальности, т.е. в режиме показа. Прежде, чем Вы броситесь это обосновывать, подумайте, почему в .NET Framework, который делался намного позже Windows и MFC, все совсем не так и ОЧЕНЬ напоминает VCL?
Re[7]: Почему настоящие программисты избегают C++
От: Garrrrr  
Дата: 24.02.05 05:10
Оценка:
Здравствуйте, d Bratik, Вы писали:

DB>И все же я пока не видел ни одной промышленной GUI бибилиотеки на С++, которая бы отдаленно приближалась по качеству к VCL и .NET Framework. Обыскал весь Интернет — таковой в природе нет. Qt более-менее ничего, но когда основательно начинаешь пользовать, начинаешь плеваться.

Хе уже несколько лет Qt пользуюсь — и только радость приносит. А вот от vcl — точно, блевать хочется (насчет NET не знаю, Бог миловал).
Re[23]: Почему настоящие программисты избегают C++
От: Pazak Россия  
Дата: 24.02.05 05:50
Оценка:
Здравствуйте, Amidlokos, Вы писали:

P>>Я, конечно, дико извиняюсь, но что, C++ Builder — это уже не C++?
A>НЕТ. Это Дельфа, только синтаксис подкрутили... В худшую сторону.

— Это что, пельмени?
— Написано равиоли...
— Но они же пельмени?
— Да нет, равиоли.
— Я понимаю, но они же пельмени?
(с) какая-то из "нациоальных особенностей"

Это я к тому, что формально билдер — это C++, тут ничего не попишешь. Человек хотел "крутые дельфовые компоненты" на С++, вот, получите — они есть на билдере. А то, как это криво/прямо это реализовано и сколько ненужных дельфовых фич перетащили в билдер — это уже отдельный вопрос.

A>Так что сей продукт, ИМХО, можно благополучно забыть (что, АФАИК, практически уже сделано самим борландом). Впрочем, при крайней необходимости предпочту его дельфе.

Ку...
Re[11]: Почему настоящие программисты избегают C++
От: The Lex Украина  
Дата: 24.02.05 07:44
Оценка:
Здравствуйте, d Bratik, Вы писали:

DB>Стандартный шрифт на кнопках — MS Sans Serif, размером 8 pt. Для людей с не очень хорошим зрением этот шрифт довольно мелкий, поэтому в программах, где важна простота и понятность (мультимедиа-программы, программы для детей, программы для домохозяек), этот шрифт иногда в массовом порядке заменяют на шрифт Arial 11 pt. При этом важно, чтобы настройки рабочего стола никак не менялись. Пример не на пустом месте — это было обязательное требование к одной из моих мультимедиа-программ (хотя я сам предпочитаю стандартный размер кнопок). В итоге программа выигрывала на фоне других программ и самой Windows — в сочетание с другими эффектами создавалось эмоциональное впечатление отсутствия казености при одновременной строгости.

Согласен, пример очень показательный: Дельфи — среда для написания программ для домохозяек!

P.S. Риторика, конечно, но... Кто может — может возразить...
Голь на выдумку хитра, однако...
Re[8]: Почему настоящие программисты избегают C++
От: Kh_Oleg  
Дата: 24.02.05 07:45
Оценка:
Здравствуйте, Garrrrr, Вы писали:

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

DB>>И все же я пока не видел ни одной промышленной GUI бибилиотеки на С++, которая бы отдаленно приближалась по качеству к VCL и .NET Framework. Обыскал весь Интернет — таковой в природе нет. Qt более-менее ничего, но когда основательно начинаешь пользовать, начинаешь плеваться.

G>Хе уже несколько лет Qt пользуюсь — и только радость приносит. А вот от vcl — точно, блевать хочется (насчет NET не знаю, Бог миловал).
Ну и как там у вас с Docking'ом? Артефактов при перетаскивании нет?
Re[11]: Почему настоящие программисты избегают C++
От: The Lex Украина  
Дата: 24.02.05 07:54
Оценка:
Здравствуйте, d Bratik, Вы писали:

DB>>>Под качеством я имел в виду не степень отлаженности, а уровень технического совершенства. Чтобы понять разницу, попробуйте, используя эти библиотеки, создать окно с обычной кнопкой OK, текст которой написан нестандартным шрифтом. Сколько нужно потратить на это времени?

TL>> 10 баллов! Первый признак дельфиста: "окно с обычной кнопкой OK, текст которой написан нестандартным шрифтом"! "Повбывав бы!" (к)

DB>Я уже привык к этой реакции обиженных Си-плюс-плюс-ом. Если Вам не нравится этот пример вот Вам другой. Объясните, какого черта в Windows и в MFC для обычного окна и окна диалога существуют разные классы объектов?! Ведь отличие лишь в модальности, т.е. в режиме показа...

Хм... Простите, я этого не знал, и ранее успешно пользовался диалоговыми окнами в немодальном режиме... Торжественно обещаю всенепременно исправиться!

P.S. Хм... А что лично Вам мешает не использовать для создания диалоговых окон CDialog, а использовать исключительно CWnd? Кстати, насчет "в Windows" я не очень понял: какие проблемы в Windows в этом вопросе? Или Дельфи, по своему старому обычаю, использует "все свое, потому как свое — самое лучшее, переносимое, и т.д." — т.е. решает проблему "окон и диалогов" своими средствами, в обход средств ОС?

DB>...Прежде, чем Вы броситесь это обосновывать, подумайте, почему в .NET Framework, который делался намного позже Windows и MFC, все совсем не так и ОЧЕНЬ напоминает VCL?

Не бросился... Ну, напоминает немного — и что? Вам сказать почему? Давайте я намекну: знаете, кроме Дельфи есть еще очень похожая система разработки ПО — кстати, на первом месте по полярности в мире — это VB. Какая мораль?

P.P.S. Не сказал бы что .NET Framework "ОЧЕНЬ напоминает VCL" — по моему нескромному мнению, "ОЧЕНЬ" — это мнение все больше дельфистов: Вы знакомы хотя бы с основами маркетинга?
Голь на выдумку хитра, однако...
Re[13]: Почему настоящие программисты избегают C++
От: Кодт Россия  
Дата: 24.02.05 07:56
Оценка:
Здравствуйте, d Bratik, Вы писали:

К>>Какие проблемы! Хотите, эту ветку (начиная отсюда
Автор: _Obelisk_
Дата: 17.02.05
) отделю?

DB>Давайте.

Название темы для отделяемой ветки придумайте, пожалуйста
Перекуём баги на фичи!
Re[24]: Почему настоящие программисты избегают C++
От: Kh_Oleg  
Дата: 24.02.05 07:59
Оценка:
Здравствуйте, Amidlokos, Вы писали:

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

A>>>Кроме того — ну, а где (повторю это любимое слово) ссылка-то на этот дельфовский суперкомпонент?
K_O>>VirtualTreeview
K_O>>XtraVerticalGrid Это PropertyEditor.

A>В случае с первым — и на каком скриншоте видно более 10000 нодов без тормозов? А главное — где при этом видно, что всей обработкой занимается контрол?
Скачай и посмотри. Там есть очень показательная демка, в том числе и по количеству элементов.
Я привел ссылки на те вещи, которыми мы сами пользуемся.

A>А второе — так это ж вроде .NET? А такое там уже есть в WinForms...
А это только мои оппоненты кричат: "Delphi! Delphi!". Я лишь показал, что на нормальной платформе, будь то Delphi или .NET есть нормальные инструменты для работы, а С++ этого лишен.
Но для VCL версия там также имеется.
Re[13]: Почему настоящие программисты избегают C++
От: _Obelisk_ Россия http://www.ibm.com
Дата: 24.02.05 07:59
Оценка:
Здравствуйте, d Bratik, Вы писали:

_O_>>Программа не на MFC. MFC глубоко похоронен в недрах Stingray-я + нашего собственного framework-а поверх Stingray-я. Потом GUI здесь отнюдь не самая
_O_>>сложная часть продукта.
_O_>>Собирается все из исходников на разных платформах одновременно и единообразно. Просто на на Linux-е/Solaris-е GUI линкуется с библиотеками от MainSoft-а. А эмуляция MFC — задача MainSoft-а, не наша. Все, что не GUI, вообще не использует ничего Windows-specific.

DB>Вы меня вконец запутали. Что же представляет собой Ваш собственный framework? И наконец, сокраментальный вопрос: нельзя ли взглянуть краем глаза на скриншот с Sun Solaris-а (на SPARK-е)?


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

Во, скриншот для Linux-а, делал через Reflection. (на Solaris-е будет тоже самое).



Душа обязана трудиться! (с) Н.Заболоцкий.
Re[9]: Почему настоящие программисты избегают C++
От: Garrrrr  
Дата: 24.02.05 08:01
Оценка:
Здравствуйте, Kh_Oleg, Вы писали:

G>>Хе уже несколько лет Qt пользуюсь — и только радость приносит. А вот от vcl — точно, блевать хочется (насчет NET не знаю, Бог миловал).
K_O>Ну и как там у вас с Docking'ом? Артефактов при перетаскивании нет?

Смотря что ты подразумеваешь под "Артефактами".
Re[25]: Почему настоящие программисты избегают C++
От: The Lex Украина  
Дата: 24.02.05 08:16
Оценка:
Здравствуйте, Kh_Oleg, Вы писали:

A>>А второе — так это ж вроде .NET? А такое там уже есть в WinForms...
K_O>А это только мои оппоненты кричат: "Delphi! Delphi!". Я лишь показал, что на нормальной платформе, будь то Delphi или .NET есть нормальные инструменты для работы, а С++ этого лишен.
K_O>Но для VCL версия там также имеется.

Дык это... Я ж Вам сразу же заметил — и не только я: уважаемый! Вы не чувствуете разницу между "языком программирования" и "платформой"! Спорить с Вами при этом, конечно же, мило и полезно для восстановления душевного равновесия, но, увы, не очень занимательно и познавательно... Как и со всяким дельфистом, впрочем...
Голь на выдумку хитра, однако...
Re[10]: Почему настоящие программисты избегают C++
От: Kh_Oleg  
Дата: 24.02.05 08:20
Оценка:
Здравствуйте, Garrrrr, Вы писали:

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

G>>>Хе уже несколько лет Qt пользуюсь — и только радость приносит. А вот от vcl — точно, блевать хочется (насчет NET не знаю, Бог миловал).
K_O>>Ну и как там у вас с Docking'ом? Артефактов при перетаскивании нет?

G>Смотря что ты подразумеваешь под "Артефактами".
Вот это (программа написана на Qt):

Здесь я пытаюсь перетащить ToolBar. Одна рамка — это я его тащу, она и должна быть. А вторая — результат Qt-шной перерисовки, артефакт. Он так и останется, пока все окно не будет перерисовано.
Re[11]: Почему настоящие программисты избегают C++
От: Garrrrr  
Дата: 24.02.05 08:25
Оценка:
Здравствуйте, Kh_Oleg, Вы писали:

K_O>Вот это (программа написана на Qt):
K_O>
K_O>Здесь я пытаюсь перетащить ToolBar. Одна рамка — это я его тащу, она и должна быть. А вторая — результат Qt-шной перерисовки, артефакт. Он так и останется, пока все окно не будет перерисовано.

К сожалению, в борьбе с кривыми руками ни одна библиотека не может одержать победу...
Я вообще такое впервые вижу, и никогда с такими проблемами ни у себя в программах, ни в многочилсленных программах для Linux,
написанных на Qt, не встречался.
Re[11]: Почему настоящие программисты избегают C++
От: sc Россия  
Дата: 24.02.05 09:34
Оценка:
Здравствуйте, d Bratik, Вы писали:

...Объясните, какого черта в Windows и в MFC для обычного окна и окна диалога существуют разные классы объектов?! Ведь отличие лишь в модальности, т.е. в режиме показа. ...

В Windows все элементы гуи, окна, это судя по названию. А разные классы потому что разная функциональность. Можно конечно все в один класс запихнуть, например CWndDialogListCtrlTreeCtrlButtonEdit..., но несколько перегруженный он получается. А еще в MFC можно создавать приложения, основанные на диалоге, и использовать только диалоговые формы. Почти как в Дельфи))
А в чем проблема создания шрифта? 
LOGFONT lf;
memset(&lf, 0, sizeof(LOGFONT));       
lf.lfHeight = 16;                      
strcpy(lf.lfFaceName, "Arial");        
VERIFY(m_font.CreateFontIndirect(&lf));
m_button.SetFont(&m_font, TRUE);
Re[12]: Почему настоящие программисты избегают C++
От: Cyberax Марс  
Дата: 24.02.05 11:45
Оценка:
The Lex пишет:

> P.P.S. Не сказал бы что .NET Framework "ОЧЕНЬ напоминает VCL" — по
> моему нескромному мнению, "ОЧЕНЬ" — это мнение все больше дельфистов:
> Вы знакомы хотя бы с основами маркетинга?

Кстати добавлю: WinForms — это действительно работа дельфиста. Такую
уродливую систему могли написать только они.

Нет чтоб сделать как Swing в Java...

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[27]: Почему настоящие программисты избегают C++
От: AlexEagle Украина http://www.vik.oil
Дата: 24.02.05 12:12
Оценка:
Здравствуйте, Kh_Oleg, Вы писали:

K_O>Не подойдет. Бибилиотеку для создания такого "офогительного" интерфейса MS разработчикам не предосталяет. Речь шла не о GUI на С++, а о библиотеке для GUI на С++.

Дык Xtreeme Toolkit тут рулит вовсю, хотя можно и BCG поюзать... Зачем же отбирать хлеб у тех, у кого доходы и так сомнительны
Re[11]: Почему настоящие программисты избегают C++
От: Amidlokos Россия  
Дата: 24.02.05 12:17
Оценка:
Этот пост должен был уйти минимум два часа назад, но отвалился интернет... Всё же оставлю его.

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

DB>Я уже привык к этой реакции обиженных Си-плюс-плюс-ом. Если Вам не нравится этот пример вот Вам другой. Объясните, какого черта в Windows и в MFC для обычного окна и окна диалога существуют разные классы объектов?! Ведь отличие лишь в модальности, т.е. в режиме показа. Прежде, чем Вы броситесь это обосновывать, подумайте, почему в .NET Framework, который делался намного позже Windows и MFC, все совсем не так и ОЧЕНЬ напоминает VCL?

Точно! А ведь и правда — не только обычные окна и диалоги, но также и кнопочки, поля ввода, списки — это всё ОКНА! И какого лешего им всем намутили разные классы?!

В идеальной библиотеке класс будет один, и называться будет Window! А уж в него мы засунем всё доступное, и навсегда забудем о неудобствах при показе модальных ComboBox-ов, флажков, имеющих свою кнопку на таскбаре и прочего. Даёшь также все модальные окна изменяемого размера!

Руль! Гибкость — закачаешься!


А для начала — RTFM Platform SDK в разделах WinApi...

.NET же, отвечая на вопрос "почему"... Во-первых, вряд ли прародителем была именно Дельфа. Во-вторых, что мешало в том же MFC слить окно и диалог в один класс? Да ничто не мешало, в VCL же слили! Но разработчики MFC не сделали этого по той же причине, по которой не добавили кучу кода для создания цветных кнопочек. Модальное окно изменяемого размера — своего рода форс-мажор, а не нормальная практика.

Более того, советую хоть немного изучить удобство такого подхода. Так сказать, "домашнее задание" дельфийцам — создайте в трёх местах своей программы одну и ту же страницу настройки. Не цветные кнопочки, не голосистые флажки, не прыгающие списки — простую серенькую страницу настройки. Её можно вызывать в отдельном окне по щелчку правой кнопки, либо среди множества вкладок где-то в диалоге настроек, либо в визарде. MFC-шный (а, по сути, WinAPI-евский) подход позволяет сделать это достаточно быстро и просто.
WARNING: expression "to_be || !to_be" is always true
Re[12]: Почему настоящие программисты избегают C++
От: Кодёнок  
Дата: 24.02.05 12:41
Оценка:
DB>>Для людей с не очень хорошим зрением этот шрифт довольно мелкий, поэтому в программах, где важна простота и понятность (мультимедиа-программы, программы для детей, программы для домохозяек), этот шрифт иногда в массовом порядке заменяют на шрифт Arial 11 pt. При этом важно, чтобы настройки рабочего стола никак не менялись. Пример не на пустом месте — это было обязательное требование к одной из моих мультимедиа-программ (хотя я сам предпочитаю стандартный размер кнопок).

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

Полностью поддерживаю! Я когда на Дельфе сидел, даже сделал надстройку над всеми контролами для себя, свойство FontModify, которое не задает фиксированный шрифт, а меняет его свойства/размер.
Re[12]: Почему настоящие программисты избегают C++
От: AlexEagle Украина http://www.vik.oil
Дата: 24.02.05 12:47
Оценка:
Здравствуйте, sc, Вы писали:

sc>А в чем проблема создания шрифта?
sc>
LOGFONT lf;
sc>memset(&lf, 0, sizeof(LOGFONT));       
sc>lf.lfHeight = 16;                      
sc>strcpy(lf.lfFaceName, "Arial");        
sc>VERIFY(m_font.CreateFontIndirect(&lf));
sc>m_button.SetFont(&m_font, TRUE);


Не ручаюсь за 100% корректность кода (придумал только что), но можно и так приколоться:

Подготовка:
#define BEGIN_CHANGE_CONTROL_FONT(hDlg, nCtrl) \
 { \
  HFONT hFont; \
  LOGFONT lf; \
  hFont = (HFONT)SendDlgItemMessage(hDlg, nCtrl, WM_GETFONT,0,0); \
  if (!hFont) \
    hFont = GetStockObject(SYSTEM_FONT); \
  if(GetObject(hFont,sizeof(LOGFONT),(LPVOID)&lf)){

#define END_CHANGE_CONTROL_FONT(hDlg, nCtrl) \ 
   SendDlgItemMessage(hDlg, nCtrl, WM_SETFONT, hFont, 0L); \
  } \
}


Ну и сам код:

void CMyDialog::OnInitDialog()
{
...
  BEGIN_CHANGE_CONTROL_FONT(m_hWnd, IDOK)
    lf.lfWeight = FW_BOLD;
    lf.lfUnderline = TRUE;
  END_CHANGE_CONTROL_FONT(m_hWnd, IDOK)

  BEGIN_CHANGE_CONTROL_FONT(m_hWnd, IDCANCEL)
    lf.lfWeight = FW_BOLD;
    lf.lfUnderline = TRUE;
  END_CHANGE_CONTROL_FONT(m_hWnd, IDCANCEL)
...
}
Re[28]: Почему настоящие программисты избегают C++
От: Cyberax Марс  
Дата: 24.02.05 13:16
Оценка:
_Obelisk_ пишет:

> Никто никогда никому не даст библиотеку делающию "офигительный" интрефейс.

Почему? Есть, например, BCG (http://www.bcgsoft.com/), стоит весьма
умеренные деньги ($300). Интерфейсы позволяет делать офигительные
(скинабельные и конфигурабельные). Написана как расширение MFC.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[28]: Почему настоящие программисты избегают C++
От: Amidlokos Россия  
Дата: 24.02.05 13:20
Оценка:
Здравствуйте, _Obelisk_, Вы писали:

_O_>"Офигительный" интерфейс — это конкурентное преимущество, им так просто не разбрасываются.

Сейчас дельфисты с гордостью начнут утверждать, что у них-то такой интерфейс давно уже есть, и на самую натуральную халяву.

Ой, что будет...

WARNING: expression "to_be || !to_be" is always true
Re[29]: Почему настоящие программисты избегают C++
От: _Obelisk_ Россия http://www.ibm.com
Дата: 24.02.05 13:29
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>_Obelisk_ пишет:

>> Никто никогда никому не даст библиотеку делающию "офигительный" интрефейс.

C>Почему? Есть, например, BCG (http://www.bcgsoft.com/), стоит весьма
C>умеренные деньги ($300). Интерфейсы позволяет делать офигительные
C>(скинабельные и конфигурабельные). Написана как расширение MFC.

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

Хм..
BCGControlBar Library Professional Edition
Corporate License US $9990.00

Это не так уж дешево. Потом, я там не вижу чего-нибудь похожего на Objective Views из Stingray-я.


Душа обязана трудиться! (с) Н.Заболоцкий.
Re[30]: Почему настоящие программисты избегают C++
От: Cyberax Марс  
Дата: 24.02.05 13:37
Оценка:
_Obelisk_ пишет:

> Хм..
> BCGControlBar Library Professional Edition
> Corporate License US $9990.00

Естественно. Смотри на обычные лицензии.

> Это не так уж дешево. Потом, я там не вижу чего-нибудь похожего на
> Objective Views из Stingray-я.

Просто немного другой тип библиотеки.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[13]: Почему настоящие программисты избегают C++
От: AlexEagle Украина http://www.vik.oil
Дата: 24.02.05 14:17
Оценка:
Здравствуйте, AlexEagle, Вы писали:

Ну а если кому понадобится — то вот рабочий код:

#define BEGIN_CHANGE_CONTROL_FONT(hDlg, nCtrlId)                \
    {    \
        HFONT hFont;    \
        LOGFONT lf;    \
        hFont = (HFONT)::SendDlgItemMessage(hDlg, nCtrlId, WM_GETFONT,0,0); \
        if (!hFont) \
            hFont = (HFONT)::GetStockObject(SYSTEM_FONT); \
        if(GetObject(hFont,sizeof(LOGFONT),(LPVOID)&lf)){ \

#define END_CHANGE_CONTROL_FONT(hDlg, nCtrlId)                \
            hFont = ::CreateFontIndirect(&lf);    \
            ::SendDlgItemMessage(hDlg, nCtrlId, WM_SETFONT, (WPARAM)hFont, 0L);    \
        }    \
    }    \


void CMyDialog::OnInitDialog()
{
...
    BEGIN_CHANGE_CONTROL_FONT(m_hWnd, IDOK)
        lf.lfWeight = FW_BOLD;
        lf.lfUnderline = TRUE;
    END_CHANGE_CONTROL_FONT(m_hWnd, IDOK)

    BEGIN_CHANGE_CONTROL_FONT(m_hWnd, IDCANCEL)
        lf.lfUnderline = TRUE;
    END_CHANGE_CONTROL_FONT(m_hWnd, IDCANCEL)
...
}
Re[14]: Почему настоящие программисты избегают C++
От: Кодт Россия  
Дата: 24.02.05 14:51
Оценка:
Здравствуйте, AlexEagle, Вы писали:

Монстр макропрограммирования!
class PatchFont : public LOGFONT
{
  HWND m_hwnd;
  UINT m_id;
public:
  PatchFont() {}

  bool take(HWND hwnd, UINT id)
  {
    m_hwnd = hwnd; m_id = id;
    HFONT hfont = (HFONT)::SendDlgItemMessage(m_hwnd, m_id, WM_GETFONT,0,0);
    if(!hfont) hfont = GetStockObject(SYSTEM_FONT);
    return GetObject(hfont, sizeof(LOGFONT), static_cast<LOGFONT*>(this)) != 0;
  }

  void give() const
  {
    HFONT hfont = CreateFontIndirectstatic_cast<const LOGFONT*>(this));
    SendDlgItemMessage(m_hwnd, m_id, WM_SETFONT, (WPARAM)hfont, 0);
  }
};

......

PatchFont pf;

pf.take(hDlg, ID_ONE);
  pf.lfWeight = FW_BOLD;
pf.give();

pf.take(hDlg, ID_TWO);
  pf.lfUnderline = TRUE;
pf.give();
Перекуём баги на фичи!
Re[15]: Почему настоящие программисты избегают C++
От: Kubera Россия  
Дата: 24.02.05 18:41
Оценка:
Здравствуйте, VladD2, Вы писали:

K>>Функция вычисления среднего арифметического не должна бросать исключений. Это нонсенс , если вместо среднего арифметического при определённых входных параметрах функция будет выкидывать ошибку! А вот её реализация обязана учитывать переполнение, точнее избегать его. Влад, с чем ты не согласен?

VD>Попробую более доходчиво:
VD>Функция не учитывающая переполенеие уже ошибочна.
В огороде бузина, а в Киеве дядька...

VD>Так понянее?
Нет, т.к. ты не ответил на мой вопрос. Я так и не понял в чём ты со мной не согласен. Спрошу по-другому:
Функция вычисления среднего арифметического не должна бросать исключений. Влад, ты согласен с этим утверждением? Да или нет?
Любая сложная технология неотличима от волшебства. (Артур Кларк)
Re[15]: Почему настоящие программисты избегают C++
От: _Obelisk_ Россия http://www.ibm.com
Дата: 25.02.05 06:45
Оценка:
Здравствуйте, d Bratik, Вы писали:

DB>Туманно все как-то Через какой API этот собственный framework что-либо рисует? Через GDI, через MFC-шные классы-оболочки над GDI?

Уфф. Рисуем используя Stingray + MFC. Дальше MainSoft все делает :
http://www.mainsoft.com/products/mainwin_howitworks.html

The Visual MainWin Runtime consists of the Windows Runtime on UNIX and Core Services. Together, they enable Windows applications to execute natively on UNIX.

The Windows Runtime on UNIX includes an extensive set of Microsoft technologies such as MSXML, SSL, MSHTML, WinSock, COM/DCOM and ATL. These are based on the original Microsoft implementation, tuned for UNIX by Mainsoft.

Visual MainWin Core Services for UNIX and Linux provide functionality such as synchronization objects, threads and low-level graphic functionality utilized by the Windows Runtime on UNIX. The Core Services also include the Mainsoft RPCSS and Registry services, which provide the robust infrastructure required to support huge numbers of Visual MainWin processes running concurrently on the same machine.

Visual MainWin creates native UNIX binaries requiring no virtual machine. No emulation or mapping is performed at runtime, guaranteeing maximum performance of the deployed application.


DB>Не-е-е, такой ответ не устраивает Пока сам воочию не увижу скриншот с солярки, не поверю Подозреваю, что программе Вашей требуется эмулятор Wine, которого на солярке нет. Я же не просто так спрашивал, сколько у Вас реальных пользователей на Solaris

Сделаю, когда доберусь до SPARС-а.


Душа обязана трудиться! (с) Н.Заболоцкий.
Re[13]: Почему настоящие программисты избегают C++
От: Demiurg  
Дата: 25.02.05 07:23
Оценка:
Здравствуйте, The Lex, Вы писали:

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

sc>>В Windows все элементы гуи, окна, это судя по названию...


TL>А теперь "фишка": а вот в Дельфи не все элементы гуи являются окнами Windows!

Кстати, я так и не понял почему борландовцы свой TLabel сделали не на основе STATIC'а... И не только его...
... << RSDN@Home 1.1.4 beta 4 303, 1995 — Tikhie Igry>>
Re[11]: Почему настоящие программисты избегают C++
От: Demiurg  
Дата: 25.02.05 07:31
Оценка:
Здравствуйте, Kh_Oleg, Вы писали:

G>>Смотря что ты подразумеваешь под "Артефактами".
K_O>Вот это (программа написана на Qt):
K_O>
K_O>Здесь я пытаюсь перетащить ToolBar. Одна рамка — это я его тащу, она и должна быть. А вторая — результат Qt-шной перерисовки, артефакт. Он так и останется, пока все окно не будет перерисовано.

Это ведь SIM? До ужаса кривая и глюкавая программа... Она бы и на VCL себя так же вела Ну или по-другому как-то глючила
... << RSDN@Home 1.1.4 beta 4 303, 1986 — Nasha Sem'ya>>
Re[7]: Почему настоящие программисты избегают C++
От: Awaken Украина  
Дата: 25.02.05 08:28
Оценка:
DB>И все же я пока не видел ни одной промышленной GUI бибилиотеки на С++, которая бы отдаленно приближалась по качеству к VCL и .NET >Framework. Обыскал весь Интернет — таковой в природе нет. Qt более-менее ничего, но когда основательно начинаешь пользовать, начинаешь >плеваться.

дался тебе этот ГУЙ! в любой мало мальски сложной программе гуй это 1-10% всей задачи.
я как-то участвовал в разработке музыкального редактора. это система распознавания и визуализации нотных записей , как положено
на линейках нотного стана, каждая нота на своей высоте. самое сложное тут это не нарисовать эти ноты — а алгоритмы как их представить
в виде векторной графики, масштабировать, сериализовать в двоичные файлы , и т.д.
писано все было на VC++ 6.0 и MFC, и впоследствие портировано на Макинтош.
это я к тому что в сложной задаче на первом месте алгоритмы, а не библиотеки примитивов (они сводятся к набору достаточно низкоуровневых функций, которые можно — и нужно — изолировать в отдельный слой и абстрагировать от основной логике)
Re[15]: Почему настоящие программисты избегают C++
От: Awaken Украина  
Дата: 25.02.05 08:37
Оценка:
K_O>Вот тут упоминали, что куча продуктов (Office, Adobe family, etc.) написана на С++. Написана, но в каждом
K_O>случае разработчикам приходилось писать свой framework конкретно под свой продукт (или семейство продуктов).

любая крупная софтверная фирма имеет собственные фреймворки и собственные солюшены. это удешевляет
разработку в промышленном масштабе, и позволяет максимально унифицировать семейства программных продуктов.
например так чтобы они выглядели одинаково на Windows и на Mac.
ну и еще и из-за политики лицензирования сторонних компонент.
Re[10]: Почему настоящие программисты избегают C++
От: Awaken Украина  
Дата: 25.02.05 08:50
Оценка:
TL> 10 баллов! Первый признак дельфиста: "окно с обычной кнопкой OK, текст которой написан нестандартным шрифтом"! "Повбывав бы!" (к)


я чего-то тоже не пойму — а нахрен там нестандартный шрифт?
а если пользователь поменяет "тему десктопа" в Винде единообразно, что станет с этим нестандартным шрифтом?
Re[9]: Почему настоящие программисты избегают C++
От: Amidlokos Россия  
Дата: 25.02.05 10:08
Оценка:
Здравствуйте, Awaken, Вы писали:

A>выскажу совсем крамольную мысль.

Мысль не крамольная, а вполне даже актуальная Многие крупные системы выглядят именно так.

Другое дело, что есть и другие варианты, кроме баз и CAD-систем... Вот об этом и флейм
WARNING: expression "to_be || !to_be" is always true
Re[12]: Почему настоящие программисты избегают C++
От: Rebus83 Россия  
Дата: 25.02.05 10:41
Оценка:
Здравствуйте, Demiurg, Вы писали:

D> Это ведь SIM? До ужаса кривая и глюкавая программа... Она бы и на VCL себя так же вела Ну или по-другому как-то глючила
Зъя, батенька, зъя. Хорошая прога. Мне нравится. Кроме последней версии в линуксе больше ничем другим и не пользуюсь!
... << RSDN@Home 1.1.4 beta 4 rev. 303>> Вокруг тишина
Какая странная планета! — подумал Маленький принц. — Совсем сухая,
вся в иглах и соленая. И у людей не хватает воображения. Они только
повторяют то, что им скажешь...
Re[13]: Почему настоящие программисты избегают C++
От: Demiurg  
Дата: 25.02.05 10:58
Оценка:
Здравствуйте, Rebus83, Вы писали:

D>> Это ведь SIM? До ужаса кривая и глюкавая программа... Она бы и на VCL себя так же вела Ну или по-другому как-то глючила
R>Зъя, батенька, зъя. Хорошая прога. Мне нравится. Кроме последней версии в линуксе больше ничем другим и не пользуюсь!

Хорошая, но глюкавая. Я сам долго ей пользовался, пока она меня совсем не всбесила своими глюками Теперь перещел на аську — плююсь сижу...
Может это виндовый порт сима такой глюкавый, конечно...
... << RSDN@Home 1.1.4 beta 4 303, 1991 — Tutankhamon (dance mix)>>
Re[16]: Почему настоящие программисты избегают C++
От: d Bratik  
Дата: 25.02.05 11:45
Оценка:
Здравствуйте, _Obelisk_, Вы писали:

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

DB>>Туманно все как-то Через какой API этот собственный framework что-либо рисует? Через GDI, через MFC-шные классы-оболочки над GDI?

_O_>Уфф. Рисуем используя Stingray + MFC. Дальше MainSoft все делает :
_O_>http://www.mainsoft.com/products/mainwin_howitworks.html

_O_>

_O_>The Visual MainWin Runtime consists of the Windows Runtime on UNIX and Core Services. Together, they enable Windows applications to execute natively on UNIX.

_O_>The Windows Runtime on UNIX includes an extensive set of Microsoft technologies such as MSXML, SSL, MSHTML, WinSock, COM/DCOM and ATL. These are based on the original Microsoft implementation, tuned for UNIX by Mainsoft.

_O_>Visual MainWin Core Services for UNIX and Linux provide functionality such as synchronization objects, threads and low-level graphic functionality utilized by the Windows Runtime on UNIX. The Core Services also include the Mainsoft RPCSS and Registry services, which provide the robust infrastructure required to support huge numbers of Visual MainWin processes running concurrently on the same machine.

_O_>Visual MainWin creates native UNIX binaries requiring no virtual machine. No emulation or mapping is performed at runtime, guaranteeing maximum performance of the deployed application.


Честно говоря, этот отрывок меня не убедил. Я с большим подозрением отношусь к рекламным заявляениям, оперирующим термином UNIX. Я подозреваю, что в данном случае под UNIX-ом подразумевается MacOS, для которой действительно есть своя реализация MFC и COM, а также другие Windows-причиндалы. Обычно, если производитель сумел портировать свой продукт на Linux, и нет технических проблем портировать на MacOS (или на FreeBSD), то он пишет, что портировал на UNIX Если же производитель портировал продукт на Solaris, то он этим начинает кичиться и обязательно так и пишет, чтобы народ об этом знал и не сомневался Например, разработчики Qt указывают длинный список конкретных версий UNIX. К сожалению, у меня нет Visual MainWin Runtime (иначе я бы давно все выяснил), поэтому мои слова в данном случае не более, чем спекуляция.

DB>>Не-е-е, такой ответ не устраивает Пока сам воочию не увижу скриншот с солярки, не поверю Подозреваю, что программе Вашей требуется эмулятор Wine, которого на солярке нет. Я же не просто так спрашивал, сколько у Вас реальных пользователей на Solaris

_O_>Сделаю, когда доберусь до SPARС-а.

Договорились, я буду ждать
Re[17]: Почему настоящие программисты избегают C++
От: Cyberax Марс  
Дата: 25.02.05 11:49
Оценка:
d Bratik пишет:

> _O_>Visual MainWin creates native UNIX binaries requiring no virtual
> machine. No emulation or mapping is performed at runtime, guaranteeing
> maximum performance of the deployed application.
> Честно говоря, этот отрывок меня не убедил. Я с большим подозрением
> отношусь к рекламным заявляениям, оперирующим термином UNIX. Я
> подозреваю, что в данном случае под UNIX-ом подразумевается MacOS, для
> которой действительно есть своя реализация MFC и COM, а также другие
> Windows-причиндалы.

Нет. Я лично тестировал MainWnd под Линуксом, и знаю что он работает под
Соляркой. Если не веришь — скачай триальную версию.

ЗЫ: именно из MainSoft'а в прошлом году утекли исходники Винды. Так что
делай выводы....

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[12]: Почему настоящие программисты избегают C++
От: d Bratik  
Дата: 25.02.05 12:25
Оценка:
Здравствуйте, Garrrrr, Вы писали:

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

G>К сожалению, в борьбе с кривыми руками ни одна библиотека не может одержать победу...
G>Я вообще такое впервые вижу, и никогда с такими проблемами ни у себя в программах, ни в многочилсленных программах для Linux,
G>написанных на Qt, не встречался.

Значит недостаточно Qt пользовал

Делаем простейшее окно с изменяющимися размерами. Сразу после запуска программы берем за нижний левый угол окна и пытаемся его увеличить. Ничего не получается Теперь беремся за правый нижний угол — все работает. Снова беремся за нижний левый угол — теперь заработало Так работает Qt на Solaris.

Я уже молчу, что иногда он (Qt) жрет процессорное время, зацикливаясь на посылках-обработках сообщений, что он вообще НЕ excetion-safe (разработчики называют это "not using exceptions" и вообще не защищают выделение ресурсов, поэтому любой виртуальный метод или обработчик сигнала должен иметь всеобъемлющий try {} catch (...) {}), что он не позволяет создавать многопоточный GUI (для отмазки предоставляя какой-то один отстойный объект синхрониации с однтим циклом обработки сообщений на все потоки!)... И т.д. и т.п.

Версия 4 вроде бы обещает быть получше, но с исключениями и потоками она до сих пор не дружит (хотя уже есть beta).
Re[13]: Почему настоящие программисты избегают C++
От: Cyberax Марс  
Дата: 25.02.05 12:37
Оценка:
d Bratik пишет:

> Версия 4 вроде бы обещает быть получше, но с исключениями и потоками
> она до сих пор не дружит (хотя уже есть beta).

Вроде я уже говорил, что ВСЕ распространенные GUI-библиотеки —
НЕпотокобезопасны. Включая WinAPI и VCL (которая построена на WinAPI).

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[13]: Почему настоящие программисты избегают C++
От: Garrrrr  
Дата: 25.02.05 13:12
Оценка:
Здравствуйте, d Bratik, Вы писали:

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

DB>Значит недостаточно Qt пользовал
Может быть

DB>Делаем простейшее окно с изменяющимися размерами. Сразу после запуска программы берем за нижний левый угол окна и пытаемся его увеличить. Ничего не получается Теперь беремся за правый нижний угол — все работает. Снова беремся за нижний левый угол — теперь заработало Так работает Qt на Solaris.

Насчет солярки не знаю — не работал, но на Linux все и всегда работает корректно (кстати, если ты за кроссплатформенность — ты видел
КАК работают kylix-приложения на linux?).

DB>Я уже молчу, что иногда он (Qt) жрет процессорное время, зацикливаясь на посылках-обработках сообщений, что он вообще НЕ excetion-safe (разработчики называют это "not using exceptions" и вообще не защищают выделение ресурсов, поэтому любой виртуальный метод или обработчик сигнала должен иметь всеобъемлющий try {} catch (...) {}), что он не позволяет создавать многопоточный GUI (для отмазки предоставляя какой-то один отстойный объект синхрониации с однтим циклом обработки сообщений на все потоки!)... И т.д. и т.п.

Хотел бы я увидеть хотя бы одну потокобезопасную, безопасную относительно исключений библиотеку GUI.
И потом — методы в Qt, из которых нельзя выкидывать исключения, объявлены как throw(), т ч разработчики честно предупреждают,
чего они от тебя НЕ ждут (ведь ты же не имеешь привычки кидать исключения из деструктора?)
И вообще, многопоточность — это отдельная песня. С каждой библиотекой можно работать в многопоточной среде, просто надо соблюдать
ряд правил для этого. STL вон тоже не многопоточная если на то пошло...

DB>Версия 4 вроде бы обещает быть получше, но с исключениями и потоками она до сих пор не дружит (хотя уже есть beta).
Qt работает на слишком многих платформах с различными по отцтойности компиляторами — отсюда изначальная политика минимализма c++ кода.

P.S.: И вообще, у меня сложилось впечатление, что для тебя не обсуждение главное, а посрать в камментах побольше....
Re[13]: Почему настоящие программисты избегают C++
От: olegkr  
Дата: 25.02.05 13:57
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Кстати добавлю: WinForms — это действительно работа дельфиста. Такую
C>уродливую систему могли написать только они.

C>Нет чтоб сделать как Swing в Java...

Свят-свят-свят! Не надо нам, дотнетчикам, свингов, упаси боже!
Re[13]: Почему настоящие программисты избегают C++
От: Awaken Украина  
Дата: 25.02.05 14:26
Оценка:
>обработчик сигнала должен иметь всеобъемлющий try {} catch (...) {}), что он не позволяет создавать многопоточный GUI (для отмазки

объясни в какой такой ОС существует многопоточный GUI?
в винде он однопоточный по определению (для этого и очередь сообщений)
Re[14]: Почему настоящие программисты избегают C++
От: Pazak Россия  
Дата: 25.02.05 14:51
Оценка:
Здравствуйте, olegkr, Вы писали:

C>>Нет чтоб сделать как Swing в Java...
O>Свят-свят-свят! Не надо нам, дотнетчикам, свингов, упаси боже!

Ну не знаю как насчет дотнетчиков, а мне, дельфисту, swing'овские layout'ы очень даже понравились.
Ку...
Re[15]: Почему настоящие программисты избегают C++
От: olegkr  
Дата: 25.02.05 15:46
Оценка:
Здравствуйте, Pazak, Вы писали:

P>Ну не знаю как насчет дотнетчиков, а мне, дельфисту, swing'овские layout'ы очень даже понравились.

Согласен. Вещь хорошая и полезная. Но только, как довесок в тех случаях, когда они действительно необходимы.
Re[15]: Почему настоящие программисты избегают C++
От: Awaken Украина  
Дата: 25.02.05 15:49
Оценка:
К>Вот в винде он как раз многопоточный (для этого и существуют очереди сообщений у потоков).
К>И этим пользуются разные подпольные компоненты — DDE, OLE.

очереди сообщений относятся к приложению а не к графическому движку.
разве можно из двух потоков одновременно (а не ставя запросы в очередь) рисовать на одном DC?
или например запустить асинхронную операцию заливки экрана а самому в это время рисовать в другом месте
Re[16]: Почему настоящие программисты избегают C++
От: Cyberax Марс  
Дата: 25.02.05 15:49
Оценка:
olegkr пишет:

> P>Ну не знаю как насчет дотнетчиков, а мне, дельфисту, swing'овские
> layout'ы очень даже понравились.
> Согласен. Вещь хорошая и полезная. Но только, как довесок в тех
> случаях, когда они действительно необходимы.

А необходимы они всегда (якоря — пример простейшего layout'а). Достают
уже программы без поддержки масштабирования окон.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[18]: Почему настоящие программисты избегают C++
От: Cyberax Марс  
Дата: 25.02.05 16:01
Оценка:
olegkr пишет:

> C>Разделение на модель-вид-контроллер не заставляет "плодить классы". Как
> C>раз наоборот.
> C>Анонимные классы — это аналог делегатов, а не следствие MVC.

[большой скип]

> Наглядно видно, что подписка на событие и сам обработчик разделены.
> Причем не надо городить отдельных классов (при желании можно и
> отдельный класс сделать).

Ну и как все это относится к MVC? Понятно, что некоторые фичи C#
позволяют слегка сократить код (кстати, по методу на обработчик события
— тоже некузяво), но как это относится к архитектуре WinForms?

> C>Да, нужно помнить параметры FormLayout'а.... Чрезвычайно
> C>сложнозапоминаемые, настолько, что даже автокомплит совсем не
> поможет. И
> C>ведь еще даже документацию просмотреть придется. Нет, это не для
> ВБистов.
> Для примера, GridBagConstraints(int gridx, int gridy, int gridwidth,
> int gridheight, double weightx, double weighty, int anchor, int fill,
> Insets insets, int ipadx, int ipady)
> Читаемость куска кода, использующего данную конструкцию просто
> изумительная.

Говорю же: FormLayout. Всякие GridBag'и нужно забыть как пережитки прошлого.

> Да и вообще, весело разбираться в чужом коде на свинге, с целью
> переместить кнопочку "отсуда-сюда". Работа для настоящих
> интеллектуалов, дотнет отдыхает, комплит помогает.
> Про документацию я вообще умалчиваю. Такое не может называться
> полноценной документацией.

Чего? Весь _исходный_ и откомментированный код Свинга доступен в JDK,
JavaDoc качается с сайта, есть замечательный Swing Tutorial. Чего еще надо?

А вот где взять код WinForms — мне самому интересно.

> C>Чтобы потом все юзеры плевались от неправильно масштабируемых (или
> C>вообще немасштабируемых) форм.
> Anchor-ы решают сию задачу в 9 из 10 случаев.

Нет.

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

Да, поэтому в большинстве программ она и не решена.

> C>У меня она вызывает отвращение. Интерфейсы не выделены, наследование
> C>используется сверх меры
> Ценность интерфейсов в винформах сомнительная, благодаря наличию
> евентов. Это в свинге без интерфейсов никуда.

Нда.... Крайняя степень VB-запущенности.

Интерфейсы нужны для отделения разных видов функциональности. Вот,
например, в WinForms список сам хранит свои данные. В Swing'е список
получает данные из объекта, реализующего интерфейс ListModel.
Соответственно, я могу сделать ListModel (точнее это уже давно
сделаено), который работает поверх ResultSet'а из БД и получить
"датабиндинг" (так любимый дельфистами). А еще можно сделать ListModel,
получающий данные по RPC с удаленного сервера.

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

> C>Хотя МС в этот раз поступила честно — пакет называется WinForms, так
> как
> C>ни на что большее, чем формочки, он не способен.
> Вот только одна беда. На винформах не проблема написать
> professional-looking GUI

К сожалению только "looking", а не "working".

> а на свинге это вызывает немалые затруднения. Фактически, любой
> прилично-выглядящий ГУИ, типа эклипса — самопис.

Агащаз. Эклипс использует свой GUI-пакет только из-за того, что Swing во
время проектировки Эклипсы был еще малоюзабельным.

> C>Руки, значит, не так работают. IDEA написана на Свинге, однако летает
> C>даже на старых машинах.
> Если бы летала... Впрочем, возможно я просто привык к шустрому VS.NET
> вот и ворчу.

Рекомендую поставить IDEA 3.0, или еще лучше IDEA 2.6 — новые версии
Идеи сами по себе тормозные (не из-за GUI).

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[15]: Почему настоящие программисты избегают C++
От: Cyberax Марс  
Дата: 25.02.05 16:03
Оценка:
Кодт пишет:

> A>объясни в какой такой ОС существует многопоточный GUI?
> A>в винде он однопоточный по определению (для этого и очередь сообщений)
> Вот в винде он как раз многопоточный (для этого и существуют очереди
> сообщений у потоков).

Он однопоточный в том смысле, что нельзя безопасно работать с
GUI-элементами, созданными в одном потоке, из другого потока (хотя
некоторые оконные сообщения действительно будут обрабатываться корректно).

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[17]: Почему настоящие программисты избегают C++
От: olegkr  
Дата: 25.02.05 16:07
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>А необходимы они всегда (якоря — пример простейшего layout'а). Достают
C>уже программы без поддержки масштабирования окон.

Простейший, то он простейший. Только в большинстве случаев его хватает за глаза. И не надо громоздить для примитивнейшой формы лайаут в лайауте. Из практики, чего мне не хватает в дополнении к якорям — размещения контролов пропорционально-горизонтально, что бы они одновременно растягивались. Буду писать, благо к дотнету подключить лайаут не так сложно и он будет прекрасно работать в дизайнере форм. Хотя... по GUI Design Guidelines ширина лабелов, текстбоксов, листбоксов и комбобоксов на форме должна быть кратной 40px, не очень хорошо это правило стыкуется со свободно-масштабируемыми формами.
Re[18]: Почему настоящие программисты избегают C++
От: Cyberax Марс  
Дата: 25.02.05 16:09
Оценка:
olegkr пишет:

> C>А необходимы они всегда (якоря — пример простейшего layout'а). Достают
> C>уже программы без поддержки масштабирования окон.
> Простейший, то он простейший. Только в большинстве случаев его хватает
> за глаза. И не надо громоздить для примитивнейшой формы лайаут в лайауте.

Пришли к соглашению: WinForms для примитивных форм. С чем я согласен.

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

Ссылки, плиз.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[19]: Почему настоящие программисты избегают C++
От: olegkr  
Дата: 25.02.05 16:20
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Ну и как все это относится к MVC? Понятно, что некоторые фичи C#
C>позволяют слегка сократить код (кстати, по методу на обработчик события
C>- тоже некузяво), но как это относится к архитектуре WinForms?

Напрямую. Ты не обязан строго следовать MVC. И код за счет этого сокращается значительно. И что немаловажно он становится намного понятнее.

C>Говорю же: FormLayout. Всякие GridBag'и нужно забыть как пережитки прошлого.

Какой еще FormLayout? Поиск по javadoc не дал результата.

C>Чего? Весь _исходный_ и откомментированный код Свинга доступен в JDK,
C>JavaDoc качается с сайта, есть замечательный Swing Tutorial. Чего еще надо?

Мелочи. Удобной документации. javadoc — большая свалка и помойка, по сравнению с MSDN.

C>А вот где взять код WinForms — мне самому интересно.

Неуверен на 100%, но можно посмотреть на mono project. Впрочем навряд-ли. Винформы никто переносить на другие платформы не собирается, т.к. он заточен под Win.

>> Anchor-ы решают сию задачу в 9 из 10 случаев.
C>Нет.
Да. Подеремся?

C>Да, поэтому в большинстве программ она и не решена.
Лениво поди девелоперами, да и не особо нужно.

C>В Swing'е список получает данные из объекта, реализующего интерфейс ListModel.

Отсылаю к документации по дотнету. В частности, к IBindingList.

C>К сожалению только "looking", а не "working".
Ошибаешься. Работает все на-ура, в отличии от свинга.

C>Агащаз. Эклипс использует свой GUI-пакет только из-за того, что Swing во
C>время проектировки Эклипсы был еще малоюзабельным.

А он и сейчас малоюзабелен. Изменений к лучшему не видно.
Re[19]: Почему настоящие программисты избегают C++
От: olegkr  
Дата: 25.02.05 16:24
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Пришли к соглашению: WinForms для примитивных форм. С чем я согласен.

Ага, а свинг — для кривых форм и любителей потрахать мозги себе и юзеру. Согласен.

C>Ссылки, плиз.

Наследуешься от класса LayoutEngine и вперед.
Re[20]: Почему настоящие программисты избегают C++
От: olegkr  
Дата: 25.02.05 16:27
Оценка:
Здравствуйте, olegkr, Вы писали:

O>Наследуешься от класса LayoutEngine и вперед.

Ссылку забыл дать по LayoutEngine
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/custlaywinforms.asp
Re[20]: Почему настоящие программисты избегают C++
От: Cyberax Марс  
Дата: 25.02.05 16:35
Оценка:
olegkr пишет:

> C>Ну и как все это относится к MVC? Понятно, что некоторые фичи C#
> C>позволяют слегка сократить код (кстати, по методу на обработчик события
> C>- тоже некузяво), но как это относится к архитектуре WinForms?
> Напрямую. Ты не обязан строго следовать MVC.

Ну что сказать... Не знаешь ты, что такое MVC.

> C>Говорю же: FormLayout. Всякие GridBag'и нужно забыть как пережитки
> прошлого.
> Какой еще FormLayout? Поиск по javadoc не дал результата.

http://www.jgoodies.com/freeware/forms/

> C>Чего? Весь _исходный_ и откомментированный код Свинга доступен в JDK,
> C>JavaDoc качается с сайта, есть замечательный Swing Tutorial. Чего
> еще надо?
> Мелочи. Удобной документации. javadoc — большая свалка и помойка, по
> сравнению с MSDN.

Нда уж....

JavaDoc — это всего лишь автосгенерированная документация по коду.
Аналога помойки MSDN в Java нет.

>>> Anchor-ы решают сию задачу в 9 из 10 случаев.
> C>Нет.
> Да. Подеремся?

Давай, как раз в Москву собираюсь ехать скоро

> C>Да, поэтому в большинстве программ она и не решена.
> Лениво поди девелоперами, да и не особо нужно.

Нужно. Например при разрешении 1400x1050 всякие формочки в 400 пикселей
выглядят оооочеьнь мелкими.

> C>В Swing'е список получает данные из объекта, реализующего интерфейс
> ListModel.
> Отсылаю к документации по дотнету. В частности, к IBindingList.

Не то. Вот код интефейса ListModel (комментарии и импорты удалены):
public interface ListModel
{
  int getSize();
  Object getElementAt(int index);
  void addListDataListener(ListDataListener l);
  void removeListDataListener(ListDataListener l);
}

Все! Это все, что мне нужно реализовать. Как мне сделать тоже самое для
IBindingList'а? Написать свою реализацию DataTable'а?

И как быть с деревьями? Вот код TreeModel'а для Явы:
public interface TreeModel
{
    public Object getRoot();
    public Object getChild(Object parent, int index);
    public int getChildCount(Object parent);
    public boolean isLeaf(Object node);
    public void valueForPathChanged(TreePath path, Object newValue);
    public int getIndexOfChild(Object parent, Object child);
    void addTreeModelListener(TreeModelListener l);
    void removeTreeModelListener(TreeModelListener l);
}


> C>К сожалению только "looking", а не "working".
> Ошибаешься. Работает все на-ура, в отличии от свинга.

Угу, то-то Янус до сих пор нормально не работает на моей машине.

> C>Агащаз. Эклипс использует свой GUI-пакет только из-за того, что
> Swing во
> C>время проектировки Эклипсы был еще малоюзабельным.
> А он и сейчас малоюзабелен. Изменений к лучшему не видно.

Еще бы. Особенно не заметно, если и не смотреть.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[16]: Почему настоящие программисты избегают C++
От: Кодт Россия  
Дата: 25.02.05 16:38
Оценка:
Здравствуйте, Awaken, Вы писали:

К>>Вот в винде он как раз многопоточный (для этого и существуют очереди сообщений у потоков).
К>>И этим пользуются разные подпольные компоненты — DDE, OLE.

A>очереди сообщений относятся к приложению а не к графическому движку.
A>разве можно из двух потоков одновременно (а не ставя запросы в очередь) рисовать на одном DC?

Можно.

A>или например запустить асинхронную операцию заливки экрана а самому в это время рисовать в другом месте

Можно. Сколько угодно.

Другое дело, что заставлять несколько потоков драться за один графический контекст — это маразм...
Перекуём баги на фичи!
Re[21]: Почему настоящие программисты избегают C++
От: olegkr  
Дата: 25.02.05 16:50
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Ну что сказать... Не знаешь ты, что такое MVC.

ОК. Пусть будет так. Не знаю я что такое MVC, хоть данная модель и используется в нашем проекте. Дело в том, что в дотнете есть выбор — использовать MVC или нет. В свинге такого выбора просто нет.

C>http://www.jgoodies.com/freeware/forms/

Интересная весчь. Спасибо. Единственная стоящая весчь, и то наваяли не в SUN-е.

C>JavaDoc — это всего лишь автосгенерированная документация по коду.
C>Аналога помойки MSDN в Java нет.

Ага, нет бабок — генерим доки с сорцов (это уже мне наш джавист подсказывает у него почему-то на джавадоки аллергия)

C>Давай, как раз в Москву собираюсь ехать скоро

Давай к нам — нам как раз пара свингистов нужны на проект. С супер-знанием свинга на хорошие бабки. Если интересно — пиши на olegkr@email.su.

C>Не то. Вот код интефейса ListModel (комментарии и импорты удалены):
C>Все! Это все, что мне нужно реализовать. Как мне сделать тоже самое для
C>IBindingList'а? Написать свою реализацию DataTable'а?

Если проще — то имеется IList.

C>Угу, то-то Янус до сих пор нормально не работает на моей машине.

Я всегда думал — что Янус написали злобные джависты, что бы им было за что ругать дотнет.
Re[21]: Почему настоящие программисты избегают C++
От: olegkr  
Дата: 25.02.05 16:53
Оценка:
Здравствуйте, Cyberax, Вы писали:

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

И которые готовы всю жизнь потратить на размещение контролов на форме.

C>Готовые взаимозаменяемые Layout'ы где? Тот в МСной статье — фигня.

Понятно дело, что писать надо. У нас один уже написан, вполне рабочий, и я бы не сказал, что супер-пупер это сложно.
Re[22]: Почему настоящие программисты избегают C++
От: Cyberax Марс  
Дата: 25.02.05 16:58
Оценка:
olegkr пишет:

> C>Нет, Свинг — для профессиональных GUI-программистов, которые могут
> C>обойтись и без редактора формочек.
> И которые готовы всю жизнь потратить на размещение контролов на форме.

Нет, при некотором опыте руками писать на Свинге получается _быстрее_,
чем рисовать в редакторе.

> C>Готовые взаимозаменяемые Layout'ы где? Тот в МСной статье — фигня.
> Понятно дело, что писать надо. У нас один уже написан, вполне рабочий,
> и я бы не сказал, что супер-пупер это сложно.

Каждый свой неинтероперабельный велосипед пишет....

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[22]: Почему настоящие программисты избегают C++
От: Cyberax Марс  
Дата: 25.02.05 17:03
Оценка:
olegkr пишет:

> C>Ну что сказать... Не знаешь ты, что такое MVC.
> ОК. Пусть будет так. Не знаю я что такое MVC, хоть данная модель и
> используется в нашем проекте. Дело в том, что в дотнете есть выбор —
> использовать MVC или нет. В свинге такого выбора просто нет.

Покажите мне, где в WinForms есть MVC.

А в Свинге можно элементарно не использовать MVC, а просто пользоваться
стандартными реализациями моделей и видов — будет почти все как в WinForms.

> C>JavaDoc — это всего лишь автосгенерированная документация по коду.
> C>Аналога помойки MSDN в Java нет.
> Ага, нет бабок — генерим доки с сорцов (это уже мне наш джавист
> подсказывает у него почему-то на джавадоки аллергия)

JavaDoc — это документация именно _к_ _исходникам_. То есть просто
документируются классы и методы — так же как и reference'ы в MSDN'е.

> C>Давай, как раз в Москву собираюсь ехать скоро
> Давай к нам — нам как раз пара свингистов нужны на проект. С
> супер-знанием свинга на хорошие бабки. Если интересно — пиши на
> olegkr@email.su.

И так работа уже есть (на С++, а не на Java — я многопрофильный)

> C>Не то. Вот код интефейса ListModel (комментарии и импорты удалены):
> C>Все! Это все, что мне нужно реализовать. Как мне сделать тоже самое для
> C>IBindingList'а? Написать свою реализацию DataTable'а?
> Если проще — то имеется IList.

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

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[23]: Почему настоящие программисты избегают C++
От: olegkr  
Дата: 25.02.05 17:05
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Нет, при некотором опыте руками писать на Свинге получается _быстрее_,
C>чем рисовать в редакторе.

Я бы поверил, если бы сам не писал на Свинге. Возможно через пару-тройку лет интерфейсы вслепую и можно натренироваться фигачать.

C>Каждый свой неинтероперабельный велосипед пишет....

аналогично можно сказать и про jgoodies
Re[17]: Почему настоящие программисты избегают C++
От: Cyberax Марс  
Дата: 25.02.05 17:06
Оценка:
Кодт пишет:

> Другое дело, что заставлять несколько потоков драться за один
> графический контекст — это маразм...

Еще очень забавный опыт: создать в одном потоке дочернее окно с
родителем в другом потоке.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[24]: Почему настоящие программисты избегают C++
От: Cyberax Марс  
Дата: 25.02.05 17:09
Оценка:
olegkr пишет:

> C>Нет, при некотором опыте руками писать на Свинге получается _быстрее_,
> C>чем рисовать в редакторе.
> Я бы поверил, если бы сам не писал на Свинге. Возможно через
> пару-тройку лет интерфейсы вслепую и можно натренироваться фигачать.

Я помню, что уже через месяц (после того, как набил шишки в нужных
местах) писал на Свинге быстрее, чем в редакторе. Причем было это в 2002
году.

> C>Каждый свой неинтероперабельный велосипед пишет....
> аналогично можно сказать и про jgoodies

Но! В Яве у layout'ов стандартный интерфейс, поэтому тот же JGoodies без
проблем может интеоперировать хоть с FlowLayout'ом из JDK1.0.1

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[23]: Почему настоящие программисты избегают C++
От: olegkr  
Дата: 25.02.05 17:11
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Покажите мне, где в WinForms есть MVC.

А чем тебе в качестве модели IList или IBindingList не катит?

C>JavaDoc — это документация именно _к_ _исходникам_. То есть просто
C>документируются классы и методы — так же как и reference'ы в MSDN'е.

Только толку с нее...

C>Ну и как он будет оповещать спиок об изменениях данных? Ну а для дерева
C>вообще ничего подходящего нет.

IBindingList.ListChanged event. C деревом сложнее.
Re[25]: Почему настоящие программисты избегают C++
От: olegkr  
Дата: 25.02.05 17:16
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Я помню, что уже через месяц (после того, как набил шишки в нужных
C>местах) писал на Свинге быстрее, чем в редакторе. Причем было это в 2002
C>году.

Согласен. На редакторах формочек для свингов много не напишешь. Проще ручками. Еще проще — в нормальном редакторе.

C>Но! В Яве у layout'ов стандартный интерфейс, поэтому тот же JGoodies без
C>проблем может интеоперировать хоть с FlowLayout'ом из JDK1.0.1

Т.к. интероперировать не с чем, то и проблемы таковой нет.
Re[24]: Почему настоящие программисты избегают C++
От: Cyberax Марс  
Дата: 25.02.05 17:19
Оценка:
olegkr пишет:

> C>Покажите мне, где в WinForms есть MVC.
> А чем тебе в качестве модели IList или IBindingList не катит?

Не катит, так как нормально я их переопределить не могу.

> C>JavaDoc — это документация именно _к_ _исходникам_. То есть просто
> C>документируются классы и методы — так же как и reference'ы в MSDN'е.
> Только толку с нее...

JavaDoc — это _просто_ комментарий к исходникам. Ни больше, ни меньше.

Подробная документация в JavaDoc'е не бывает (обычно), а скачивается
(вариант: браузится) отдельно.

> C>Ну и как он будет оповещать спиок об изменениях данных? Ну а для дерева
> C>вообще ничего подходящего нет.
> IBindingList.ListChanged event. C деревом сложнее.

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

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[19]: Почему настоящие программисты избегают C++
От: Cyberax Марс  
Дата: 25.02.05 17:21
Оценка:
Кодт пишет:

> C>Еще очень забавный опыт: создать в одном потоке дочернее окно с
> C>родителем в другом потоке.
> Вот только что опыт ставил. Результат — мрачный, но (через
> пень-колоду) работает.

Угу, причем ломается в самых неожиданных местах (типа SetFocus).

Я как-то пытался довести такой подход до ума — в итоге наплевал, и стал
делать GUI полностью однопоточным.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[26]: Почему настоящие программисты избегают C++
От: Cyberax Марс  
Дата: 25.02.05 17:22
Оценка:
olegkr пишет:

> C>Я помню, что уже через месяц (после того, как набил шишки в нужных
> C>местах) писал на Свинге быстрее, чем в редакторе. Причем было это в
> 2002
> C>году.
> Согласен. На редакторах формочек для свингов много не напишешь. Проще
> ручками. Еще проще — в нормальном редакторе.

Я с VB тогда сравнивал

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[14]: Почему настоящие программисты избегают C++
От: d Bratik  
Дата: 25.02.05 17:26
Оценка:
Здравствуйте, Garrrrr, Вы писали:

DB>>Я уже молчу, что иногда он (Qt) жрет процессорное время, зацикливаясь на посылках-обработках сообщений, что он вообще НЕ excetion-safe (разработчики называют это "not using exceptions" и вообще не защищают выделение ресурсов, поэтому любой виртуальный метод или обработчик сигнала должен иметь всеобъемлющий try {} catch (...) {}), что он не позволяет создавать многопоточный GUI (для отмазки предоставляя какой-то один отстойный объект синхрониации с однтим циклом обработки сообщений на все потоки!)... И т.д. и т.п.

G>Хотел бы я увидеть хотя бы одну потокобезопасную, безопасную относительно исключений библиотеку GUI.
G>И потом — методы в Qt, из которых нельзя выкидывать исключения, объявлены как throw(), т ч разработчики честно предупреждают,
G>чего они от тебя НЕ ждут (ведь ты же не имеешь привычки кидать исключения из деструктора?)
G>И вообще, многопоточность — это отдельная песня. С каждой библиотекой можно работать в многопоточной среде, просто надо соблюдать
G>ряд правил для этого. STL вон тоже не многопоточная если на то пошло...

Речь идет о моногопоточном, exception-safe GUI. Мне это позарез нужно. Таких библиотек (промышленных) только две: .NET framework и VCL (там все хуже, но все равно есть).

DB>>Версия 4 вроде бы обещает быть получше, но с исключениями и потоками она до сих пор не дружит (хотя уже есть beta).
G>Qt работает на слишком многих платформах с различными по отцтойности компиляторами — отсюда изначальная политика минимализма c++ кода.

G>P.S.: И вообще, у меня сложилось впечатление, что для тебя не обсуждение главное, а посрать в камментах побольше....

Я ставлю проблемы.
Re[15]: Почему настоящие программисты избегают C++
От: Cyberax Марс  
Дата: 25.02.05 17:41
Оценка:
d Bratik пишет:

> G>чего они от тебя НЕ ждут (ведь ты же не имеешь привычки кидать
> исключения из деструктора?)
> G>И вообще, многопоточность — это отдельная песня. С каждой
> библиотекой можно работать в многопоточной среде, просто надо соблюдать
> G>ряд правил для этого. STL вон тоже не многопоточная если на то пошло...
> Речь идет о моногопоточном, exception-safe GUI. Мне это позарез нужно.
> Таких библиотек (промышленных) только две: .NET framework и VCL (там
> все хуже, но все равно есть).

ТАКИХ нет. VCL — НЕпотокобезопасна, пора бы уже знать. Естественно, ее
можно использовать в многотредовом окружении, точно так же как и: MFC,
WTL, WinAPI, QT, GTK и прочие. То есть маршалируя графические вызовы в
нужный поток или используя только их потокобезопасное подмножество.

Ну а в качестве exception-safe — чем MFC или WTL не нравится?

> Я ставлю проблемы.

Какие? Которых нет?

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[14]: Почему настоящие программисты избегают C++
От: The Lex Украина  
Дата: 25.02.05 17:48
Оценка:
Здравствуйте, Demiurg, Вы писали:

sc>>>В Windows все элементы гуи, окна, это судя по названию...

TL>>А теперь "фишка": а вот в Дельфи не все элементы гуи являются окнами Windows!

D> Кстати, я так и не понял почему борландовцы свой TLabel сделали не на основе STATIC'а... И не только его...

— Ы!
— А почему "Ы"?
— А чтоб никто не догадался!
(к)

Хотя могу заметить, что определенный резон в этом есть, но с непривычки это несколько смущает...
Голь на выдумку хитра, однако...
Re[11]: Почему настоящие программисты избегают C++
От: The Lex Украина  
Дата: 25.02.05 17:50
Оценка:
Здравствуйте, Awaken, Вы писали:

TL>> 10 баллов! Первый признак дельфиста: "окно с обычной кнопкой OK, текст которой написан нестандартным шрифтом"! "Повбывав бы!" (к)

A>я чего-то тоже не пойму — а нахрен там нестандартный шрифт?
A>а если пользователь поменяет "тему десктопа" в Винде единообразно, что станет с этим нестандартным шрифтом?

— Ы!
— А почему "Ы"?
...
Голь на выдумку хитра, однако...
Re[16]: Почему настоящие программисты избегают C++
От: The Lex Украина  
Дата: 25.02.05 17:59
Оценка:
Здравствуйте, Awaken, Вы писали:

К>>Вот в винде он как раз многопоточный (для этого и существуют очереди сообщений у потоков).
К>>И этим пользуются разные подпольные компоненты — DDE, OLE.

A>очереди сообщений относятся к приложению а не к графическому движку.
A>разве можно из двух потоков одновременно (а не ставя запросы в очередь) рисовать на одном DC?
A>или например запустить асинхронную операцию заливки экрана а самому в это время рисовать в другом месте

Стоп-стоп-стоп! А при чем тут нижний уровень графики? Или Вы хотите сказать, что на двух мониторах нельзя будет рисовать одновременно?

В конце-концов, какой смысл: "запустить асинхронную операцию заливки экрана а самому в это время рисовать в другом месте"? И опять-таки никто не запрещает "запустить", а рисовать в это время в памяти — правда? И это относится скорее г GDI, чем к GUI, правда?
Голь на выдумку хитра, однако...
Re[16]: Почему настоящие программисты избегают C++
От: The Lex Украина  
Дата: 25.02.05 18:03
Оценка:
Здравствуйте, Cyberax, Вы писали:

>> A>объясни в какой такой ОС существует многопоточный GUI?
>> A>в винде он однопоточный по определению (для этого и очередь сообщений)
>> Вот в винде он как раз многопоточный (для этого и существуют очереди
>> сообщений у потоков).

C>Он однопоточный в том смысле, что нельзя безопасно работать с
C>GUI-элементами, созданными в одном потоке, из другого потока (хотя
C>некоторые оконные сообщения действительно будут обрабатываться корректно).

В целом — нельзя. И со многими элементами системы тоже нельзя. И даже с памятью приходится ухищряться и самому писать синхронизацию. Вот только средства для обеспечения "многопоточного GUI" в Винде есть — те же очереди — и работают они отнюдь неплохо, правда? По крайней мере, свою задачу они выполняют...

Наверняка можно найти те или иные методы, которыми можно будет работать небезопасно с любым объектом любой ОС или платформы. Правда, говорят, AS/400 "совсем-совсем безопасная" — но сам я не видел...
Голь на выдумку хитра, однако...
Re[21]: Почему настоящие программисты избегают C++
От: The Lex Украина  
Дата: 25.02.05 18:06
Оценка:
Здравствуйте, Cyberax, Вы писали:

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

да... помню, в былые времена все веб-дизайнеры "обходились без редакторов формочек" — я вот до сих пор обхожусь... Правда я не профессионал...
Голь на выдумку хитра, однако...
Re[20]: Почему настоящие программисты избегают C++
От: The Lex Украина  
Дата: 25.02.05 18:12
Оценка:
Здравствуйте, Cyberax, Вы писали:

>> C>Еще очень забавный опыт: создать в одном потоке дочернее окно с
>> C>родителем в другом потоке.
>> Вот только что опыт ставил. Результат — мрачный, но (через
>> пень-колоду) работает.

C>Угу, причем ломается в самых неожиданных местах (типа SetFocus).

C>Я как-то пытался довести такой подход до ума — в итоге наплевал, и стал
C>делать GUI полностью однопоточным.

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

Т.е. вы хотите сказать, что ежели дочернее окно и родительское окно будут иметь разные потоки, то возникнут проблемы? Хм... Можно огласить весь код? Можно в новую тему...
Голь на выдумку хитра, однако...
Re[21]: Почему настоящие программисты избегают C++
От: Cyberax Марс  
Дата: 25.02.05 18:23
Оценка:
The Lex пишет:

> C>Я как-то пытался довести такой подход до ума — в итоге наплевал, и стал
> C>делать GUI полностью однопоточным.
> Так, я где-то потерялся: придется поднимать старый проект и смотреть,
> как я "делал это" — самому интересно, а то вы тут заставили меня
> самому засомневаться в своей жизни...
> Т.е. вы хотите сказать, что ежели дочернее окно и родительское окно
> будут иметь разные потоки, то возникнут проблемы? Хм... Можно огласить
> весь код? Можно в новую тему...

Возникнут обязательно. Я пытался заставить MDIChild'ов работать в своих
потоках. Оно, в принципе, работало. Но ОООЧЕНЬ глючно.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[20]: Почему настоящие программисты избегают C++
От: Awaken Украина  
Дата: 25.02.05 18:28
Оценка:
C>Я как-то пытался довести такой подход до ума — в итоге наплевал, и стал
C>делать GUI полностью однопоточным.

это примерно как писать многопоточные программы на VB(6)
в теории оно возможно но на практике лучше потратить время на что-нибудь другое
Re[2]: Почему настоящие программисты избегают C++
От: Denis_TST Россия www.transsys.ru
Дата: 25.02.05 20:15
Оценка:
Здравствуйте, AlexEagle, Вы писали:

AE>Здравствуйте, d Bratik, Вы писали:
AE>И предпочитают делфи где-то по следующим причинам:

AE>2. За отсутствие шаблонов.
Не смертельно. в VB их тоже нет, в java и C# они недавно появились.

AE>3. За отсутствие возможности создания автоматических объектов (все объекты изначально является указателем).
Есть такая возможность — используй интерфесы и будет тебе счастье. Или напиши интерфейс обертку — получишь аналог SmartPointer'a
Например как в JCL :

Associates a resource, pointer or object reference, with a safeguard.

function Guard(Mem: Pointer; out SafeGuard: ISafeGuard): Pointer; overload;
function Guard(Obj: TObject; out SafeGuard: ISafeGuard): TObject; overload;
function Guard(Mem: Pointer; var SafeGuard: IMultiSafeGuard): Pointer; overload;
function Guard(Obj: TObject; var SafeGuard: IMultiSafeGuard): TObject; overload;

   var
     SafeGuard: ISafeGuard;
     Strings: TStrings;
   begin
     Strings := TStrings(Guard(TStringList.Create, SafeGuard));
     String.ReadFromFile('d:\delphi\jcl\source\JclBase.pas');
     // code to manipulate strings goes here
     Strings.SaveToFile('d:\delphi\jcl\source\JclBase.pas');
   end;

Project JEDI

AE> Соответственно приходистя вручную вызывать конструктор/деструктор (для чего и TRY..Finnaly)
ЭЭ а в каком языке не нужно вручную вызывать конструктор?

AE>4. За отсутствие множественного наследования
в Java тоже его нет, в мусор java!
AE>5. За отсутствие возможности перегрузки операций
не смертельно. см п. 4
AE>6. За WITH благодаря которому код становится не читабельным до ужаса...
так не используй его! goto тоже в Delphi есть , это же не значит что его нужно пихать где попало!
AE>7. За дикую абстрактность от GUI модели, благодаря чему некоторые события не доступны
Кто тебе мешает отделить модель? Зачем все пихать в одну форму? можно разбить на фреймы, на отдельные
модули...
AE> реализован Handle у компонентов — просто бестселлер, понял когда случайно вызвал в
AE> деструкторе.
нормально реализован, чтобы ресурсы не жрать когда handle не нужен.
AE>12. За отсутствие менеджера конфигураций. Так чтобы сделать Debug и Release хотябы, и пользоваться просто переключая их.
AE>13. За дикий размер EXE, если конечно же не юзать пакаджи.
Дался тебе этот размер. Ты что програмки на дискетках распространяешь?

и вообще, а почему таки не юзать пакаджи? Только вместо стандартных, создать свои — с теми модулями котрые тебе нужны.
Получишь 1-2 пакета размером 1-2 мб + остальные файлы проекта (exe,dll) по 10-90 кб.
Дистрибутив из 300 проектов-плагинов вместо 100 мб занимает 12 мб.
Сложно ставить кучу файлов ? так сделай инсталлятор! и авто обновление .
AE>14. За то что ошибочная работа встроенных функций ведет к генерированию исключения, а не возврату кода ошибки. При этом во многих случаях приходится писать просто try ... except end; чтобы пропустить эту фичу.
Такая же модель в java и С. Если сделать через возврат кода ошибки, то есть вероятность что ты не вставишь код проверки
результата (ты же давишь исключения не глядя) и ошибка произойдет гораздо позже и в другом месте.И опять будут крики
что Delphi ламерская система


AE>15. За то что она не MDI. Это ужасно "УДОБНО". Приходится очищать рабочий стол перед открытием делфи, да и две запущенные — это головняк ("КРУТО"), поскольку никогда не знаешь в редакторе какой находишся. Иногда по ALT-TAB переключается только редактор, а главное окно нет.
Единственный случай кода тебе нужны две IDE — это когда отлаживаешь расширения среды. В остальных случаях используем ProjectManager
для работы. Открываем там N проектов...

AE>16. За WITH благодаря которому дебаггер не показывае значение переменных типа with TComeCObject.Create(...) do Visible := TRUE;
AE> Значение Visible — не увидишь никогда. Только если with SomeObject do SomeProperty := SomeValue; то в ТОЛЬКО окне свойств надо подставить SomeObject.SomeProperty и только тогда будет значение
Не пользуйся им ! см п. 6
AE>17. За дебаггер который видит стек вызовов исключительно ограниченный модулями, пути которых включены в проект.
Это потому что dcu из $(Delphi)\lib собраны без отладочной информации (см п 13). Хочешь видеть весь стек — зайди в настройки
и поставь галочку use Debug DCUs и не мучайся с путями. RTFM!

AE>18. За отсутствие оператора "?". Есть только два псевдоаналога — варианты функции ifthen. При этом нормально работать можно со строкой и Integer-подобными значениями.
AE> Когда речь идет об объекта то тогда запись выростает до TType(ifthen(...,Integer(Object1),(object2)) — грустно...
Ну напиши нужные тебе ifthen (работы на 5 минут), добавь их в отдельный модуль и не грусти.

AE>19. За компилятор, который хавает на ура запятую без указания последнего необязательного параметра функции.
AE> Т.е. если function f(p1: Integer; b1: Boolean=false; B2: Boolean = false), то такое прокатит на ура — f(1,false,);
Это ошибка парсинга на компиляцию это никак не влияет . В D7 эта ошибка исправлена. Можно подумать в компиляторах C ранних версий нет
ошибок. (в мусор их!)
AE>20. За директивы компилятора сделанные в стиле коментариев и мещающие коментированию текста их содержащего
используй // или (* *)
если в коде уже есть комметарии то его тоже неудобно комментировать

AE>21. За отсутствие нормального хелпа к системным функциям.
Поставь MSDN и эксперт для поиска в нем из среды. Или ты хочешь чтобы справка Delphi дублировала весь MSDN

AE> Для того чтобы определить где находится описание сетевой
AE> функции нужно выполнять поиск по каталогу сырцов. К примеру NetWkstaGetInfo которая вообще отсутствиет в
AE> стандартных сырцах
Можно подумать в VC 6 есть все-все API фунции?

AE> Ламерская система....
ага и компонета TNetWkstaGetInfo нет, ламерская система!

AE>23. За то что нельзя создать два пакета содержащие модули с одинаковыми названиями — среда не позволит, будет каждый раз ругаться что Пакет ХХХ использует модуль УУУ, который уже содержится в ХХ1 — это очень удобно, в с++ такого не добиться
Можно , если их не ставить в среду и использовать только в runtime . Как IDE определит из какого пакета брать модуль YYY?


Вы не любите кошек? вы просто не умеете их готовить!

Кроче пост полностью аналогичный первому в ветке.
Я не говорю что Delphi идеальная среда, и для нового проекта я бы выбрал C# . Но ИМХО когда C# еше не было, Delphi
был лучшим инструметом для быстрой разработки мордочек для работы с базами данных (всякие АСУ и т.д.), и сейчас остается если машины слабые
Проблемы начинаются когда инструмент начинают использовать не по назначению. Например
пытатся писать на Delphi игры или маленкие программы или хакерские утилиты
... << RSDN@Home 1.1.4 beta 4 rev. 326>>
Re[4]: Почему настоящие программисты избегают C++
От: Denis_TST Россия www.transsys.ru
Дата: 25.02.05 20:30
Оценка:
Здравствуйте, AlexEagle, Вы писали:

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

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

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

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

А у нас для сборки release версии есть сервер сборки. Там и директивы нужные подставляются и инсталлятор генерится и тд.
Никакого человеческого фактора — все исходники из StarTeam, управление через web интерфейс.

Ну а для начала для сборки релиза достаточно батника обрашающегося к dcc32. Все директивы можно там указать.
или посмотри на это:

WANT automates the process of building, testing, and packaging applications and libraries much like Jakarta Ant does. WANT is written in Borland Delphi.
https://sourceforge.net/projects/want/

отличная вещь, уже 3 года пользуемся.
... << RSDN@Home 1.1.4 beta 4 rev. 326>>
Re[13]: Почему настоящие программисты избегают C++
От: Denis_TST Россия www.transsys.ru
Дата: 25.02.05 21:22
Оценка:
Здравствуйте, The Lex, Вы писали:

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

sc>>В Windows все элементы гуи, окна, это судя по названию...


TL>А теперь "фишка": а вот в Дельфи не все элементы гуи являются окнами Windows!

Это для экономии ресурсов, в win95 с этим были проблемы — ограничение на число hwnd. И машины с 16 мб
были не редкость (и сейчас такие есть).

или например похожий принцип используется в TCanvas —
когда ты например, меняшь цвет кисти или шрифт — это означает что нужно создать новый объект GDI.
Тк в win95 было ограничение на их количество (кажется не больше 16 000) то все гди объекты реально создаются в
только при обращении к ним 

procedure TCanvas.Ellipse(X1, Y1, X2, Y2: Integer);
begin
  Changing;
  RequiredState([csHandleValid, csPenValid, csBrushValid]); <<----здесь
  Windows.Ellipse(FHandle, X1, Y1, X2, Y2);
  Changed;
end;

procedure TCanvas.RequiredState(ReqState: TCanvasState);
var
  NeededState: TCanvasState;
begin
  NeededState := ReqState - State;
  if NeededState <> [] then
  begin
    if csHandleValid in NeededState then
    begin
      CreateHandle; <<----------- вот  
      if FHandle = 0 then
        raise EInvalidOperation.CreateRes(@SNoCanvasHandle);
    end;
    if csFontValid in NeededState then CreateFont; <<<---
    if csPenValid in NeededState then CreatePen;   <<--
    if csBrushValid in NeededState then CreateBrush; <<--
    State := State + NeededState;
  end;
end;


и для оконных компонетов такая же система — handle создается только тогда когда он нужен.
Непонятно зачем тебе нужно чтобы все было окнами ? Вот в XAML тоже есть только одно окно, и что это плохо?
... << RSDN@Home 1.1.4 beta 4 rev. 326>>
Re[16]: Почему настоящие программисты избегают C++
От: Denis_TST Россия www.transsys.ru
Дата: 25.02.05 21:22
Оценка:
Здравствуйте, Awaken, Вы писали:

К>>Вот в винде он как раз многопоточный (для этого и существуют очереди сообщений у потоков).
К>>И этим пользуются разные подпольные компоненты — DDE, OLE.

A>очереди сообщений относятся к приложению а не к графическому движку.
A>разве можно из двух потоков одновременно (а не ставя запросы в очередь) рисовать на одном DC?
A>или например запустить асинхронную операцию заливки экрана а самому в это время рисовать в другом месте
А зачем ? Можно создать в памяти битмап и заливать его цветом в другом потоке. Потом послать сообщение SendMessage основному потоку и
передать в нем адрес битмапа... или нужно видеть как он заливает и моргает при перерисовке ?
в чем смысл такой многопоточности?
в тех же игрушках есть два буфера в один рисуют , другой показывают
... << RSDN@Home 1.1.4 beta 4 rev. 326>>
Re[8]: Почему настоящие программисты избегают C++
От: AndrewJD США  
Дата: 26.02.05 12:17
Оценка:
Здравствуйте, Awaken, Вы писали:


A>писано все было на VC++ 6.0 и MFC, и впоследствие портировано на Макинтош.

Можешь описать, хотя бы в двух словах, как портировали под Мак?
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Re[17]: Почему настоящие программисты избегают C++
От: Amidlokos Россия  
Дата: 26.02.05 18:32
Оценка:
Здравствуйте, d Bratik, Вы писали:

C>>Ну а в качестве exception-safe — чем MFC или WTL не нравится?

DB>В моем инструментальном ящике этому отстою нету места. Если мне нужно будет сделать программу для Windows, я не раздумывая возьму Delphi и VCL (или нынче уже VS.NET с WinForms). Если передо мной цель — сделать программу для Solaris и Linux (и в последнюю очередь Windows), то я возьму Qt.

Народ, дэ братику программ для виндовоза не давать, ему хватит!

DB>Для того, чтобы понять, что проблемы есть и проблемы серьезнейшие, нужно принять определенную систему ценностей. После многих лет программирования я принял систему ценностей Вирта и проповедую ее.

И тебя вылечат...
WARNING: expression "to_be || !to_be" is always true
Re[23]: Почему настоящие программисты избегают C++
От: Kh_Oleg  
Дата: 28.02.05 09:06
Оценка:
Здравствуйте, Awaken, Вы писали:

C>>Да. Само приложение, хотя 10^5 записей и дерево сможет отсортировать.

A>пихать 10^5 записей в гуйный контрол это уже кривой дизайн. за такое по рукам надо
A>данные дерева должны быть в невизуальном контейнере, и только малая часть визуализируется по мере
A>необходимости

Умница! Вот только VirtualTreeView делает это за меня. И визуализирует "по мере необходимости",
избавляя от многих забот.
Re[3]: Почему настоящие программисты избегают C++
От: AndrewJD США  
Дата: 28.02.05 10:40
Оценка:
Здравствуйте, Denis_TST, Вы писали:

AE>>13. За дикий размер EXE, если конечно же не юзать пакаджи.
D_T>Дался тебе этот размер. Ты что програмки на дискетках распространяешь?
Нет, через интернет.

D_T>Единственный случай кода тебе нужны две IDE — это когда отлаживаешь расширения среды. В остальных случаях используем ProjectManager
D_T>для работы. Открываем там N проектов...


AE>> Для того чтобы определить где находится описание сетевой
AE>> функции нужно выполнять поиск по каталогу сырцов. К примеру NetWkstaGetInfo которая вообще отсутствиет в
AE>> стандартных сырцах
D_T>Можно подумать в VC 6 есть все-все API фунции?
В platform SDK есть все документированные функции и даже не документированные
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Re[19]: Почему настоящие программисты избегают C++
От: AndrewJD США  
Дата: 28.02.05 10:52
Оценка:
Здравствуйте, d Bratik, Вы писали:

DB>Я сам доктор, между делом студентов лечу.
Не жалко студентов то?
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Re[18]: Почему настоящие программисты избегают C++
От: d Bratik  
Дата: 28.02.05 17:43
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>d Bratik пишет:

>> C>ТАКИХ нет. VCL — НЕпотокобезопасна, пора бы уже знать. Естественно, ее
>> C>можно использовать в многотредовом окружении, точно так же как и: MFC,
>> C>WTL, WinAPI, QT, GTK и прочие. То есть маршалируя графические вызовы в
>> C>нужный поток или используя только их потокобезопасное подмножество.
>> Вы хоть раз Qt на Солярке пускали? Там Qt (по собственнной вине и по
>> вине X11) по определению с многопоточностью не дружит (впрочем,
>> разработчики Солярки вообще с головой не дружат, так что создателям Qt
>> есть на кого пальцем тыкать).

C>Ррррррррр..... Да _НИ_ _ОДНА_ распространенная GUI не дружит с
C>многопоточностью по очень простой причине — ВСЕ они построены на
C>концепции очереди сообщений (событий, сигналов). Но при этом _ЛЮБУЮ_
C>современную GUI-систему можно использовать в многопоточной среде, приняв
C>соответствующие меры.

Тогда Вы может быть мне расскажите, какие меры нужно принять, чтобы организовать многопоточное рисование (требуется просто фоновое рисование двух картинок) в Qt-программе, работающей на Солярисе? Или под "соответствующими мерами" понимается также смена оконного менеджера, библиотеки графического вывода и операционной системы?

>> C>Ну а в качестве exception-safe — чем MFC или WTL не нравится?
>> В моем инструментальном ящике этому отстою нету места. Если мне нужно
>> будет сделать программу для Windows, я не раздумывая возьму Delphi и
>> VCL (или нынче уже VS.NET с WinForms). Если передо мной цель — сделать
>> программу для Solaris и Linux (и в последнюю очередь Windows), то я
>> возьму Qt.

C>Да я и не сомневался...

C>Ксати, VCL построена на стандартном WinAPI, почти вся ее
C>функциональность — это лишь достаточно тонкая обертка над виндовыми
C>вызовами. Только вот VCL пытается (плохо) скрыть свое родство с WinAPI,
C>а WTL использует это родство себе на выгоду.

>>>> Я ставлю проблемы.
>> C>Какие? Которых нет?
>> Для того, чтобы понять, что проблемы есть и проблемы серьезнейшие,
>> нужно принять определенную систему ценностей. После многих лет
>> программирования я принял систему ценностей Вирта и проповедую ее.

C>А, все понятно. Теоретик, оторванный от практики.

Это кто, Вирт, что ли? С его практикой может сравниться только практика Хайльсберга (и то с натяжкой). Стыдно этого не знать.
Re[19]: Почему настоящие программисты избегают C++
От: Cyberax Марс  
Дата: 28.02.05 17:56
Оценка:
d Bratik пишет:

> C>Ррррррррр..... Да _НИ_ _ОДНА_ распространенная GUI не дружит с
> C>многопоточностью по очень простой причине — ВСЕ они построены на
> C>концепции очереди сообщений (событий, сигналов). Но при этом _ЛЮБУЮ_
> C>современную GUI-систему можно использовать в многопоточной среде,
> приняв
> C>соответствующие меры.
> Тогда Вы может быть мне расскажите, какие меры нужно принять, чтобы
> организовать многопоточное рисование (требуется просто фоновое
> рисование двух картинок) в Qt-программе, работающей на Солярисе?

Рисовать картинки в разных потоках, передавать обновленные картинки в
GUI-тред, а в GUI-треде их показывать.

Кстати, рисование средствами какой библиотеки производится?

> Или под "соответствующими мерами" понимается также смена оконного
> менеджера, библиотеки графического вывода и операционной системы?

Нет, понимается синхронизация и маршаллирование вызовов.

> C>А, все понятно. Теоретик, оторванный от практики.
> Это кто, Вирт, что ли? С его практикой может сравниться только
> практика Хайльсберга (и то с натяжкой). Стыдно этого не знать.

Чего? Как практиков я уважаю: Кернигана и Ритчи (создателей языка С), Б.
Страуструпа, Алана Кея (с натяжкой) и многих других.

Вот Вирта в этом списке нет, так как я не помню хороших его практических
творений: Pascal годен только для обучения, Oberon не входит даже в
сотню самых распространенных языков, а Дельфи делалась и вовсе без Вирта
(наверное поэтому и получилось сравнительно удачной). Я не спорю, что
Вирт сделал много для развития теории (как и Дональд Кнут), но вот для
практики....

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re: Почему настоящие программисты избегают C++
От: Chez Россия  
Дата: 01.03.05 13:30
Оценка:
Здравствуйте, d Bratik, Вы писали:

Q Почему настоящие программисты избегают C++
A Потому что реальные перцы ваяют кульный софт исключительно в универсальной среде WinHex

Chez, ICQ#161095094

Posted via:RSDN@Home;version:1.1.3;muzikstamp:Ajattara — Naaras

Re[2]: Почему настоящие программисты избегают C++
От: AlexEagle Украина http://www.vik.oil
Дата: 01.03.05 14:42
Оценка:
Здравствуйте, Chez, Вы писали:

C>A Потому что реальные перцы ваяют кульный софт исключительно в универсальной среде WinHex

Да ну... скажешь еще! WinHex... Фу!.. Вот Far с DOS интерфейсом — это руль (и диагноз)
Re[15]: Почему настоящие программисты избегают C++
От: AlexEagle Украина http://www.vik.oil
Дата: 01.03.05 14:50
Оценка:
Здравствуйте, Кодт, Вы писали:

К>Монстр макропрограммирования!
От монстра слышу!

К>
К>class PatchFont : public LOGFONT
К>{
К>    ...
К>public:
К>  PatchFont(HWND hWnd=0) {HWND m_hwnd= hWnd;}

К>  bool take(UINT id, HWND hwnd=-1)
К>  {
К>    if(hwnd != -1) m_hwnd = hwnd; 
К>    m_id = id;
К>    ...
К>  }

К>......

К>PatchFont pf(hDlg);

К>pf.take(ID_ONE);
К>  pf.lfWeight = FW_BOLD;
К>pf.give();

К>pf.take(ID_TWO);
К>  pf.lfUnderline = TRUE;
К>pf.give();

К>
Re[16]: Почему настоящие программисты избегают C++
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.03.05 16:12
Оценка:
Здравствуйте, Kubera, Вы писали:

K>Нет, т.к. ты не ответил на мой вопрос. Я так и не понял в чём ты со мной не согласен. Спрошу по-другому:
K>Функция вычисления среднего арифметического не должна бросать исключений. Влад, ты согласен с этим утверждением? Да или нет?

Как по твоему a + b может вызвать переполнение?

Решения могут быть какие угодно. Но если фонкция содержит код способный привести к переполнению и переполнение не учитывается, то см. пре. отв.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[21]: Почему настоящие программисты избегают C++
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 02.03.05 05:04
Оценка:
Здравствуйте, d Bratik, Вы писали:

DB>Страуструп вообще ничего практического не сделал.

Распечатаю и повешу себе на стенку над рабочим местом.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>

SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[3]: Почему настоящие программисты избегают C++
От: Demiurg  
Дата: 02.03.05 07:37
Оценка:
Здравствуйте, AlexEagle, Вы писали:

C>>A Потому что реальные перцы ваяют кульный софт исключительно в универсальной среде WinHex

AE>Да ну... скажешь еще! WinHex... Фу!.. Вот Far с DOS интерфейсом — это руль (и диагноз)

Какой?
... << RSDN@Home 1.1.4 beta 4 303, 1995 — Krasnye List'ya>>
Re[4]: Почему настоящие программисты избегают C++
От: Pazak Россия  
Дата: 02.03.05 07:57
Оценка:
Здравствуйте, Demiurg, Вы писали:

AE>>Да ну... скажешь еще! WinHex... Фу!.. Вот Far с DOS интерфейсом — это руль (и диагноз)
D> Какой?

Здоров!
Ку...
Re[4]: Почему настоящие программисты избегают C++
От: AlexEagle Украина http://www.vik.oil
Дата: 02.03.05 09:28
Оценка:
Здравствуйте, Demiurg, Вы писали:

AE>>Да ну... скажешь еще! WinHex... Фу!.. Вот Far с DOS интерфейсом — это руль (и диагноз)

D> Какой?

Ну как же — Р Е А Л Ь Н Ы Й П Е Р Е Ц!
Re[5]: Почему настоящие программисты избегают C++
От: Demiurg  
Дата: 02.03.05 10:02
Оценка:
Здравствуйте, AlexEagle, Вы писали:

AE>>>Да ну... скажешь еще! WinHex... Фу!.. Вот Far с DOS интерфейсом — это руль (и диагноз)

D>> Какой?

AE>Ну как же — Р Е А Л Ь Н Ы Й П Е Р Е Ц!

А в чем заключается реальность перца, который пользуется ФАРом с "дос-интерфейсом"? Тем, что пользуется консольным интерейсом? Есть такая программка — QView, по-моему так она называется... Так вот это консольный (а вернее полноценный dos16 ) hex-редактор, который для меня гораздо круче чем всякие там WinHex'ы...
Так что я реальный перец!!!
... << RSDN@Home 1.1.4 beta 4 303, Ария — 2-Раскачаем этот мир>>
Re[5]: Почему настоящие программисты избегают C++
От: Кодт Россия  
Дата: 02.03.05 11:33
Оценка:
Здравствуйте, AlexEagle, Вы писали:

AE>Ну как же — Р Е А Л Ь Н Ы Й П Е Р Е Ц!

В смысле — x86 real mode перец?
Перекуём баги на фичи!
Re[6]: Почему настоящие программисты избегают C++
От: AlexEagle Украина http://www.vik.oil
Дата: 02.03.05 13:12
Оценка:
Здравствуйте, Кодт, Вы писали:

AE>>Ну как же — Р Е А Л Ь Н Ы Й П Е Р Е Ц!

К>В смысле — x86 real mode перец?

а то!
Re[6]: Почему настоящие программисты избегают C++
От: AlexEagle Украина http://www.vik.oil
Дата: 02.03.05 13:16
Оценка:
Здравствуйте, Demiurg, Вы писали:

D> А в чем заключается реальность перца, который пользуется ФАРом с "дос-интерфейсом"? Тем, что пользуется консольным интерейсом? Есть такая программка — QView, по-моему так она называется... Так вот это консольный (а вернее полноценный dos16 ) hex-редактор, который для меня гораздо круче чем всякие там WinHex'ы...
D> Так что я реальный перец!!!

Ты не реальный перец!!! Не льсти себе! Вот когда станешь программы ПИСАТЬ а не править в hex редакторе — тогда будешь перцем. Причем x86 real mode перцем
Re[7]: Почему настоящие программисты избегают C++
От: Demiurg  
Дата: 02.03.05 13:22
Оценка:
Здравствуйте, AlexEagle, Вы писали:

D>> А в чем заключается реальность перца, который пользуется ФАРом с "дос-интерфейсом"? Тем, что пользуется консольным интерейсом? Есть такая программка — QView, по-моему так она называется... Так вот это консольный (а вернее полноценный dos16 ) hex-редактор, который для меня гораздо круче чем всякие там WinHex'ы...
D>> Так что я реальный перец!!!

AE>Ты не реальный перец!!! Не льсти себе! Вот когда станешь программы ПИСАТЬ а не править в hex редакторе — тогда будешь перцем. Причем x86 real mode перцем

Сказано реальный — значит реальный! Мне лучше знать
... << RSDN@Home 1.1.4 beta 4 303, Раскачаем этот мир>>
Re[8]: Почему настоящие программисты избегают C++
От: AlexEagle Украина http://www.vik.oil
Дата: 02.03.05 13:25
Оценка:
Здравствуйте, Demiurg, Вы писали:

D> Сказано реальный — значит реальный! Мне лучше знать

Аргументы извольте батенька, а то все реальными станут!!!
Re[9]: Почему настоящие программисты избегают C++
От: Demiurg  
Дата: 02.03.05 13:32
Оценка:
Здравствуйте, AlexEagle, Вы писали:

D>> Сказано реальный — значит реальный! Мне лучше знать

AE>Аргументы извольте батенька, а то все реальными станут!!!

Не, вы все виртуальны, я вас через только янус и аську вижу. Для меня только я реален по-настоящему
... << RSDN@Home 1.1.4 beta 4 303, ARIA — Закат>>
Re[22]: Почему настоящие программисты избегают C++
От: d Bratik  
Дата: 03.03.05 13:58
Оценка:
Здравствуйте, Pazak, Вы писали:

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

DB>>Именно Виртом и его командой были придуманы и реализованы (в операционной системе Oberon) все самые лучшие технические идеи, которые спустя несколько десятилетий были внедрены в .NET:

P>Знающие люди поправят, но ИМХО...

DB>>высокоуровневый байт-код,

P>...был в smalltalk...

DB>>динамическая компиляция,

P>...была в smalltalk...

DB>>автоматическая сборка мусора,

P>...вроде тоже была.

Речь идет не об интерпретируемом байт-коде, а о промежуточном языке (Intermediate Language — IL) и динамической компиляции. Языки Lisp и Smalltalk по природе своей интерпретируемы. Сделать все это эффективно в императивном языке, на котором написать потом операционную систему удалось только Вирту и Ко.

DB>>Вирт собственноручно проектировал язык, программировал компилятор, операционную систему, графическую библиотеку визуальных компонентов и др. Проблема Вирта лишь в том, что он слишком сильно (на 20-30 лет) опередил свое время.
DB>>Кернигана и Ритчи — неплохие ребята, но до Вирта им как до луны. Да, они тоже делали язык, компилятор и операционную систему, поэтому их есть за что уважать (хотя все их творения уже давно морально устарели).
DB>>Страуструп вообще ничего практического не сделал.

P>Угу, вот только "морально устаревшие творения K&R+S" продолжают успешно применяться, а Виртовские "опредившие время" системы так и остались по большому счету на уровне "интересных для изучения". А разговор-то идет о практике.

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

P>Ты вот, например, сейчас под какой осью эту мессагу читаешь? Под Oberon-based или все-таки под написанными на С[++] виндами/линухом?

Ну и какое это имеет отношение к практическому программированию Страуструпа?

Кстати, Вы вот в Интернет на форумы ходите, а поди даже не знаете, что телефонные станции и спутники связи, через которые Ваш трафик идет, на Модуле-2 работают. И когда на самолете летите, не знает, что авионика тоже на Модуле-2 работает.

Что касается Oberon, то это был экспериментальный проект, на котором были откатаны идеи и который позволил потом сделать .NET. Не даром же все лучшие ученики Вирта давно наняты или спонсируются MS. Об учениках Страуструпа такого не скажешь (их вообще никогда не было).
Re[3]: Почему настоящие программисты избегают C++
От: _Obelisk_ Россия http://www.ibm.com
Дата: 03.03.05 14:09
Оценка:
Здравствуйте, AlexEagle, Вы писали:

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

C>>A Потому что реальные перцы ваяют кульный софт исключительно в универсальной среде WinHex

AE>Да ну... скажешь еще! WinHex... Фу!.. Вот Far с DOS интерфейсом — это руль (и диагноз)

Не, никаких Фаров. Только 

copy con: MyCoolProg.exe


Душа обязана трудиться! (с) Н.Заболоцкий.
Re[23]: Почему настоящие программисты избегают C++
От: Кодт Россия  
Дата: 03.03.05 14:19
Оценка:
Здравствуйте, d Bratik, Вы писали:

DB>Речь идет не об интерпретируемом байт-коде, а о промежуточном языке (Intermediate Language — IL) и динамической компиляции. Языки Lisp и Smalltalk по природе своей интерпретируемы. Сделать все это эффективно в императивном языке, на котором написать потом операционную систему удалось только Вирту и Ко.

Lisp может быть компилируемым. Smalltalk — тоже.
В самом простом виде, можно оттранслировать байткод в команды реального процессора.
Перекуём баги на фичи!
Re[23]: Почему настоящие программисты избегают C++
От: Cyberax Марс  
Дата: 03.03.05 14:22
Оценка:
d Bratik пишет:

> Речь идет не об интерпретируемом байт-коде, а о промежуточном языке
> (Intermediate Language — IL) и динамической компиляции.

Открою страшную тайну: байт код он не интерпретируемый, а комплириуемый!
Причем динамически. Причем первые исследования на тему IL и
JIT-компиляции появлились еще в 50-х годах, а первые реализации
JIT-компиляторов были в 60-х.

> Языки Lisp и Smalltalk по природе своей интерпретируемы. Сделать все
> это эффективно в императивном языке, на котором написать потом
> операционную систему удалось только Вирту и Ко.

Не надо свое невежество выставлять напоказ.... Интепретируемость и
императивность никак не связаны друг с другом, а Лисп-код может быть
вполне нормально JIT-скомпилирован.

> P>Угу, вот только "морально устаревшие творения K&R+S" продолжают
> успешно применяться, а Виртовские "опредившие время" системы так и
> остались по большому счету на уровне "интересных для изучения". А
> разговор-то идет о практике.
> Вот именно, разговор о практике, а не о популярности.

Так что у Вирта практичного-то? А?

> P>Ты вот, например, сейчас под какой осью эту мессагу читаешь? Под
> Oberon-based или все-таки под написанными на С[++] виндами/линухом?
> Ну и какое это имеет отношение к практическому программированию
> Страуструпа?

Такое, что язык, созданный им, используется в написании этих средств.

> Кстати, Вы вот в Интернет на форумы ходите, а поди даже не знаете, что
> телефонные станции и спутники связи, через которые Ваш трафик идет, на
> Модуле-2 работают. И когда на самолете летите, не знает, что авионика
> тоже на Модуле-2 работает.

ССЫЛКИ, ССЫЛКИ, ССЫЛКИ, ССЫЛКИ! Где? Вот уж не верю я, что на
коммерческих спутниках связи используется Модула-2. Знаю, что
используется Ада и С, про Модулу-2 не слышал.

> Что касается Oberon, то это был экспериментальный проект, на котором
> были откатаны идеи и который позволил потом сделать .NET. Не даром же
> все лучшие ученики Вирта давно наняты или спонсируются MS. Об учениках
> Страуструпа такого не скажешь (их вообще никогда не было).

Имена, фамилии, явки учеников Вирта, создавших .NET (точнее слизавших ее
архитектуру с Java) ....

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[4]: Почему настоящие программисты избегают C++
От: AlexEagle Украина http://www.vik.oil
Дата: 03.03.05 14:26
Оценка:
Здравствуйте, _Obelisk_, Вы писали:

_O_>Не, никаких Фаров. Только

_O_>
_O_>copy con: MyCoolProg.exe
_O_>


Про это я как-то не подумал Это уже диагнох реального перца в квадрате
Re[24]: Почему настоящие программисты избегают C++
От: AVC Россия  
Дата: 03.03.05 14:55
Оценка:
Здравствуйте, Cyberax, Вы писали:

>> Что касается Oberon, то это был экспериментальный проект, на котором
>> были откатаны идеи и который позволил потом сделать .NET. Не даром же
>> все лучшие ученики Вирта давно наняты или спонсируются MS. Об учениках
>> Страуструпа такого не скажешь (их вообще никогда не было).
C>Имена, фамилии, явки учеников Вирта, создавших .NET (точнее слизавших ее
C>архитектуру с Java) ....

Например, Шиперски (Szipersky) — один из основателей Oberon Microsystems.
Поправочка: именно Java слизана с Оберона.
По поводу того, как используется Оберон, см. хотя бы презентации, представленные на дне Оберона в ЦЕРНе:
http://cern.ch/oberon.day
Обратите внимание, например, на такие презентации
http://ftkachov.home.cern.ch/ftkachov/talks/ftkachov.pdf (использование Оберона в РАН)
http://www.amadeus-3.com/cern/background.pdf (тот самый Метцелер, в одиночку создавший множество программ для ряда крупнейших компаний: Du Pont, Deutsche Bank и т.д.)
Впрочем, сколько бы я не привел аргументов, Вы их проигнорируете, так как, по Вашему собственному признанию, Вы — фанат Си++.
Вообще-то, я думал, что пустые словопрения по поводу Оберона закончились.
Лично я перешел к практическому использованию этого языка. (DLL сейчас пишу именно на Обероне.)
Жизнь продолжает подбрасывать мне примеры, что Си++ снижает надежность программ и производительность программистов. Но если уж Си++ так нравится, то ради Бога — дело Ваше.

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

Хоар
Re[23]: Почему настоящие программисты избегают C++
От: Pazak Россия  
Дата: 03.03.05 15:01
Оценка:
Здравствуйте, d Bratik, Вы писали:

DB>Речь идет не об интерпретируемом байт-коде, а о промежуточном языке (Intermediate Language — IL) и динамической компиляции. Языки Lisp и Smalltalk по природе своей интерпретируемы. Сделать все это эффективно в императивном языке, на котором написать потом операционную систему удалось только Вирту и Ко.

Может потому, что остальным это просто на фиг не нужно было? Или 100% программистов начала 80-х были идиотами, раз не использовали "наиболее эффективную" технологию?

P>>Угу, вот только "морально устаревшие творения K&R+S" продолжают успешно применяться, а Виртовские "опредившие время" системы так и остались по большому счету на уровне "интересных для изучения". А разговор-то идет о практике.
DB>Вот именно, разговор о практике, а не о популярности.

Это и есть применение на практике.

P>>Ты вот, например, сейчас под какой осью эту мессагу читаешь? Под Oberon-based или все-таки под написанными на С[++] виндами/линухом?
DB>Ну и какое это имеет отношение к практическому программированию Страуструпа?

Такое, что одно дело — написать и поддерживать институтскую экспериментальную поделку (имея при этом гарантированный профессорский оклад и роту студентов в подчинении), и несколько другое — делать то же самое в рамках реального коммерческого проекта, где на доведение софта до идеала никто денег не выделит. После того, как c++ "пошел в массы" Страуструп потерял над ним влияние и, соответственно, ушел от самостоятельной его доработки в сторону консультаций и советов. Получи 20 лет назат такую же популярность оберон — глядишь на месте Бьярна мы бы увидели старину Вирта.
Ку...
Re[25]: Почему настоящие программисты избегают C++
От: Cyberax Марс  
Дата: 03.03.05 15:14
Оценка:
AVC пишет:

> C>Имена, фамилии, явки учеников Вирта, создавших .NET (точнее
> слизавших ее
> C>архитектуру с Java) ....
> Например, Шиперски (Szipersky) — один из основателей Oberon Microsystems.

И? Гугл выдает на нее 10000 ссылок, и даже сайта на английском у них нет.

> Поправочка: именно Java слизана с Оберона.

Java ни с чего не слизана — она весьма отличается от Оберона (одно лишь
наличие GC и системы пакетов — не признак слизанности).

> По поводу того, как используется Оберон, см. хотя бы презентации,
> представленные на дне Оберона в ЦЕРНе:
> http://cern.ch/oberon.day

Больше всего посмеялся над: "*Benchmark:* Component Pascal vs C++ in a
real-world physics problem"...

> Обратите внимание, например, на такие презентации
> http://ftkachov.home.cern.ch/ftkachov/talks/ftkachov.pdf
> (использование Оберона в РАН)
> http://www.amadeus-3.com/cern/background.pdf (тот самый Метцелер, в
> одиночку создавший множество программ для ряда крупнейших компаний: Du
> Pont, Deutsche Bank и т.д.)

Мы сейчас тоже создаем программы для Porsche и Du Pont. И что из этого?

> Впрочем, сколько бы я не привел аргументов, Вы их проигнорируете, так
> как, по Вашему собственному признанию, Вы — фанат Си++.

Я скорее антифанат Pascal-подобных языков...

Мне нравятся еще OCaml, Haskell и даже Java и C#.

> Вообще-то, я думал, что пустые словопрения по поводу Оберона закончились.
> Лично я перешел к практическому использованию этого языка. (DLL сейчас
> пишу именно на Обероне.)
> Жизнь продолжает подбрасывать мне примеры, что Си++ снижает надежность
> программ и производительность программистов. Но если уж Си++ *так*
> нравится, то ради Бога — дело Ваше.

У меня примеры обратные — где всякие экзотические "надежные" языки типа
Python'а валили проект.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[26]: Почему настоящие программисты избегают C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 03.03.05 15:27
Оценка:
Здравствуйте, Cyberax, Вы писали:



C>Java ни с чего не слизана — она весьма отличается от Оберона (одно лишь
C>наличие GC и системы пакетов — не признак слизанности).

GC + JIT это основа манагед сред. Все остальное это сахар.

C>Я скорее антифанат Pascal-подобных языков...

C>Мне нравятся еще OCaml, Haskell и даже Java и C#.

И чем они тебе не угодили. С# и Delphi (не смотря на единого создателя) больше похожи друг на друга, чем на С/С++.
При этом миграция на Net у Delphi прошла очень гладко.
Все таки Виртовская концепции больше претворились в манагед средах (Оберон одна из них)
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Re[7]: Почему настоящие программисты избегают C++
От: transglucator  
Дата: 04.03.05 07:01
Оценка:
жена — Pascal
проститутка — C++
любовница — ?
Re[27]: Почему настоящие программисты избегают C++
От: Pazak Россия  
Дата: 04.03.05 07:56
Оценка:
Здравствуйте, AVC, Вы писали:

C>>У меня примеры обратные — где всякие экзотические "надежные" языки типа
C>>Python'а валили проект.
AVC>А что, Python — надежный язык?
AVC>Я просто не в курсе.

Имелось в виду, наверное, отсутствие адресной арифметики и наличие GC.
Ку...
Re[16]: Почему настоящие программисты избегают C++
От: vog Россия [реклама удалена модератором]
Дата: 04.03.05 08:54
Оценка:
Здравствуйте, alnsn, Вы писали:

K_O>>The internal SRI software exception was caused during execution of a data conversion from 64-bit floating point to 16-bit signed integer value. The floating point number which was converted had a value greater than what could be represented by a 16-bit signed integer. This resulted in an Operand Error. The data conversion

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

Господа, о каких там ексепшенах вы говорите? Чисто логически, это какой-то 16-разрядник, вот и потребовалост это дурацкое преобразование, а еще может быть мРС, работающая под ДОС. Ну или что-то вроде того. Там же все очень консервативно, один раз сработало, так и будут ставить до следующей аварии. Все-таки эксепшены реализуются операционкой, а не языком.
[реклама удалена модератором]
Re[14]: Почему настоящие программисты избегают C++
От: Andrew.Kroupa  
Дата: 05.03.05 22:13
Оценка:
Здравствуйте, ansi, Вы писали:

A>
A>int a = 10;
A>(&a)[a&a+~(a|a)+1])=*(&a+(a&~a)*(a^a)*(~(int)&a-(0xFFFFFFFF–(int)&a)));
A>

А так?
int a = 10;
a = a;

Re[16]: Почему настоящие программисты избегают C++
От: VladD2 Российская Империя www.nemerle.org
Дата: 06.03.05 04:33
Оценка:
Здравствуйте, _Obelisk_, Вы писали:

The Windows Runtime on UNIX includes an extensive set of Microsoft technologies such as MSXML, SSL, MSHTML, WinSock, COM/DCOM and ATL. These are based on the original Microsoft implementation, tuned for UNIX by Mainsoft.


Нда, за бабки можно и из Линя Вынь сделать.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Почему настоящие программисты избегают C++
От: ansi  
Дата: 06.03.05 05:24
Оценка:
Здравствуйте, Andrew.Kroupa, Вы писали:
A>>
A>>int a = 10;
A>>(&a)[a&a+~(a|a)+1]=*(&a+(a&~a)*(a^a)*(~(int)&a-(0xFFFFFFFF–(int)&a)));
A>>

AK>А так?
AK>
AK>int a = 10;
AK>a = a;
AK>

AK>
Тогда уж так:
int a = 10;

Но дело в том, что тогда вся фишка пропадает
Re[27]: Почему настоящие программисты избегают C++
От: Cyberax Марс  
Дата: 06.03.05 11:39
Оценка:
AVC пишет:

> C>Java ни с чего не слизана — она весьма отличается от Оберона (одно лишь
> C>наличие GC и системы пакетов — не признак слизанности).
> Не только GC.
> Я просто беру и сопоставляю конструкции Оберона и Java.
> Почти один в один!
> В Си++ есть объединения (union). В Обероне — нет. В Java — тоже нет.

В С++ есть много того, чего нет в Java.

> Применение instanceof в Java — полная копия Обероновского IS.

Оно еще в лиспе было

> И так с десяток заимствованных свойств, причем самых важных,
> существенных, деляющих Java "надежным языком".
> Дома где-то пылится список "случайных совпадений".
> Я когда разбирался с этим вопросом, просто взял и сопоставил
> конструкции языков.
> И все стало ясно.

Оберон отличается от Явы очень сильно: в Обероне нет системы интефейсов,
наследование работает слегка по-другому, конструкторы работают не так.

Явно видные мне следы Оберона: систем пакетов и GC. Но похожая система
пакетов есть и в Аде, а GC ко времени создания Явы был уже в куче языков.

> C>Больше всего посмеялся над: "*Benchmark:* Component Pascal vs C++ in a
> C>real-world physics problem"...
> Ну что же, давайте посмеемся вместе.
> Когда-то Вы уверяли, что сами видели компилятор Си++, умещающийся в
> 20K. Вы и сейчас будете это утверждать?

Такого я нигде ну утверждал. Можно ссылку на мои слова?

> В конце 90-х по результатам тестов компилятор XDS обскакал *все*
> компиляторы Си++.

Из-за чего, интересно? Есть подозрение, что XDS выполнял анализ
aliasing'ов, который только недавно появился в компиляторах С++.

> В лаборатории CERN [26], начиная с 1994 была сделана попытка создать
> стандартную платформу для программирования на основе C++ в рамках
> мега-проекта LHC (Large Hadron Collider — Большой Адронный Коллайдер;
> 2006-2020).
> Нет нужды объяснять, что C++ не может обеспечить решение перечисленных
> выше проблем из-за критических дефектов дизайна и экстравагантной
> сложности. В коллективах физиков даже имели место конфликты по поводу
> C++, и ряд специалистов не спешит переключаться на чрезмерно сложный
> C++, предпочитая пока оставаться с фортраном. Фактический провал C++
> иллюстрируется разработанной в CERN библиотекой ROOT для анализа и
> визуализации данных [18]; библиотека, написанная на C++, печально
> известна своей способностью генерировать фатальные ошибки.[3]

Ну не смогли ученые договориться, и что? Я вот вижу перед собой
библиотеку VTK для визуализации научной графики. Замечательная вещь —
написана на С++.

> Во время дискуссии об Обероне я приводил ряд "багов" прямо "с места
> происшествия".
> С тех пор их количество возрасло.
>>> Обратите внимание, например, на такие презентации
>>> http://ftkachov.home.cern.ch/ftkachov/talks/ftkachov.pdf
>>> (использование Оберона в РАН)

Я долго над ней смеялся.

>>> http://www.amadeus-3.com/cern/background.pdf (тот самый Метцелер, в
>>> одиночку создавший множество программ для ряда крупнейших компаний: Du
>>> Pont, Deutsche Bank и т.д.)
> C>Мы сейчас тоже создаем программы для Porsche и Du Pont. И что из этого?
> Разница в том, что у Вас — "мы", а там человек может сказать — "я".

_Я_ один тоже могу писать весь проект без проблем. Только времени это
займет больше.

> C>Я скорее антифанат Pascal-подобных языков...
> C>Мне нравятся еще OCaml, Haskell и даже Java и C#.
> Java и C# идут по стопам Оберона.
> Значит ли это, что Вам просто не нравится присать BEGIN и END?

Я просто НЕ вижу в Обероне передовых идей, даже для 80-х годов. ООП в
нем недоделаный, синтаксис ужасный, а втроенная поддержка ассемблерных
вставок кажется издевательством. Мне Оберон напоминает салат, куда
намешано куча всего, но не продумано их взаимодействие. Как, например,
заPin'ить указатель при работе с ним из ассемблера?

> C>У меня примеры обратные — где всякие экзотические "надежные" языки типа
> C>Python'а валили проект.
> А что, Python — надежный язык?
> Я просто не в курсе.

Да, так же как и Оберон. Он выполняется на виртуальной машине, в нем нет
указателей и т.п.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[28]: Почему настоящие программисты избегают C++
От: AVC Россия  
Дата: 06.03.05 21:47
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>AVC пишет:

>> C>Больше всего посмеялся над: "*Benchmark:* Component Pascal vs C++ in a
>> C>real-world physics problem"...
>> Ну что же, давайте посмеемся вместе.
>> Когда-то Вы уверяли, что сами видели компилятор Си++, умещающийся в
>> 20K. Вы и сейчас будете это утверждать?

C>Такого я нигде ну утверждал. Можно ссылку на мои слова?

Извольте:
http://www.rsdn.ru/Forum/Message.aspx?mid=994845&amp;only=1
Автор: Cyberax
Дата: 19.01.05

Вот Ваше утверждение:

А простой неоптимизирующий компилятор в нейтив на С++ пишется где-то
килобайт в 20 кода (сам видел).

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

Хоар
Re[29]: Почему настоящие программисты избегают C++
От: Cyberax Марс  
Дата: 07.03.05 09:38
Оценка:
AVC пишет:

>>> Ну что же, давайте посмеемся вместе.
>>> Когда-то Вы уверяли, что сами видели компилятор Си++, умещающийся в
>>> 20K. Вы и сейчас будете это утверждать?
> C>Такого я нигде ну утверждал. Можно ссылку на мои слова?
> Извольте:
> http://www.rsdn.ru/Forum/Message.aspx?mid=994845&amp;only=1
Автор: Cyberax
Дата: 19.01.05
> <http://rsdn.ru/Forum/Message.aspx?mid=994845&amp;only=1&gt;
Автор: Cyberax
Дата: 19.01.05

> Вот Ваше утверждение:
> А простой неоптимизирующий компилятор в нейтив на С++ пишется где-то
> килобайт в 20 кода (сам видел).

Это иллюстрация принципа "Если что-то можно понять неправильно — то это
будет понято неправильно" Я в той фразе сказал, что НА С++ можно
_написать_ компилятор в нэйтивный код, причем он будет размером килобайт
в 20 кода.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[3]: Почему настоящие программисты избегают C++
От: retn нет
Дата: 09.03.05 12:01
Оценка:
Здравствуйте, d Bratik, Вы писали:

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

Да ты юморист из Аншлага.

Блин спасибо тебе , было плохое настроение и голова разболелась,
прочитал некоторые твои посты и от доброго смеха всё прошло, а ведь ничего не помогало.

Тут еще в Железе один из учередителей АМД обясняет всем что такое Интел и всех несогласных кличет на рукопашную, во блин неделька.
... << RSDN@Home 1.1.4 beta 4 rev. 350>>
Re[30]: Почему настоящие программисты избегают C++
От: AVC Россия  
Дата: 09.03.05 13:34
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>AVC пишет:
>>>> Ну что же, давайте посмеемся вместе.
>>>> Когда-то Вы уверяли, что сами видели компилятор Си++, умещающийся в
>>>> 20K. Вы и сейчас будете это утверждать?
>> C>Такого я нигде ну утверждал. Можно ссылку на мои слова?
>> Извольте:
>> http://www.rsdn.ru/Forum/Message.aspx?mid=994845&amp;only=1
Автор: Cyberax
Дата: 19.01.05
>> <http://rsdn.ru/Forum/Message.aspx?mid=994845&amp;only=1&gt;
Автор: Cyberax
Дата: 19.01.05

>> Вот Ваше утверждение:
>> А простой неоптимизирующий компилятор в нейтив на С++ пишется где-то
>> килобайт в 20 кода (сам видел).

C>Это иллюстрация принципа "Если что-то можно понять неправильно — то это
C>будет понято неправильно" Я в той фразе сказал, что НА С++ можно
C>_написать_ компилятор в нэйтивный код, причем он будет размером килобайт
C>в 20 кода.

Выражайтесь яснее, если хотите быть правильно понятым.
Пока что, ИМХО, Вам это не очень удается.
Вы утверждаете, что я неправильно Вас понял. (И, ясное дело, я же и виноват. Ловко, конечно. Но не слишком честно.)
А я вот вижу, что Вы просто пытаетесь выкрутиться из неловкого положения (в котором, кстати, нет ничего страшного: все мы иногда что-нибудь ляпнем не подумав; потом извиняемся), и пытаетесь все "свалить с больной головы на здоровую".
Смысл Вашей последней фразы вообще темен.
Что значит — "на C++ можно написать компилятор в неэйтивный код, причем он будет размером килобайт в 20 кода"?
Компилятор — для какого языка программирования? Для какого процессора?
Если для самого C++ и для IBM PC, то это, несомненно, шутка или вранье.
Кроме того, я что-то не пойму: можно (в принципе) написать, или Вы сами видели этот компилятор, как изначально утверждалось.

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

Хоар
Re[5]: Почему настоящие программисты избегают C++
От: AlexEagle Украина http://www.vik.oil
Дата: 09.03.05 16:28
Оценка:
Здравствуйте, d Bratik, Вы писали:

DB>Это было бы смешно, если бы не было так грустно... У меня одна надежда — что MS, вылечившись сама, вылечит и других. Только вес такой фирмы может быть противопоставлен [i]снобизму программистов на С++[/i].

так вот где корень зла...
Re[25]: Почему настоящие программисты избегают C++
От: AVC Россия  
Дата: 13.03.05 12:09
Оценка:
AVC>Вот ссылка:
AVC>http://www.inr.ac.ru/~info21/info/koltashev.jpg

На всякий случай добавлю, что упомянутые ребята из "Эксельсиор" и создали компилятор XDS.

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

Хоар
Re[27]: Почему настоящие программисты избегают C++
От: 4ertus2  
Дата: 13.03.05 15:40
Оценка:
Здравствуйте, AVC, Вы писали:

AVC>

AVC>Нет нужды объяснять, что C++ не может обеспечить решение перечисленных выше проблем из-за критических дефектов дизайна и экстравагантной сложности.
От чего же? Хотелось бы послушать.

AVC>

В коллективах физиков даже имели место конфликты по поводу C++, и ряд специалистов не спешит переключаться на чрезмерно сложный C++, предпочитая пока оставаться с фортраном.


Ну уж если специалисты не переключаются, то куда уж нам смертным. Впрочем, можно поговорить на чем пишут программы биологи или мастера слесарного дела.
Непривязанное к форме вечно.
Re[5]: Почему настоящие программисты избегают C++
От: 4ertus2  
Дата: 13.03.05 16:26
Оценка:
Здравствуйте, d Bratik, Вы писали:

DB>Это было бы смешно, если бы не было так грустно... У меня одна надежда — что MS, вылечившись сама, вылечит и других. Только вес такой фирмы может быть противопоставлен снобизму программистов на С++.

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

Отказаться сегодня от С++ — значит отказаться от огромной базы исходников (в том числе и открытых). Опять же, весь разговор проходит на ЯВУ и из предположения что продукт должен работать сносно. Вполне возможны ситуации, когда вашему приложению мешают работать нормалльно: переполняют все, что только можно, инжектируют всякие гадости. И вы предлагаете пересаживаться на неизвестную технологию только ради "концепции Вирта"?
Непривязанное к форме вечно.
Re[28]: Почему настоящие программисты избегают C++
От: AVC Россия  
Дата: 14.03.05 13:06
Оценка:
Здравствуйте, 4ertus2, Вы писали:

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

AVC>>

AVC>>Нет нужды объяснять, что C++ не может обеспечить решение перечисленных выше проблем из-за критических дефектов дизайна и экстравагантной сложности.
4>От чего же? Хотелось бы послушать.

Вы, наверное, в первый раз заглянули на форум?
"Тяжелые бои" между "оберонщиками" и "Си++никами" шли долго и уже окончились.
Как следствие, лично я стал писать не только на Си++, но и на Обероне.
Но каждый, конечно, делает выводы сам.

Если Вам интересно, приведу несколько ссылок на "отголоски былых сражений".
http://www.rsdn.ru/Forum/Message.aspx?mid=889124&amp;only=1
Автор: AVC
Дата: 08.11.04

http://www.rsdn.ru/Forum/Message.aspx?mid=899918&amp;only=1
Автор: AVC
Дата: 15.11.04

http://www.rsdn.ru/Forum/Message.aspx?mid=960464&amp;only=1
Автор: AVC
Дата: 22.12.04

http://www.rsdn.ru/Forum/Message.aspx?mid=994706&amp;only=1
Автор: AVC
Дата: 19.01.05

http://www.rsdn.ru/Forum/Message.aspx?mid=1013678&amp;only=1
Автор: AVC
Дата: 07.02.05

(Я там допустил неточность в комментарии. operator bool() не проверял "валидность", а сравнивал число с нулем. )
http://www.rsdn.ru/Forum/Message.aspx?mid=1017841&amp;only=1
Автор: AVC
Дата: 09.02.05

http://www.rsdn.ru/Forum/Message.aspx?mid=1017887&amp;only=1
Автор: AVC
Дата: 10.02.05

http://www.rsdn.ru/Forum/Message.aspx?mid=1030289&amp;only=1
Автор: AVC
Дата: 16.02.05

http://www.rsdn.ru/Forum/Message.aspx?mid=1030546&amp;only=1
Автор: Павел Кузнецов
Дата: 17.02.05

http://www.rsdn.ru/Forum/Message.aspx?mid=1031642&amp;only=1
Автор: Kh_Oleg
Дата: 17.02.05

http://www.rsdn.ru/Forum/Message.aspx?mid=1030506#1030506
Автор: AVC
Дата: 17.02.05


Вот мнение астрономов, авторов книги "Астрономия на персональном компьютере":

Здесь надо сказать, что по сравнению с другими языками C++ имеет много недостатков, которые затрудняют разработку сложных научных программ. В частности, у него слабая поддержка одномерных и многомерных массивов, нет локальных процедур, неудачная концепция модуля, не поддерживается проверка индексов массивов, а также выполняется неконтролируемое преобразование типов.


AVC>>

4>В коллективах физиков даже имели место конфликты по поводу C++, и ряд специалистов не спешит переключаться на чрезмерно сложный C++, предпочитая пока оставаться с фортраном.


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

Наверное, это была попытка пошутить?

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

Хоар
Re[29]: Почему настоящие программисты избегают C++
От: 4ertus2  
Дата: 14.03.05 13:29
Оценка:
Здравствуйте, AVC, Вы писали:

AVC>Наверное, это была попытка пошутить?

Какие уж тут шутки, когда такая тема обсуждается!
Непривязанное к форме вечно.
Re[30]: Почему настоящие программисты избегают C++
От: AVC Россия  
Дата: 14.03.05 13:57
Оценка:
Здравствуйте, 4ertus2, Вы писали:

AVC>>Наверное, это была попытка пошутить?
4>Какие уж тут шутки, когда такая тема обсуждается!

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

Хоар
Re[7]: Почему настоящие программисты избегают C++
От: AVC Россия  
Дата: 14.03.05 14:22
Оценка:
4>>Отказаться сегодня от С++ — значит отказаться от огромной базы исходников (в том числе и открытых). Опять же, весь разговор проходит на ЯВУ и из предположения что продукт должен работать сносно. Вполне возможны ситуации, когда вашему приложению мешают работать нормалльно: переполняют все, что только можно, инжектируют всякие гадости. И вы предлагаете пересаживаться на неизвестную технологию только ради "концепции Вирта"?
AVC>Как раз "концепция Вирта" и позволяет бороться с такими "гадостями".
AVC>Хотя никакой отдельной "концепции Вирта", ИМХО, не существует.
AVC>А существует старая добрая школа структурного программирования (Дейкстра, Хоар, Вирт и т.д.)
AVC>Что же касается "отказа от базы исходников", то это старый и сомнительный аргумент.
AVC>Например, у меня коды на Си++ и Обероне работают совместно и даже дружно.

Вот Microsoft не боится "начать с чистого листа".
Читаю интервью Хейлсберга (автора Турбо Паскаля и C#):

Хейлсберг: Во-первых с С# у нас была возможность начать все с чистого листа. У нас не было обязательств обратной совместимости, и это действительно сильно упрощало ситуацию. Даже не с точки зрения реализации, а с точки зрения использования. Например, мы имеем один вид классов в C#, и он может подвергаться сборке мусора. С++, напротив, имеет два, так как он придерживается стиля отсутствия сборки мусора. Так C# имеет несколько простых концепций которые вы понимаете.

Я уж было обрадовался.
Однако, в этом же интервью Хейлсберг говорит:

Одно из ключевых отличий С# от других языков, в частности Java, в том, что мы пытались как можно больше приблизиться к C++. C# наследует большинство операторов, ключевых слов и выражений напрямую из С++.

Вот и пойми их загадочные неславянские души...

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

Хоар
Re[8]: Почему настоящие программисты избегают C++
От: Pazak Россия  
Дата: 14.03.05 16:51
Оценка:
Здравствуйте, AVC, Вы писали:

AVC>Как раз на тему переполнений и прочей "гадости".
AVC>См. страничку:
AVC>http://www.inr.ac.ru/~info21/blackbox/disciplina/arr_bounds_checks.htm
AVC>Вот выдержка:

Вопрос: Что мешает Майкрософт компилировать Windows XP с включенной опцией контроля выхода за границы массивов?
AVC>Ответ: Неадкватность языков и компиляторов, использованных в написании операционной системы (C и C++).
Плохому танцору... Кстати интересно, неужели в MS не нашлось ни одного человека, знаюцего про Оберон? Сомневаюсь... Видать показался еще более "неадекватным".
Ку...
Re[9]: Почему настоящие программисты избегают C++
От: AVC Россия  
Дата: 14.03.05 17:34
Оценка:
Здравствуйте, Pazak, Вы писали:

AVC>>Как раз на тему переполнений и прочей "гадости".
AVC>>См. страничку:
AVC>>http://www.inr.ac.ru/~info21/blackbox/disciplina/arr_bounds_checks.htm
AVC>>Вот выдержка:

Вопрос: Что мешает Майкрософт компилировать Windows XP с включенной опцией контроля выхода за границы массивов?
AVC>>Ответ: Неадкватность языков и компиляторов, использованных в написании операционной системы (C и C++).
P>Плохому танцору... Кстати интересно, неужели в MS не нашлось ни одного человека, знаюцего про Оберон? Сомневаюсь... Видать показался еще более "неадекватным".

Угу. Показался настолько неадекватным, что Microsoft начала настоящую "охоту" на "оберонщиков".
Для разработки платформы .NET в Microsoft был привлечен Шиперски (соучредитель Oberon Microsystems).
Были наняты несколько сотрудников XDS (все-таки компилятор их "зацепил". ).
Среди представленных летом 2000г. 12 компиляторов для .NET было 2 Оберона: Oberon-2 и Component Pascal. (Поговаривают, что только они и работали без ошибок. )
Microsoft спонсирует проект Zonnon для .NET (развитие Active Oberon).
Вот настолько "неадекватным" показался Оберон Майкрософту.
Что же касается "плохих танцоров"...
Уже говорилось, что программисты на Си++ — снобы и зазнайки.
Разве неверно говорилось?

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

Хоар
Re[8]: Почему настоящие программисты избегают C++
От: Cyberax Марс  
Дата: 14.03.05 17:46
Оценка:
AVC пишет:

> Как раз на тему переполнений и прочей "гадости".
> См. страничку:
> http://www.inr.ac.ru/~info21/blackbox/disciplina/arr_bounds_checks.htm
> <http://www.inr.ac.ru/%7Einfo21/blackbox/disciplina/arr_bounds_checks.htm&gt;
> Вот выдержка:
> *Вопрос:* Что мешает Майкрософт компилировать Windows XP с включенной
> опцией контроля выхода за границы массивов?

Ничего. Собственно, в WinXP SP2 так и сделали.

> *Ответ:* Неадкватность языков и компиляторов, использованных в
> написании операционной системы (C и C++).

Ответ неверный. Мешает неполная совместимость получившегося бинарного API.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[9]: Почему настоящие программисты избегают C++
От: AVC Россия  
Дата: 17.03.05 11:03
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>AVC пишет:

>> Как раз на тему переполнений и прочей "гадости".
>> См. страничку:
>> http://www.inr.ac.ru/~info21/blackbox/disciplina/arr_bounds_checks.htm
>> <http://www.inr.ac.ru/%7Einfo21/blackbox/disciplina/arr_bounds_checks.htm&gt;
>> Вот выдержка:
>> *Вопрос:* Что мешает Майкрософт компилировать Windows XP с включенной
>> опцией контроля выхода за границы массивов?

C>Ничего. Собственно, в WinXP SP2 так и сделали.

Что, опять?
На упомянутой страничке
http://www.inr.ac.ru/~info21/blackbox/disciplina/arr_bounds_checks.htm
было сообщение о попытке "номер раз":

Сообщениями о таких атаках пестрят новостные ленты компьютерного мира. Например, вспомним одну поучительную историю. В августе 2001 г. вице-президент Майкрософт Джим Олчин (Jim Allchin) объявил во время доклада на открытии конференции Intel Developers Forum в Сан Хосе, что в новой операционной системе Windows XP все возможные проблемы из разряда переполнение буфера были устранены посредством специального анализа исходных текстов на предмет безопасности (security audit). Но в декабре того же года была найдена "дыра" в одной из программ в составе Windows XP (в программах поддержки стандарта подключения внешних устройств Universal Plug and Play) — причем дыра оказалась именно из категории переполнение буфера.


>> *Ответ:* Неадкватность языков и компиляторов, использованных в
>> написании операционной системы (C и C++).

C>Ответ неверный. Мешает неполная совместимость получившегося бинарного API.

Можно поконкретней?
Что с чем несовместимо?

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

Хоар
Re[10]: Почему настоящие программисты избегают C++
От: _doctor Финляндия http://agilesoftwaredevelopment.com
Дата: 19.03.05 21:32
Оценка:
Здравствуйте, nixite, Вы писали:

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. я решение знаю, но не сказал бы что оно простое 

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

Чем так сложно-то?
Только теперь это не для всех signed int'ов будет работать
Если серьёзно, то отсутствие проверок на переполнение или написания заведомо безопасного кода, который понадобится только в редких случаях очень больших чисел — это обычная дилемма выбора между временем (и разработки и выполнения) и качеством.

В конце-концов, если у программиста не хватило ума/времени усмотреть опасность в "return (a+b)/2;", то вряд ли он предусмотрит корректную обработку OverflowException
Chief Software Engineer,
Scrum Master, Symbian
Re[11]: Почему настоящие программисты избегают C++
От: ansi  
Дата: 20.03.05 07:23
Оценка:
Здравствуйте, _doctor, Вы писали:

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

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. я решение знаю, но не сказал бы что оно простое

_>
_>int kaka (int a, int b) {
_>  return b + (a-b)/2;
_>}
_>

_>Чем так сложно-то?
_>Только теперь это не для всех signed int'ов будет работать
_>Если серьёзно, то отсутствие проверок на переполнение или написания заведомо безопасного кода, который понадобится только в редких случаях очень больших чисел — это обычная дилемма выбора между временем (и разработки и выполнения) и качеством.

_>В конце-концов, если у программиста не хватило ума/времени усмотреть опасность в "return (a+b)/2;", то вряд ли он предусмотрит корректную обработку OverflowException

Вообще дурацкий пример — на каждом языке на одной платформе он будет вести себя одинаково, если только язык не предоставляет более-менее полной абстракции от архитектуры (т.е. не ограничивает числа разрядностью процессора). Хотя, выглядит конечно симпатично:
int kaka(int a, int b) {
   try {
      return (a+b)/2;
   } catch (OverflowException) {
      return b + (a-b)/2;
   }
}

Но только выглядит
Re[8]: Почему настоящие программисты избегают C++
От: AVC Россия  
Дата: 21.03.05 13:15
Оценка:
Здравствуйте, 4ertus2, Вы писали:

4>Я без сомнения чайник

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

4>и, как мне тут объяснили, сноб (что бы это слово значило),

Во-первых, на тот случай, если смысл слова неясен, существуют словари.
Во-вторых, я имел в виду тех программистов на Си++ (многих), с которыми тесно общался долгие годы, и кого я хорошо знаю. Причем, называя их "снобами", я уж никак не хочу их обидеть (я говорю о своих приятелях, и они с радостью бы подтвердили мои слова — на все другие языки они смотрят "свысока").
Так что я назвал "снобом" не Вас, хотя меня и удивила Ваша фраза:

Впрочем, можно поговорить на чем пишут программы биологи или мастера слесарного дела.


4>Язык программирования — это прежде всего язык общения, а уже потом технология. С-подобный синтаксис — лучший придуманняй на данный момент (или это тоже спорный вопрос?).

Раз существуют разные точки зрения, этот вопрос, видимо, надо считать спорным.
Если Вы спросите мое личное мнение, то я предпочитаю синтаксис Модулы-2 и Оберона.
Во-первых, он лучше (ИМХО) читается и понимается. (И это несмотря на то, что я почти 20 лет пишу преимущественно на Си и (с начала 90-х) на Си++!)
Во-вторых, грамматика Модулы-2 (и Оберона) позволяет быстрее находить ошибки (многих из них вообще избежать) и больше способствуют оптимизации кода (за счет приводимости графов — подробности в "красном драконе" Ахо, Сети и Ульмана).

4>Поддержка любого другого синтаксиса — маркетинговая необходимость всем понятно каких фирм.

Каких?
Вот когда Sun передрала Оберон, но использовала Си-подобный синтаксис, — это маркетинговый ход.
А какие фирмы Вы имеете в виду?

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

Хоар
Re[9]: Почему настоящие программисты избегают C++
От: Шахтер Интернет  
Дата: 22.03.05 03:26
Оценка:
Здравствуйте, AVC, Вы писали:

AVC>Раз существуют разные точки зрения, этот вопрос, видимо, надо считать спорным.
AVC>Если Вы спросите мое личное мнение, то я предпочитаю синтаксис Модулы-2 и Оберона.
AVC>Во-первых, он лучше (ИМХО) читается и понимается. (И это несмотря на то, что я почти 20 лет пишу преимущественно на Си и (с начала 90-х) на Си++!)
AVC>Во-вторых, грамматика Модулы-2 (и Оберона) позволяет быстрее находить ошибки (многих из них вообще избежать) и больше способствуют оптимизации кода (за счет приводимости графов — подробности в "красном драконе" Ахо, Сети и Ульмана).

Вы, очевидно, невнимательно читали книгу. Там же ясно, черным по белому написано:
"Использование только структурированных конструкций управления потоком, таких как if-then-else, while-do, continue и break, приводит к программам, графы потоков которых всегда приводимы".
В реальности, это не проблема в C/C++, поскольку использование goto (или switch для прыжка внуть цикла) в нормально написаных программах есть вещь исключительная.
И вообще -- чем больше возможностей, тем больше возможностей и для написания эффективного кода.
... << RSDN@Home 1.1.3 stable >>
В XXI век с CCore.
Копай Нео, копай -- летать научишься. © Matrix. Парадоксы
Re[10]: Почему настоящие программисты избегают C++
От: AVC Россия  
Дата: 22.03.05 11:54
Оценка:
Здравствуйте, Шахтер, Вы писали:

AVC>>Раз существуют разные точки зрения, этот вопрос, видимо, надо считать спорным.
AVC>>Если Вы спросите мое личное мнение, то я предпочитаю синтаксис Модулы-2 и Оберона.
AVC>>Во-первых, он лучше (ИМХО) читается и понимается. (И это несмотря на то, что я почти 20 лет пишу преимущественно на Си и (с начала 90-х) на Си++!)
AVC>>Во-вторых, грамматика Модулы-2 (и Оберона) позволяет быстрее находить ошибки (многих из них вообще избежать) и больше способствуют оптимизации кода (за счет приводимости графов — подробности в "красном драконе" Ахо, Сети и Ульмана).

Ш>Вы, очевидно, невнимательно читали книгу. Там же ясно, черным по белому написано:
Ш>"Использование только структурированных конструкций управления потоком, таких как if-then-else, while-do, continue и break, приводит к программам, графы потоков которых всегда приводимы".

Действительно, использование только указанных конструкций гарантирует приводимость потоков графов.
В чем именно проявилась моя невнимательность?

Ш>В реальности, это не проблема в C/C++, поскольку использование goto (или switch для прыжка внуть цикла) в нормально написаных программах есть вещь исключительная.

Одно дело, когда оператора goto вообще нет в языке (как в Модуле-2 и Обероне).
И совсем другое, когда он просто редко используется.
В первом случае возможна синтаксически управляемая оптимизация, во втором — приходится дополнительно анализировать графы потоков управления.

Ш>И вообще -- чем больше возможностей, тем больше возможностей и для написания эффективного кода.

ИМХО, как раз наоборот — тем больше возможностей написать неэффективный код.

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

Хоар
Re[9]: Почему настоящие программисты избегают C++
От: AVC Россия  
Дата: 22.03.05 12:29
Оценка:
Здравствуйте, Михаил, Вы писали:

AVC>>Как раз на тему переполнений и прочей "гадости".
AVC>>См. страничку:
AVC>>http://www.inr.ac.ru/~info21/blackbox/disciplina/arr_bounds_checks.htm
AVC>>Вот выдержка:

Вопрос: Что мешает Майкрософт компилировать Windows XP с включенной опцией контроля выхода за границы массивов?
AVC>>Ответ: Неадкватность языков и компиляторов, использованных в написании операционной системы (C и C++).

 М>Представь себе, случилось. Вся операционка (драйвера, ядро, утилиты — все-все) переписана на свервысоконадежном языке. Попробуй оценить, сколько тысяч раз в секунду будет выполняться проверка выхода счетчика за свои границы, правильности строки и т.п. Там много чего придется ежесекундно проверять!
М>В твоем любимом компиляторе тоже все счетчики сначала сами проверятся, а потом уже до твоих доберутся.
М>И можно развить идею. Зачем тормозить на полпути?
М>Во всех деревьях также необходимо проверять, что ветки указывают на правильный адрес, а не куда попало. Также обязательно следить, чтобы случайно не образовалось циклических ссылок и дубликатов ключей.

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

М>Запретить null terminated string, всегда следить на уровне ОС, чтобы длина строки вдруг не превысила бы размер выделенного ей блока памяти.

Для этого нет нужды запрещать null terminated string.

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

Хороших идей должно быть много.
И какова мораль?
Если Вы хотите намекнуть, что многократно упадет эффективность, то Вы заблуждаетесь.
По результатам сравнения программ с проверками и без оных было установлено — падение эффективности не превышает 10%. А зачастую — не превышает 1%.
Если же для Вас так критичен этот процент, то отладьте программу, а затем отключите проверки.

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

Хоар
Re[10]: Почему настоящие программисты избегают C++
От: Amidlokos Россия  
Дата: 22.03.05 13:05
Оценка:
Здравствуйте, AVC, Вы писали:

AVC>Так это все давно реализовано.
AVC>Вы со своей идеей опоздали.

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

AVC>Если Вы хотите намекнуть, что многократно упадет эффективность, то Вы заблуждаетесь.
AVC>По результатам сравнения программ с проверками и без оных было установлено — падение эффективности не превышает 10%. А зачастую — не превышает 1%.

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

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

AVC>Если же для Вас так критичен этот процент, то отладьте программу, а затем отключите проверки.

А вот это идея. Только и без того уже реализованная во многих компиляторах — дебажные релизы с проверками, окончательный чистый.
WARNING: expression "to_be || !to_be" is always true
Re[11]: Почему настоящие программисты избегают C++
От: AVC Россия  
Дата: 22.03.05 13:27
Оценка:
Здравствуйте, Amidlokos, Вы писали:

A>Как я понял, новых идей никто и не предлагает... Предложение относится только к использованию всех возможных проверок.

AVC>>Если Вы хотите намекнуть, что многократно упадет эффективность, то Вы заблуждаетесь.
AVC>>По результатам сравнения программ с проверками и без оных было установлено — падение эффективности не превышает 10%. А зачастую — не превышает 1%.

A>ИМХО некорректная цифра, т.к. эти программы испытывались на "классической" операционной системе — без встроенных проверок границ и указателей.

A>А если сама система начнёт проверять границы? На десять ли процентов рухнет производительность, или таки поболее? Операционка-то посложнее даже самых крутых офисных пакетов будет...

Такая операционка существует с 80-х годов: ОС Оберон.
Не так давно на RSDN с жаром дебатировался вопрос: нужна ли ОС Оберон защита памяти?
Дело в том, что наличие указанных проверок в ОС Оберон приводит не к уменьшению, а к увеличению производительности, т.к. не требуется нескольких адресных пространств, а достаточно одного; нет нужды "щелкать" контекстами. (В Обероне компилятор гарантирует "сохранность" памяти.)
В итоге минимальный системный вызов в Обероне в 30 раз быстрее, чем в Linux.

AVC>>Если же для Вас так критичен этот процент, то отладьте программу, а затем отключите проверки.

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

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

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

Хоар
Re[12]: Почему настоящие программисты избегают C++
От: ansi  
Дата: 23.03.05 10:00
Оценка:
Здравствуйте, AVC, Вы писали:

AVC>Я бы и в релизном коде оставлял проверки, когда важна корректность результата.

Интересно, а как корректность результата будет обеспечиваться проверками? Такая проверка лишь даст возможность как можно более корректно вывалить программу/модуль, при условии, что исключение было поймано и соответсвующим образом обработано (что делается редко).

Хотя конечно можно и вместо
int summ(int[] a) {
   int r = 0;

   for (int i = 0; i < a.Length; r += a[i++]);

   return r;
}

писать
int summ(int[] a) {
   int r = 0, i = 0;

   try {
      while (true)
         r += a[i++];
   } catch (IndexOutOfRangeException) {
      return r;
   }
}



Но плюс конечно есть — проще будет локализовать ошибку, если таковая всплывет.
Re[9]: Почему настоящие программисты избегают C++
От: 4ertus2  
Дата: 24.03.05 23:02
Оценка:
Здравствуйте, AVC, Вы писали:

AVC>Так что я назвал "снобом" не Вас, хотя меня и удивила Ваша фраза:

Впрочем, можно поговорить на чем пишут программы биологи или мастера слесарного дела.
Это, в свою очередь, меня удивила Ваша фраза:

Очевидно, продуманный минимализм средств является ключевым требованием, если мы хотим, чтобы язык программирования мирно «уживался» в мозгу исследователей со всей необходимой физикой, математикой и проч. знаниями.


Довод в ветке "Почему настоящие программисты избегают C++"?
Непривязанное к форме вечно.
Re[12]: Почему настоящие программисты избегают C++
От: Eugeny__ Украина  
Дата: 28.03.05 07:37
Оценка:
Здравствуйте, AVC, Вы писали:

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

A>>Как я понял, новых идей никто и не предлагает... Предложение относится только к использованию всех возможных проверок.

AVC>>>Если Вы хотите намекнуть, что многократно упадет эффективность, то Вы заблуждаетесь.
AVC>>>По результатам сравнения программ с проверками и без оных было установлено — падение эффективности не превышает 10%. А зачастую — не превышает 1%.

A>>ИМХО некорректная цифра, т.к. эти программы испытывались на "классической" операционной системе — без встроенных проверок границ и указателей.

A>>А если сама система начнёт проверять границы? На десять ли процентов рухнет производительность, или таки поболее? Операционка-то посложнее даже самых крутых офисных пакетов будет...

AVC>Такая операционка существует с 80-х годов: ОС Оберон.
AVC>Не так давно на RSDN с жаром дебатировался вопрос: нужна ли ОС Оберон защита памяти?
AVC>Дело в том, что наличие указанных проверок в ОС Оберон приводит не к уменьшению, а к увеличению производительности, т.к. не требуется нескольких адресных пространств, а достаточно одного; нет нужды "щелкать" контекстами. (В Обероне компилятор гарантирует "сохранность" памяти.)
AVC>В итоге минимальный системный вызов в Обероне в 30 раз быстрее, чем в Linux.

А эта ОС платная? Если нет, то можно ли себе где-нибудь скачать? (Хочется пощупать, что это такое, да и если доки какие есть — почитать).
Прошу прощения за вопросы чайника, но я до прочтения споров об этой системе вообще никогда про нее не слышал...

AVC>>>Если же для Вас так критичен этот процент, то отладьте программу, а затем отключите проверки.

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

AVC>Я бы и в релизном коде оставлял проверки, когда важна корректность результата.
... << RSDN@Home 1.1.3 stable >> Winamp: silent
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Re[10]: Почему настоящие программисты избегают C++
От: Михаил  
Дата: 14.04.05 01:57
Оценка:
Здравствуйте, AVC, Вы писали:

AVC>По результатам сравнения программ с проверками и без оных было установлено — падение эффективности не превышает 10%. А зачастую — не превышает 1%.

Правильно! Будут даже сотые доли процента!
Ну, не нужны массивы ядру ОС... Точнее, очень редко используются.
А вот как проверять те замысловатые хитросплетения, которые там на самом деле есть — это под большим вопросом.
...А отсюда наливаем, когда рецепт написан совсем неразборчиво...
Re[11]: Почему настоящие программисты избегают C++
От: AVC Россия  
Дата: 19.05.05 22:04
Оценка:
Здравствуйте, Михаил, Вы писали:

Прошу прощения, что не долго отвечал.
Было не до Интернета.

AVC>>По результатам сравнения программ с проверками и без оных было установлено — падение эффективности не превышает 10%. А зачастую — не превышает 1%.

М>Правильно! Будут даже сотые доли процента!
М>Ну, не нужны массивы ядру ОС... Точнее, очень редко используются.

Увы, я не понял, что Вы хотели этим сказать.
Массивы используются часто, и ядро ОС не является исключением.
Возьмите для примера хотя бы буферы ввода/вывода, которые так любят переполняться.
Если же Вы хотели сказать, что потеря эффективности незначительная только потому, что массивы используются редко, то это (ИМХО) сомнительное утверждение.
Рассмотрим простой пример:
PROCEDURE InitArray(VAR a: ARRAY OF INTEGER);
  VAR i: LONGINT;
BEGIN
  FOR i := 0 TO LEN(a)-1 DO
    a[i] := 0
  END
END InitArray;

Много ли нужно run-time проверок, чтобы удостовериться, что индекс не выходит за границы массива?
Очевидно, ни одной. Потери эффективности нет вовсе!
А ведь это самый "ходовой" вид цикла в Обероне (и не только).
Проверка на выход за границы массива в данном случае полностью происходит на этапе компиляции.
А вот для Си/Си++ это невозможно: там передается не массив, а указатель. Что не одно и то же.

М>А вот как проверять те замысловатые хитросплетения, которые там на самом деле есть — это под большим вопросом.

А в чем, собственно, заключается этот "большой" вопрос?

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

Хоар
Re[12]: Почему настоящие программисты избегают C++
От: ansi  
Дата: 20.05.05 04:27
Оценка:
AVC>А вот для Си/Си++ это невозможно: там передается не массив, а указатель. Что не одно и то же.
Дык и тут тоже передается указатель и длина массива (в неявном виде). А Си++ такое и не надо. Проверки нужны только в отладочной версии, всё.
Re[3]: Почему настоящие программисты избегают C++
От: Erop Россия  
Дата: 20.05.05 06:05
Оценка:
Здравствуйте, d Bratik, Вы писали:

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

Ну просвети нас, тёмных, пророк-Братик!
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[8]: Почему настоящие программисты избегают C++
От: Erop Россия  
Дата: 20.05.05 06:34
Оценка:
Здравствуйте, d Bratik, Вы писали:


DB>Вот так думает каждый здравомыслящий человек, но увы, переменная i не имеет знака, следовательно значение -1 для нее автоматически преобразуется в 4 млрд... и цикл продолжается.

Я, кстати, согласен что в STL много косяков всяких. Сам язык намного лучше этой библиотеки.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[11]: Почему настоящие программисты избегают C++
От: Erop Россия  
Дата: 20.05.05 06:46
Оценка:
Здравствуйте, Kubera, Вы писали:

K>ИМХО, твой пример со средним арифметическим неудачный. Что же касается знаковых индексов в векторе, то они нецелесообразны по двум причинам:
K>1. дополнительная ошибочная ситуация с отрицательным индексом
Так это же хорошо! Типа лишняя проверка. Но вообще отоличие формальное, так как что отрицательный индекс, что большой положительный -- всё равно мимо массива Просто ошибки переполнения легче assert'ами ловить при знаковой арифметике.

K>2. размер массива уменьшается в два раза (по сравнение с таким же знаковым типом)
Да? И это где же стока памяти-то взять, под массив-то?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[9]: Почему настоящие программисты избегают C++
От: Mr. None Россия http://mrnone.blogspot.com
Дата: 20.05.05 07:20
Оценка:
Здравствуйте, Erop, Вы писали:

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


DB>>Вот так думает каждый здравомыслящий человек, но увы, переменная i не имеет знака, следовательно значение -1 для нее автоматически преобразуется в 4 млрд... и цикл продолжается.

E>Я, кстати, согласен что в STL много косяков всяких.
Например? Хоть один... Я знаю, причём реальные, а вы?
То что size_type беззнаковый, так в этом нет ничего удивительного — название типа внимательно прочитайте: тип размера... как много типов вы знаете, имеющих отрицательный размер? Кстати этот самый size_type — как правило всего лишь синоним типа size_t, который к stl не имеет никакого отношения, а по сути является для массивов в стиле C тем же самым, что и size_type для контейнеров stl...
Вот вы же не сокрушаетесть, что sizeof возвращает именно беззнаковый size_t... так почему же вам не нравится тип size_type, возвращаемый vector::size?
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Re[3]: Почему настоящие программисты избегают C++
От: AlexEagle Украина http://www.vik.oil
Дата: 20.05.05 07:40
Оценка:
Здравствуйте, AlexBS, Вы писали:

AE>>8. За жесткие ограничения на место описания переменных функции — между названием функции и началом блока
ABS>+ и допуск совпадения имен переменных и типов. т.е конструкция
ABS>var
ABS> Word : Integer;
ABS>вполне допустима. но, понятно, что работать с такой переменной будет крайне сложно

Привычка писать на с++ довела до:

Var
  hDC: HDC;


потом дошло что написал какую-то чушь для паскаля ...
Re[8]: Почему настоящие программисты избегают C++
От: ZevS  
Дата: 20.05.05 09:09
Оценка:
Здравствуйте, transglucator, Вы писали:

T>жена — Pascal
T>проститутка — C++
T>любовница — ?

Вирт — тесть
Страуструп — сутенер,
? — рогоносец

Re[3]: Почему настоящие программисты избегают C++
От: nataniel  
Дата: 22.05.05 02:59
Оценка:
Здравствуйте, d Bratik, Вы писали:

Простите, что я вставляю свои пять копеек, я всего 2 года как знаком вообще с понятием "программирование", я не смогу поспорить с вами о многих заморочках и тонкостях, но я подумал, что было бы, если бы я начал учиться на Делфи.
На самом деле, Делфи я в глаза никогда не видел, но слышал. Слышал, что чтобы заполнить комбобокс данными из базы, нужно ткнуть пальцем в базу, ткнуть в список, и он зальется сам. При этом чуствуешь себя идиотом, потому что не знаешь, что происходит внутри. Особенно, если что то не работает. Примерно я прочуствовал это, когда взялся за C# и положил на диалог DataGrid. Но я просто догадывался, что происходит, потому что делал то же самое на плюсах. А если бы я видел и работал только с Делфи? Смог бы я когда-нибудь решить нестандартную задачу?
Иногда складывается впечатление, что шарп — просто огромная оболочка над API. Я долго смеялся, когда через Рефлектор увидел, что MessageBox.Show () импортирует апишную функцию. Неужели им сложно было переписать ее с возможностью добавлением чекбокса, который часто необходим?

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

Может, с годами и опытом проходит желание создать свой контрол, написанный с нуля или почти с нуля (наследуемся от CWnd) ?
А что легче, быстрее, понятнее etc — написать, например, всплывающую панель, как в VS .NET (или любой другой нестандартный контрол) — написать на С++ или на Делфи? Я совсем недавно сделал свое дерево, у которого единственное сходство со стандартным в том, что это дерево. Я получал удовольствие от того, что понимаю до конца, что написано, и что могу манипулировать данными и вообще языком, как мне захочется.

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

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

черт, даже я понимаю, какие...

ps
где-то на РСДН я видел пост, примерно процитирую:

С++ — это как шлюха. Можешь делать с ней, что хочешь, что если что-то подцепишь, то это твоя вина. ты имеешь ее, она тебя, вы квиты и довольны
C# — как жена. Шаг влево, шаг вправо — расстрел. На тебя одевают огромный презерватив, и перед каждой, простите, фрикцией, ты думаешь, а позволят? Но зато когда узнАешь ее эрогенную зону — позволено все. И ты спокоен и удовлетворен

и добавлю от себя:
C++ Builder — как 18-летняя девочка. Она готова на классику, и только. Жесткие рамки для фантазии. Что-то подцепишь — все равно твоя вина — она тебе не поможет выкрутиться, даже морально, а еще тебя обвинит. Чтобы развести ее на что-то кроме миссионерской, ты гробишь кучу времени, нервов и сил. Легче послать и трахнуть шлюху. Или расслабиться с женой... после того, как накувыркался со шлюхой
Re[13]: Почему настоящие программисты избегают C++
От: AVC Россия  
Дата: 22.05.05 10:16
Оценка:
Здравствуйте, ansi, Вы писали:

AVC>>А вот для Си/Си++ это невозможно: там передается не массив, а указатель. Что не одно и то же.
A>Дык и тут тоже передается указатель и длина массива (в неявном виде). А Си++ такое и не надо. Проверки нужны только в отладочной версии, всё.

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

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

Хоар
Re[8]: Почему настоящие программисты избегают C++
От: ZetRooT Россия  
Дата: 22.05.05 17:10
Оценка:
Здравствуйте, transglucator, Вы писали:

T>жена — Pascal
T>проститутка — C++
T>любовница — ?


тогда уж Java

"Если бы не было колобка, его следовало бы придумать..."

Re[10]: Почему настоящие программисты избегают C++
От: p_kolya  
Дата: 23.05.05 15:41
Оценка:
Здравствуйте, nixite, Вы писали:


N>положим захотелось нам искать среднее двух чисел и написали мы функцию:
N>int kaka (int a, int b){return (a+b)/2;}

N>и всё вроде тип-топ, но вот тут сунули нам два числа (вполне корректных):

N>int a = 2113929216;
N>int b = 2113929210;
Функциб kak можно переписать так:
int kaka(int a, int b){return ((a/2) + (b/2));}

Математика однако рулит не хуже Си с плюсами...и без плюсов тоже
Best regards, p_kolya [ http://p-kolya.narod.ru ] WinAmp сообщает: Rammstein — Links 2-3-4
Re[17]: :)))
От: Erop Россия  
Дата: 23.05.05 16:25
Оценка:
Здравствуйте, Amidlokos, Вы писали:
A>Уважаемый язвительный Верхний Ряд Клавиатуры!
Не обижай qwertyuiop! Он "верхинй ряд клавиатуры без квадратных скобок"
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[17]: Почему настоящие программисты избегают C++
От: Erop Россия  
Дата: 23.05.05 16:27
Оценка:
Здравствуйте, Amidlokos, Вы писали:
A>Уважаемый язвительный Верхний Ряд Клавиатуры! Во-первых, inline-код выполняется всё равно дольше одной операции сравнения. Во-вторых, на оптимизатор надейся, а сам не плошай. Может, я и правда так плохо знаю возможности современного оптимизатора, но я не стал бы давать гарантию, что он осознает необходимость вызвать size() один раз, особенно с учётом обращения где-то в цикле к тому же vec. Более того — оптимизаторов много. И более того — я бы не стал за счёт оптимизатора отвыкать думать.

А на читабельность всем уже и наплевать?
Я не очень понимаю для решения каких именно задач заточен STL.
Мне так кажется, что никаких. Такой классный универсальный всемогутер. Зато типа красивый.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[19]: что бы это значило
От: Erop Россия  
Дата: 23.05.05 19:27
Оценка:
Здравствуйте, Cyberax, Вы писали:
>> А на читабельность всем уже и наплевать?
>> Я не очень понимаю для решения каких именно задач заточен STL.
>> Мне так кажется, что никаких. Такой классный универсальный всемогутер.
>> Зато типа красивый.

C>Для любых Контейнеры в STL сделаны очень гибко, их можно использовать
C>почти под что угодно. А если сюда добавить еще и boost...

Для любых это тоже самое, что ни заточен ни для каких (КМК, разумеется)

Вот мне например, в моих задачах, тоже не хватает проверок на выход за границы массива.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[3]: Почему настоящие программисты избегают C++
От: borka Россия  
Дата: 24.05.05 18:11
Оценка:
Здравствуйте, AlexBS, Вы писали:

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

ABS>Например, ReadProcessMemory
ABS>
ABS>function ReadProcessMemory(hProcess: THandle; const lpBaseAddress: Pointer; lpBuffer: Pointer; nSize: DWORD; var lpNumberOfBytesRead: DWORD): BOOL; stdcall;
ABS>

ABS>Ну нахрена мне всегда(!!) заводить бесполезную переменную для параметра var lpNumberOfBytesRead: DWORD, когда она в 99% случаях просто ненужна!
ABS>А таких функций уйма!

В принципе можно написать:

ReadProcessMemory(..., ..., ..., ..., PDWORD(nil)^)

Re[11]: Почему настоящие программисты избегают C++
От: AVC Россия  
Дата: 24.05.05 23:55
Оценка:
Здравствуйте, p_kolya, Вы писали:

N>>положим захотелось нам искать среднее двух чисел и написали мы функцию:
N>>int kaka (int a, int b){return (a+b)/2;}

N>>и всё вроде тип-топ, но вот тут сунули нам два числа (вполне корректных):

N>>int a = 2113929216;
N>>int b = 2113929210;
_>Функциб kak можно переписать так:
_>int kaka(int a, int b){return ((a/2) + (b/2));}

_>Математика однако рулит не хуже Си с плюсами...и без плюсов тоже

Посчитаем по Вашей формуле среднее арифметическое , скажем, двух троек.
Получим:
(3/2) + (3/2) = 1 + 1 = 2.
Да, математика рулит, однако... Вон куда она Вас зарулила.

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

Хоар
Re[12]: Почему настоящие программисты избегают C++
От: Amidlokos Россия  
Дата: 25.05.05 07:18
Оценка:
Здравствуйте, AVC, Вы писали:

AVC>Посчитаем по Вашей формуле среднее арифметическое , скажем, двух троек.
AVC>Получим:
AVC>(3/2) + (3/2) = 1 + 1 = 2.
AVC>Да, математика рулит, однако... Вон куда она Вас зарулила.

Математика в данном случае и правда рулит. Только при вычислении надо скастовать во float.
WARNING: expression "to_be || !to_be" is always true
Re[2]: Почему настоящие программисты избегают C++
От: Sheridan Россия  
Дата: 25.05.05 07:57
Оценка:
Здравствуйте, SWW, Вы писали:

DB>>
DB>>for (std::vector<int>::size_type i = 0; v.size() - 1; ++i)
DB>>


SWW>А что это за чушь написал здесь настоящий программист?

мда... А про итераторы все позабыли? Или как?
std::vector<int>::iterator It = v.begin();
while(It != v.end())
{
    printf("%d \n",(*It));
    It++;
}

Поправьте меня если неправ...
[RSDN@Home][1.1.4][beta 7][458]
[FSOL — Papua New guinea (Hybrid mix)]
Matrix has you...
Re[13]: Почему настоящие программисты избегают C++
От: Sinclair Россия https://github.com/evilguest/
Дата: 25.05.05 09:45
Оценка:
Здравствуйте, Amidlokos, Вы писали:
A>Математика в данном случае и правда рулит. Только при вычислении надо скастовать во float.
Это ты знатно придумал. Сможешь оценить просад производительности, не заглядывая в Intel Optimization Guide?
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[5]: Почему настоящие программисты избегают C++
От: xBlackCat Россия  
Дата: 25.05.05 13:07
Оценка:
Здравствуйте, AlexEagle, Вы писали:

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

_O_>>Не, никаких Фаров. Только

_O_>>
_O_>>copy con: MyCoolProg.exe
_O_>>


AE>Про это я как-то не подумал Это уже диагнох реального перца в квадрате

Уже такие перцы есть! Смотреть здесь
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Rojac &mdash; Rsdn Offline JAva Client
Анонсы и обсуждение здесь
Автор: xBlackCat
Дата: 08.02.10
Re[11]: Почему настоящие программисты избегают C++
От: tinytjan  
Дата: 25.05.05 15:21
Оценка:
Здравствуйте, p_kolya, Вы писали:

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


N>>положим захотелось нам искать среднее двух чисел и написали мы функцию:
N>>int kaka (int a, int b){return (a+b)/2;}

N>>и всё вроде тип-топ, но вот тут сунули нам два числа (вполне корректных):

N>>int a = 2113929216;
N>>int b = 2113929210;
_>Функциб kak можно переписать так:
_>int kaka(int a, int b){return ((a/2) + (b/2) + ((a%2) + (b%2))/2);}

_>Математика однако рулит не хуже Си с плюсами...и без плюсов тоже
Re[14]: Почему настоящие программисты избегают C++
От: Amidlokos Россия  
Дата: 25.05.05 18:14
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Amidlokos, Вы писали:
A>>Математика в данном случае и правда рулит. Только при вычислении надо скастовать во float.
S>Это ты знатно придумал. Сможешь оценить просад производительности, не заглядывая в Intel Optimization Guide?

"А это уже второй вопрос" (С) Анекдот

Я не говорю, что это будет быстрее. Я просто не понимаю (раз уж флейм пошёл) как от просада производительности спасёт контроль языком границ. Кастовать-то всё равно придётся, а на проверку пойдут лишние такты.

(кстати, int-овую реализацию здесь
Автор: tinytjan
Дата: 25.05.05
 уже предложили... что-то совсем голова до такого по жаре не допёрла)
WARNING: expression "to_be || !to_be" is always true
Re: Почему настоящие программисты избегают C++
От: llirik  
Дата: 25.05.05 19:09
Оценка:
Здравствуйте, d Bratik, Вы писали:

Человеку скучно сделалось. Человек повоевать пришел.
А, собственно, повод к войне значения не имеет
... << RSDN@Home 1.1.4 beta 7 rev. 454>>
Мне твоя Москва нравится, и обратно в Россию я не вернусь! (с) мыльная о.
Re[15]: А всё-так чем же pascal дгчше для GUI библиотек-то?
От: Erop Россия  
Дата: 25.05.05 20:11
Оценка:
Здравствуйте, Kh_Oleg, Вы писали:

K_O>Вот тут упоминали, что куча продуктов (Office, Adobe family, etc.) написана на С++. Написана, но в каждом
K_O>случае разработчикам приходилось писать свой framework конкретно под свой продукт (или семейство продуктов).

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

K_O>Вывод: для С++ нет нормальной (надежной и полнофункциональной) библиотеки для GUI.

Ну вот у нас долгое время был продукт, в котором использовалась стандартная GUI библиотека. И ничего. Работал.

Но потом оказалось, что всё-таки хочется от контролов большего, чем может дать библиотека, даже с расширениями.
В конце концов морду продукта (хотя там главное мозги) переписали на самописные контролы и оконную библиотеку. И не так уж дорого в масштабе всего изделия получилось. А лучше.

Просто у каждого прилодения есь свои особенности. Развитие опять же не стоит на месте. А библиотеки всё-таик зело статичны. Всегда предоставляют возможности нужные вчера.

У нас, кстати, рассматривалась идея перенсти оболочку на что-то дроугое с C++, (архитектура изделия в принципе это позволяет). Но оказалось, что не стоят яйца выделки. Всё-равно стандартные контроды хоть там хоть тут а всё же жмуть.
А уж если переписывать, то от чего бы и не переписать как нравится?

Ну а если надо быстро сработать приблуду какую-нибудь, то библиотека как раз и нужна.
В конце концов те самые приложения на C++ они не на VCL тоже написаны
Просто для такого большого монстра стандартная GUI библиотека невыгодной становится да и всё.

Кроме того вообще не ясна логика. Наверное в паскалеподобных языках есть что-то, что позволяет писать афигительные GUI библиотеки. Интересно что же это такое?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[18]: Почему настоящие программисты избегают C++
От: Erop Россия  
Дата: 25.05.05 20:19
Оценка:
Здравствуйте, Cyberax, Вы писали:

>> C>Есть. MFC, Stringray, и т.п.
>> Наша сказка хороша — начинай сначала. Только что подробно разобрали,
>> почему конкретно
>> MFC нельзя использовать для разработки, и тут на тебе опять.

C>Я услышал только один аргумент: не кроссплатформенная. Ну так оно
C>никогда таким и не планировалось.

1) MFC есть под Mac OS, но наверное лучше бы не было
2) Обычно portable GUI выглядят уродами всюду Запусти какоцй-нибудь ява-апплет. Например отсюда и насладись
И это понятно -- на разных платформах GUI приянто строить по-разному. Так что совсем-совсем переносимое GUI сделать "как родным" всюду очень трудно. Проще как-то иначе это всё запроектировать. MFC под Mac OS ужасна в первую очередь именно из-за того, что пытается совместить ужа с ежом и ведёт себя как принято на Mac OS, а приложению ажет вид что всё хорошо, всё как дома. Ну и лезут и лезут гадости.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[22]: Почему настоящие программисты избегают C++
От: Erop Россия  
Дата: 25.05.05 20:21
Оценка:
Здравствуйте, Amidlokos, Вы писали:

A>Кроме того — ну, а где (повторю это любимое слово) ссылка-то на этот дельфовский суперкомпонент? Где пример программы с десятком тысяч node-ов?

есть таколе чудо!
его дельфисты зело любят показывать.
Правда тот, что мен показывали разработан сторонними энтузиастами. Я так думаю, что нет проблем перенести его на C++ при нужде. Скорее всего есть уже готовые аналоги

Но мне опять же кажется, что обычно он таки не нужен
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[15]: Почему настоящие программисты избегают C++
От: Sinclair Россия https://github.com/evilguest/
Дата: 26.05.05 04:34
Оценка:
Здравствуйте, Amidlokos, Вы писали:

A>Я не говорю, что это будет быстрее. Я просто не понимаю (раз уж флейм пошёл) как от просада производительности спасёт контроль языком границ.
Очень просто. Язык либо станет статически ругаться на такую операцию (и тебе придется придумывать обходной вариант для подавления ворнинга), либо кинет ексепшн, не дав неверному результату прокрастся в программу.
A>Кастовать-то всё равно придётся,
С чего это вдруг?
A> а на проверку пойдут лишние такты.
Пойдут. Но флоат-вычисления, афаик, до сиж пор немеряно дороже целых.
A>(кстати, int-овую реализацию здесь
Автор: tinytjan
Дата: 25.05.05
 уже предложили... что-то совсем голова до такого по жаре не допёрла)
Вообще-то, правильную реализацию предложили еше в феврале: Re[10]: Почему настоящие программисты избегают C++
Автор: screw_cms
Дата: 18.02.05
. И мне почему-то кажется, что она будет все-таки быстрее твоей
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[17]: А всё-так чем же pascal дгчше для GUI библиотек-то?
От: Пацак Россия  
Дата: 26.05.05 09:24
Оценка:
Здравствуйте, Kh_Oleg, Вы писали:

E>>Кроме того вообще не ясна логика. Наверное в паскалеподобных языках есть что-то, что позволяет писать афигительные GUI библиотеки. Интересно что же это такое?
K_O>События,

Ето не фича языка, это фича ОСи (если имеются в виду всякие WM_PAINT) или фича библиотеки (если имеются в виду всякие OnClick). Во всяком случае никто не помешал реализовать ту же идеологию в совершенно непаскалеподобном builder'е.

K_O>try...finally,

А гуи тут при чем?

K_O>информация о типах...

И что, таки только в паскалях есть?
Ку...
Re[18]: А всё-так чем же pascal дгчше для GUI библиотек-то?
От: Sinclair Россия https://github.com/evilguest/
Дата: 26.05.05 11:01
Оценка:
Здравствуйте, Пацак, Вы писали:

П>Ето не фича языка, это фича ОСи (если имеются в виду всякие WM_PAINT) или фича библиотеки (если имеются в виду всякие OnClick). Во всяком случае никто не помешал реализовать ту же идеологию в совершенно непаскалеподобном builder'е.
Ну ты даешь. Непаскалеподобный билдер, между прочим, от С++ весьма и весьма отличается. Как ни странно, борланду пришлось изменить именно язык, а не библиотеки. Получилось что-то совершенно чудовищное. Как ты думаешь, удастся скомпилить билдерное приложение при помощи MSVC?
П>И что, таки только в паскалях есть?
Нет, есть еще и в билдере. См. выше. А также в управляемых средах.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[19]: А всё-так чем же pascal дгчше для GUI библиотек-то?
От: Пацак Россия  
Дата: 26.05.05 12:47
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

Но, согласись, от паскаля он отличается еще больше?

S>Как ни странно, борланду пришлось изменить именно язык, а не библиотеки.

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

S>Получилось что-то совершенно чудовищное.

Согласен. Но ведь получилось.

П>>И что, таки только в паскалях есть?
S>Нет, есть еще и в билдере. См. выше. А также в управляемых средах.

В скриптовых языках опять же (в питоне например). Так что рассматривать это как исключительное преимущество паскаля — вряд ли стоит ИМХО.
Ку...
Re[19]: А всё-так чем же pascal дгчше для GUI библиотек-то?
От: Пацак Россия  
Дата: 26.05.05 13:12
Оценка:
Здравствуйте, Kh_Oleg, Вы писали:

K_O>Ну, во-первых, не следует путать сообщения Windows и события.

Согласен, запутался слегка.

K_O>Во-вторых, события — это для Win32 именно фича языка, которую на С++ реализовать нормально невозможно. Чтобы С++Buildere реализовать события пришлось измененить язык. Тот С++, который там используется со стандартом несовместим.

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

E>Кроме того вообще не ясна логика. Наверное в паскалеподобных языках есть что-то, что позволяет писать афигительные GUI библиотеки. Интересно что же это такое?


Я так понял, обсуждаюются какие-то исключительные фичи паскаля, которые а) есть только в нем и б) не могут быть внесены в другой язык без его коренной переработки. Тот же билдер — это хоть и кривой и несовместимый со стандартом, но все же С++, т.е. ничего не помешало хорошим танцорам от борланда реализовать те же фичи в другом языке. Плюс опять же есть шарп, java... В общем не вижу я какой-то особой "исключительности", вопрос привычки скорее.

K_O>Где многопоточность — там и объекты синхронизации. И вот тут finally очень помогает.

Спорить не буду — не сталкивался настолько плотно.

K_O>>>информация о типах...
П>>И что, таки только в паскалях есть?
K_O>Еще есть на платформах Java и .NET. Но для Win32 — только в Delphi.

Сейчас придут оберонисты и затопчут ногами. Питонщики тоже могут им помочь попинать. Глядишь и еще кто-нибудь подтянется. И в конце концов выяснится, что получение информации о типах на этапе выполнения — не такая уж и редкая штука. Однако хорошие гуи почему-то как кролики не плодятся.
Ку...
Re[19]: А всё-так чем же pascal дгчше для GUI библиотек-то?
От: AlexEagle Украина http://www.vik.oil
Дата: 26.05.05 14:33
Оценка:
Здравствуйте, Kh_Oleg, Вы писали:

K_O>try...finally обеспечивает гарантированный вызов finalization кода даже в тех случаях, когда в блоке try произошла исключительная ситуация. Причем в блоке finalization допускается возникновение еще одной исключительной ситуации, что недопустимо в С++ если использовать для этой цели scope guards. Причем здесь GUI? А притом, что нормальный GUI немыслим без многопоточности. Где многопоточность — там и объекты синхронизации. И вот тут finally очень помогает.

Что насчет __try... __finally в с++ ? Хотя это и MS-specific но все же...
С другой стороны, мы на делфе реально пользуемся try..finally в 90% случаев для обеспечения эмуляции автоматических переменных...

K_O>>>информация о типах...
Что насчет RUNTIME_CLASS и проч.. ?
Re[20]: А всё-так чем же pascal дгчше для GUI библиотек-то?
От: AlexEagle Украина http://www.vik.oil
Дата: 26.05.05 14:34
Оценка:
Здравствуйте, Пацак, Вы писали:

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

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

П>Но, согласись, от паскаля он отличается еще больше?

Я бы сказал так: паскаль — подмножество билдера, ввиду возможности последнего компилить пасовские юниты
Re[17]: А всё-так чем же pascal дгчше для GUI библиотек-то?
От: Erop Россия  
Дата: 27.05.05 05:49
Оценка:
Здравствуйте, Kh_Oleg, Вы писали:

K_O>События, try...finally, информация о типах...

уведомления (шаблон проектирования такой, вообще не language-specific практически), scope guard, rtti
Чем же они хуже для построения GUI библиотеки?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[19]: А всё-так чем же pascal дгчше для GUI библиотек-то?
От: Erop Россия  
Дата: 27.05.05 05:53
Оценка:
Здравствуйте, Sinclair, Вы писали:

П>>Ето не фича языка, это фича ОСи (если имеются в виду всякие WM_PAINT) или фича библиотеки (если имеются в виду всякие OnClick). Во всяком случае никто не помешал реализовать ту же идеологию в совершенно непаскалеподобном builder'е.
S>Ну ты даешь. Непаскалеподобный билдер, между прочим, от С++ весьма и весьма отличается. Как ни странно, борланду пришлось изменить именно язык, а не библиотеки. Получилось что-то совершенно чудовищное. Как ты думаешь, удастся скомпилить билдерное приложение при помощи MSVC?
П>>И что, таки только в паскалях есть?
S>Нет, есть еще и в билдере. См. выше. А также в управляемых средах.

А что, там мега GUI библиотека?
Всё-таки хотелось бы понять что же нужно от языка для "действительно хорошей GUI библиотеке" такого, чего нет в C++.
Мне кажется, что однем из главных недостатков C++ является его гибкость. Но как раз этот недостаток позволяет промоделировать на C++ всё что угодно.

Бывают даже разработки, которые заставляют C++ прикинуться чем-то LISP-ообразным (или Prolog-оподобным)
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[18]: А всё-так чем же pascal дгчше для GUI библиотек-то?
От: Kh_Oleg  
Дата: 27.05.05 06:30
Оценка:
Здравствуйте, Erop, Вы писали:

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

K_O>>События, try...finally, информация о типах...

E>уведомления (шаблон проектирования такой, вообще не language-specific практически), scope guard, rtti
E>Чем же они хуже для построения GUI библиотеки?
Про scope guards я уже сказал — они не допускают возникновения исключительной ситуации в finalization коде. Потому что в этом случае finalization код выполняется в деструкторе объекта, а в С++ исключение в деструкторе — это undefined behaviour.

rtti не является полноценнной заменой reflection'у, который есть в Java или .NET. Это очередная заплатка в языке.
Re[20]: А всё-так чем же pascal дгчше для GUI библиотек-то?
От: Sinclair Россия https://github.com/evilguest/
Дата: 27.05.05 07:28
Оценка:
Здравствуйте, Erop, Вы писали:
E>А что, там мега GUI библиотека?
Вообще-то одна из лучших. И это если считать только встроенную. А если учесть количество и качество бесплатных и коммерческих компонентов, которые бесшовно интегрируются с VCL (в частности, дизайнятся дизайнером и сериализуются стандартной подсистемой), то практически все остальные окажутся пылесосами.
E>Всё-таки хотелось бы понять что же нужно от языка для "действительно хорошей GUI библиотеке" такого, чего нет в C++.
Поддержки компонентной разработки. Я не буду расшифровывать — все это уже обсасывалось, и в том числе в этом форуме.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[21]: А всё-так чем же pascal дгчше для GUI библиотек-то?
От: Cyberax Марс  
Дата: 27.05.05 08:47
Оценка:
Sinclair wrote:

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

А в чем здесь заслуга *самого* VCL? Это заслуга среды и технологии
ActiveX. Сам VCL непосредственно — простенький враппер над WinAPI, не
сильно лучше WTL.

Лучшая GUI-либа, ИМХО, это QT.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[22]: А всё-так чем же pascal дгчше для GUI библиотек-то?
От: AlexEagle Украина http://www.vik.oil
Дата: 27.05.05 10:03
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Сам VCL непосредственно — простенький враппер над WinAPI, не
C>сильно лучше WTL.

Ну нет... Враппер над WinAPI это действительно WTL... MFC Тоже враппер своего рода,
тока с расширением функции.. VCL — это искажение WinAPI, местами добавлен функционал,
местами убран (скрыт) местами дико искажен для поддержки концепции VCL.. Чего стоит один
Handle ...

Когда юзал MFC — не мог и предположить что случайное использование хендла
в деструкторе окна приведет к таким диким последствиям как оказалось в VCL
А чего стоит TWinControl.SetFocus который кидается exception если контрол невидим
Так что не самый лучший вариант для построения ГУЯ... некоторые функции я использую апишные
принципиально, чтобы не писать лишние Try..finally.


Хотя с другой стороны надо отдать должное этой библиотеке ввиду наличия большого набора компонент и простоты
построения ГУЯ. Наверное этим она и прельщает многих разработчиков + удобно работать с БД...

C>Лучшая GUI-либа, ИМХО, это QT.
К сожалению не пробовал
Re[23]: А всё-так чем же pascal дгчше для GUI библиотек-то?
От: Cyberax Марс  
Дата: 27.05.05 10:29
Оценка:
AlexEagle wrote:

> Хотя с другой стороны надо отдать должное этой библиотеке ввиду
> наличия большого набора компонент и простоты
> построения ГУЯ. Наверное этим она и прельщает многих разработчиков +
> удобно работать с БД...

Работа с БД к самому VCL отношения не имеет, как и большой набор
компонент. Это заслуга среды, а VCL почти ничего существенного сам по
себе не добавляет по сравнению с WinAPI.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[22]: А всё-так чем же pascal дгчше для GUI библиотек-то?
От: Sinclair Россия https://github.com/evilguest/
Дата: 27.05.05 11:14
Оценка:
Здравствуйте, Cyberax, Вы писали:
C>А в чем здесь заслуга *самого* VCL? Это заслуга среды
Что и требовалось доказать. Субж топика читал? ата не она, среда. Что и требовала
C>и технологии ActiveX.
АктивХэ к VCL имеет весьма косвенное отношение. Мой опыт использования внедренных активхэ контролов очень мал и чрезвычайно негативен. Все нормальные компоненты под VCL сделаны на VCL.
C>Лучшая GUI-либа, ИМХО, это QT.
Если учитывать стороннние компоненты, типа DevExpress, которые построены только благодаря языку и библиотеке Delphi, то, имхо, QT тихо умрет от зависти. Могу ошибаться.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[21]: А всё-так чем же pascal дгчше для GUI библиотек-то?
От: AlexEagle Украина http://www.vik.oil
Дата: 27.05.05 11:17
Оценка:
Здравствуйте, Kh_Oleg, Вы писали:

K_O>Все эти изменения в языке или макросы в библиотеках — все это заплатки, свидетельствующие о кривизне языка С++.

Кривизна — это когда речь идет о руках программиста А так — самый гибкий язык, надо RTTI — получи с помощь RUNTIME_CLASS, надо обработчик завершения — тут уж доработала MS свой __try...__finally...
Re[24]: А всё-так чем же pascal дгчше для GUI библиотек-то?
От: AlexEagle Украина http://www.vik.oil
Дата: 27.05.05 11:21
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Работа с БД к самому VCL отношения не имеет, как и большой набор
C>компонент. Это заслуга среды, а VCL почти ничего существенного сам по
C>себе не добавляет по сравнению с WinAPI.

Я конечно понимаю что для тебя VCL просто три буквы, но для всех остальных
это Visual Components Library, поэтому свое "не причем" оставь при себе, хорошо ?
Re[24]: А всё-так чем же pascal дгчше для GUI библиотек-то?
От: Sinclair Россия https://github.com/evilguest/
Дата: 27.05.05 11:56
Оценка:
Здравствуйте, AlexEagle, Вы писали:
AE>Имхо, DevExpress подавятся кросплатформенностью от QT
Конечно. Но функциональность зачастую важнее кроссплатформенности.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[24]: А всё-так чем же pascal дгчше для GUI библиотек-то?
От: Sinclair Россия https://github.com/evilguest/
Дата: 27.05.05 11:56
Оценка:
Здравствуйте, Cyberax, Вы писали:
C>Работа с БД к самому VCL отношения не имеет, как и большой набор
C>компонент.
Правда что ли? Т.е. десятки тысяч строк VCL DB-компонентов — они для красоты написаны?
C>Это заслуга среды
А почему не пятницы?
C>, а VCL почти ничего существенного сам по
C>себе не добавляет по сравнению с WinAPI.
Ты точно видел VCL? Ну-ка, воспроизведи мне TClientDataSet заслугами среды или WinAPI.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[25]: А всё-так чем же pascal дгчше для GUI библиотек-то?
От: Cyberax Марс  
Дата: 27.05.05 12:06
Оценка:
Sinclair wrote:

> C>Работа с БД к самому VCL отношения не имеет, как и большой набор
> C>компонент.
> Правда что ли? Т.е. десятки тысяч строк VCL DB-компонентов — они для
> красоты написаны?

Есть ADO и ODBC, есть otl. Там те же десятки тысяч строк. А уж то что
они по какой-то причине попали в VCL — тупость Борланда.

> C>, а VCL почти ничего существенного сам по
> C>себе не добавляет по сравнению с WinAPI.
> Ты точно /видел/ VCL? Ну-ка, воспроизведи мне TClientDataSet заслугами
> среды или WinAPI.

ADO.Recordset. И я не понимаю почему оно входит в VCL, когда ему место в
отдельной либе.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[26]: А всё-так чем же pascal дгчше для GUI библиотек-то?
От: AlexEagle Украина http://www.vik.oil
Дата: 27.05.05 12:13
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Есть ADO и ODBC, есть otl. Там те же десятки тысяч строк. А уж то что
C>они по какой-то причине попали в VCL — тупость Борланда.

Чушь — это просто враперы сделанные по манере борланда упрощать до безобразия рутинные операции

>> C>, а VCL почти ничего существенного сам по
>> C>себе не добавляет по сравнению с WinAPI.
>> Ты точно /видел/ VCL? Ну-ка, воспроизведи мне TClientDataSet заслугами
>> среды или WinAPI.

C>ADO.Recordset. И я не понимаю почему оно входит в VCL, когда ему место в
C>отдельной либе.
Это и есть отдельная либа — ADOExpress Как и IBX в случае с TIBDatabase, TIBTable...

А тебе про TDatasource, TDataset и прочие базовые компоненты для доступа к БД говорят...
А также про TDBGgid, TDBEdit, TDBComboBox которые служат для ввода/редактирования данных из БД
Re[22]: А всё-так чем же pascal дгчше для GUI библиотек-то?
От: Kh_Oleg  
Дата: 27.05.05 13:12
Оценка:
Здравствуйте, AlexEagle, Вы писали:

K_O>>Все эти изменения в языке или макросы в библиотеках — все это заплатки, свидетельствующие о кривизне языка С++.

AE>Кривизна — это когда речь идет о руках программиста А так — самый гибкий язык, надо RTTI — получи с помощь RUNTIME_CLASS, надо обработчик завершения — тут уж доработала MS свой __try...__finally...

Только использование всех этих "гибкостей" обременено тысяей "если": если используешь только MSVC, если используешь именно MFC, и так далее...
Re[24]: А всё-так чем же pascal дгчше для GUI библиотек-то?
От: Kh_Oleg  
Дата: 27.05.05 13:14
Оценка:
Здравствуйте, AlexEagle, Вы писали:

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

C>>>Лучшая GUI-либа, ИМХО, это QT.
S>>Если учитывать стороннние компоненты, типа DevExpress, которые построены только благодаря языку и библиотеке Delphi, то, имхо, QT тихо умрет от зависти. Могу ошибаться.

AE>Имхо, DevExpress подавятся кросплатформенностью от QT

Пусть лучше мое приложение блестяще работает под одной ОС, чем коряво под десятью.
Re[19]: А всё-так чем же pascal дгчше для GUI библиотек-то?
От: Владик Россия  
Дата: 27.05.05 14:40
Оценка:
Здравствуйте, Kh_Oleg, Вы писали:

K_O>Во-вторых, события — это для Win32 именно фича языка, которую на С++ реализовать нормально невозможно.

Ну конечно boost::signal/function/bind дают такие "события", что дельфям и не снились.

K_O>Чтобы С++Buildere реализовать события пришлось измененить язык. Тот С++, который там используется со стандартом несовместим.

Что касается билдера, то изуродовать С++ там пришлось для того, чтобы обечпечить бинарную совместимость с паскалевской VCL.

[...]
K_O>try...finally обеспечивает гарантированный вызов finalization кода даже в тех случаях, когда в блоке try произошла исключительная ситуация.

finally — это костыль, ведущий к copy-paste. В некоторых языках без него нельзя, в С++ — можно и нужно.

K_O>Причем в блоке finalization допускается возникновение еще одной исключительной ситуации, что недопустимо в С++ если использовать для этой цели scope guards.

А смысл? Я не вижу чем полезна возможность неявно потерять информацию об исключительной ситуации. Хоть для GUI, хоть не для GUI.

K_O>Причем здесь GUI? А притом, что нормальный GUI немыслим без многопоточности. Где многопоточность — там и объекты синхронизации. И вот тут finally очень помогает.

Для синхронизации scope-guards рулят как никогда. Их нельзя забыть написать.

[...]
K_O>Еще есть на платформах Java и .NET. Но для Win32 — только в Delphi.

Вот с информацией о типах в С++ туго, здесь нечено сказать. Хотя в дельфях не намного лучше.
Как все запущенно...
Re[19]: А всё-так чем же pascal дгчше для GUI библиотек-то?
От: Владик Россия  
Дата: 27.05.05 15:56
Оценка:
Здравствуйте, Kh_Oleg, Вы писали:

K_O>finalization код выполняется в деструкторе объекта, а в С++ исключение в деструкторе — это undefined behaviour.

В С++ исключение в деструкторе — это вполне себе defined behaviour. Хотя и плохой тон. Проблемы начинаются в случае, когда деструктор вызывается уже как реакция на возбуждение исключения.
Как все запущенно...
Re: Почему настоящие программисты избегают C++
От: EcliptoR  
Дата: 29.05.05 03:02
Оценка:
Здравствуйте, d Bratik, Вы писали:

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

DB>1.Отсутствие модулей. Имитация понятия модуль в виде пары h-файл – cpp-файл приводит к многочасовым компиляциям системы.

Можно все в хэдере писать. Никто не запрещает.

DB>2.Использование целочисленных типов данных без знака (unsigned int) для номеров элементов и количественных значений в стандартной библиотеке stdc++. Приводит к следующим ошибкам:

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

DB>3.Отсутствие встроенной проверки на выход за диапазоны массива. Приводит к необходимости писать «обертки» для классов-контейнеров (в частности, для класса vector).

А кто мешает польховаться итераторами.

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

А почему например нет встроенных средств инициализации еденицами, мне например чаще еденицами надо инициализировать? Гибкость, однако.

DB>5.«Автоматизм» конструкторов и деструкторов для объектов, создаваемых динамически и имеющих виртуальные методы; работа виртуальных методов как не виртуальных при их вызове из конструкторов и деструкторов; отсутствие стандартного базового класса. Значительно затрудняет решение проблемы повторного входа в объекты (reentrance problem) при создании библиотек визуальных компонентов и систем GUI.

Ну тут согласен, просто С++ — язык довольно сразу, он рождался вместе с этими идеями, в Java и C# эти проблемы вроде решены.

DB>6.Отсутствие оператора try {…} finally {…}. Приводит к созданию программ, неустойчивых к исключительным ситуациям. Попытка имитировать этот оператор с помощью оператора try {…} catch {…} приводит к большой избыточности кода.

есть __try, __except, __finally, правда только у MS-совместимых.
Re[2]: Почему настоящие программисты избегают C++
От: ydab  
Дата: 29.05.05 19:52
Оценка:
DB>>6.Отсутствие оператора try {…} finally {…}. Приводит к созданию программ, неустойчивых к исключительным ситуациям. Попытка имитировать этот оператор с помощью оператора try {…} catch {…} приводит к большой избыточности кода.

UGN>Зачем он вообще нужен, этот finally? Делай все что нужно в деструкторах автоматических объектов

on ne nushen, no ochen' udoben... v ostal'nom polnostju s tonoj soglasen
Re[11]: Почему настоящие программисты избегают C++
От: ydab  
Дата: 29.05.05 20:19
Оценка:
D>Ну зачем же ставить заведомо нерешаемые задачи?
D>Над такими лучшие умы человечества бьются не один десяток лет, а Вы хотите чтоб Вам на каком-то инетрнет-форуме всё разрулили. 

int kaka (int a, int b)
{
   return (a/2 + b/2);
}
Re[21]: поддержка компонентной разработки
От: Erop Россия  
Дата: 29.05.05 22:11
Оценка:
Здравствуйте, Sinclair, Вы писали:

E>>Всё-таки хотелось бы понять что же нужно от языка для "действительно хорошей GUI библиотеке" такого, чего нет в C++.
S>Поддержки компонентной разработки. Я не буду расшифровывать — все это уже обсасывалось, и в том числе в этом форуме.

Можно понятнее?

Поиск вот так что-то ничего кроме как COM не дал. Но COM -- зело таки порождение C++

А если я правильно понимаю, кто такая "поддержка компонентной разработки", то это в основном требования к среде, а не к языку.
Если говорить о C++ и построении GUI, то смотрим на PowerPlant, например. Я не знаю насколько это супер библиотека, но она бесшовно интегрирована в среду (CodeWarrior) и в неё можно так же бесщовно интегрировать свои контролы, довольно произвольной степени сложности. При это они будут поддерживаться встроенными в среду средствами наровне со стандартной библиотекой.

Таки я не понимаю, что же не так в C++ именно с компонентной разоработкой, равно и то, зачем она нужна для хорошей GUI библиотеки
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[2]: Почему настоящие программисты избегают C++
От: Mr. None Россия http://mrnone.blogspot.com
Дата: 30.05.05 04:11
Оценка:
Здравствуйте, EcliptoR, Вы писали:

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

ER>Ну не нравится не пиши на С++, че флейм то разжигать.
ER>Ксати, а есть что нибудь лучше С++, с таким же коммерческим успехом.

DB>>1.Отсутствие модулей. Имитация понятия модуль в виде пары h-файл – cpp-файл приводит к многочасовым компиляциям системы.

ER>Можно все в хэдере писать. Никто не запрещает.

НЕЕЕТ!!!!!! НЕ НАДО!!!!!!!!!!!!!!!!!!!! Эта ветка уже задолбала!!!!! Пусть она спокойно умрёт, не начинайте этот флейм с начала!!!!!!!!!!!!! Всё что вы тут сказали уже было сказано и пересказано на 3 раза!!!!!!!!! Пошлите лучше
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Re[20]: А всё-так чем же pascal дгчше для GUI библиотек-то?
От: Kh_Oleg  
Дата: 30.05.05 07:27
Оценка:
Здравствуйте, Владик, Вы писали:

K_O>>finalization код выполняется в деструкторе объекта, а в С++ исключение в деструкторе — это undefined behaviour.

В>В С++ исключение в деструкторе — это вполне себе defined behaviour. Хотя и плохой тон. Проблемы начинаются в случае, когда деструктор вызывается уже как реакция на возбуждение исключения.

Так я ж про это и говорю — читайте внимательнее.
Re[21]: SEH и C++ синонимы или нет?
От: Erop Россия  
Дата: 31.05.05 07:49
Оценка:
Здравствуйте, Kh_Oleg, Вы писали:

AE>>Что насчет __try... __finally в с++ ? Хотя это и MS-specific но все же...
K_O>Все эти изменения в языке или макросы в библиотеках — все это заплатки, свидетельствующие о кривизне языка С++.

Собственно SEH -- это часть WIN32. Интерфейс этой части требует поддержки со стороны компилятора (требуется формировать специфический фрейм), так что менять компилятор, для поддержки SEH всё равно надо. От чего бы не добавить для этого специальные операторы в язык? Это конечно не по C++ному, но зато по SEHовски

Так что пи чём тут C++ вообще не понятно
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[22]: Я тоже не люблю гибкость :)
От: Kh_Oleg  
Дата: 31.05.05 08:21
Оценка:
Здравствуйте, Erop, Вы писали:

K_O>>Все эти изменения в языке или макросы в библиотеках — все это заплатки, свидетельствующие о кривизне языка С++.

E>Забавно, а вот приверженцы C++, обычно, возможность вводить в язык новые синтаксические кончтрукции при помощи макросов и хитрых шаблонов и перегруженных операторов, называют гибкостью и считают одним из огромных достоинств языка

Они просто не отлаживали и не сопросвождали свои "хитрые синтаксические конструкции".

Однако, я имел ввиду не макросы вообще, а RUNTIME_CLASS конкретно. А недостаток в том, что он доступен только при использовании MFC.

E>Так что по этому поводу спорить толку нет. Кому-то нарвится, чтобы в языке были зафиксированы стандартные средства на удовлетворение каждой нужды, а кому-то нравится гибкость. Впринципе в случае стандартной задачи и хорошего владения инструментом рулит первый подход В слкчае, риска того, что задача вдруг станет нестандартной -- второй.

E>Но я всё равно не понял при чём тут GUI

Вообще, изначально ветка была именно про С++ и почему он плох при создании больших систем с GUI.
Re[22]: SEH и C++ синонимы или нет?
От: Kh_Oleg  
Дата: 31.05.05 08:22
Оценка:
Здравствуйте, Erop, Вы писали:

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

AE>>>Что насчет __try... __finally в с++ ? Хотя это и MS-specific но все же...
K_O>>Все эти изменения в языке или макросы в библиотеках — все это заплатки, свидетельствующие о кривизне языка С++.

E>Собственно SEH -- это часть WIN32. Интерфейс этой части требует поддержки со стороны компилятора (требуется формировать специфический фрейм), так что менять компилятор, для поддержки SEH всё равно надо. От чего бы не добавить для этого специальные операторы в язык? Это конечно не по C++ному, но зато по SEHовски

E>Так что пи чём тут C++ вообще не понятно

Речь идет именно о языке, который предетдует на роль универсального языка для кроссплатформенной разработки. И приведены аргументы, почему он на эту роль не подходит.
Re[12]: Почему настоящие программисты избегают C++
От: johny5 Новая Зеландия
Дата: 31.05.05 09:21
Оценка:
A>.NET же, отвечая на вопрос "почему"... Во-первых, вряд ли прародителем была именно Дельфа.

Ходят слухи, что microsoft при написания .Net выкрала у borland главного проектировщика VCL (фамилию я как всегда не помню, кто знает может кинет.. ).

Лично мне переход Builder -> .Net дался жутко легко, чуствуешь себя как дома — те же properties, синтаксис методов.. Правда пришлось столкнуться с managed c++ но это другое.

p.s.: например в VB существовало понятие Tag у объектов?
... << RSDN@Home 1.1.4 beta 6a rev. 443>>
Re: Почему настоящие программисты избегают C++
От: nataniel  
Дата: 31.05.05 09:23
Оценка:
черт, даже не знаю, в юмор это записать или сюда...
приведу кусок кода, в который я залез час назад. Цель программы — получение информации о сетевых адапторах
int MibII::MIB_GetIPAddress(DWORD *MIB_Array,int max_addresses, 
    BOOL bShowLoopbackAddress)
{

    UINT OID_ipAdEntAddr[] = { 1, 3, 6, 1, 2, 1, 4 , 20, 1 ,1 };
    AsnObjectIdentifier MIB_ipAdEntAddr = 
    { sizeof(OID_ipAdEntAddr)/sizeof(UINT), OID_ipAdEntAddr };
    RFC1157VarBindList  varBindList;
    RFC1157VarBind      varBind[1];
    AsnInteger          errorStatus;
    AsnInteger          errorIndex;
    AsnObjectIdentifier MIB_NULL = {0,0};
    BOOL                Exit;
    int                 ret;
    int                 IpCount=0;
    DWORD               dtmp;
    BYTE                a1,a2,a3,a4;
    
    varBindList.list = varBind;
    varBindList.len  = 1;
    varBind[0].name  = MIB_NULL;
    SNMP_oidcpy(&varBind[0].name,&MIB_ipAdEntAddr);
    Exit = FALSE;
    
    IpCount=0;

    while(!Exit){
        ret = Query(ASN_RFC1157_GETNEXTREQUEST,&varBindList,
            &errorStatus,&errorIndex);
        
        if(!ret)
            Exit=TRUE;
        else{
            ret = SNMP_oidncmp(&varBind[0].name,&MIB_ipAdEntAddr,
                MIB_ipAdEntAddr.idLength);
            if(ret!=0){
                Exit=TRUE;
            }
            else
            {
                dtmp = *((DWORD *)varBind[0].value.asnValue.address.stream);
                if (dtmp!=0)
                {
                    // Octets in returned IP addresses are in reverse order
                    a1=(BYTE)((dtmp>>24) & 0xFF);
                    a2=(BYTE)((dtmp>>16) & 0xFF);
                    a3=(BYTE)((dtmp>>8) & 0xFF);
                    a4=(BYTE)(dtmp & 0xFF);

                    if ((a4!=127) && (a4!=0))
                    {
                        *MIB_Array = (a4<<24) + (a3<<16) + (a2<<8) + a1;
                        *MIB_Array++;
                        IpCount++;
                    }
                    else
                    {
                        if (bShowLoopbackAddress)
                        {
                            *MIB_Array = (a4<<24) + (a3<<16) + (a2<<8) + a1;
                            *MIB_Array++;
                            IpCount++;
                        };
                    };
                };

                if(IpCount>=max_addresses)
                    Exit = TRUE;
            }
        }
    }

    SNMP_FreeVarBind(&varBind[0]);

    return IpCount;
}

Обратите внимаение, какие мудреные условия для выхода из цикла
А условия внутри цикла... нет слов

MIB_Array — это временный статический массив; когда функция завершается, из него копируются данные в другой, такой же массив
max_addresses — отдефайненая константа
... да что это я, смотрите сами:

int CSysInfo::MIBRefreshAddresses()
{
    int i,nAddresses=0; BOOL bDiff=FALSE;

    for(i=0;i<MAX_IPADDRESSES;i++)
        { m_dwMIBIPArray_tmp[i]=0; };

    nAddresses=m_mib.MIB_GetIPAddress(&m_dwMIBIPArray_tmp[0],
        MAX_IPADDRESSES,m_bMIBShowLoopback);

    if (m_nMIBAddresses!=nAddresses)
    {
        bDiff=TRUE;
    }
    else
    {
        for (i=0;i<nAddresses;i++)
        {
            if (m_dwMIBIPArray[i]!=m_dwMIBIPArray_tmp[i])
            {
                bDiff=TRUE;
                break;
            };
        };
    };

    if (bDiff)
    {
        for(i=0;i<nAddresses;i++)
        {
            m_dwMIBIPArray[i]=m_dwMIBIPArray_tmp[i];
        };
        m_nMIBAddresses=nAddresses;
    };

    return m_nMIBAddresses;
}


Я, может, ошибаюсь, но этот человек не с Делфи пришел не так давно?
Скажите, это Делфи заставляет так писать или это его личная инициатива?
Re[2]: Почему настоящие программисты избегают C++
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 31.05.05 09:43
Оценка:
Здравствуйте, nataniel, Вы писали:

N>
N>int CSysInfo::MIBRefreshAddresses()
N>{
...
N>    if (m_nMIBAddresses!=nAddresses)
N>    {
N>        bDiff=TRUE;
N>    }
N>    else
N>    {
N>        for (i=0;i<nAddresses;i++)
N>        {
N>            if (m_dwMIBIPArray[i]!=m_dwMIBIPArray_tmp[i])
N>            {
N>                bDiff=TRUE;
N>                break;
N>            };
N>        };
N>    };
...
N>}
N>


N>Я, может, ошибаюсь, но этот человек не с Делфи пришел не так давно?
N>Скажите, это Делфи заставляет так писать или это его личная инициатива?

Особенно умиляют точки с запятой после закрывающих фигурных скобок. Интересно, автор с ними на такие грабли никогда не наступал:
if( a )
    if( a > 10 )
        {
            std::cout << "a > 10" << std::endl;
        };
    else
        std::cout << "a <= 10" << std::endl;

?

... << RSDN@Home 1.1.4 beta 7 rev. 447>>

SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[25]: SEH и C++ синонимы или нет?
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 31.05.05 09:48
Оценка:
Здравствуйте, Kh_Oleg, Вы писали:

В>>И тем не менее, по факту он им является Как раз потому, что не заточен под всякие SEH и т.п. platform-specific. Тебе уже популярно объяснили, что finally в C++ нужен не более, чем goto (если еще не понял — воспользуйся поиском по сайту, эта тема неоднократно обсуждалась). Разница только в том, что goto в языке официально есть (пресловутая совметимость с С этому не последняя причина), а finally — нет. Но это не мешает большинсву программистов всячески избегать применения goto или принципиально обходится без него (при этом не напрягаясь). Код, не загроможденный лестницами try/finally, выглядит намного понятнее, а на тот единичный случай, когда совсем влом писать отдельный и очень специфичный guard для выполнения какого-либо финализирующего действия — можно воспользоваться обобщенным guard'ом с функтором.

K_O>Не знаю, что такое guard с функтором, но если он работает также, как и обычные guards — т.е. если finalization код вызывается в деструкторе некоторого объекта, но такой подход неприменим при создании exception-safe приложений.



О как! А мужики-то и не знают!
... << RSDN@Home 1.1.4 beta 7 rev. 447>>

SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[3]: Почему настоящие программисты избегают C++
От: nataniel  
Дата: 31.05.05 10:10
Оценка:
Здравствуйте, eao197, Вы писали:

E>?

E>

я не понимаю, почему после while () {} точка с запятой не стоит...
Re[25]: Почему настоящие программисты избегают C++
От: Erop Россия  
Дата: 01.06.05 22:15
Оценка:
Здравствуйте, AVC, Вы писали:

AVC>Вот ссылка:
AVC>http://www.inr.ac.ru/~info21/info/koltashev.jpg

Мне там особенно понравилось про "впервые удалось написать систему, которую можно было отлаживать в диалоговом режиме в терминах языка программирования"

Интересно, они хоть какую-то современную среду разработки видали?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[21]: Почему настоящие программисты избегают C++
От: Erop Россия  
Дата: 01.06.05 22:18
Оценка:
Здравствуйте, The Lex, Вы писали:

TL>Т.е. вы хотите сказать, что ежели дочернее окно и родительское окно будут иметь разные потоки, то возникнут проблемы? Хм... Можно огласить весь код? Можно в новую тему...

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

В смысле сама винда конечно нифига дедлок не сделает, но если в программе будет ещё и какая-то логика взаимодействия нитей помимо окон, то без проблем
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[9]: Почему настоящие программисты избегают C++
От: Erop Россия  
Дата: 01.06.05 22:22
Оценка:
Здравствуйте, d Bratik, Вы писали:

DB>Есть алгоритмическая сложность, а есть архитектурная. С первым видом сложности справиться намного проще, чем со вторым.

DB>GUI (framework) — это огромная архитектурная сложность.

В принципе я соглдасен, что если GUI -- это огромнгая арх. сложность, то навернео лучше не на C++. МОжно много наколбасить

Всё-таки бывают ещё задачи, где архитектура очень сильно сложнее GUI. Всё-таки GUI обычно устроен не так чтобы очень сложно.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[9]: Почему настоящие программисты избегают C++
От: Erop Россия  
Дата: 01.06.05 22:24
Оценка:
Здравствуйте, AndrewJD, Вы писали:

AJD>Можешь описать, хотя бы в двух словах, как портировали под Мак?

А в чём проблемы? Он же писал, что гуй абстрагирован был от внутренней логики

Ну а остальное портится вполне, если с умом подойти
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[3]: Почему настоящие программисты избегают C++
От: Erop Россия  
Дата: 01.06.05 22:39
Оценка:
Здравствуйте, d Bratik, Вы писали:

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


Всё-таки бывают программы, в которых UI (не важно насколько он G) не самое сложное. Компилятор Дельфи например, я надеюсь таков. И скорее всего алгоритмы и структуры данных там не UI определяются.

И вообще любой Engine, который делает что-то нужное, а особенно наукоёмкое, частенько сложнее любого самого навороченного GUI.

Например, система реендринга Word'а скорее всего сложнее всего GUI вместе взятого. Или, например, Photoshop, я так подозреваю, что не в GUI там дело и пользуются им не из-за GUI и программируют там в основном не его

Вообще, КМК, в программировании ценно делать всё как можно проще, а не как можно сложнее. И есть вполне простые, легко масштабируемые подходы к написанию GUI.

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

Всё-таки обычно программе нужен engine, который делает что-то нужное пользователю.
Ну а если ты имеешь уже реализованные моторы, и строишь на их базе продукт, в котором самое сложное и дорогое в разработек -- это GUI, то наверное C++ для тебя действительно может оказаться "пушкой, для стрельбы по воробьям"

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

C++ -- уникальная штука. Это такой странный гибрид "ужа с ежом", что язык может быть чем-то очень высокоуровневым, но может оказаться чем-то вроде ассемблера. Он почти не прячет от программиста компьютер, на котором работает его программа. Но умудряется делать это псевдопереносимым способом. Мне кажется, что это чудо. Но за чудо приходится платить -- в любом месте программы мы можем оказаться программистами на языке низкого уровня. Так как мы от компа не защищены никак. Но в действительно сложных ситуациях так всё складывается, что приходится прибегать к этому чуду. Ну а в стандартных, зато, приходится платить удорожением разработки.
Только и всего.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[6]: Почему настоящие программисты избегают C++
От: Erop Россия  
Дата: 01.06.05 22:56
Оценка:
Здравствуйте, xBlackCat, Вы писали:

BC>Уже такие перцы есть! Смотреть здесь

Это халява. Я как-то видел на много более полезное практически извращение на эту тему.

Это был com файл, который умел разUUEть письма. При этом он был записан только печатными символами и концами строк. И строки все были короткими. Так что его можно было прислать по мылу прямо вместе с инструкциями, ну и потом слать уже нормальные вложения. Ну а уж потом...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[12]: Почему настоящие программисты избегают C++
От: Михаил  
Дата: 02.06.05 07:06
Оценка:
Здравствуйте, AVC, Вы писали:

AVC>Рассмотрим простой пример:
AVC>
AVC>PROCEDURE InitArray(VAR a: ARRAY OF INTEGER);
AVC>  VAR i: LONGINT;
AVC>BEGIN
AVC>  FOR i := 0 TO LEN(a)-1 DO
AVC>    a[i] := 0
AVC>  END
AVC>END InitArray;
AVC>

AVC>Много ли нужно run-time проверок, чтобы удостовериться, что индекс не выходит за границы массива?
AVC>Очевидно, ни одной. Потери эффективности нет вовсе!

Только если i — это константа внутри цикла. Что _обязан_ везде_проверять_ компилятор.
Кстати, если в этом есть необходимость — ничего не мешает в этом случае слово const писать на С для адреса и длины массива. Будет то же самое. То, что у кого-то руки кривые (не делает так) — ни о чем не говорит.
Таким образом, на С есть средства, которые позволяют создавать код, АБСОЛЮТНО АНАЛОГИЧНЫЙ вышеприведенному.
Еще есть понятие "защищенного массива". В котором с помощью #ifdef выделить run-time проверку. И включать или выключать ее при компиляции. Где угодно и сколько угодно. Посмотри CArray в MFC например. Он так и работает.
Кстати, как тогда в обероне насчет "ходовой" сортировки? При таких ограниченных циклах только пузырьковую возможно применить. Или ОС предоставит встроенные алгоритмы на все случаи жизни?

AVC>Проверка на выход за границы массива в данном случае полностью происходит на этапе компиляции.
AVC>А вот для Си/Си++ это невозможно: там передается не массив, а указатель. Что не одно и то же.

М>>А вот как проверять те замысловатые хитросплетения, которые там на самом деле есть — это под большим вопросом.
AVC>А в чем, собственно, заключается этот "большой" вопрос?

Например, как Оберон хранит в памяти директории, файлы, кластеры которые есть на диске.
Тоже в массивах? И они на этапе компиляции создаются?
А буфер для устройства вроде сканера или сетевой карты как сделать.
Устройство в одном из параметров возвращает число байт, которое им обработано или передано в ответ на запрос.
Запросы-ответы идут непрерывно в обе стороны.
Вот когда надо массив с результатом создавать? И как, когда узнать его окончательный размер?
С помощью ОС динамически массив наращивать?
Как вообще предлагается работать с _большими_ массивами переменной длины? Которые могут быть и намного больше размера оперативки. Как такой массив обработать редактором, например.
...А отсюда наливаем, когда рецепт написан совсем неразборчиво...
Re[13]: Почему настоящие программисты избегают C++
От: AVC Россия  
Дата: 02.06.05 22:31
Оценка:
Здравствуйте, Михаил, Вы писали:

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

AVC>>Рассмотрим простой пример:
AVC>>
AVC>>PROCEDURE InitArray(VAR a: ARRAY OF INTEGER);
AVC>>  VAR i: LONGINT;
AVC>>BEGIN
AVC>>  FOR i := 0 TO LEN(a)-1 DO
AVC>>    a[i] := 0
AVC>>  END
AVC>>END InitArray;
AVC>>

AVC>>Много ли нужно run-time проверок, чтобы удостовериться, что индекс не выходит за границы массива?
AVC>>Очевидно, ни одной. Потери эффективности нет вовсе!

М>Только если i — это константа внутри цикла. Что _обязан_ везде_проверять_ компилятор.
М>Кстати, если в этом есть необходимость — ничего не мешает в этом случае слово const писать на С для адреса и длины массива. Будет то же самое. То, что у кого-то руки кривые (не делает так) — ни о чем не говорит.
М>Таким образом, на С есть средства, которые позволяют создавать код, АБСОЛЮТНО АНАЛОГИЧНЫЙ вышеприведенному.

К сожалению, Си не имеет средств, позволяющих создавать код "аналогичный вышеприведенному".
Добавление const также не решает проблему.
Представим себе эту игрушечную процедуру на Си:
void InitArray(int * const a, const int n)
{
    int i;

    for (i = 0; i < n; ++i)
        a[i] = 0;
}

Кажется, Вы полагаете, что этот код "АБСОЛЮТНО АНАЛОГИЧНЫЙ вышеприведенному".
Но это не так. Для компилятора между указателем a и целым числом n нет связи.
Это значит, что компилятор Си не может гарантировать защиту памяти.
Почему, например, следующий код должен считаться некорректным?
void InitArray(int * const a, const int n)
{
    int i;

    for (i = -1; i <= n; ++i)
        a[i] = 0;
}

Вообще, кто сказал, что a — это массив?
Что мешает написать
void foo()
{
    int *ip;

    ip = (int *) malloc(sizeof (*ip));
    InitArray(ip, 1024);
}

?
Как видите, Си не может бороться даже с явно бредовым кодом.

М>Например, как Оберон хранит в памяти директории, файлы, кластеры которые есть на диске.
М>Тоже в массивах? И они на этапе компиляции создаются?

В Обероне массивы (в том числе многомерные) могут создаваться динамически.
Например, создадим матрицу заранее неизвестной размерности:
TYPE Matrix = POINTER TO ARRAY OF ARRAY OF REAL;
PROCEDURE NewMatrix(rows, cols: INTEGER): Matrix;
  VAR new: Matrix;
BEGIN
  NEW(mat, rows, cols);
  RETURN mat
END NewMatrix;


М>Вот когда надо массив с результатом создавать? И как, когда узнать его окончательный размер?

Возьмем пример с той же матрицей.
VAR matrix: Matrix;
Тогда
LEN(matrix, 0) — число строк
LEN(matrix, 1) — число столбцов.

М>С помощью ОС динамически массив наращивать?
М>Как вообще предлагается работать с _большими_ массивами переменной длины? Которые могут быть и намного больше размера оперативки. Как такой массив обработать редактором, например.

Так же как и в Си++: создайте класс.

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

Хоар
Re[14]: Почему настоящие программисты избегают C++
От: Михаил  
Дата: 02.06.05 23:29
Оценка:
Здравствуйте, AVC, Вы писали:

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

AVC>К сожалению, Си не имеет средств, позволяющих создавать код "аналогичный вышеприведенному".
AVC>Добавление const также не решает проблему.
AVC>Представим себе эту игрушечную процедуру на Си:
AVC>
AVC>void InitArray(int * const a, const int n)
AVC>{
AVC>    int i;

AVC>    for (i = 0; i < n; ++i)
AVC>        a[i] = 0;
AVC>}
AVC>

AVC>Кажется, Вы полагаете, что этот код "АБСОЛЮТНО АНАЛОГИЧНЫЙ вышеприведенному".
AVC>Но это не так. Для компилятора между указателем a и целым числом n нет связи.
AVC>Это значит, что компилятор Си не может гарантировать защиту памяти.

inline void body(int* const a, const int i)
{
      a[i]=0;
}
void InitArray(int * const a, const int n)
{
    int i;

    for (i = 0; i < n; ++i)
        body(a, i);
}


Хотя не знаю, кому в голову такое написать придет .
Однако, если в body лежит кусок кода в 100К размером (куча вложенных функций) — это будет уже совсем не лишнее. Хотя inline желательно будет убрать.
Второе решение — использовать защищенный класс, в котором есть оператор [] и в нем проверка.
void InitArray(CProtectedArrayOfInt a, const int n)

AVC>Почему, например, следующий код должен считаться некорректным?
(...)
AVC>Как видите, Си не может бороться даже с явно бредовым кодом.

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

М>>Например, как Оберон хранит в памяти директории, файлы, кластеры которые есть на диске.
М>>Тоже в массивах? И они на этапе компиляции создаются?

AVC>В Обероне массивы (в том числе многомерные) могут создаваться динамически.
AVC>Например, создадим матрицу заранее неизвестной размерности:
AVC>
AVC>TYPE Matrix = POINTER TO ARRAY OF ARRAY OF REAL;
AVC>PROCEDURE NewMatrix(rows, cols: INTEGER): Matrix;
AVC>  VAR new: Matrix;
AVC>BEGIN
AVC>  NEW(mat, rows, cols);
AVC>  RETURN mat
AVC>END NewMatrix;
AVC>


М>>Вот когда надо массив с результатом создавать? И как, когда узнать его окончательный размер?

AVC>Возьмем пример с той же матрицей.
AVC>VAR matrix: Matrix;
AVC>Тогда
AVC>LEN(matrix, 0) — число строк
AVC>LEN(matrix, 1) — число столбцов.

М>>С помощью ОС динамически массив наращивать?
М>>Как вообще предлагается работать с _большими_ массивами переменной длины? Которые могут быть и намного больше размера оперативки. Как такой массив обработать редактором, например.

AVC>Так же как и в Си++: создайте класс.
Ирония осталась непонятой .
Ну, вот такая проблемка есть у драйверов: им совсем некогда динамически память выделять. Байты от устройства потеряются. Или блокировка на ресурсы возникнет в многозадачной среде. Зачем ring0 придумали — поинтересуйтесь!
...А отсюда наливаем, когда рецепт написан совсем неразборчиво...
Re[15]: Почему настоящие программисты избегают C++
От: Sinclair Россия https://github.com/evilguest/
Дата: 03.06.05 03:38
Оценка:
Здравствуйте, Михаил, Вы писали:


М>Хотя не знаю, кому в голову такое написать придет .
Я тебя уверяю — подавляющее большинство разработчиков по инструкции "выделить буфер размером 512 байт" пишут именно так:
void* buf = malloc(512);
...
PasstoSomeFunc(buf, 0, 2, 0x1|0x4, 512);

Стоит ли удивляться, что потом меняется только одна из двух магических констант (или две из трех, или восемь из десяти)?
Конечно, можно отвыкнуть их от этого. Но практика показывает, что лучше отдать эту нудятину среде/компилятору, чем упражняться в педагогике. Со всех точек зрения.
Кроме ровно одной: "зато если человек написал работающую программу на плюсах — это Программист! А на всех этих Delphi, C#, Java и проч. люди годами пишут успешные приложения, вообще ничего о программировании не зная..."
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[4]: Почему настоящие программисты избегают C++
От: johny5 Новая Зеландия
Дата: 03.06.05 05:45
Оценка:
N>Может, с годами и опытом проходит желание создать свой контрол, написанный с нуля или почти с нуля (наследуемся от CWnd) ?
N>А что легче, быстрее, понятнее etc — написать, например, всплывающую панель, как в VS .NET (или любой другой нестандартный контрол) — написать на С++ или на Делфи? Я совсем недавно сделал свое дерево, у которого единственное сходство со стандартным в том, что это дерево. Я получал удовольствие от того, что понимаю до конца, что написано, и что могу манипулировать данными и вообще языком, как мне захочется.

С годами само не проходит, нужно упорно, насильно заставлять себя доверять чужому коду.. Иначе вся жизнь твоя будет в велосипедах и ничего нового ты написать не успеешь
... << RSDN@Home 1.1.4 beta 6a rev. 443>>
Re[16]: Почему настоящие программисты избегают C++
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 03.06.05 08:25
Оценка:
Здравствуйте, Sinclair, Вы писали:

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


М>>Хотя не знаю, кому в голову такое написать придет .
S>Я тебя уверяю — подавляющее большинство разработчиков по инструкции "выделить буфер размером 512 байт" пишут именно так:
S>
S>void* buf = malloc(512);
S>...
S>PasstoSomeFunc(buf, 0, 2, 0x1|0x4, 512);
S>

S>Стоит ли удивляться, что потом меняется только одна из двух магических констант (или две из трех, или восемь из десяти)?
S>Конечно, можно отвыкнуть их от этого. Но практика показывает, что лучше отдать эту нудятину среде/компилятору, чем упражняться в педагогике. Со всех точек зрения.
S>Кроме ровно одной: "зато если человек написал работающую программу на плюсах — это Программист! А на всех этих Delphi, C#, Java и проч. люди годами пишут успешные приложения, вообще ничего о программировании не зная..."

Т.е., ты хочешь сказать, что в Delphi, C# и Java hardcoded константы можно использовать без проблем?
... << RSDN@Home 1.1.4 beta 7 rev. 447>>

SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[17]: Почему настоящие программисты избегают C++
От: Sinclair Россия https://github.com/evilguest/
Дата: 03.06.05 08:50
Оценка:
Здравствуйте, eao197, Вы писали:

E>Т.е., ты хочешь сказать, что в Delphi, C# и Java hardcoded константы можно использовать без проблем?

В C# и Java вместо прохода по памяти в ты получишь нормальный index out of bounds. По крайней мере, другие потоки в твоем процессе будут дальше жить. В Delhi для типовых задач нажо писать меньше кода, что дает меньше возможностей напакостить.
Хотя, конечно, предела совершенству нету — забавнее всего смотреть на Delphi-код, написанный незнакомыми с VCL программистами. Все вручную, и все через ж...технологическое отверстие. Как выбрать в комбобоксе элемент №5? Нет, неправильно, никаких ItemIndex. Надо добавить в название каждого итема его номер, вот так: "<1> Item one", "<2> Item two". А потом в цикле перебирать итемы, парсить и проверять. С обязательными штуками типа 
If ffxidx <> 0 then
  cmb1.itemIndex:= ffxidx else 
 cmb1.itemindex :=0

(форматирование оригинала сохранено)
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[18]: Почему настоящие программисты избегают C++
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 03.06.05 08:55
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

E>>Т.е., ты хочешь сказать, что в Delphi, C# и Java hardcoded константы можно использовать без проблем?

S>В C# и Java вместо прохода по памяти в ты получишь нормальный index out of bounds. По крайней мере, другие потоки в твоем процессе будут дальше жить.

Имхо, в C# и Java эта ошибка будет на несколько порядков быстрее локализована. А вот будет ли этот index out of bounds exception менее пагубным -- еще вопрос.
Так что проблема в использовании магических констант (что от языка не зависит), а уже следствия в разных языках могут быть разные. И не обязательно в C++ они будут самыми катострофическими, имхо.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>

SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[19]: Почему настоящие программисты избегают C++
От: Sinclair Россия https://github.com/evilguest/
Дата: 03.06.05 09:52
Оценка:
Здравствуйте, eao197, Вы писали:

E>Имхо, в C# и Java эта ошибка будет на несколько порядков быстрее локализована.
Верно, благодаря Stack Trace
E>А вот будет ли этот index out of bounds exception менее пагубным -- еще вопрос.
Никаких вопросов. Проход по памяти -> обрушение процесса. Для десктоп-приложения index out of bounds — не менее смертелен, потому как если он не обработан (а он нифига не обработан), то инварианты нарушены, и с вероятностью 70% любое следующее действие пользователя приведет к наведенной ошибке. Остается только маленький шанс, что "сохранить изменения" все еще будет доступно
E>Так что проблема в использовании магических констант (что от языка не зависит), а уже следствия в разных языках могут быть разные. И не обязательно в C++ они будут самыми катострофическими, имхо.
А вот на сервере в неуправляемой среде проход по памяти проносится по всем потокам как метеор, оставляя неконтролируемые разрушения для всех пользователей. Управляемое приложение уронит одну пользовательскую сессию; более того — в steteless модели это затронет только один текущий request. Пользователь давит back в браузере и продолжает работать. Подобный сбой в неуправляемом коде может убить весь сервер.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re: Почему настоящие программисты избегают C++
От: Ka3a4oK  
Дата: 04.06.05 18:33
Оценка:
DB>3.Отсутствие встроенной проверки на выход за диапазоны массива. Приводит к необходимости писать «обертки» для классов-контейнеров (в частности, для класса vector).
А vector::at ? Хочешь безопасно, но медленно — vector::at. Небезопасно но быстро — vector::operator[]. Хочешь — итераторы, хочешь — индексы. В этом и сила С++, брат.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Re[17]: Почему настоящие программисты избегают C++
От: AVC Россия  
Дата: 05.06.05 16:07
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>AVC wrote:

>> Честно говоря, я не понял *какую именно* проблему Вы решаете этими
>> двумя способами.
>> Особенно первым.
>> Что касается второго, то в нем предлагается создать класс, содержащий
>> run-time проверки индекса массива.
>> Это похвальная попытка скомпенсировать отсутствие в языке строгой
>> типизации.

C>Ррррр.... Никакая статическая типизация не поможет в проверке контроля
C>выхода за границы массива, если есть динамическое распределение памяти.

Интересно, откуда такое убеждение?
Конечно, я помню, что Вы фанат Си++. Но ведь пишете Вы не только на этом языке.
Может быть, Вы хотите извлечь какой-то аргумент из терминологической путаницы, заменив мою "строгую" (strict)типизацию на Вашу "статическую"?
В любом случае, это Ваше убеждение неверно.
Рассмотрим тот же игрушечный пример, который я приводил Михаилу.
PROCEDURE InitArray(VAR a: ARRAY OF INTEGER);
  VAR i: LONGINT;
BEGIN
  FOR i := 0 TO LEN(a)-1 DO
    a[i] := 0
  END
END InitArray;

Очевидно, что цикл корректен без run-time проверок, т.к. LEN(a) — это не какое-то неизвестное число n, а однозначная характеристика (длина) самого массива a, о чем компилятору Оберона известно, в отличие от компилятора Си/Си++, лишенного подобной информации.
Теперь допустим, что массив был создан динамически:
VAR ap: POINTER TO ARRAY OF INTEGER;
  n: INTEGER;
(* ... другие строки исходного текста *)
  NEW(ap, n);
  InitArray(ap^);

Мы видим, что массив был создан динамически, затем передан в процедуру InitArray.
Разве это повлияло на корректность процедуры InitArray?
Ни в малейшей степени.
Т.е., несмотря на динамическое распределение памяти, проверка корректности индекса массива в процедуре InitArray остается "строгой" и даже "статической".

>> Так вот, я просто хочу обратить Ваше внимание на то, что *для
>> компилятора* p и size — по прежнему две отдельные переменные, не
>> имеющие между собой ничего общего. Если при реализации класса
>> CProtectedArrayOfInt Вы (не дай Бог! ) допустите ошибку, компилятор
>> ничем не сможет Вам помочь.

C>А чем мне в этом случае поможет Оберон? В нем будет абсолютно такая же
C>ситуация.

Только что я привел пример, что ситуация в Оберона совсем другая.
Размерность массива контролируется компилятором в любой точке программы, в то время как в Си/Си++ информация о размерности массива утрачивается при передаче массива в качестве параметра.
Я уже не говорю о том, что в Си/Си++ нет многомерных открытых (гибких) массивов...
В сущности, можно сказать, что в Си/Си++ вообще нет массивов.

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

Хоар
Re[18]: Почему настоящие программисты избегают C++
От: Cyberax Марс  
Дата: 05.06.05 17:22
Оценка:
AVC wrote:

> Конечно, я помню, что Вы фанат Си++. Но ведь пишете Вы не только на
> этом языке.
> Может быть, Вы хотите извлечь какой-то аргумент из терминологической
> путаницы, заменив мою "строгую" (strict)типизацию на Вашу "статическую"?
> В любом случае, это Ваше убеждение неверно.
> Рассмотрим тот же игрушечный пример, который я приводил Михаилу.
>
>PROCEDURE InitArray(VAR a: ARRAY OF INTEGER);
> VAR i: LONGINT;
>BEGIN
> FOR i := 0 TO LEN(a)-1 DO
> a[i] := 0
> END
>END InitArray;
>
>
> Очевидно, что цикл корректен без run-time проверок, т.к. LEN(a) — это
> не какое-то неизвестное число n, а однозначная характеристика (длина)
> самого массива a, *о чем компилятору Оберона известно*, в отличие от
> компилятора Си/Си++, лишенного подобной информации.

В данном _простейшем_ случае компилятор может проверить корректность
кода (кстати, для С++ есть верефикаторы, делающие тоже самое).
А вот для такого случая уже ничего не получится:
PROCEDURE InitArray(VAR a: ARRAY OF INTEGER);
 VAR i: LONGINT;

BEGIN
  FOR i := 0 TO LEN(a)-1 DO
    a[someFunction(i)] := 0
  END
END InitArray;



> Мы видим, что массив был создан динамически, затем передан в процедуру
> InitArray.
> Разве это повлияло на корректность процедуры InitArray?
> Ни в малейшей степени.
> Т.е., несмотря на динамическое распределение памяти, проверка
> корректности индекса массива в процедуре InitArray остается "строгой"
> и даже "статической".

Зато указатель уже не является массивом, а это очень часто нужно для
программ низкого уровня.

> C>А чем мне в этом случае поможет Оберон? В нем будет абсолютно такая же
> C>ситуация.
> Только что я привел пример, что ситуация в Оберона *совсем другая*.

Да. Компилятор может поймать несколько простых случаев нарушения границ,
но при этом требует повсеместного использования специальных массивов.

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

Для передачи размерности есть std::vector (который, кстати, понимают
верефикаторы).

> Я уже не говорю о том, что в Си/Си++ нет многомерных открытых (гибких)
> массивов...

boost::multi_array — гибкости во много раз больше Обероновских.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[16]: Почему настоящие программисты избегают C++
От: Михаил  
Дата: 06.06.05 00:29
Оценка:
Здравствуйте, AVC, Вы писали:

AVC>Так вот, я просто хочу обратить Ваше внимание на то, что для компилятора p и size — по прежнему две отдельные переменные, не имеющие между собой ничего общего. Если при реализации класса CProtectedArrayOfInt Вы (не дай Бог! ) допустите ошибку, компилятор ничем не сможет Вам помочь.

Тогда не надо самому писать такие классы. Пользуйтесь готовыми. Я не понимаю, чем разработчикм С++ной библиотеки хуже создателей Оберона. Уже попахивает ладаном, свечами, бубнами и т.д.

AVC>(Кстати, этот опыт последних лет свидетельствует, что программисты, пишущие на Си, проявляют повышенный интерес к отладчику, т.к. зачастую не в состоянии найти ошибку в своих программах без его помощи.)
Отладчик, в сочетании с развитой системой навигации по коду — это просто наиболее удобный инструмент. Почему ему и предпочтение. Конечно если это производственный процесс, а не соревнование вундеркиндов.

AVC>Также согласен с Вами относительно идеологии Си. Кажется, главное из правил Spirit of C начинается так: "Не мешай программисту..."
AVC>Но вот в чем я с Вами не согласен, так это в понимании "высокоуровневости" языков программирования.
AVC>На мой взгляд, язык Си (равно как и Си++ в этом случае), не способный передать в подпрограмму даже информацию о
размерности массива, не может считаться высокоуровневым.
AVC>Весь смысл высокоуровневости — позволить компилятору гарантировать определенные свойства программ, например — безопасность типов (type safety).

Еще раз повторю — пользуйтесь библиотеками! Естественно, голый язык с несколькими десятками ключевых слов вряд ли будет кому-то сильно полезен. С++ (не С!) позволяет те же массивы "тюнинговать" как угодно.

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

AVC>Мне приходилось писать ПО, работающее автономно в очень жестком real-time, причем в системе безопасности.
AVC>Память под буфера отводилась заранее, а затем управлялась маленьким специализированным "распределителем памяти".
AVC>Не вижу никакого преимущества у Си/Си++ по сравнению с Обероном в данном случае.

Возникает впечатление, что проекты были существенно "бюджетные", что вызывало утечки мозгов и в конечном счете привело к таким заблуждениям насчет языка.
На мой взгляд, здесь обсуждаются в основном "детские" ошибки, нехарактерные для "продвинутых". То есть вылавливание которых не являются проблемой. И не потому что кода мало или алгоритмы простые. Просто он написан ТАКИМ ОБРАЗОМ, что вероятность ошибки МАЛА. И на порядок меньше, чем в боготворимых выше языках.
...А отсюда наливаем, когда рецепт написан совсем неразборчиво...
Re[2]: Почему настоящие программисты избегают C++
От: ilya_ny  
Дата: 06.06.05 00:43
Оценка:
Здравствуйте, EcliptoR, Вы писали:


DB>>1.Отсутствие модулей. Имитация понятия модуль в виде пары h-файл – cpp-файл приводит к многочасовым компиляциям системы.

ER>Можно все в хэдере писать. Никто не запрещает.

тогда будут огромные inline функции и *.obj будет намного большего размера..
Re[16]: Почему настоящие программисты избегают C++
От: ansi  
Дата: 06.06.05 01:03
Оценка:
AVC>
AVC>private:
AVC>    int *p;
AVC>    size_t size;
AVC>

AVC>Так вот, я просто хочу обратить Ваше внимание на то, что для компилятора p и size — по прежнему две отдельные переменные, не имеющие между собой ничего общего. Если при реализации класса CProtectedArrayOfInt Вы (не дай Бог! ) допустите ошибку, компилятор ничем не сможет Вам помочь.
А если разработчики Оберона допустят ошибку... В любом случае, ошибка, если она есть, локализована в одном месте и если класс работать не будет, то работать он не будет везде.
Re[14]: Почему настоящие программисты избегают C++
От: Михаил  
Дата: 06.06.05 01:26
Оценка:
Здравствуйте, AVC, Вы писали:

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

Далее имею в виду MSVC. Тем не менее согласен, что другие компиляторы С/С++ могут не иметь этого или иметь другое поведение (что лично мне фиолетово).
1. Не раз уже обсуждавшийся _DEBUG.
2. Из MSDN: (цитирую полностью, т.к. не уверен, что этот анекдот знают по номеру)

Memory Management and the Debug Heap
Two of the most common and intractable problems that programmers encounter are overwriting the end of an allocated buffer and leaking memory (failing to free allocations after they are no longer needed). The debug heap provides powerful tools to solve memory allocation problems of this kind.

The debug versions of the heap functions call the standard or base versions used in release builds. When you request a memory block, the debug heap manager allocates from the base heap a slightly larger block of memory than requested and returns a pointer to your portion of that block. For example, suppose your application contains the call: malloc( 10 ). In a release build, malloc would call the base heap allocation routine requesting an allocation of 10 bytes. In a debug build, however, malloc would call _malloc_dbg, which would then call the base heap allocation routine requesting an allocation of 10 bytes plus approximately 36 bytes of additional memory. All the resulting memory blocks in the debug heap are connected in a single linked list, ordered according to when they were allocated:

The additional memory allocated by the debug heap routines is used for bookkeeping information, for pointers that link debug memory blocks together, and for small buffers on either side of your data to catch overwrites of the allocated region.

Currently, the block header structure used to store the debug heap’s bookkeeping information is declared as follows in the DBGINT.H header file:

typedef struct _CrtMemBlockHeader
{
// Pointer to the block allocated just before this one:
struct _CrtMemBlockHeader *pBlockHeaderNext;
// Pointer to the block allocated just after this one:
struct _CrtMemBlockHeader *pBlockHeaderPrev;
char *szFileName; // File name
int nLine; // Line number
size_t nDataSize; // Size of user block
int nBlockUse; // Type of block
long lRequest; // Allocation number
// Buffer just before (lower than) the user's memory:
unsigned char gap[nNoMansLandSize];
} _CrtMemBlockHeader;

/* In an actual memory block in the debug heap,
* this structure is followed by:
* unsigned char data[nDataSize];
* unsigned char anotherGap[nNoMansLandSize];
*/

The “NoMansLand” buffers on either side of the user data area of the block are currently 4 bytes in size, and are filled with a known byte value used by the debug heap routines to verify that the limits of the user’s memory block have not been overwritten. The debug heap also fills new memory blocks with a known value. If you elect to keep freed blocks in the heap’s linked list as explained below, these freed blocks are also filled with a known value. Currently, the actual byte values used are as follows:

NoMansLand (0xFD)

The “NoMansLand” buffers on either side of the memory used by an application are currently filled with 0xFD.

Freed blocks (0xDD)

The freed blocks kept unused in the debug heap’s linked list when the _CRTDBG_DELAY_FREE_MEM_DF flag is set are currently filled with 0xDD.

New objects (0xCD)

New objects are filled with 0xCD when they are allocated.

...А отсюда наливаем, когда рецепт написан совсем неразборчиво...
Re[9]: Почему настоящие программисты избегают C++
От: Михаил  
Дата: 06.06.05 03:29
Оценка:
Здравствуйте, ZetRooT, Вы писали:

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

T>>жена — Pascal
T>>проститутка — C++
T>>любовница — ?


ZRT>тогда уж Java

не-а...
богатая дама.
...А отсюда наливаем, когда рецепт написан совсем неразборчиво...
Re[10]: Почему настоящие программисты избегают C++
От: Михаил  
Дата: 06.06.05 03:55
Оценка:
Здравствуйте, nixite, Вы писали:

MN>>Да согласен — ваша правда... это я поторопился... но как-то у меня такой проблемы никогда не было... наверное потому, что для работы с контейнерами C++ всегда использовал итераторы, а для доступа к массивам в стиле pure C использовал знаковый int и никогда не путал эти понятия между собой, чего и вам советую... ну или если вы моему совету не внемлите, то обращайтесь к С. Ю. Губанову — он вам других советов надаёт

N>для любителей signed int'ов:

N>положим захотелось нам искать среднее двух чисел и написали мы функцию:
N>int kaka (int a, int b){return (a+b)/2;}

N>и всё вроде тип-топ, но вот тут сунули нам два числа (вполне корректных):

N>int a = 2113929216;
N>int b = 2113929210;

А сколько надо
Т.е. какой смысл должен быть у среднего? Почему необходимо использовать signed int в таких диапазонах?
Может, лучше подойдет unsigned?
...А отсюда наливаем, когда рецепт написан совсем неразборчиво...
Re[12]: Почему настоящие программисты избегают C++
От: lepsai  
Дата: 24.06.05 23:51
Оценка:
Здравствуйте, ydab, Вы писали:

D>>Ну зачем же ставить заведомо нерешаемые задачи?
D>>Над такими лучшие умы человечества бьются не один десяток лет, а Вы хотите чтоб Вам на каком-то инетрнет-форуме всё разрулили.

Y>
Y>int kaka (int a, int b)
Y>{
Y>   return (a/2 + b/2);
Y>}
Y>



int kaka (int a, int b)
{
    return (a>>1 + b>>1);
}


 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.