Один из лучших компиляторов C++ для Linux прекращает существование

Pardon. Конечно STL.

Bear

2 anonymous (*) (2002-04-29 18:15:17.161)

>А ведь о приемуществе С над С++ тут писал не один человек. Я думаю, что и С++ до такой степени, которая сейчас обсуждается обычно не
>используют. По крайней мере я лично знаком видимо только с одним человеком, который пишет именно на таком уровне.

Считай что знаешь еще 5ых :) (пишем main engine для одной production системы которая на HPUX крутится). Думаю что большей части здесь присутствуюших не приходилось писать что нидь подобное.
А ведь именно на таких time/resource critical вещах плюсы и проявляют себе на полную катушку. К слову сказать - код на 90 процентов состоит из функторов + STL algorithm's.
(кстати - здесь я с АХ пролностью согласен: функторы - незаменимая вещь).

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

2 Die-Hard (*) (2002-04-29 16:18:28.97)

>IMHO у ЦеПП есть 2 native ниши.
>1. Любителям ваять проги прямо в компьютер, с помощью какого-нибудь билдера ....

Сейчас примерно 150000 строк, все написано в vim/emacs (отпределяется личными пристрастиями конкретного девелопера). Никто не жужжит.

--
With best wishes,
Nick.

2Смоляное Чучелко

А вот перед тобой я действительно извиняюсь.
Я перепутал твой мессаг с читателем 58какойто страницы 
из Страуструпа. И мой ответ в конце 7-ой странице не тебе
(извиняюсь еще раз ), а тому товарисчу, который не освоив
базовый синтаксис С взялся ваять классы

Bear 

2bugfixer (*) (2002-04-29 19:32:01.956):

Прошу прощения, но написал, что ЛИЧНО. А так - тут ведь почти все такие. Даже если взять Antichrist - разве он признается, что не владеет подобной техникой.

2anonymous (*) (2002-04-29 19:53:28.326)(АКА Bear):

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

Для того, чтобы не быть голословным и подтвердить или опровергнуть предыдущий абзац хотел бы задать Вам вопрос:

Каким образом заставить алгоритм STL под названием for_each применить к каждому элементу контейнера vector<double> операцию умножения на 2.0? Желательно с кодом. Я утверждаю лишь то, что по стандарту С++ для этого следует написать класс и совсем не достаточно только написания функции умножения объекта типа double на 2.0.

> anonymous (*) (2002-04-29 20:17:07.912)

примерно так:

transform(vec.begin(), vec.end(), vec.begin(), bind2nd(multiplies<double>(), 2.0));

--
With best wishes,
Nick.

to anonymous (*) (2002-04-29 14:11:46.804):

(с тех пор много воды утекло, но все же отвечу)

>> А что по этому поводу сказал Страуструп? Он отделался заявлением, что 
>> реализовать возможность определения новых операторов слишком сложно 

> или я чего то не понял или перегрузки и определения операторов уже в с++ 
> нет .. берем класс - определяем для него какие угодно операторы с какими 
> угодно типами опрандов справа или слева

Пожалуйста, определите класс "число" (представление неважно)
и для него --- оператор ** (да, именно такой), и чтобы приоритет у него
был повыше умножения, пониже унарных операций, да и еще правоассоциативный
(гулять, так гулять). Если Вам это удастся, то я признаю, что возможность
определить *новый* оператор (а я писал именно об этом) в C++ есть, иначе
я останусь при своем мнении.

--
SVK

2AC (*) (2002-04-29 17:26:22.312):
> Хочу параметризованные классы, generic programming, инлайнинг, базовую поддержку ООП,
> базовую поддержку инкапсуляции, перегрузку операторов. Где это все в С?
Все вышеперечисленное представляет собой либо лишние сущности, изобретенные в угоду моде
любителями злоупотребления терминологией ("базовая поддержка ООП", "базовая поддержка
инкапсуляции"); либо прекрасно реализуемо в Си, только так не называется
(инлайнинг,generic programming); либо есть откровенная насмешка над основами
безопасного кодирования (перегрузка операторов). Разумеется, все вышесказанное -
мое глубокое "IMHO", являющееся результатом многолетнего увлечения идеями ООП
в молодости.

> Далее, что проще и читабельнее?:
IMO - первый вариант проще, нагляднее и читабельнее.
Через пару месяцев у тебя из головы все эти t_elem& operator()(int i,int j)
напрочь повылетят, и долго придется тупо смотреть на странного вида конструктор
A(i,j)...

А еще я офигеваю от перегрузок оператора []. В сочетании с ссылочным типом,
гениальное изобретение по запутыванию программиста...

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

2bugfixer (*) (2002-04-29 20:24:57.063):

Сам понимаешь, что это был пример. А если что-нибудь более сложное - типа tan()+atan+sin и т.д. (конкретно - дисперсионное уравнение для квантовой ямы с конечными стенками).

2 anonymous (*) (2002-04-29 20:33:41.674) (SVK)

это невозможно.
прикол в том - что и не нужно. Ведь обычно хочется расширить действие какого нибудь оператора типа operator+() на пользовательский тип.
Но ввести свои операторы или изменить приоритеты операторов - нельзя. Видимо господа путают понятия mutable & extendable

--
With best wishes,
Nick.

2 anonymous (*) (2002-04-29 20:42:57.839)

Какая разница?? Все равно если не нужно помнить состояние между вызовами то все сведется к функции + transform.

--
With best wishes,
Nick

2anonymous (*) (2002-04-29 18:15:17.161):

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

Чесслово, используют! ;)

