LINUX.ORG.RU

быстрый взгляд на C++0x


0

0

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

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

Обещается опциональная сборка мусора и поддержка параллелизма. Внимание разработчиков стандарта фокусируется на расширениях, которые "меняют способ которым люди думают" (дословно!). Добавлено наиболее значительное расширение - "концепция" как "тип типов" (посредством where-выражения) и обобщенный список инициализации. Обещано, что вектора базовых типов будут работать не медленнее встроенных массивов тех же типов. В общем всё для того, чтобы сделать обощённое программирование таким же мейнстримом как объектно-ориентированное.
Также комитет по языку уже проголосовал за добавку в STL хешей, регекспов, смарт-поинтеров, генераторов случайных чисел и математических спец-функций. Появится новый тип итераторов - auto с автоопределением своего типа. Наконец-то стандартизаторы обещают уделять внимания простоте не меньше, чем гибкости но, тем не менее, не в ущерб последней.

Просьба языковой флейм не начинать, языки всякие важны, языки всякие нужны.

>>> Подробности

★★

Проверено: Pi ()

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

>>Где Страуструп говорит, что С++ не ООП язык?

<cut>
C++ is a multi-paradigm programming language that supports Object-Oriented and other useful styles of programming
<cut>

вы бы ещё всю статью сюда положили, или лучше книгу )
Цитату не нашли, решили целиком параграф послать?.

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


>Кстати ответ про ООП-ность C++ адресовался не лично вам, но вы полезли отвечать и на него

нечего в ответ на мой пост писать было ответ всем, хоть бы 2all вставили, как маленький, её богу.

>Ссылку на статью я уже давал
не давали, да и своими словами объяснить тоже не сможете.

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

Спасибо за интересную цитату. Особенно понравилось "Writing Smalltalk-style in C++ can be equally frustrating and sub-optimal as writing C-style code in C++". Это-то и огорчает, и вместе с тем ставит точки над плюсом... Эклектизм и является причиной того горького катаклизма, который мы сегодня наблюдаем в виде плюсов...

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

> >Перфокарты - тоже кое где встречаются.

> Никак в передовых китайских универах? Али в ПТУ в твоем застранском городе?

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

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

> На C++ полно языковых возможностей, от которых всегда можно отказаться если они мешают.

К сожалению, нет, нельзя.

Мне, например, зачастую _очень_ мешают exception'ы. Но как от них отказаться, если их запускает стандартная библиотека?

Это просто так, для примера.

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

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

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

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

>>Ссылку на статью я уже давал

>не давали, да и своими словами объяснить тоже не сможете.

http://www.linux.org.ru/view-message.jsp?msgid=1217255#1219112 Танкист )

wbr

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

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

Неправда.
тип 'long long' стандартен для C99, но нестандартен для C++.
макросы с переменным количеством аргументов стандартны для C99,
но, опять-таки не для C++.
Инициализация в духе (очень удобно, между прочим):
struct ab_t { int a; double b; };
struct ab_t ab =
{
.a = 1,
.b = 0.5
};
стандартна в C99 и спросто синтаксическая ошибка в C++.

Про геморой на C++ если надо организовать, например, именно 32-х
разрядное беззнаковое целое на платформе _неизвестной_
разрядности, и нет никакой возможности задействовать autoconf & Co
я вообще молчу.
В случае же C99 есть абсолютно стандартный uint32_t и если
его по какой-то причине нет -- то это не C99 компилятор.

И так можно продолжать.

Посему: на тукущий момент C и C++ -- это несколько разные языки.
Похожие, но разные. Даже если "забыть" такую "мелочь" как
абсолютно разные привычки и накатанные пути решения у пишущих
на этих языках.

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

>Пост про "неООП-ность" С++ был дан в контексте ответа про "нефункциональность" ЛИСП

Да ещё и в ответ на мой пост, в котором я ни слова не говорил ни про С++ ни про LISP.
Так вот, в той статье, автор говорит, что С++ не только ООП язык. Там нет ни одной фразы про то, что автор считает С++ не ООП языком.
Разницу понимаете? ;-)


>>>Ссылку на статью я уже давал
>>не давали, да и своими словами объяснить тоже не сможете.
>http://www.linux.org.ru/view-message.jsp?msgid=1217255#1219112

