LINUX.ORG.RU
ФорумTalks

C++ - некошерно, C - кошерно. Почему?


0

0

Решил тут поднять свой левел знания С/С++ дальше понимания синтаксиса и пр., т.к. с Pascal'ем в моем городе дальше хобби не "уехать" по всей видимости :) Ну и собственно начал практиковаться, переводя один свой проЭкт на С. Почему-то расстроило отсутствие аргументов по умолчанию, с трудом привык к работе со строками и пляскам вокруг ручного контролирования выделения под них памяти и т.д. Свыкся с разбивкой модулей на *.c/*.h(даже проникся)... в общем ладно, отошел от темы немного ) Хотел поинтересоваться, какие реальные аргументы на тему "С++ - УГ" можно привести? :) И будет ли извратом/некошерно использовать C++ не прибегая к использованию классов/STL/etc.?

ЗЫ: давно подобных тредов не было, лень искать старые.

★★★★
Ответ на: комментарий от r

> Я искренне считаю, что любой ассист должен делать индекс символов, и этот индекс - немаленький.

"родной" IntelliSense зарублен на корню удалением нужной(ненужной) dll( в 2005 не нашел другого способа отключить его полностью - при отключении в настройках он все-равно рвался парсить файлы ), остается VA - при просмотре "Local Settings\Application Data\VisualAssist" найдены около 1Гб результатов парсинга( уже жестоко потерты - вдруг много лишнего пооставалось :) ), очевидно он на лету выгружает/подгружает необходимые данные

lester ★★★★
()
Ответ на: комментарий от Absurd

> Чем дальше ты отошел от Си-подмножества тем менее это надежно и тем больше подводных камней ты встретишь

ну ... да, в принципе так и есть

PIn
()
Ответ на: комментарий от robot12

ну давайте рассмотрим:

> too many features


:)

> missing useful features


плохо соотносится с первым

> implementation is difficult (language tools and compilers are bad)


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

> feature X is broken, dangerous, has too many special cases, noone understands the semantics.

> feature X is good, but it is abused in c++ or does not work well with other features.


забыли написать про features Y, Z etc.

> not enough compatibility


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

> senseless compatibility: c design (preprocessor, type system,..) is unsuitable for the feature set of c++.

> difficult to maintain, debug, fix, understad and reason

> big (language tools, src code, compiled code)


высосано из пальца

> complexity: learning and using the language requires too much effort.


кому-то и бейсик сложен

> c++ is slow (compile, link and run time)


чушь, что тогда уж говорить о других языках

> and ugly.


логичное завершение высера :)

lester ★★★★
()
Ответ на: комментарий от lester

>> missing useful features

>плохо соотносится с первым

По моему логично: фичей много, но большинство из них не имеют практической пользы.

>> implementation is difficult (language tools and compilers are bad)

>первая часть правда( хоть и важна только разработчикам компиляторов ), вторая - глупость, все есть и хорошего качества

Нет, нету. Даже сделать нормальную подсветку синтаксиса в С++ это нетривиальная задача. Остается распозновать и подсвечивать типы из <windows.h> и MFC/ATL. Под линуксом тоже самое с Qt.

>> not enough compatibility

>если писать по стандартам - нет проблем, потому практически все проекты на С++ прекрасно собираются на любой платформе

Речь наверно идет о поставке интерфейсов на С++. Под виндой оптимально делать какой-нибудь ActiveX либо DLL c Plain-C интерфейсом.

>> complexity: learning and using the language requires too much effort.

>кому-то и бейсик сложен

Я повторяю: инженерная культура подразумевает простоту решения а не сложность.

Absurd ★★★
()
Ответ на: комментарий от Absurd

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

давайте конкретику, а то неубедительно

> Нет, нету. Даже сделать нормальную подсветку синтаксиса в С++ это нетривиальная задача


я уже писал - VA

> Речь наверно идет о поставке интерфейсов на С++


и что тут несовместимого?

> Я повторяю: инженерная культура подразумевает простоту решения а не сложность.


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

lester ★★★★
()
Ответ на: комментарий от lester

