Что мне [не] нравится в C++ и Ко
 

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

Ответ: ООП
 

можно подробней?

2jimon
а чем плох stl? Для меня не проблема реализовать то или иное (а раньше - дак только и делал), но зачем велосипедировать?

Ответ: ООП
 

можно.

1. непоследовательность: язык С++ создавался с учетом совместимости с Си, из-за чего унаследовал недостатки дизайна последнего, НО...
С++ не только дополняет правила Си, но и МЕНЯЕТ их.
пример: определение struct, enum, union в Cи и в C++ имеют разный вид.

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

2.2 разделение на файлы кода и заголовков так же логически испорчено.
примеры:
в заголовках могут быть не только объявления, но и определения (inline) и шаблоны (которые вообще рекомендуется располагать именно там).
аналогично объявления функций и классов могут быть в файлах кода и доступ можно получить к ним через extern.

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

Ответ: ООП
 

это совершенно разные вещи.

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

Ответ: ООП
 

тема про недостатки ООП, как подхода, так что не будем углубляться в недостатки сиплюсов.

Ответ: ООП
 

ffinder
а зачем ? я чётко знаю максимальный размер каждого элемента системы

impersonalis
главное правило чтобы узнать хоть частичку правды - лезть руками и ногами в самый ад, а именно в исходники STL, в исходники CRT (благо мелкософту - они идут вместе с студией), и после это мы вдруг узнаём что STL это мрачный ад с кучей макросов, с кучей шаблонов и вообще с кучей всего и не понятно как достигать максимальной эффективности, и вдруг мы узнаем что CRT юзает функции ядра, чуть просвещаемся как работают функции изнутри (много кто тут свой powf или sqrtf напишет на сях и int-only математике ?)

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

Ответ: ООП
 

я тебя задел что-ли чем, что столько пафоса в ответ. О спасибо великий! Какбе оно и понятно из первого поста было: тебя не устраивает реализация (перечисли конкретику, как это сделал ffinder). На счёт "знания каждого винтика" согласен (я не лишён некоторой доли романтики и максимализма), хотя на практике это и не так: всем пофиг на детали реализации. Пока ты пилишь свой связный список, вася-прогер юзает vector с realloc и проигрывает наносекунду в работе приложения (при актуальных размерах ОЗУ и быстродействии) против твоего кодо-дня. Сокеты? Не - возьмём builder-овские обёртки. Потоки - см. выше. Плата за кроссплатформенность - монстроидальные фреймворки.
Мало какая самопальная (даже коллективная) либа сравнится по качеству и поддержке с, пусть и не идеальными, порождениями гигантов.
И много ты sqrtf сам сделал (это при том, что свой рецепт только ленивый не постил - задача из серии олмпиадных: тьолочек поражать своим хацкерством)?

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

Максимальная эффективность? :-D Ты живёшь в эпоху VHLL и рассуждаешь о низкоуровневой оптимизации? Игра стоит (и требует!) свеч только на критичных участках, в остальном - собственноручно сделанный ад. Не пытайся объять необъятное.
Нет я не за паллиативы, я за трезвость в мечтаниях - переписывать из-за размытых "мрачный ад с кучей макросов" stl в принципе, это оптимизация ради оптимизации, такая же крайность как и ооп ради опп.

Ответ: Что мне [не] нравится в C++ и Ко
 

ну так можно все сократить.
ведь если подумать еще дольше, то станет ясно, что циклы и виртуальные функции - это средства ИСПОЛНЯЕМОГОФАЙЛАГЕНЕРАЦИИ, т.е. одно и то же по своей сути.

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

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

Ответ: Что мне [не] нравится в C++ и Ко
 

штоэта?

ну, вот в языке D выкинули макросы, и сильно расширили шаблоны.
там теперь и условная компиляция и вычисление формул во время компиляции и еще куча всего. но это всё в одной части языка, а не в двух разных.[/quote]

Ответ: Что мне [не] нравится в C++ и Ко
 

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

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

в микроконтроллерах (а их, учтите, всё же куда больше чем всех пк вместе взятых) саму архитектуру, зачастую ос и язык-компилятор разрабатывает одна компания (иногда только 1-50 человек всего, вспомните центр разработки процессоров интела в израиле), и в мк получается что всё продумано, ты просто покупаешь готовое решение и пишешь на одном доступном языке и всё гармонично и прекрасно работает, когда в пека понятие "работает" довольно неопределенно, прям как квантовая неопределённость, работает может и да, но медленно, а может коды корректировки в озу несправились и процессор получил не те биты, а может в мобильниках SoC деградировал и всё поехало, а может MLC ячейка в флеш памяти накрылась и опять битые данные и тд и тп