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

VD>Переписывается все что хочешь. Вот только когда баг найдется. Люди лепят баги не специально.

Если я пишу unsigned n, то я всегда должен осознавать, какие правила арифметики будут применяться к n. Написание int n также не всегда позволяет избежать "задумчивости".

VD>Вот такие самоуверенные обычно первыми по граблям и ходят.

Машинная арифметика — это не то же самое, что общепринятая арифметика. Это фундаментально важно понимать. Есть языки программирования, которые стремятся "затушевать" эту разницу; тем не менее, языки вроде Си++ и Си-Шарпа, опирающиеся именно на машинную арифметику, почему-то находят большее применение. Если, имея unsigned n1, n2, пишешь n1 — n2, нужно четко понимать, что получится, будь n1 < n2.

Есть приложения, в которых существенно важной является арифметика по модулю 2^n; тогда естественный выбор — беззнаковые типы.

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

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

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

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

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

Здравствуйте, _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, чтобы поговорить подробнее?

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

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

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

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

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


Я привел список именно тех проблем, которые прочувствовал сам на собственных программах. На счет сборщика мусора -- да, его нужно было поставить на первое место (деинициализация должна быть отделена от освобождения памяти, как в Oberon и .NET), но эту проблему мне удалось побороть (правда, ценой определенного housekeeping-инга). Но есть кричащие проблемы, анализируя истоки которых приходишь к очень неутешительным выводам по поводу компетентности некоторых товарищей (Б.С.).

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

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

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

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

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

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

.

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

Наконец-то на RSDN появляется всамделишный Anti-C++ evanhelism.

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

K>>Проблема переполнения остаётся и при использовании беззнаковых целых. А для int в данном случае решение есть и простое (не сказал бы что красивое, но...). Приводим a и b к long long, а после деления обратно к int.

N>В стандарте C++ нет типа long long ! это всё мелгомягкие дополнения решения есть но ещё кривее
А ты спрашивал про простое, а не универсальное или мультиплатформенное решение.
P.S. Я могу ошибаться, но, кажется, CodeWarrior и gcc стали раньше VC поддерживать long long, у VC сначало появился __int64.

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

A>Машинная арифметика — это не то же самое, что общепринятая арифметика. Это фундаментально важно понимать. Есть языки программирования, которые стремятся "затушевать" эту разницу; тем не менее, языки вроде Си++ и Си-Шарпа, опирающиеся именно на машинную арифметику, почему-то находят большее применение. Если, имея unsigned n1, n2, пишешь n1 — n2, нужно четко понимать, что получится, будь n1 < n2.

мне кажется если была перенесена такая арифметика как есть, то нужны и полные средства работы с этой арифметикой, такие какие предоставляет ассемблер. (правда ассемблер ассемблеру рознь, но пусть будет хотябы x86)

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

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

мне тоже интересно, может новую ветку открыть о качественном портировании в Linux/Solaris из под виндовс и библиотеках GUI под них.

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

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

конечно так в лоб врядли встретишь, но (a+b)/2 довольно частaя операция, и схожие с ними, а предположить что кто-то сунет в функцию не съедобное рядовому программисту часто не доводится и потому он смотрит и недоумевает что же происходит в формуле с 10-ом операций, формула то абсолютно верная... (c т.з. обычной математики?). суровая реальность

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

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

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

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

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

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

Поскорее бы сдох этот Unix, этот Sun с его соляркой, чтобы пересесть на C# или на Delphi, или на Oberon наконец.

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

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

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

"Обидеть поэта может всякий! А вот понять его тонкую чуствительную натуру..." (с) не мое


DB>Поскорее бы сдох этот Unix, этот Sun с его соляркой, чтобы пересесть на C# или на Delphi, или на Oberon наконец.

Я угадал

Автор: AlexEagle
Дата: 18.02.05

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

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

Позвольте вставить свое Э )
Помню, как-то давно один молодой чел спрашивал на каком-то форуме, что ему выбрать для изучения — Паскаль или С++
Выдал я ему совет примерно такой — Паскаль — как строгая жена, все время в одной позе, зато почти безопасно. А с++ — проститутка, делай с ней что захочешь, но за последствия отвечаешь сам ))) Вот мне больше по душе как-то шлюхи, хотя на Дельфях тоже приходиться иногда.

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

Здравствуйте, 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% случаях просто ненужна!
А таких функций уйма!

Здравствуйте, 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). то что у вас некорректно функция объявлена не вина языка.

Здравствуйте, 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, т.к это единственное место, где без него не обойтись.

Здравствуйте, 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, это был
лучший компилятор.