2bugfixer (*) (2002-04-29 20:42:58.976):

Спасибо за пример - притормозил и в постинге anonymous (*) (2002-04-29 20:42:57.839) не поблагодарил. Вот мой знакомый приблизительно на таком уровне работает.

Насчет не расширяемости операторов - смены приоритетов, ввода новых символов есть две позиции (обе очевидно справедливы):

1) Если что-то не используешь труднее увериться в том, что это тебе поможет. Поэтому скорее всего понадобится, если введут.

2) Когда-то надо остановится, ибо язык должен быть не бесконечен. Нельзя вводить новые features, совершенствуя его вечно, поскольку на его изучение уйдет тоже много времени (будет ситуация ка в "Понедельник нач. в субб." с Кощеем Бессмертным). Язык должен быть конечен и, соответственно смертен. Как написано у Ильфа - "мне не нужна вечная игла для примуса - я не собираюсь жить вечно". Язык это инструмент. Просто С++ не входит в явное противоречие с нашими задачами, ка BASIC.

2bugfixer (*) (2002-04-29 20:46:39.779):

Я этого не знал, но в #include<functional> вроде нет тангенса. И потом, если хочешь написать нормальное уравнение, то такой метод все же еще больше раздувает код, нежели создание класса. Что все равно, больше, чем функция. Бог с ним, с этим спором.

Мне просто очень не нравится, когда меня начинают просто так несправедливо оскорблять. Я думаю, подобное никто не приветствует. А тут человек не удосужился не только разобратся в том, комментарий к чему он написал, но даже книжку открыть. Страницу я честно указал.

2 Die-Hard:
>Все вышеперечисленное представляет собой либо лишние сущности, изобретенные в угоду моде любителями
Если вы считаете, что инкапсуляция ни к чему, что конструкторы и деструкторы ни к чему, и готовы каждый раз ломать голову над тем, поставили вы clean-up, и кто поменял это поле -- это ваше право. А для меня формально специфицированные протоколы доступа к объекту и его создания/удаления имеют значение.
>либо прекрасно реализуемо в Си, только так не называется
Ну и _как_ реализуются в Си шаблоны, частичная специализация и инлайнинг?? Только не говорите, что макросами, дабы я в вас не разочаровался...
>либо есть откровенная насмешка над основами безопасного кодирования
а что здесь смешного? Я, например, предпочитаю видеть формулы, которые еще и развертываются сами, чем батареи add, sub, multiply и т.д.
>IMO - первый вариант проще, нагляднее и читабельнее.
А по-моему, элементы матрицы -- это ее свойство, и отрывать доступ к ним от понятия матрицы -- первостатейный маразм.
>и долго придется тупо смотреть на странного вида конструктор
A(i,j)...
IMO, для любого человека, которого учили линейной алгебре, смысл этой записи A(i,j) очевиден. Непонятно, чего тут странного.
>В сочетании с ссылочным типом, гениальное изобретение по запутыванию программиста...
А что такого в ссылочном типе? Ссылка -- это просто alias, другое имя. По-моему, указатели со своими звездочками и стрелочками куда как менее очевидны.
>большинство присутствующих с этими моими утверждениями не согласится
Конечно. Потому что за этими утверждениями стоит голый консерватизм, и ничего кроме.

2 anonymous (*) (2002-04-29 21:04:28.557)

>Мне просто очень не нравится, когда меня начинают просто так несправедливо оскорблять.

Согласен. Я считаю что отвечать на такие мессаги - ниже моего достоинства.

Кстати, о transform. Если объекты в векторе "тяжелые" и хочется избежать их копирования, то можно внести doSomething() в этот класс и сделать
for_each(vec.begin(), vec.end(), mem_fun(&Obj::doSomething));

--
With best wishes,
Nick

2Die-Hard: > Второе - какой-то последний абзац не понятен и не однозначен в толковании. Поскольку > ANSI/ISO C - подмножество ISO C++, Не совсем. Синтаксис в С++ значительно строже, несколько другие соглашения о передаче параметров (char, sizeof) и т.д.

по-моему ты заблуждаешь/путаешь ANSI C и ISO C, так вот ISO C это подмножество ISO C++ (ну с понятными оговорками :), а также почти любой сколько-нибудь грамотный и переносимый код на C является валидным кодом на C++.