>> Нет, нету. Даже сделать нормальную подсветку синтаксиса в С++ это нетривиальная задача

> я уже писал - VA

И что? Задача, даже решенная, всё равно остается нетривиальной. Eclipse CDT потребовалось 7 лет и 5 версий, чтобы ее решить.

Си++ очень сложен. То, что кому-то "и Бейсик сложен", не меняет этого очевидного факта.

tailgunner ★★★★★
()
Ответ на: комментарий от Absurd

> "Чем дальше ты отошел от Си-подмножества тем менее это надежно и тем больше подводных камней ты встретишь"

Давно волнует вопрос - что мешает использовать только тот набор фич из C++, который является понятным и достаточным для решения конкретной задачи, и не начинать срач на тему монструозности?

Иллюстрация моей точки зрения. Захожу вот я, скажем, на ЛОР - читаю новости, толксы, иногда ещё несколько разделов. В "Клуб" и "Web-development", например, не захожу -> мне совершенно побоку, что там в этих разделах творится, для меня ЛОР не становится хуже из-за этого.

hexenlord
()
Ответ на: комментарий от tailgunner

> И что? Задача, даже решенная, всё равно остается нетривиальной. Eclipse CDT потребовалось 7 лет и 5 версий, чтобы ее решить.

и что?

> Си++ очень сложен


что предложите взамен?

lester ★★★★
()
Ответ на: комментарий от lester

>> И что? Задача, даже решенная, всё равно остается нетривиальной. Eclipse CDT потребовалось 7 лет и 5 версий, чтобы ее решить.

> и что?

Это значит, задача нетривиальна.

>> Си++ очень сложен

> что предложите взамен?

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

tailgunner ★★★★★
()
Ответ на: комментарий от lester

>давайте конкретику, а то неубедительно

Куча говна вроде возможностей сделать ссылку даже на int в памяти,
"пятьдесят три" разных варианта вызова конструкторов, тучи неочевидностей где имеет значение не как произведен вызов, а как он объявлен (вроде & в параметрах), эта чертова void *, и прочая разная херня, которую можно переччислять сотнями с десятками подвариантов использования, которые и нафиг не нужны, а нормальное пробрасывание исключений из so, нормальных строк нет. А про такие необходимые вещи как замыкания, таплы или type parameter variance, можно вообще не заикаться.

r ★★★★★
()
Ответ на: комментарий от r

> Куча говна вроде возможностей сделать ссылку даже на int в памяти,

да - этот( и последующие ) довод убедит любого приверженца С/С++, мы сами удивляемся зачем это надо - глупо же, я б заодно и массивы в сишном стиле запретил - глупость какая-то

lester ★★★★
()
Ответ на: комментарий от lester

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

>давайте конкретику, а то неубедительно

Ссылки vs указатели vs смарт-указатели.

>> Нет, нету. Даже сделать нормальную подсветку синтаксиса в С++ это нетривиальная задача

>я уже писал - VA

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

>> Речь наверно идет о поставке интерфейсов на С++

>и что тут несовместимого?

А то что С++-интерфейсы в общем случае поставлять нельзя. Нет ABI.

>> Я повторяю: инженерная культура подразумевает простоту решения а не сложность.

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

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

Absurd ★★★
()
Ответ на: комментарий от lester

На:

void f(int * x) {
cout << 1 << endl;
}
void f(double * x) {
cout << 2 << endl;
}
template <typename T> void f(T t) {
cout << 3 << endl;
}

template <typename T> void f(T* t){
cout << 4 << endl;
}
template <typename T> void f(const T& t){
cout << 5 << endl;
}

Хочу увидеть на экране:
3
5

r ★★★★★
()
Ответ на: комментарий от Absurd

> С++-интерфейсы в общем случае поставлять нельзя. Нет ABI.

ЛПиП.

tailgunner ★★★★★
()
Ответ на: комментарий от Absurd

> Ссылки vs указатели vs смарт-указатели.

что тут по вашему мнению лишнее?

> Не пудри мне мозги. Весь инструментарий для С++ хорош только на рекламных скриншотах, на практике эта ботва деградирует до функционала gedit - дерево файлов слева, редактор с простенькой подсветкой справа, табы, букмарки и сплиттинг. Не более.


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