Мда... ;-)
Напоминаю, вы утрвержали, что autoboxing влияет на производительность generics .
В статье, говорится как применять autoboxing и как не применять при работе с generics.

кроме шуток, вы правда все ещё считаете, что скорость работы generics как то связана с autoboxing? ;-)))

ps Я только один раз видел человека на ЛОР который имел мужество признаться, что был не прав.
То ли правда народ глупеет, то ли дальше некуда.




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

> Вот когда создатели жабы откажутся от байткода

Тебе обязательно что бы создатели? gcj, вроде как в натив компилит, нет? Потом, практика показала, что JIT не шибко хуже. Ну, если, конечно, не ставить вопрос о задачах, типа, рендринга... В упомянутом тобой текстовом процессоре, большую часть времени приложение ждёт пользовательсткого ввода...

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

>К сожалению, нет, нельзя.

>Мне, например, зачастую _очень_ мешают exception'ы. Но как от них
>отказаться, если их запускает стандартная библиотека?

Думаю там, где не нужны exceptions, и stl будет как корове седло...
тут ведь речь о том, что можно С++ превратить в С с классами, т.е.
например вместо использования структур с указателями использовать
классы, но не более того. Т.е. никаких извратов с шаблонами,
перегрузками, неявными конструкторами и прочими прелестями С++.
(за взятие ссылки "&" струпа надо пристрелить, в .Net в этом плане
неплохо сделали с in/out модификаторами).

>Посему: на тукущий момент C и C++ -- это несколько разные языки.
>Похожие, но разные. Даже если "забыть" такую "мелочь" как
>абсолютно разные привычки и накатанные пути решения у пишущих
>на этих языках.

Не согласен. Вот java и c++ - разные (не смотря на похожий синтаксис,
принцип другой :) - "все есть указатель который нельзя трогать
руками"). А вот С и С++ близкие (тончнее один является super-типом
другого с небольшими отличиями и ограничениями).

По поводу best-practice для этих языков, ИМХО даже для разных платформ
разные best-practice и conventions. А в общем и целом все довольно
похоже (если не рассматривать реальный C++, а не "С с классами").
Пример - win32 C++. Чистейший С с фичами из С++ (типа шоб this
нахаляву передавался, а не в виде dev_t его в каждую функцию пихать).

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

>Sun давным давно открыл исходники Java.

ГДЕ?

Если это о JRE, то интересно, не более... а вот где исходники JIT? :)

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

Где, где... На java.sun.com. Регистрируешься и качаешь. Есть там сырцы Hotspot. Кстати - отвратительнейший код.

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

>интересно када сан откроет исходники жабы что мы там увидим c или c++ %)

По RLE лицензии ты уже сейчас можешь все исходники увидеть

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

>Например:

>MyClass mc(arg1, arg2, ..., argn); >MyClass newmc(mc); //Для newmc будет вызван конструктор копирования

MyClass mc(arg1, arg2, ..., argn); MyClass newmc = mc.clone(); Ну и? Чем хуже?

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

C++. И очень кривой C++. Например, код server и client Hotspot-ов - разный. Уроды!

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

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

Хаскель по потребляемой памяти идет нос в нос с явой, причем без жита, а компилить ghc без гига памяти - мазохизм.

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

>Где, где... На java.sun.com. Регистрируешься и качаешь. Есть там сырцы >Hotspot. Кстати - отвратительнейший код.