далее, по поводу дикой смеси inline и virtual, в чем дикость? так же фанаты могут сказать, мол чудовищная смесь циклов: while, for и do while :)

хотя в принципе помнится все это уже обсуждалось несколько месяцев назад в похожем треде про кажется доступность ICC под linux :) и тем-же контингентом... AC и я и Die-Hard и ZhekaSmith помнится :)

и напоследок по поводу перегрузки и нечитабельности... разумная перегрузка это как разумное именование функций, просто соглашение :)... и если кто-то тебе дал класс, объекты которого умножаются по operator+ , то ... ну пошли этого контрибьютора в задницу и все... логично? :)

to: bugfixer (*) (2002-04-29 20:42:58.976)
cc: anonymous (*) (2002-04-29 20:53:21.599)

Sorry, что пишу ответ "оптом", просто вместе оно неплохо смотрится

Итак, речь идет о введении в язык новых операторов.

> это невозможно. 
> прикол в том - что и не нужно. Ведь обычно хочется расширить действие какого 
> нибудь оператора типа operator+() на пользовательский тип. 

Это когда как. Вот, к примеру, если реализовывать интервальные вычисления,
приятно иметь символы операций с направленным округлением:

a +> b (округляем вверх)

a <* b (округляем вниз)

Что в данной ситуации лучше: символ операции, либо вызов функции типа add(...)?

> Но ввести свои операторы или изменить приоритеты операторов - нельзя. 
> Видимо господа путают понятия mutable & extendable 

Я в курсе, что нельзя :-) И попытка ввести новый оператор никоим образом не
влияет на существующие (т.е. это действие из класса extendable, а не mutable).
Кажется, сам Страуструп возражал именно насчет изменения существующих
операций (т.е. переопределить оператор "+" для целых чисел как деление),
это действительно плохо. Я же говорю, что расширение языка вводом новых 
операторов бывает нужно. В конце концов, определение функций тоже означает
расширение базового набора операций исполнителя операциями более высокого
уровня.

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

> 1) Если что-то не используешь труднее увериться в том, что это тебе поможет. 
> Поэтому скорее всего понадобится, если введут. 

> 2) Когда-то надо остановится, ибо язык должен быть не бесконечен. Нельзя 
> вводить новые features, совершенствуя его вечно, 

Все гораздо проще. Достаточно выбрать при создании языка правильный набор
базовых features, которые обладают дополнительным запасом прочности и 
универсальности. Как пример --- скобочная запись программ на Лиспе (что
поделать, нравится мне этот язык :-). С 1959 года много сменилось парадигм,
но все они ложатся в лисповский синтаксис удивительно красиво. Так вот,
скобочная запись *автоматически*, *без введения дополнительных конструкций*
вроде определения приоритетов операторов, позволяет решить нужную мне
задачу (ввести новый символ операции). И не только эту.

В общем,

> Programming languages should be designed not by piling feature on top of 
> feature, but by removing the weaknesses and restrictions that make additional 
> features appear necessary. Scheme demonstrates that a very small number of 
> rules for forming expressions, with no restrictions on how they are composed, 
> suffice to form a practical and efficient programming language that is 
> flexible enough to support most of the major programming paradigms in use 
> today. 
--
From "Revised^5 Report on the Algorithmic Language Scheme"

--
SVK

2anonymous (*) (2002-04-29 20:17:07.912)

Я не пытался обвинить Вас в некомпетентности.

Мой ответ был скорее на тон Вашего письма.
Думаю что ниже следующее _небесполезно_

Я, не зная Вашей задачи, просто подумал, что 
Вы ее усложняете. 

При наличии 2-х классов в пограмме для численного счета
возникает естественное чувство, что для решения 
задачи привлечены излишние средства.

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


И это вовсе не обвинение в некомпетентности.

Это предостережение от ошибки, в которую 
впадают слишком многие. (даже иногда "профессионалы")

Уметь программы писать еше не значит уметь  
проводить расчеты. 

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


Возможно, подчеркиваю "возможно", так как не знаю Вашей 
задачи, гораздо эфективней использовать простой массив, 
или массив указателей( 1, 2, 3-х мерный).

Для численного счета не нужны навороты!!!
Классы и шаблоны и перегрузку надо использовать для 
управления окруженим(по моему мнению)
иначе Вы терете производительность. 
И любой Фортран код будет быстрее.

Кстати
Когда я возражаю против использовани Фортрана,
я имею в виду, что все можно с той же скоростью сделать на
С или С++.

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

Не вижу смысла приводить код так хакеры 
уже привели варианты. 

Люди ответили на 
Ваш вопрос. и, вероятно, лучше меня.


Но это не лучшие варианты для численного счета!!!!


Однако владение языком не может не вызывать уважения.



Bear

P.S.
Если нежелание 
приводить код Вы воспримете 
как некомпетентность, то сообщите.
Я постараюсь Вас разубедить.