> А то что С++-интерфейсы в общем случае поставлять нельзя. Нет ABI.


вы хотите использовать интерфейс без использования описания из оригинального хедера? ССЗБ

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


это только ваше неаргументированное мнение

lester ★★★★
()
Ответ на: комментарий от lester

>> Ссылки vs указатели vs смарт-указатели.

>что тут по вашему мнению лишнее?


Уже само существование вопроса говорит о качестве языка. Вернее его отсутствии.

r ★★★★★
()
Ответ на: комментарий от r

> Ты ответил на свой вопрос о конкретике мусора в С++?

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

lester ★★★★
()
Ответ на: комментарий от lester

>> Ссылки vs указатели vs смарт-указатели.

>что тут по вашему мнению лишнее?

Любые две отдельно взятые сущности из этого списка.

>> Не пудри мне мозги. Весь инструментарий для С++ хорош только на рекламных скриншотах, на практике эта ботва деградирует до функционала gedit - дерево файлов слева, редактор с простенькой подсветкой справа, табы, букмарки и сплиттинг. Не более.

>если вам хочется, чтоб так и было - не буду вас разубеждать, блаженны верующие

Нет, я знаю что это именно так, т.к представляю сложность задачи. Это примерно как распознование образов: половинчатые решения для частных случаев есть, но без AI в общем случае не решаемо.

>> А то что С++-интерфейсы в общем случае поставлять нельзя. Нет ABI.

>вы хотите использовать интерфейс без использования описания из оригинального хедера? ССЗБ

Ну есть разные компиляторы, разные версии компиляторов, разные версии libc, разные аллокаторы памяти, итд.

Absurd ★★★
()
Ответ на: комментарий от lester

>тупо, шаблоны нужны для других задач,

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

r ★★★★★
()
Ответ на: комментарий от lester

>чтобы вы оставили?

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

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

r ★★★★★
()
Ответ на: комментарий от tailgunner

>> Для чего-чего нужны шаблоны?

>Для создания параметризованных контейнеров // К.О.

А не как более безопасная замена макросам?

>Степанова - на фонарь.

Он всего-навсего действовал в кильватере понимания Строуструпом ООП как стирания рахницы между простыми и составными типами.

Absurd ★★★
()

C++ RIP, зачем ты насилуешь труп страуса? Будующее за F#, Nemerle, LINQ. Именно с помощью этих языков будут писать стратегическое программное обеспечение для стратегического суперкомпьютера lentaru/news/2009/06/18/medvedev

Karapuz ★★★★★
()

какой годный тред

jtootf ★★★★★
()

Вообще в задрищенске самая тема охранником работать в какой-нить аптеке. Деньги те же. А что C что Pascal одинаково в Задрищенсках не нужны

Karapuz ★★★★★
()
Ответ на: комментарий от Karapuz

>Ну и сколько в мире их? Программистов на питоне? Хотя бы 29 наберется?

не, 29 миллионов не наберется, максимум 5-7

DNA_Seq ★★☆☆☆
()

Ну как? У C есть область, где он оптимален. У плюсов нет. Вот и...

>

Они есть.

