LINUX.ORG.RU

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

Всё равно будущее за питоном.

рептилии выживут после ядрёной войны?

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

это, предполагаю, те, кто недавно поселились

в чущи!

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

хорошо, замени слово «удобный» на «лучше чем никакой» :)

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

В том числе да. А главное - потому, что C++ - объектно-ориентированный, а C - нет (это тоже можно рассматривать как фичу).

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

g++

даже в 4.6 ещё не всё (плюс далеко не всегда есть возможность использовать даже 4.6)

поделие_врага_#1

тут буквально в этом месяце кто-то пейсал, что как-то совсем не фонтан, сам не трогал, врать не буду

В Intel и clang активно пилится.

а работать-то нужно сейчас, угу

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

Полужив и никем не поддерживаемый толком.

Deleted
()
Ответ на: комментарий от lazyklimm

даже в 4.6 ещё не всё

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

тут буквально в этом месяце кто-то пейсал, что как-то совсем не фонтан, сам не трогал, врать не буду

Да я тоже не трогал, но, говорят, там оно есть :)

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

что ты говорил про "поделие_врага_#1"

теперь покажи мне компиляторы, которые его нормально поддерживают.

g++ и поделие_врага_#1. В Intel и clang активно пилится.

gcc 4.7 - 30/35
clang 3.0 - 31/35
msvc 10.0 - 16/35
http://wiki.apache.org/stdcxx/C++0xCompilerSupport?action=print

seed_stil ★★
()
Ответ на: что ты говорил про "поделие_врага_#1" от seed_stil

clang 3.0 - 31/35

Там лямбд нету и других самых часто используемых фич :) Initializer Lists - тоже нет, а жаль - весьма вкусная фича.

что ты говорил про «поделие_врага_#1»

Посмотрел. Действительно, с поделием врага #1 все плохо :)

Deleted
()
Ответ на: комментарий от PolarFox

C++ - объектно-ориентированный

Разве? В нём ведь функции…

Ну, ведь, объектно-_ориентированный_, а не объектный :)

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

Ну в си тоже можно сделать ООП различными способами. Явно передавать указатель на структуру «методам объекта», сделать какой-нибудь динамический рантайм с набором функций или сделать умный препроцессор и получить валу, с++ (cfront) или обжектив-си.

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

Ну в си тоже можно сделать ООП различными способами.

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

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

С++ — такое же ужасное мессиво, только с ключевым словом class. Где duck typing, блин? Без дактайпинга, я считаю, подобное ооп — не ооп, а хитрые неймспейсы со структурами.

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

и чем он лучше шаблонов

Всё что угодно лучше compile-time шаблонов.

обычного наследования

Как я полагаю, множественного. Отличный способ попасть стрелой в колено.

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

Как я полагаю, множественного. Отличный способ попасть стрелой в колено.

Обоснуй свою ненависть к множественному наследованию. [qutoe]Всё что угодно лучше compile-time шаблонов. А duck typing - это уже не compile-time?

Deleted
()
Ответ на: комментарий от PolarFox

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

Как я полагаю, множественного. Отличный способ попасть стрелой в колено.

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

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

Duck typing обычно разруливается в рантайме. В том же objective c можно вообще решить, как реагировать на незнакомый метод.

Обоснуй свою ненависть к множественному наследованию

Мои представления о наследовании не совпадают с таковым у автора и поклонников языка С++.

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

Всегда удивляло, как плюсеры любят апеллировать к некоему «осиливанию». Это же не хаскель какой-нибудь, чтобы его надо было осиливать, а вполне себе примитивный язычок со стрёмными фичами, лишь бы compile time.

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

Если он для тебя достаточно примитивен - чего ныть о «ненужных вещах»? :) Твои представления о наследовании в С++ достаточно показывают «не читал, но осуждаю». С++ не прибит гвоздями к множественному наследованию - если оно тебе понадобилось для чего-то, может подумать еще немного? Возможность выбрать удобное подмножество языка - предпосылка к тому, что называется «стиль» :) Пользоваться острыми и достаточно примитивными инструментами без навыков тоже опасно. Это не значит, что они не нужны, потому что ты не можешь ими яйца чесать, как привык. Есть обширная категория людей, которых постоянно надо защищать от самих себя. Особенно если они берутся не за свое дело.

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

Duck typing обычно разруливается в рантайме.

Тогда уж тем более он неуместен в C-like языках. А какие такие фичи даст duck typing, которые не даст наследование или шаблоны?

Мои представления о наследовании не совпадают с таковым у автора и поклонников языка С++.

Можно объективную критику, а не КГ/АМ?

Deleted
()
Ответ на: комментарий от PolarFox

Острый нож тоже примитивен, но весьма функциональный, но при неумелом использовании можно убиться или отрезать себе чего-нибудь, поэтому осиливание нужно :)

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