2SVK:

Я в курсе, что нельзя :-) И попытка ввести новый оператор никоим образом не влияет на существующие (т.е. это действие из класса extendable, а не mutable).

если чуть подумать, то применительно к С++ ввиду наследия С очень даже влияет, т.к. в коде написанном до введения оператора может встретиться этот оператор (написанный в виде двух без пробела) очевидно ваш-же пример есть валидный код с УЖЕ определенным смыслом, стало быть введение нового оператора мало того, что поломает старый код, так еще и легко ведет к неоднозначности...

если кто не догадался, я про то, что a <* b УЖЕ умеет определенную семантику, а именно (a < (*b)), хотя опять-же зависит от того, что есть a и b :) (надеюсь примеры очевидны)

2anonymous (*) (2002-04-29 21:28:20.122)(SVK):

Наверно ты прав. Тогда становится грустно. Ибо нравится мне этот язык (С++), а LISP - нет. Впрочем, мне ведь действительно почти не нужно переопределять существующие операторы и тем более вводить новые. Язык это инструмент под конкретные задачи.

Sorry Забыл подписаться

last message is mine.

Bear

 Не успел. Не мой последний мессаг.
:-))

Bear

2AC (*) (2002-04-29 21:11:41.028):

>> Все вышеперечисленное представляет собой либо лишние сущности, изобретенные в угоду
>> моде любителями
> Если вы считаете, что инкапсуляция ни к чему, что конструкторы и деструкторы ни к чему,
> и готовы каждый раз ломать голову над тем, поставили вы clean-up, и кто поменял это поле
> -- это ваше право.
В С++ НЕ удалось реализовать концепцию защиты данных - все инкапсуляции
со скрытиями, сильно мешая, элементарно (иногда случайно) обходятся. Мало того,
немного подумав, нетрудно сообразить, что защита данных невозможна в любом
не строго типизированном языке. А строго типизированные языки не годятся для
серьезных разработок (Да простит меня Антихрист!;)

> А для меня формально специфицированные протоколы доступа к объекту и
> его создания/удаления имеют значение.
Надо же! Для меня - тоже!!!
Только зачем водить себя за нос и доверять столь деликатную материю тупому
компилеру? Следование протоколу - задача кодировщика!

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

> Только не говорите, что макросами, дабы я в вас не разочаровался.
Вынужден Вас разочаровать - именно макросами ;)

> А по-моему, элементы матрицы -- это ее свойство, и отрывать доступ к ним от
> понятия матрицы -- первостатейный маразм.
Типичный закидон апологета ООП :)
Ну и не отрывайте! А зачем придумывать формальный механизм для инкапсуляции-то?
Или Вы себе не доверяете?

> для любого человека, которого учили линейной алгебре, смысл этой записи
> A(i,j) очевиден.
Угу - в учебнике по линейке. А в программе он несколько двусмысленен,
особенно если учесть, что конструктор может выглядеть примерно так же.

> А что такого в ссылочном типе? Ссылка -- это просто alias, другое имя.
Угу - особенно в параметрах и возвращаемых значениях.

Обнажды я поимел большое удовольствие, половину дня убив на разгадку
такого примерно паззла:

int main(int argc, char *argv[])
{
init_gui(argc,argv);
...
init_sys(argc,argv);
...

Фенька было в том, что init_gui был объявлен в некоем левом хидере как
int init_gui(int& argc, char *argv[]), а init_sys как
int init_sys(int argc, char *argv[]), причем документирован был init_sys,
а про init_gui было сказано, что он - "такой же". Соответственно, я никак
не мог взять в толк, куда деваются параметры командной строки.

> ...за этими утверждениями стоит голый консерватизм, и ничего кроме.
ок, это - Ваше мнение. Только непонятно мне тогда, чего Вы со мной спорите?
Он же - "голый"!

Да, кстати - я согласен, что Вам по роду Вашей деятельности ЦеПП как раз
подходит. Как я уже писАл, разработка квазинаучных библиотек - единственная
native ниша ЦеПП.

Нет ребяты, самая фича языка в данный момент эволюции - это скорость разработки на нем _большого_ проекта. Тут канешна можно начать кричать: да я типа любой проект на неС++(OCaml/lisp/пр.хрень) налабаю, с GUI или без, числодробилку или мозгоправку, под Web (кстати, как насчет под веб?!) или без. НО где ж взять 200 _профессиональных_ программеров на языке пр.хрень? Мне нужно быстро. Пока я их буду искать, мою супер-пупер идею реализую 20 контор 30 способами и я буду...ну это А/Х получше сможет объяснить где ;) А 200 индусов я могу за это время с нулячего положения завести до работоспособного (особенно на Java :). Качество? Не волнует. Работает и зашибись. К тому же на 10 итерацие переписывания продукта, чего-то более менее стабильное и получится. К этому моменту как раз первая итерация проекта на OCaml закончилась бы возможно ;)