Кинь линком... зарегился, но в упор не вижу :(

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

>http://www.linux.org.ru/view-message.jsp?msgid=1217255#1219112 Танкист )

ТАм не написано что генерики "тормозят" scientific computing. ТАм написано что его тормозит autoboxing.

Генерики там только в качестве иллюстрации так же как и for-each.

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

>...калькулятор на флеш будет покрасивее. Софт это не только веб а если такой мощный язык как джава нужен только для веб то нафик он такой мощный нужен.

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

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

>> Мне, например, зачастую _очень_ мешают exception'ы. Но как от них отказаться, если их запускает стандартная библиотека?

> Думаю там, где не нужны exceptions, и stl будет как корове седло...

Не факт. Точнее в в текущей его реализации -- факт. Но сама идея неплоха.

Но речь-то всё-равно не о том. Речь о том, что запрет на exception'ы полностью разрушает идеологию языка. И проще поменять язык, чем заблокировать эту его "фичу".

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

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

И это только для своего кода.

Если же код чужой (используется какая-нибудь c++ библиотека, например), то тут уже только морг и даст гарантию. Точка выхода может оказаться любой. Состояние на момент выхода -- любое. Побочные эффекты -- любые. Да ещё операторы по перегружают. И статических объектов на создают, чтобы в ихнем конструкторе что-нибудь сотворить, чего я _не_ хочу. Да ещё и про неопределённость времени вызова деструктора забудут.

Хотьба по минному полю, право слово...

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

>gcj, вроде как в натив компилит, нет? Потом, практика показала, что JIT не шибко хуже.

gcj хуже hotspot'а как по скорости, так и по потреблению памяти. почему он должен быть лучше то?

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

> Вопрос первый. Представьте, в базовом классе B описана виртуальная функция f, потом в дочернем классе D она переопределена. Что будет, если вызов f запихнуть в конструктор класса B - если на самом деле я создаю объект класса D? Оцените время поиска ошибки, если функция f вызывается не прямо из конструктора, а внутри некоторой функции, вызываемой внутри некоторой функции, вызываемой из конструктора.

Компилятору нет дела до ваших извращений и потому он не будет разбераться в том, для чего конструктор вызывает ту или иную функцию. Метод DWIMNIS(Do what I mean, not I say) в С++ не работает. В данном случае строго соблюдается инкапсуляция и с этой точки зрения компилятор генерит корректный код вызывая функцию базового класса(ну, вернее должен так делать)

> Вопрос второй. Оцените легкость поддержки кода, наполненного по делу и не по делу перегруженными операторами.

Правокация флейма ;>

> Доп. вопрос. Как сочетается декларируемая бинарная совместимость по структурам данных с С - и необходимость хранения rtti информации для классов?

Тут не уверен. Но, информация о типах храниться вне класса. Нет?

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

Из С++ не стали ничего выкидывать, что бы не случилось:

"And when I tell people that, they tend to nod, and have some story of their own why they had a feature they used to use, but it was removed because it might have been confusing." - Linus about ... :)))))

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

Удел питона - прототипирование для C++, твой удел - стена, разбегайся!

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

Генерики вообще только во время компиляции проявляются, в рантайме нет их поддержки (и нах не надо).

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

Сами приложения памяти много не жрут. GHC такой прожорливый от шибко умных оптимизаций.

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

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

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

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

Я не SVU, но позволю себе ответить:

>> Вопрос первый. Представьте, в базовом классе B описана виртуальная функция f, потом в дочернем классе D она переопределена. Что будет, если вызов f запихнуть в конструктор класса B - если на самом деле я создаю объект класса D? Оцените время поиска ошибки, если функция f вызывается не прямо из конструктора, а внутри некоторой функции, вызываемой внутри некоторой функции, вызываемой из конструктора.

> Компилятору нет дела до ваших извращений и потому он не будет разбераться в том, для чего конструктор вызывает ту или иную функцию. Метод DWIMNIS(Do what I mean, not I say) в С++ не работает. В данном случае строго соблюдается инкапсуляция и с этой точки зрения компилятор генерит корректный код вызывая функцию базового класса(ну, вернее должен так делать)

Компилятору -- конечно же нет. Но мне, как девелоперу, очень даже есть. Просто ввиду сложности языка, количество точек, где человек ошибается (получает не то, что хотел) резко возрастает. Добавим к этом точки, где человек получает абсолютно то, что хотел, вот только забыл подумать на 10 шагов вперёд, чем это закончится для другого человека (который попытается повторно его код использовать)...

Вот и получаем, что более-менее спокойно можно использовать только код написанный людьми _очень_ высокой квалификации. И, ввиду синтаксических особенностей языка, верифициовать его нет никакой возможности (в разумное время). Для сомневающихся простой тест -- найдите точку, где был перегружен оператор '+'. И был ли вообще перегружен.

Из-за невозможности повторного использования растёт общее время и трудозатраты.

И, как следствие, возникает неодолимое желание "не тратить силы, а просто взять молоток побольше".

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

> применять только для написания сайтов и аплетов

Детка, "сайт" - это не только домашняя страничка Васо Пупидзе.

