Здравствуйте, WolfHound, Вы писали:
WH>А как на С++ написать что-то типа такого ...
Хорошо, теперь я поглядел код
Опять цитатой от туда же (уж больно мне понравилось )
C++’s strengths lies in the huge range of what it is pretty good at rather than in what it’s superb at.
Да, тут nemerle рулит. В С++ есть паттерн-матчинг, но конечно не такой сильный...
Ну а как насчёт, ну не знаю, доступа к регистрам аппаратуры, или "написания программы на машинном коде" (ну это когда ты пишешь программу на яву, но при этом фактически знаешь, что будет делать процессор). Может это конечно тоже есть в nemerle — не знаю. В С++ есть и фичи для программирования на очень высоком уровне абстракции. Может оно, конечно, тоже не такое хорошее как в nemerle, но суть в том, что оно есть _всё_. На с++ я могу сделать всё. Пусть для чего-то мне понадобится в начале сделать свою библиотеку, и синтаксис будет не такой красивый. Но преград нет. В этом суть.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, remark, Вы писали:
WH>>>Во только С++ черизвычайно сложный и позволяет решать относительно сложные задачи... R>>Какие интересно задачи не позволяет решать С++? Имхо, если С++ сегодня не позволяет, то ни один язык сегодня не позволяет её решить. WH>Например компилятор nemerle. Написать его на С++ настолько сложная задача что справится с ней не сможет даже мелкософт с его гигабаксами. Меж тем на nemerle его ниписали два студента. WH>И больше всего у них проблем возникает с ошибками в CLR который сам понимаешь кем и начем написан. А ведь мелкософт может позволить себе нанять элиту. WH>Что уж говорить о конторах помельче...
no programming language is or could be a panacea, not even C++
WH>>>А для абсолютно сложных задач нужно что-то попроще и помощьнее. R>>Под complex он подразумевает не сложный (как алгоритм), а скорее комплексный. Т.е. некая real-world задача с неким абсолютно непредсказуемым набором нефункциональных требований, и которые могут непредсказыемым образом эволюционировать. WH>И как тут поможет С++?
У него нет семантической пропасти.
R>>Как бы это не было печально (или кому наоборот хорошо) и сегодня из-за семантической пропасти некое множество систем, написанных на языках _попроще_, или терпит крах или переписывается на С/С++... WH>Примеры в студию.
Был свидетелем как переписывали с явы — не тянула требования работать на очень слабых машиных, которое вначале как-то не учли, а потом уже не смогли ничего сделать...
С явы и шарпа, слышал, переписывают, когда по портируемости не тянет.
R>>Во-первых, язык с++ не такой уж и сложный для пофессионалов (ты согласился, что домохозяйкам не надо давать программировать). WH>Я сейчас работаю в одной очень крупной и богатой конторе. Основная разработка идет на С++. WH>Персонал набирают очень придирчиво. WH>Так вот даже тут есть всего человек 10 (не больше) у которых с С++ почти нет проблем.
А говорил, что вообще будет легко?
R>>Во-вторых, не так уж там много граблей. WH>Это ты мне не расказывай ладно?
Ну не знаю, я сейчас работаю, особых проблем не встречается. Но встречаются конечно, но не то, что б очень всё плохо.
R>>В-третьих, язык С++ очень мощный по выразительной мощности и по возможности абстрагироваться, и пакетировать функциональность (создавать повторноиспользуемые компоненты). По крайней мере из императивных языков. WH>Раскажи это тем кто не пишет сложные кроссплатформенные системы на С++ ладно? WH>Что касается выразительности то покажи мне сериализацию на С++, а потом я тебе покажу сериализацию на nemerle. WH>Да вобще просто посмотри http://nemerle.org/svn/nemerle/trunk/macros/ и подумай как это все будет выглядеть на С++.
А это не важно. Важно то, что real-world приложения сейчас пишут на С++. На чём, ты там говорил, ты пишеть кластерный сервер? Почему не на немерле?
Здравствуйте, WolfHound, Вы писали:
R>>В-третьих, язык С++ очень мощный по выразительной мощности и по возможности абстрагироваться, и пакетировать функциональность (создавать повторноиспользуемые компоненты). По крайней мере из императивных языков. WH>Раскажи это тем кто не пишет сложные кроссплатформенные системы на С++ ладно?
А какие у них проблемы?
WH>Что касается выразительности то покажи мне сериализацию на С++, а потом я тебе покажу сериализацию на nemerle. WH>Да вобще просто посмотри http://nemerle.org/svn/nemerle/trunk/macros/ и подумай как это все будет выглядеть на С++.
Поглядел:
Copyright (c) 2003, 2004 The University of Wroclaw.
Всё ясно
Диплом/кандидатскую кто-то видимо защитил
А если серьёзно, то — да как хочешь она будет выглядеть.
Есть просто надо ограниченный набор структур сериализовать — то просто перечислением полей в функции сериализации.
Если сериализовать действительно много — то можно подумать о генераторе кода — perl/самописный/готовый — asn.1 или ещё что-то.
Можно препроцессор подпрячь.
Можно описать список полей на template metaprogramming, тогда получится compile-time рефлекшн.
Можно ввести базовые классы для классов и полей, что б автоматически собирать информацию о структуре.
...
В общем несколько хватит фантации и какие требования.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, remark, Вы писали:
WH>>>Во только С++ черизвычайно сложный и позволяет решать относительно сложные задачи... R>>Какие интересно задачи не позволяет решать С++? Имхо, если С++ сегодня не позволяет, то ни один язык сегодня не позволяет её решить. WH>Например компилятор nemerle. Написать его на С++ настолько сложная задача что справится с ней не сможет даже мелкософт с его гигабаксами. Меж тем на nemerle его ниписали два студента. WH>И больше всего у них проблем возникает с ошибками в CLR который сам понимаешь кем и начем написан. А ведь мелкософт может позволить себе нанять элиту. WH>Что уж говорить о конторах помельче...
ну .net с++ осилил же. Или он тоже не на с++ написан?
и много там в CLR ошибок? Что-то сомневаюсь, что они только и знают, что продираться среди них.
PS: Ну вот по-хорошему проигнорировать тебя надо. А то на тухлую дорожку идем. Больше по этой теме не высказываюсь.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, remark, Вы писали:
R>>
R>>We need relatively complex language to deal with absolutely complex problems.
WH>Во только С++ черизвычайно сложный и позволяет решать относительно сложные задачи... WH>А для абсолютно сложных задач нужно что-то попроще и помощьнее.
Парни, имхо, вопрос философский и должен идти в соответствующий форум
Давай отделим ветку...
Здравствуйте, remark, Вы писали:
R>Здравствуйте, WolfHound, Вы писали:
WH>>Здравствуйте, remark, Вы писали:
R>>>
R>>>We need relatively complex language to deal with absolutely complex problems.
WH>>Во только С++ черизвычайно сложный и позволяет решать относительно сложные задачи...
R>Какие интересно задачи не позволяет решать С++? Имхо, если С++ сегодня не позволяет, то ни один язык сегодня не позволяет её решить.
В C++ даже нет такого базового свойства как рефлексия. Дальше можно не продолжать.
WH>>А для абсолютно сложных задач нужно что-то попроще и помощьнее.
R>Под complex он подразумевает не сложный (как алгоритм), а скорее комплексный. Т.е. некая real-world задача с неким абсолютно непредсказуемым набором нефункциональных требований, и которые могут непредсказыемым образом эволюционировать.
R>В одной из других статей (сейчас точно не помню в какой) он так же писал про понятие т.н. семантической пропасти языка. Это когда вдруг появляется некое требование, которое изначально не было учтено, и которое язык принципиально не позволяет реализовать.
R>Часто такими требованиями бывает портируемость не некую платформу, производительность, потребление памяти, доступ к аппаратному обеспечению, полный доступ к возможностям ос и т.д.
Это как раз к семантике (т.е. смыслу программы) никакого отношения не имеет. Это чисто технические подробности реализации.
R>Как бы это не было печально (или кому наоборот хорошо) и сегодня из-за семантической пропасти некое множество систем, написанных на языках _попроще_, или терпит крах или переписывается на С/С++...
Примеры?
R>Во-первых, язык с++ не такой уж и сложный для пофессионалов (ты согласился, что домохозяйкам не надо давать программировать).
) которые дают просто таки комбинаторный взрыв разных очень заковыристых случаев. А если еще вспомнить про всякие SFINAE .
R>Во-вторых, не так уж там много граблей.
R>В-третьих, язык С++ очень мощный по выразительной мощности и по возможности абстрагироваться, и пакетировать функциональность (создавать повторноиспользуемые компоненты). По крайней мере из императивных языков.
Он очень слаб с точки зрения создания повторноиспользуемых компонент, поскольку
1) нет стандарта ABI. Попробуй-ка хотя бы передать std::vector из программы скомпилированной компилятором A в библиотеку скомпилированную компилятором B и там его заресайзить. Это 100% UB.
2) нет нормальной системы модулей как в .NET/JVM/whatever, есть заголовочные файлы, которые просто текст, который вообще-то говоря никто не запрещает менять и после компиляции библиотеки при этом возможны любые ошибки. Как насчет изменения pragma pack? Я уж не говорю что чтобы это более менее быстро компилировалось нужны всякие свистопляски с guards и precompiled headers, что вообще костыли .
R>Вобщем, Страуструп там действительно очень грамотно пишет, и на все эти вопросы отвечает (лучше меня). Рекомендую прочитать.
Он выступает в основном против упрощения программирования и считает, что профессионалам нужны мощные инструменты. С этим я согласен.
R>>>Напоследок ещё одна цитата — просто очень понравиась: R>>>
R>>>why do I see character echo delays in Word on my 2GHz, 2Gb computer? I didn’t see that on my editor on a shared 1MHz, 1Mb PDP11 25 years ago
WH>>Угу вот только word написан на С/С++.
R>Это он о другом там говорит — об сегодняшнем образовании и об сегодняшнем подходе. И вообще:
R>[q] R>In C++, you can write code that is simultaneously elegant and efficient.
У меня elegant не получается . Хотя бы потому что нет foreach и вывода типов. Да и с efficient не всегда получается (т.к. стандартные malloc/new довольно медленные по сравнению с выделением памяти в .NET/Java).
D уже лучше в этом смысле, хотя там от многих вещей которые мне нравятся в C++ (const, ссылки, перегрузка=) отказались.
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, WolfHound, Вы писали:
WH>>Здравствуйте, remark, Вы писали:
R>>>
R>>>We need relatively complex language to deal with absolutely complex problems.
WH>>Во только С++ черизвычайно сложный и позволяет решать относительно сложные задачи... WH>>А для абсолютно сложных задач нужно что-то попроще и помощьнее.
J>Парни, имхо, вопрос философский и должен идти в соответствующий форум J>Давай отделим ветку...
Мои два цента в дискуссию — из того же Страуструпа:
However, the solution is not to dumb down the programming languages but to use a variety of programming languages and educate more experts. There has to be languages for those experts to use – and C++ is one of those languages.
Нужно пользоватся всем, что предоставил нам человеческий гений в лице творцов языков и прочего.
А то получается (пользуясь аналогией Бьярне), что два плотника спорят, что лучше — гвозди или шурупы.
Причем споря не для конкретных случаев, а вообще.
То, что у С++ много проблем — никто с этим не спорит, иначе бы комитет не занимался ничем и понятия C++ evolution не было бы вообще.
Направления развития понятны и четко озвучены (это видно на обсуждаемой страничке комитета), и никто не пребывает в эйфории, думая, что С++ идеален.
К сожалению, то, что язык никому не принадлежит, а используется всеми, делает процесс стандартизации слишком сложным и долгим, в отличие от проприетарных языков типа жавы и шарпа.
Здравствуйте, jazzer, Вы писали:
J>К сожалению, то, что язык никому не принадлежит, а используется всеми, делает процесс стандартизации слишком сложным и долгим, в отличие от проприетарных языков типа жавы и шарпа.
Это спорный вопрос. Проприетарные языки развиваются узкой группой людей, которых никто не знает, которые мотивированы непонятно чем. В результате язык становится заложником корпоративной политики. Вспомни яву. Язык не развивался много лет пока не появился .Net.
C++ же развивался под воздействием требований разработчиков, возникших не на пустом месте, и не вымученых из головы, а основаных на опыте практического применения. Результат налицо.
Здравствуйте, WolfHound, Вы писали:
R>>В-третьих, язык С++ очень мощный по выразительной мощности и по возможности абстрагироваться, и пакетировать функциональность (создавать повторноиспользуемые компоненты). По крайней мере из императивных языков. WH>Раскажи это тем кто не пишет сложные кроссплатформенные системы на С++ ладно?
Вот тут не очень понял. Ты имеешь ввиду, что сложные кроссплатформенные системы нельзя писать на C++? Или что тем, кто не пишет сложных кроссплатформенных систем, C++ с его фичами не нужен?
WH>Что касается выразительности то покажи мне сериализацию на С++, а потом я тебе покажу сериализацию на nemerle.
-- хотелось бы посмотреть на аналогичные средства в Nemerle (как говорится здесь и сейчас, по факту ). Чтобы там было расширение типов в будущем, в том числе и для наследования.
А еще можно попросить показать реализацию ASN.1 на Nemerle, тоже интересно посмотреть, когда она вообще появится.
Я это к тому, что для C++ при всех его проблемах есть достаточное количество наработок, которые для других, "более правильных" языков еще нужно делать, делать и делать. А программы нужно писать здесь и сейчас.
Если же говорить по теме ветки, то, имхо, сейчас очень большая проблема с C++ в том, что ему нужно учить людей годы. В то время как конкуренты (могу смело говорить за Java) осваиваются гораздо быстрее (по крайней мере на том уровне, когда на ровном месте люди на грабли не наступают). А в C++ сейчас проекты развиваются не по пути упрощения, а наоборот -- усложнения. Например, Boost во многих местах имеет сложную реализацию. И это считается нормальным, мол, это библиотечный код, пользователям в него заглядывать не нужно. А мне кажется, что наоборот -- язык должен быть таким, чтобы даже сложные вещи в нем можно было реализовывать так, чтобы не сильно продвинутые программисты могли в реализации разобраться. И, мне кажется, на C++ можно именно так и программировать (пример -- ACE). Но вот что-то C++ привлекает к себе любителей понапридумывать сложностей... Поэтому с точки зрения обучения C++у молодежи C++ вообще в очень тяжелом положении.
А нововедения в стандарт, мне кажется, еще больше повысят порог вхождения.
Из-за чего может получится эффект выжженой земли -- заматеревшие C++ программисты, которые уже давно на нем работаю и никуда не переходят, получат от C++09 выгоды. Но молодежь к C++у будет обращаться все реже и реже, соответственно, образуется пробел между поколениями "старых" и "молодых" программистов.
Такое вот MHO.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
[]
АХ>В C++ даже нет такого базового свойства как рефлексия. Дальше можно не продолжать.
Хе-хе. Она мне в с# почти ни разу не пригодилась, не говоря уже о с++. Имхо рефлексия нужна там, где есть ошибки проектирования (сериализацию и т.п. в расчет не берем).
) которые дают просто таки комбинаторный взрыв разных очень заковыристых случаев. А если еще вспомнить про всякие SFINAE .
И че там такого сложного? Хочешь испугать — приводи че-нить посложнее.
R>>Во-вторых, не так уж там много граблей.
АХ>
кто про что, а вшивый про баню
R>>В-третьих, язык С++ очень мощный по выразительной мощности и по возможности абстрагироваться, и пакетировать функциональность (создавать повторноиспользуемые компоненты). По крайней мере из императивных языков.
АХ>Он очень слаб с точки зрения создания повторноиспользуемых компонент, поскольку
В общем согласен. Но COM продвинул с++ в этом плане.
WH>Например компилятор nemerle. Написать его на С++ настолько сложная задача что справится с ней не сможет даже мелкософт с его гигабаксами. Меж тем на nemerle его ниписали два студента.
Ну-ну, вон три человека сумели компилятор С++ с экспортом шаблонов написать, да еще и на С. Наверное, справились бы и с немерле.
Of course, the code must be complete enough to compile and link.
Здравствуйте, Константин Л., Вы писали:
АХ>>В C++ даже нет такого базового свойства как рефлексия. Дальше можно не продолжать.
КЛ>Хе-хе. Она мне в с# почти ни разу не пригодилась, не говоря уже о с++. Имхо рефлексия нужна там, где есть ошибки проектирования КЛ> (сериализацию и т.п. в расчет не берем).
Почему не берем? Это одна из базовых и необходимейших задач, а ее значение в свете веб-сервисов еще важнее. А также сюда же AOP, Unit Tests и еще много других нужных и полезных технологий.
АХ>>Да? Да все тонкости C++ мало кто знает. В нем слишком много концепций (см. хотя бы Re[4]: Посоветуйте книжку по С++.
) которые дают просто таки комбинаторный взрыв разных очень заковыристых случаев. А если еще вспомнить про всякие SFINAE .
КЛ>И че там такого сложного? Хочешь испугать — приводи че-нить посложнее.
Да каждая вещь кажется сама по себе несложной, но когда их вместе применяют возможны самые неожиданные эффекты, при этом компилятор еще и пытается как правило в случае неоднозначности "угадать" лучший вариант .
АХ>>Он очень слаб с точки зрения создания повторноиспользуемых компонент, поскольку
КЛ>В общем согласен. Но COM продвинул с++ в этом плане.
COM — это кроссязыковая технология и при этом такой жутик, что MS пришлось сделать .NET. При этом собственно изначально .NET возник из проекта по добавлению метаданных к C++ (здесь), но в процессе оказалось что для полноценной компонентной технологии этого мало.
Здравствуйте, Шахтер, Вы писали:
Ш>Это спорный вопрос. Проприетарные языки развиваются узкой группой людей, которых никто не знает,
Ну как правило этих людей все знают .
Ш> которые мотивированы непонятно чем.
Они мотивированы конкуренцией. Т.е. язык который они сделают должен быть чем-то лучше чем те которые уже есть, тогда он сможет отвоевать у них часть рынка. Поэтому его необходимо сделать лучше чем существующие.
Ш> В результате язык становится заложником корпоративной политики.
Только отчасти. Если корпорация будет пытаться слишком подминать под себя разработчиков они уйдут к конкурирующим языкам.
Ш>Вспомни яву. Язык не развивался много лет пока не появился .Net.
+1. Вот оно — благотворное влияние конкуренции.
Ш>C++ же развивался под воздействием требований разработчиков, возникших не на пустом месте, и не вымученых из головы, а основаных на опыте практического применения. Результат налицо.
В результате сборная солянка. Очень много чего напихали (и еще больше хотят) и теперь попробуй-ка напиши для этого дела компилятор. Я уж не говорю, что он жутко медленным будет.
Здравствуйте, Андрей Хропов, Вы писали:
АХ>Здравствуйте, Шахтер, Вы писали:
Ш>>Это спорный вопрос. Проприетарные языки развиваются узкой группой людей, которых никто не знает,
АХ>Ну как правило этих людей все знают .
Вряд ли. Скажем C#. Библиотеки для него написаны толпой безликих программистов.
Известны обычно только несколько лидеров проекта.
Ш>> которые мотивированы непонятно чем.
АХ>Они мотивированы конкуренцией. Т.е. язык который они сделают должен быть чем-то лучше чем те которые уже есть, тогда он сможет отвоевать у них часть рынка. Поэтому его необходимо сделать лучше чем существующие.
Нет языковой конкуренции. java, скажем принадлежит просто другому классу чем C++, поэтому бессмысленно говорить о конкуренции java и C++.
Язык возникает как ответ на потребность в результате осмысления опыта. Этот процесс не может быть мотивирован конкуренцией.
Ш>> В результате язык становится заложником корпоративной политики.
АХ>Только отчасти. Если корпорация будет пытаться слишком подминать под себя разработчиков они уйдут к конкурирующим языкам.
Ага, щаз. Потрут весь code-base и уйдут.
Ш>>Вспомни яву. Язык не развивался много лет пока не появился .Net.
АХ>+1. Вот оно — благотворное влияние конкуренции.
Ш>>C++ же развивался под воздействием требований разработчиков, возникших не на пустом месте, и не вымученых из головы, а основаных на опыте практического применения. Результат налицо.
АХ>В результате сборная солянка.
Это твою личное неправильное мнение. С++ -- очень логичный и стройный язык. Если у тебя с ним проблемы -- это твои проблемы, а не языка.
АХ>Очень много чего напихали (и еще больше хотят) и теперь попробуй-ка напиши для этого дела компилятор.
Написать компилятор C++ -- не проблема.
АХ>Я уж не говорю, что он жутко медленным будет.
Почему то современные компиляторы C++ не являются жутко медленными. Опять врешь.
Здравствуйте, Шахтер, Вы писали:
АХ>>Я уж не говорю, что он жутко медленным будет.
Ш>Почему то современные компиляторы C++ не являются жутко медленными. Опять врешь.
К сожалению, если сравнивать, например, с компилятором D, то являются жутко медленными. Се ля ви.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Андрей Хропов, Вы писали:
АХ>Здравствуйте, Константин Л., Вы писали:
АХ>>>В C++ даже нет такого базового свойства как рефлексия. Дальше можно не продолжать.
КЛ>>Хе-хе. Она мне в с# почти ни разу не пригодилась, не говоря уже о с++. Имхо рефлексия нужна там, где есть ошибки проектирования КЛ>> (сериализацию и т.п. в расчет не берем).
АХ>Почему не берем? Это одна из базовых и необходимейших задач, а ее значение в свете веб-сервисов еще важнее. А также сюда же AOP, Unit Tests и еще много других нужных и полезных технологий.
SOAP сериализация — да. Вэб-сервисы — частный случай. Поддержка AOP должна быть на уровне языка.
[]
АХ>COM — это кроссязыковая технология и при этом такой жутик, что MS пришлось сделать .NET. При этом собственно изначально .NET возник из проекта по добавлению метаданных к C++ (здесь), но в процессе оказалось что для полноценной компонентной технологии этого мало.
жутик? А может просто у некоторых людей проблемы с с++ и COM и им надо что-то попроще? Ну так пусть юзают что попроще, но к нам сюда не лезут.
Здравствуйте, Lorenzo_LAMAS, Вы писали:
WH>>Например компилятор nemerle. Написать его на С++ настолько сложная задача что справится с ней не сможет даже мелкософт с его гигабаксами. Меж тем на nemerle его ниписали два студента.
L_L>Ну-ну, вон три человека сумели компилятор С++ с экспортом шаблонов написать, да еще и на С. Наверное, справились бы и с немерле.
Сложность разработки C++ front-endа можно оценить в 10-12 человеко-лет. Back-enda -- ещё в столько же. Это вобщем небольшие проекты по современным меркам.
Кроме того, для проектов такого рода написание кода -- не самая большая проблема.
Усилий на проверку корректности поведения компилятора надо потратиь значительно больше, чем на его разработку.
С++, кстати, замечательно подходит для написания компиляторов, учитывая, что хороший компилятор содержит массу алгоритмически нетривиальных вещей.
Здравствуйте, Шахтер, Вы писали:
Ш>Усилий на проверку корректности поведения компилятора надо потратиь значительно больше, чем на его разработку.
Ну так на это тест-сьюты есть. EDG поименно называют, через что они свой фронтэнд прогнали. Бешеных денег стоят, кстати. Вот на разработчиков тестов и ляжет основная нагрузка при выходе нового стандарта, имхо.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Шахтер, Вы писали:
АХ>>>Я уж не говорю, что он жутко медленным будет.
Ш>>Почему то современные компиляторы C++ не являются жутко медленными. Опять врешь.
E>К сожалению, если сравнивать, например, с компилятором D, то являются жутко медленными. Се ля ви.
Языки разные. Кроме того, если ты не используешь "навороченные" библиотеки с матерноэтажными шаблонами типа boost, то скорость компиляции очень хорошая.
Основная причина низкой скорости компиляции больших С++ проектов -- это изобилие тяжелых заголовков. Хорошо помню, как сам избавлялся в старые добрые времена от iostream.h по этой причине.
К сожалению, современный С++ страдает библиотечной болезнью. Т.е. когда пишутся безразмерные библиотеки "общего назначения", которые однако оказываюся плохо приложимыми для решения конкретных задач. Как результат -- и компилируется медленно, и испольняется тоже. Да ещё и тянет мегабайты мертвого кода.
Повторное использование кода -- хорошая штука, но она не избавляет от необходимости думать.
.
. Хотя бы потому что нет foreach и вывода типов. Да и с efficient не всегда получается (т.к. стандартные malloc/new довольно медленные по сравнению с выделением памяти в .NET/Java).
.