to anonymous (*) (2002-04-29 21:42:44.554):

> если кто не догадался, я про то, что a <* b УЖЕ умеет определенную 
> семантику, а именно (a < (*b))

Отличное возражение! Спасибо, мне оно пригодится. Действительно, данная 
комбинация символов уже "задействована". Правда, в некоторых достаточно
серьезных конторах QA dept. очень эффективно приучает ставить побольше
пробелов и скобок :-) и наказывает за неприличные выражения типа

 i+++j ;

--
SVK

2 Bear: >Классы и шаблоны и перегрузку надо использовать для управления окруженим(по моему мнению) иначе Вы терете производительность.
Вопросы со стороны -- вот вы так красиво рассуждаете, а не могли бы _конкретно_ объяснить, _как_ именно_, к примеру, шаблоны влияют на производительность. Далее, _как_именно_ с точки зрения производительности отличаются вызовы функций, имеющих параметрами какую-то структуру, над которой производится действия, и вызовы соответствующих _невиртуальных_ методов класса, "реализующего" данную структуру? Далее, как влияет на производительность использование перегруженного оператора "+" по сравнению с вызовом аналогичной функции add?
>Ваш код будет медленным если Вы будете использовать класс для реализации вектора.
Расскажите, как именно использование класса для реализации вектора, особенно заинлайненных методов, не проверяющих выход за пределы массива etc., повлияет на производительность? Где будет оверхэд?

2Bear:

ну вот вам два опровержения ваших достаточно амбициозных заявлений:

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

делаем например двумерный массив с доступом по индексу, за счет того, что индексация лежит в реализации класса, а не размазана по всему коду, тривиальным #ifdef MY_DEBUG (в одном месте, в реализации класса) включаем и выключаем проверку на диапазон(и например бросаем исключение), когда все отлажено и работает выключаем и не имеем никаких накладных расходов... прошу заметить без модификации основного кода программы. предвижу возражения про накладные расходы на вызов operator[], возражения необоснованы, ибо кто угодно в состоянии проверить, что overhead даже тривиальной реализации в пределах 10% по сравнению с кодом на C

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

так что не надо про медленный код...

2anonymous (*) (2002-04-29 21:38:45.334)(AKA Bear):

Естественно, я не занимаюсь копированием vector<double> в самом глубоком цикле - только во внешнем. Соответственно потери производительности никакой. Далее, известно, что на С++ легко написать плохую программу. Но можно и хорошую. В глубоких циклах все должно быть исключительно inline, без выделения памяти, исключений (недавно проверял - на C Builder 5 - конкретно падает производительность), доступ к массивам типа vector<double> без изменения размера (никаких erase, push_back и т.д.).Не надо бояться средств С++, надо только знать, какие операции отнимают сколько времени. И тогда все будет ОК.

1) По крайней мере в Rogue Wave STL границы vector не проверяются. И потом, если его использовать в циклах только на чтение, то все будет быстро.

2) Самый быстрый код (в случае не самого дуболомного компилятора) получается именно с использованием шаблонов, поскольку все шаблоны это inline структуры и раскрываются прямо при компиляции. Именно поэтому при одиаковом алгоритме qsort из C проигрывает алгоритму sort из С++, поскольку в первом идет вызов функции, а во втором обычно нет - все вкомпилировано намертво.

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

>А ЦеППшные деструкторы - костыль, 
>в половине случаев срабатывающий не так, 
>как задумывалось


2Die-Hard 

Я тож поклонник чистого С.
A(i,j) тоже не хочу видеть (и обычно не вижу)

Но все равно хочется спросить 
в каких именно случаях деструкторы не срабатывают?

Bear

2anonymous (*) (2002-04-29 21:21:01.319):

> ISO C это подмножество ISO C++
ISO/IEC 14882:1998(E)
Page 687:

The subclauses of this subcause list the differences between C++ and ISO C
...
Type of character literal is changed from int to char
...
Page 688
ISO C programs which depend on sizeof('x') == sizeof(int) will not work the
same as C++ programs.

И т.д.

> далее, по поводу дикой смеси inline и virtual, в чем дикость? так же фанаты могут сказать,
> мол чудовищная смесь циклов: while, for и do while :)
Я - не о том.
По виду вызова метода нельзя сказать, inline он, просто вызов или virtual, что иногда весьма
критично.