> и альтернативы нет и в ближайшее время не будет

Просто лжешь.

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

> Генерики вообще только во время компиляции проявляются, в рантайме нет их поддержки (и нах не надо).

Поэтому самый безобидный на вид код компилируется в ужас, летящий на крылях ночи. Который ужас, собственно, и тормозит. чтд.

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

> Детка, "сайт" - это не только домашняя страничка Васо Пупидзе.

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

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

> на швейцарского работодателя в системе форекс

Гы гы гы, лошок ушастый.

> и не хуже тебя знаю что такое сайт.

Убейся в стену. Google - это сайт? :)

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

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

А заглянуть в объявления классов или быстренько прогнать программу и библиотеки дебагером ну совсем не судьба? :(

Забегая вперед, если вы о закрытом коде, то там кроме отсутствия информации о перегрузках операторов много чего интересного может быть скрыто(например указатели на void закрашенные typedef под что-нибудь очень красивое и умное и т.п и т.д.). Если оно работает и есть не просит, то какое вам дело до того, перегружен ли тот или иной элемент или нет?

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

Для этого даже книжки есть по ОО проектированнию и дизайну.

Если вам нужно быстро и что бы с дебагером не возиться и вообще всё сходу с нуля написать, тогда - да, С++ - это не то, что вам нужно. Просто не используйте его, но ругать то зачем? Критика необъективная выходит.

> Из-за невозможности повторного использования растёт общее время и трудозатраты.

С++ как раз и позиционируется как язык с мощьнейшим уровнем reuse кода. То есть, это выходит неправда?

> Вот и получаем, что более-менее спокойно можно использовать только код написанный людьми _очень_ высокой квалификации.

Команды из сотен программистов разной квалификации спокойно работают над одним проектом и не знают, что такое оказывается невозможно. Нонсенс просто какой-то! :))))

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

> > Вот и получаем, что более-менее спокойно можно использовать только код написанный людьми _очень_ высокой квалификации.

А вы хотите спокойно использовать код, написанный кем?

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

Pi (*) (04.01.2006 20:38:24) жуйте опилки:

K 3.2 2005-10-16 Copyright (C) 1993-2005 Kx Systems WIN32 1CPU 255MB ppp85-140-58-55.pppoe.mtu-net.ru 0 EVAL

factorial:{:[1=x;1;_f[x-1]*x]}

чуешь? тут по облюдочному два раза название функции не надо юзать.

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

> Генерики вообще только во время компиляции проявляются, в рантайме нет их поддержки (и нах не надо).

Немножко есть - но об этом умолчим ;)

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

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

А основания так говорить есть? Если вот например пойти на сорсефоржу - мы там найдем все сплош фреймворки для веба в java foundry? Или таки нет?

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

> С++ как раз и позиционируется как язык с мощьнейшим уровнем reuse кода. То есть, это выходит неправда?

Конечно же это неправда. Более того, это откровенная ложь. Уровень code reuse с С++ - не многим лучше, чем у ассемблера.

> или быстренько прогнать программу и библиотеки дебагером ну совсем не судьба?

Извращенец. Что и понятно - C++ - язычок для больных извращенцев.

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

> Немножко есть - но об этом умолчим ;)

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

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

> Убейся в стену. Google - это сайт? :)

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

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

Быдлушко, Гугль - пример "сайта" (это ТЫ о всех "сайтах" презрительно высказывался) со сложной логикой. Да, Жаба такое не потянет - и хрен с ней. Тебя, быдлёнка, волновало, что такой язык общего назначения используется для "всего лишь" сайтов - вот тебе хлебалом об стену и объяснили, как ты, быдлёнок, неправ.

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

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