> Свыкся с разбивкой модулей на *.c/*.h(даже проникся)

Учти, что это не модули. Это текстуальная подстановка. Отсюда геморрой с циклическими инклудами.

> И будет ли извратом/некошерно использовать C++ не прибегая к использованию классов/STL/etc.?

Зачем? Пиши на C, если надо.

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

В паскакале с памятью не многим лучше.

Miguel ★★★★★
()
Ответ на: комментарий от Absurd

>>> Для чего-чего нужны шаблоны?

>> Для создания параметризованных контейнеров // К.О.

> А не как более безопасная замена макросам?

Нет.

>> Степанова - на фонарь.

> Он всего-навсего действовал в кильватере понимания Строуструпом ООП

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

tailgunner ★★★★★
()
Ответ на: комментарий от jtootf

>> Шаблоны - это не ООП вообще

> ты говоришь об этом так, как будто это что-то плохое

Йаааа? O_o Не, тебе показалось. И вообще ты всё пропустил :D

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

>Йаааа? O_o Не, тебе показалось. И вообще ты всё пропустил :D

ну дык, надо ж было в Devel тему создавать :)

но вообще лучшие треды - это треды про C++ и LISP; и думается мне, что в ближайшую декаду вряд ли что-то изменится (ну разве что C++ станет D++, а лиспу изобретут ещё два десятка диалектов)

jtootf ★★★★★
()
Ответ на: комментарий от Miguel

>> В паскакале с памятью не многим лучше.

Я и не про память говорил, а про строки char* и геморрой с ними по выделению памяти и сусюканью. В Pascal'е String'и порядком удобнее. Хотя да, в плюсах тоже есть свой string/wstring, который порядком удобнее обычного char*.

Andru ★★★★
() автор топика
Ответ на: комментарий от tailgunner

>> А не как более безопасная замена макросам?

>Нет.

По моему даже Строуструп писал что шаблоны сделаны как безопасная замена макросам.

>>> Степанова - на фонарь.

>> Он всего-навсего действовал в кильватере понимания Строуструпом ООП

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

STL это всеже в первую очередь набор твоих любимых typesafe-коллекций. И дизайн у этой библиотеки вполне приличный, баланс между простотой и гранулярностью контроля выдержан. Порог вхождения невысокий - новичек вполне может ограничиться вектором и for-лупами, и получится нормально. iostreams намного хуже, поскольку там бессмысленно перемешано собственно io, буферизация и парсинг/форматтинг текста при околонулевой гранулярности контроля. Интересно только, кто написал iostreams. Не Строуструп ли?

>Шаблоны - это не ООП вообще.

В понимании Строуструпа это ООП. Он же писал что ООП это когда нет разницы между встроенными и пользовательскими типами. Шаблоны позволяют это обеспечить, по крайней мере в теории.

Absurd ★★★
()
Ответ на: комментарий от Absurd

> По моему даже Строуструп писал что шаблоны сделаны как безопасная замена макросам.

Не припомню. Во 2-й редакции TC++PL он _объяснял_ шаблоны как "хитрые макроопредления". Понятно, что это всего лишь аналогия, направляенная тупым Си-прогерам.

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

Они typesafe, но всё остальное - чушь. За pair Степанова нужно пытать перед повешанием.

А самое худшее в STL - то, что она открыла ящик Пандоры.

> Интересно только, кто написал iostreams. Не Строуструп ли?

По крайней мере первую версию - нет. Да и вторую тоже вряд ли.

>> Шаблоны - это не ООП вообще.

> В понимании Строуструпа это ООП.

Цитату или сам понимаешь.

> Он же писал что ООП это когда нет разницы между встроенными и пользовательскими типами.

Он писал это еще до шаблонов.

tailgunner ★★★★★
()
Ответ на: комментарий от lester

...if you want a fancier language (than C), C++ is absolutely the worst one to choose. If you want real high-level, pick one that has true high-level features like garbage collection or a good system integration, rather than something that lacks both the sparseness and straightforwardness of C, *and* doesn't even have the high-level bindings to important concepts.

LT

r ★★★★★
()

А что господа ЛОР-аналилики думают по поводу D? Пробовал его кто в реальных приложениях? Придел ли он на смену плюсам, а если нет, то на что смотреть как на возможную альтернативу плюсам?

nanokot
()
Ответ на: комментарий от tailgunner

>> По моему даже Строуструп писал что шаблоны сделаны как безопасная замена макросам.

>Не припомню. Во 2-й редакции TC++PL он _объяснял_ шаблоны как "хитрые макроопредления". Понятно, что это всего лишь аналогия, направляенная тупым Си-прогерам.

Ну а замена Си-шным макросам по твоему вообще нужна?

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

>Они typesafe, но всё остальное - чушь.

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

>За pair Степанова нужно пытать перед повешанием.

А с помошью чего можно сгруппировать key и value для помещения в map и multimap?

>А самое худшее в STL - то, что она открыла ящик Пандоры.

Это свехценная идея какая-то.

>> Он же писал что ООП это когда нет разницы между встроенными и пользовательскими типами.

>Он писал это еще до шаблонов.

Ну а шаблоны были сделаны для того чтобы эту мысль воплотить чтобы не приходилолсь дублировать одинаковый код для разных типов. Т.е шаблоны логично вытекают из Строуструповского понимания ООП.

Absurd ★★★
()
Ответ на: комментарий от Absurd

>> Во 2-й редакции TC++PL он _объяснял_ шаблоны как "хитрые макроопредления". Понятно, что это всего лишь аналогия, направляенная тупым Си-прогерам.

> Ну а замена Си-шным макросам по твоему вообще нужна?

Не понял вопроса. Нормальный препроцессор - штука полезная, это очевидно. Только причем препроцессор к параметризованным типам и процедурам? Они, если что, родом из языков, в которых понятия препроцессора не было вообще, и заменять было просто нечего.

> Что бы ты там упростил? По моему нечего там упрощать.

Я бы ее не стал писать - недостоин-с.

>> За pair Степанова нужно пытать перед повешанием.

> А с помошью чего можно сгруппировать key и value для помещения в map и multimap?

С помощью keyvalue<>

>> А самое худшее в STL - то, что она открыла ящик Пандоры.

> Это свехценная идея какая-то.

STL сильно повлияла на развитие шаблонов в Си++. И развитие это пошло в направлении, которое мне категорически не нравится.

> шаблоны были сделаны для того [...] чтобы не приходилолсь дублировать одинаковый код для разных типов. Т.е шаблоны логично вытекают из Строуструповского понимания ООП.

Причем тут Страуструп вообще? Шаблоны не имеют к ООП совсем никакого тоношения, ты не понимаешь этой простой вещи?

tailgunner ★★★★★
()
Ответ на: комментарий от nanokot

>Придел ли он на смену плюсам, а если нет, то на что смотреть как на возможную альтернативу плюсам?

Не придет. По причине того, что может и убрал некоторые загибоны плюсов - но он не добавил ничего особо ценного - или добавил, но раком. В результате получилось отсутствие в языке необходимых на сегодняшний день фичь, которе ребята вроде александреску реализуют поплюсовому - то есть даро^H раком. Достаточно глянуть на ужос вроде std.functional. Как опять нафигачили функциональщины - шаблонами.

r ★★★★★
()
Ответ на: комментарий от jtootf

>> а что смотреть как на возможную альтернативу плюсам?

> на Haskell, само собой

Грамотно вбросил %)

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

>>> Во 2-й редакции TC++PL он _объяснял_ шаблоны как "хитрые макроопредления". Понятно, что это всего лишь аналогия, направляенная тупым Си-прогерам.

>> Ну а замена Си-шным макросам по твоему вообще нужна?

>Не понял вопроса. Нормальный препроцессор - штука полезная, это очевидно. Только причем препроцессор к параметризованным типам и процедурам?

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

>> Что бы ты там упростил? По моему нечего там упрощать.

>Я бы ее не стал писать - недостоин-с.

Явных дефектов проектирования я в STL не вижу и не понимаю чего ты на нее так ополчился. Хотя лично я бы сделал в С++ высокоуровневые примитивы и нужды в STL бы не было.

>>> За pair Степанова нужно пытать перед повешанием.

>> А с помошью чего можно сгруппировать key и value для помещения в map и multimap?

>С помощью keyvalue<>

Это принципиально? Какие вообще проблемы могут быть с std::pair<>?

>>> А самое худшее в STL - то, что она открыла ящик Пандоры.

>> Это свехценная идея какая-то.

>STL сильно повлияла на развитие шаблонов в Си++. И развитие это пошло в направлении, которое мне категорически не нравится.

Оно пошло в том направлении как его видел Строуструп: когда функции неважно получила ли она указатель или итератор и неважно на простой или составной тип с подходящей сементикой.

>Шаблоны не имеют к ООП совсем никакого тоношения, ты не понимаешь этой простой вещи?

К ООП в понимании Строуструпа - имеют. Именно они призваны обеспечить такую "типовую прозрачность".

Absurd ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.