> и если кто-то тебе дал класс, объекты которого умножаются по operator+ , то
> ... ну пошли этого контрибьютора в задницу и все... логично? :)
Нет.
Как-то раз я долго трахался с оператором QString& operator[].
Все было вполне логично - только делало ЧУТЬ-ЧУТЬ не то, что я думал :(

ты бы хоть Брукса почитал, что он про 200 индусов vs. 10 человек пишет...

2anonymous (*) (2002-04-29 22:12:08.365)(AKA Bear):

В случае выброса исключения из конструктора не выполняется деструктор. А большего я не знаю.

2anonymous (*) (2002-04-29 22:08:05.376)

Согласен.

Но спрошу
Разве inline всегда раскрываются?
как методы? 

Мне казалось, что этот процесс
в критических участках лучше самому контролировать.

Bear

2anonymous (*) (2002-04-29 22:12:08.365) aka Bear:
> в каких именно случаях деструкторы не срабатывают?
1. Когда забыл освободить память где-нибудь в самом деструкторе.
2. Когда забыл грохнуть распределенный через new объект.

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

I meant
полиморфизм в С++ реализуется
(только через указатели) и распределенные вручную объекты...

2SVK:

вот-вот... i+++j в общем очевидно что значит :) но это просто пример как не надо писать, опять-же в догонку распостраненное выражение a=*b :) в ++ есть имхо только одно место наступившее на проблему которую мы обсуждаем: vector<vector<int>> :)

2Die-Hard:

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

1. "В С++ НЕ удалось реализовать концепцию защиты данных" ее не пытались реализовать, реализована защита от ошибки, а не от взлома.

2. " А ЦеППшные деструкторы - костыль, в половине случаев срабатывающий не так, как задумывалось." глупость, ну приведите пример когда "конструктор не так работает"... это как free не так работает... либо вы понимаете, как оно работает и пользуетесь инструментом либо не хотите понимать, но тогда не пользуетесь и не наезжаете необоснованно, логично?

3. " Ну и не отрывайте! А зачем придумывать формальный механизм для инкапсуляции-то? Или Вы себе не доверяете?" во первых программу пишет не один человек, во вторых это защита от ошибки или случайной опечатки.

4. " Фенька было в том, что init_gui был объявлен в некоем левом хидере как int init_gui(int& argc, char *argv[]), а init_sys как int init_sys(int argc, char *argv[]), причем документирован был init_sys," ну это просто смешно, в нормальном коде если не изменяют ссылочный параметр то делают const T&, если нет const значит может изменять. далее, если в документации написано, что не изменяет, а на самом деле изменяет, то это баг, так-же как и если-бы это было с указателями, но с указателями вы бы не возмущались? непоследовательно :Р

2 anonymous (*) (2002-04-29 22:16:34.064)

Очень рекомендую почитать Herb Sutter "Exceptional C++"

Там весьма популярно объясняется почему throwable destructors are evil.
Да и вообще, очень хорошая книжка (в отличие от многих).
В основном там рассказывается как писать код устойчивый к exceptions.

--
With best wishes,
Nick.

Но ведь все указанные случаи -
1)исключение
2)неосвобожденная память

это просто ошибка кодирования


Страуструп это осознанно оставил 
на программера.

Наверное, если все делать аккуратно
Все будет OK

2All Спасибо. Удачи. Я пошел спать.

Bear

2 Die-Hard: >В С++ НЕ удалось реализовать концепцию защиты данных - все инкапсуляции со скрытиями, сильно мешая, элементарно (иногда случайно) обходятся.
Очевидно, задачей таких механизмов не является противодействие намеренному обходу. Случайно же обойти такие механизмы -- довольно тяжело.
>Только зачем водить себя за нос и доверять столь деликатную материю тупому компилеру?
Потому что формальная спецификация протоколов улучшает, к примеру, читабельность и ясность текста.
>А ЦеППшные деструкторы - костыль, в половине случаев срабатывающий не так, как задумывалось.
Разумный пример срабатывания деструктора не так, как задумывалось.
>Вынужден Вас разочаровать - именно макросами ;)
Ну-ну. Очень печально:( Доводы против я даже не буду приводить, в силу их очевидности любому, кто знает, что такое и чего дает шаблон. А макросы -- это вообще самое большое зло в C++ из тяжкого наследия С. Наряду с адресной арифметикой. Вот уж что издевательство над принципами безопасного кодирования.
>А зачем придумывать формальный механизм для инкапсуляции-то? ли Вы себе не доверяете?
А зачем придумывать компиляторы? Пишите сразу в кодах, или Вы себе не доверяете? Ладно, в C были бы хоть какие-то пристойные аналоги модулей и возможность строгой спецификации АТД. Тогда бы можно было говорить об избыточности классов. Но ведь этого нет. Более того, элементарный контроль типов Си перенял из С++.
>А в программе он несколько двусмысленен,
Не вижу никакой двусмысленности.
>что конструктор может выглядеть примерно так же.
Ну и? Вы же не баран? Если уж компилятор может отличить подобную запись от вызова конструктора, то вы и тем более.
>Угу - особенно в параметрах и возвращаемых значениях.
Именно для этого они и придуманы -- чтобы использовать сам объект, но не тратить время на передачу, и обходиться без всяких совершенно неочевидных звездочек и стрелочек. Потому что указатели -- зло, особенно в параметрах.
>Обнажды я поимел большое удовольствие, половину дня убив на разгадку
А я тратил массу времени, выискивая места, когда кто-то в каких-то кустах менял значение по нужному мне указателю, и ничего об этом не говорил.
>Фенька было в том, что init_gui был объявлен в некоем левом хидере как int init_gui(int& argc, char *argv[]),
1. Любым инструментом можно воспользоваться неправильно.
2. В C++ и особенно в C вообще очень мало инструментов, не дающих воспользоваться собою некорректно. В Си вообще все отдается "на откуп" программисту, и не производится элементарного контроля. Но вы же не против указателей, адресной арифметики, многократных разыменований, макросов, функций с переменным числом параметров, отсутствия типизации в Cи?
3. Ссылки на элементарные типы -- зло. Они оставлены, чтобы не нарушать целостность языка.
>Только непонятно мне тогда, чего Вы со мной спорите?
В рамках идеологической борьбы с консерватизмом:)