> А заглянуть в объявления классов или быстренько прогнать программу и библиотеки дебагером ну совсем не судьба? :(

Прошу обратить внимание на "в разумное время". Когда объём .tar.gz с исходниками несколько [десятков] мегабайт а классов -- за несколько тысяч, и часть из них генерится из макросов с десятком аргументов, которые сами вызывают другие макросы, и в итоге оказывается, что за всем этим скрывается template от template'а (ну обчитался кто-то Александреску, а головой подумать забыл)...

Так что просто поверьте -- "быстренько пробежаться" и "отладчиком" -- это действительно не судьба.

Кавалерийский наскок "отладчиком" годиться только если количество классов не превышает десятки. В реальной же жизни это не работает. Причём именно тогда, когда это особенно нужно.

> Забегая вперед, если вы о закрытом коде,

код, допустим, есть.

> Если оно работает и есть не просит, то какое вам дело до того, перегружен ли тот или иной элемент или нет?

А если не работает? А если, временами, даже не компилиться? Ну не подумал человек, что "bcpp-5.1 for windows" -- это не совсем c++, а IBM Visual Age тоже с тараканами в голове, но своими. А про вылавливание гадостей, связанных с разницей в разрядности и порядком битов между Intel-x86 и PPC64?.. Пока найдёшь -- поймёшь, что всё, что не grep(1)-friendly в большие проекты допускаться не должно.

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

> Для этого даже книжки есть по ОО проектированнию и дизайну.

Вы много видели реальных проектов, где была действительно и до конца пройдена стадия OO-анализа (без каковой всё остальное, включая проектирование практически бесполезно (с OO точки зрения), как многоэтажный дом, построенный на грунте с _неизвестными_ характеристиками)?

>> Из-за невозможности повторного использования растёт общее время и трудозатраты.

> С++ как раз и позиционируется как язык с мощьнейшим уровнем reuse кода. То есть, это выходит неправда?

Да, это неправда. Неправда, причём _абсолютная_.

Он неплох для маленьких задач моделирования. Но для больших и/или не моделирования -- не подходит абсолютно.

Хотите пример? Попробуйте хоть в одной книге, посвящённой OO & C++ найти пример сложнее однокнопочной микроволновой печки. Сомневаюсь, что найдёте. Но количеству сил, потраченных на эту, в общем-то примитивную задачу, -- удивиться можно. И сразу же становится понятно, почему нет ничего сложнее. Просто сложность растёт, по моему субъективному впечатлению, даже не как куб, а скорее, как факториал. Все влияют почти на всех, и всё влияет почти на всё.

Какой же reuse кода может быть в этих условиях?

>> Вот и получаем, что более-менее спокойно можно использовать только код написанный людьми _очень_ высокой квалификации.

> Команды из сотен программистов разной квалификации спокойно работают над одним проектом и не знают, что такое оказывается невозможно. Нонсенс просто какой-то! :))))

Счастливый человек!

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

Это не значит, что они не смогут работать. Это значит, что затраты получаются больше, чем, например, в случае, если бы они использовали просто Си.

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

>> Вот и получаем, что более-менее спокойно можно использовать только код написанный людьми _очень_ высокой квалификации.

> А вы хотите спокойно использовать код, написанный кем?

Допустим, сотрудником моей же компании для _этого_ же проекта.

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

>Быдлушко, Гугль - пример "сайта" (это ТЫ о всех "сайтах" презрительно высказывался) со сложной логикой. Да, Жаба такое не потянет - и хрен с ней. Тебя, быдлёнка, волновало, что такой язык общего назначения используется для "всего лишь" сайтов - вот тебе хлебалом об стену и объяснили, как ты, быдлёнок, неправ.

ха-ха приехали я больше не буду спорить, бесполезно.

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

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

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

>Сами приложения памяти много не жрут. GHC такой прожорливый от шибко умных оптимизаций.

Если монады слабо использовать и про 32 битный char забыть, то конечно да, ну а если нет, то тогда совсем другое дело:

http://shootout.alioth.debian.org/benchmark.php?test=revcomp&lang=all&...

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

Уважаемый awn. Вы, конечно, не svu - но Вы настолько "по-моему" ответили на все вопросы, что я даже засомневался - не мой ли Вы виртуал;)

В принципе, мне даже добавить нечего. Разве что про reuse. Процесс разработки на С++ действительно требует монументального и детальнейшего анализа в начале проекта - т.е. реально пропагандирует "соборный" стиль разработки (что, в общем, не так страшно). Но штука в том, что плюсовый код, сделанный в рамках такого проекта - может оказаться, крайне тяжело реюзать в других проектах. Именно потому что соглашения и детали поведения явно (greppable) не выражены в коде (неявный вызов конструкторов-деструкторов, переопределение операторов и пр.) - как коде самих классов, так и в использующем их коде (который можно было бы использовать как examples).

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