2Die-Hard:

" 1. Когда забыл освободить память где-нибудь в самом деструкторе. 2. Когда забыл грохнуть распределенный через new объект."

это вообще детский лепет... если вы память не удалили free(), то тоже деструкторы виноваты? :((( что за бред...

по поводу ISO итд... ну ЭТО очевидное отличие, чтоб можно было в частности ввод и вывод перегружать для int и char.

по поводу inline и virtual можете рассматривать эти модификаторы как часть прототипа/документации, inline пользователя совершенно не должен волновать, он волнует разработчика

" Как-то раз я долго трахался с оператором QString& operator[]. Все было вполне логично - только делало ЧУТЬ-ЧУТЬ не то, что я думал"

ну так ответ в том, что вы неправильно думали, printf("%d","засада"); тоже у некоторых делает не совсем то, что им кажется дожен... надо знать инструменты, чтобы ими грамотно пользоваться.

2bear по поводу inline, это настоятельная просьба компилятору, хороший компилятор должен приложить максимум усилий к ее реализации, хотя безусловно можно наворотить код, который компилятор толком не сможет встроить, ибо нет предела извращенству :)

"В случае выброса исключения из конструктора не выполняется деструктор. А большего я не знаю."

до окончания выполнения конструктора объект НЕ сконструирован и деструктор ОБЯЗАН НЕ вызываться, очевидный пример надеюсь приводить не надо? если у вас это проблема пользуйтесь "выделение ресурса есть инициализация" и тем очевидным фактом, что все члены и предки инициализируются до объекта самого класса.

Да, меня AC заставил задуматься. И родилось такое мнение - хотя C++ не является оптимальным для любой области, он является оптимальном на большом наборе областей. С/Фортран все-таки слабоваты для сложной логики, а другие языки не дотягивают до C++ по производительности. Вернее, С++ программу можно всегда подтянуть до максимальной/почти максимальной производительности. И когда решаешь произвольную задачу, или набор произвольных задач, то, как говорится, выбирай C++, если не знаешь или нет времени выбирать другие средства. В результате получается нехилый бонус - прозрачный доступ из одних частей программы к другим, даже если они требуют совершенно разных стилей программирования.

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

2 Die-Hard: полиморфизм в С++ реализуется (только через указатели) и распределенные вручную объекты...
Неверно. Полиморфизм реализуется и через ссылки. Далее, по поводу деструкторов -- или мы имеем язык с автоматической сборкой мусора, или нет. Во-втором случае, очевидно, управление ресурсами возлагается на программиста. Деструктор -- всего-навсего функция, которая гарантированна вызывается при явном или неявном уничтожении уже созданного объекта. Очевидно, сама по себе она не гарантирует корректного освобождения ресурсов. Это вообще принципиально невозможно, поскольку "корректность" зависит от конкретной задачи. Тогда, если вы забыли что-то освободить, причем здесь деструктор как _механизм_? Если вы забудете что-то сделать в finalize в языке со сборкой мусора, или забудете сделать корректный cleanup, "виноват" же будет не сборщик мусора, а вы. И по поводу управления памятью -- в С++ можно организовать хоть какое-то подобие, сделать smart-pointer, сборку мусора etc. А как с этим в C?

ZhekaSmith %) хотя несправедливо... половину в защиту плюсов я написал, а лавры все АС :) хотя не жалко, он на мой взгляд очень грамотный человек и специалист :)

ну а по поводу "каждому блюду свою ложку" так кто б спорил :) в общем моя позиция очень близка к сформулированной, а "бурная" защита С++ связана пожалуй с необоснованностью претензий

По мотивам ZhekaSmith (*) (2002-04-29 22:50:05.991):

AC конечно прав, но все, что выдал Die-Hard тривиальности, причем много раз почти дословно разобранные в любой книжке по С++ в разделе - а нафига это нужно.

Другое дело - как-то плохо понятны отсутствия нескольких других вещей в С++. Я только что думал о возможности введения дополнительных операторов и мне кажется бинарные и унарные можно вводить без особой трудности - пусть они содержат только символы (сколько угодно) и описываются как обычные - перегружаемые. И что с того?

Кстати, не знает ли кто, можно ли корректно ввести индексацию как в паскале - [i,j]. Я слышал, что это надо делать чем-то подобным:

class int_pair; int_pair operator ,(int i, int j) { return int_pair( i, j); } а дальше определять

xxx operator [](const int_pair&) { } Делал ли кто это?

Просьба отвечать подумавши...

2AC (*) (2002-04-29 22:40:06.452):

> Разумный пример срабатывания деструктора не так, как задумывалось.
Я говорил про управление памятью.
Деструктор не будет вызван, если вы забыли сделать delete объекту из кучи;)
А при попытке пользовать только автоматические объекты вы фактически
оставляете за бортом весь полиморфизм.

>> А в программе он несколько двусмысленен,
> Не вижу никакой двусмысленности.
А я вижу! :)
>> что конструктор может выглядеть примерно так же.
> Ну и? Вы же не баран? Если уж компилятор может отличить подобную запись от вызова
> конструктора, то вы и тем более.
Ну, я же - не компилятор ;)
Я смотрю на запись A(i,j) в файле xxx.cpp НЕ проходя предварительно по
1001 хидеру, от которых этот файл зависит...

> Си вообще все отдается "на откуп" программисту, и не производится элементарного контроля.
> Но вы же не против указателей, адресной арифметики, многократных разыменований, макросов,
> функций с переменным числом параметров, отсутствия типизации в Cи?
Вот этим он мне и нравится.
Я много лет писал на С++ и считал его чуть ли не венцом творения, пока не понял,
что он не справляется с декларированными обязанностями. Теперь я за всем слежу сам,
и оказалось, что это - значительно надежнее и - легче. Я не доверяю С++ даже в плюсатых
проектах, ибо много раз убеждался в том, какая ЭТО гадость:)

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

Невозможно быть "чуть-чуть беременным"!!!

2anonymous (*) (2002-04-29 23:09:51.306):

> все, что выдал Die-Hard тривиальности,
Естественно - я вообще удивляюсь всем этим спорам на пустом месте!
Надо же, как мозги народу запудрили этими ЦеПП!!!
> причем много раз почти дословно разобранные в любой книжке по С++
> в разделе - а нафига это нужно.
От того, что я 10 раз прочту в книжке Страуструпа, что "макросы - зло!",
я не стану верить ему больше.

Посмотри на исходники Qt - если компилятор не поддерживает шаблоны, они
все реализуются через макросы ПРОЗРАЧНО ДЛЯ ПОЛЬЗОВАТЕЛЯ!!! И после этого
я буду слушать умных дядей?

> Я только что думал о возможности введения дополнительных операторов и
> мне кажется бинарные и унарные можно вводить без особой трудности -
> пусть они содержат только символы (сколько угодно) и описываются как
> обычные - перегружаемые. И что с того?
Много раз почти дословно разобрано в любой книжке по С++ в разделе - а
нафига это нужно ;)

2anonymous (*) (2002-04-29 22:41:43.584):
> это вообще детский лепет... если вы память не удалили free(), то тоже деструкторы
> виноваты? :((( что за бред...
Речь шла о конроле за памятью. Я просто утверждал, что автоматически вызываемых деструкторов
не достаточно для управления памятью в С++.

> ну так ответ в том, что вы неправильно думали, printf("%d","засада"); тоже у некоторых
> делает не совсем то, что им кажется дожен.
Не принимается - в printf("%d","засада") я вижу ошибку непосредственно; в моем примере
я должен был, не доверяя мануалу, лезть в хидер.

2AC (*) (2002-04-29 22:58:38.199):
>> полиморфизм в С++ реализуется (только через указатели) и распределенные
>> вручную объекты...
> Неверно. Полиморфизм реализуется и через ссылки.
Согласен, действительно, так...

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

> И по поводу управления памятью -- в С++ можно организовать
> хоть какое-то подобие, сделать smart-pointer, сборку мусора etc.
То-то и оно, что "можно", но в языке для этого явных средств нет.

> А как с этим в C?
Точно так же!
Хочется - пиши, или используй готовые либы.

" что он не справляется с декларированными обязанностями. Теперь я за всем слежу сам, и оказалось, что это - значительно надежнее и - легче. Я не доверяю С++ даже в плюсатых проектах, ибо много раз убеждался в том, какая ЭТО гадость:)"

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

"пример" про деструктор динамически созданного объекта не подходит, ибо деструктор вызывается при уничтожении объекта, если вы не хотите объект уничтожать не пеняйте на деструктор :)

"я С++ не доверяю" ну так на здоровье, только не надо в этом язык обвинять, обвиняйте себя :) раз причина в вашей психологии

а если вы по неграмотности написали "гадость" то опять-же нефиг на язык пинать.

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

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