[C++] Насоветуйте проектов с качественным кодом.

И превратится это потом в огород ифов, если кнопочек много

не превратится. с какой радости?

man виртуальные функции, которые в реальности делают именно то, что ты описал

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

зачем с умным видом говорить о том, в чём ни хрена не разбираешься?

можно один раз написать макрос и упростить запись

можно. а ещё можно воспользоваться препроцессором, реализующим более высокоуровневый язык поверх C++ (вроде Felix или Prop). или подключить boost и пользовать плюшки вроде lambda, bind, prot. всё это можно. однако убогости стандартной библиотеки это не отменяет

> или подключить boost и пользовать плюшки вроде lambda

опять же уже в gcc + msvc реализована «нативная» поддержка

однако убогости стандартной библиотеки это не отменяет

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

благодаря тому, что c++ таки развивается

слишком медленно. даже с учётом многочисленных изменений в C++0x

думаю, что компиляторы вроде JHC и библиотеки вроде Reactive, Fudgets, Tk быстрей станут стабильными (и перестанут быть похожимы на Motiff), чем C++ станет по-настоящему высокоуровневым языком

too much legacy

есть широкий набор библиотек, которые позволяют частично нивелировать этот недостаток

и хороших программистов, которые их пишут. это да, это есть

> можно воспользоваться препроцессором, реализующим более высокоуровневый язык поверх C++ (вроде Felix или Prop)

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

Блин, неужели этим кто-то пользуется на практике?

на практике они (препроцессоры) пишутся под задачу. в случае проекта с временем жизни ~10 лет это вполне себя оправдывает

> слишком медленно

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

ну, jedem das seine :)

>хороший код

C++

Division by zero.

Смешнее было бы только если бы ты попросил примеры хорошего кода на code.google.com

>ни кортежей

ну std::pair есть. Отсутствие tuple в том виде, в котом это реализовано, скажем, в бусте — это только плюс: у клинических идиотов не будет возможности наговнокодить на ровном месте.

ни хэш-контейнеров

hashmap, hashset, hashtable. Правда это все либо не стандартное, либо из tr1, но оно есть в gcc-шной реализации STL.

ни деревьев

См. выше (rb_tree). Некие рассуждения на тему, почему в STL нет деревьев, можно найти в гугле.

интерфейс с файловой системой отсутствует

И слава богу, что он минимален. В последние годы понапихали в бусты всякого говна, так теперь на плюсовые поделки без слез не взглянуть: абстракции и прочая дрянь, порождающие тормоза и тут и там. Просто ужасно. Чего только люди не придумают, только бы не читать маны по stat и прочему.

стандартные алгоритмы расчитаны на ФП-стиль

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

то, что в нормальном языке будет выглядеть как

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

>man Objective-C, C--
Это уже не чистый С.

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

Отвечал выше. Для того, чтобы не плодить свои костыли для решения порой тривиальных решений.

Правда это все либо не стандартное, либо из tr1

а обсуждаем мы стандартную библиотеку текущего стандарта. выйдет следующая - обсудим её

Некие рассуждения на тему, почему в STL нет деревьев, можно найти в гугле

в гугле можно вообще очень много всякого найти

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

зачем? без функций как first-class value такой подход в любом случае будет уродливым

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

а это вообще к чему? и о чём?

Это уже не чистый С.

ага, ага. Qt отличается от С++ существенней, чем они от C

Для того, чтобы не плодить свои костыли для решения порой тривиальных решений.

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

Вижу проектов на плюсах не особо много :)

>ага, ага. Qt отличается от С++ существенней, чем они от C

Qt я привёл как пример успешного использования ООП.

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

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

>Java: Тормозной ынтырпрайз (из-за сборшика дерьма)

C#: недопиленный тормознутый полупроприетарный ынтырпрайз со сборщиком >мусора.

Умник, ты хоть раз что-нибудь более-менее серьезное писал на Java или C# ? Или просто модных слов и баянных тем про сборщик мусора начитался ?

> Вижу проектов на плюсах не особо много :)

очень толсто

Qt я привёл как пример успешного использования ООП.

и что? ООП в Objective-C не хуже, зато бинарно совместим с C

Конечно, куда лучше переписывать костыли каждому по новому в своём проекте

в нормальных языках эти костыли просто не нужны. вообще, представляешь? «переписывать по новому в каждом проекте» - это как раз характерная черта программирования на C++

>Умник, ты хоть раз что-нибудь более-менее серьезное писал на Java или C# ? Или просто модных слов и баянных тем про сборщик мусора начитался ?


Я сам ничего не имею против них, и мне даже симпатизирует некоторый софт на Java (netbeans). Но по моим личным наблюдениям, как и многим отзывам ява не готова для конечного пользователя, она главным образом для ынтырпрайза, веба, мобильных приложений. Если вы не тролль и станете утверждать обратное - приведите примеры пяти-десяти более-менее серьёзных программ, круг которых шире быдлофофисов и всяких Tommy-like машин.

> «переписывать по новому в каждом проекте» - это как раз характерная черта программирования на C++

можно узнать, что лично вы переписывали «по новому в каждом проекте» на С++?

> Но по моим личным наблюдениям, как и многим отзывам ява не готова для конечного пользователя

т.е. для написания IDE готова, а для прочей гуйни - нет? ню-ню

>в нормальных языках эти костыли просто не нужны. вообще, представляешь? «переписывать по новому в каждом проекте» - это как раз характерная черта программирования на C++


Каких-таких сферических нормальных языках в вакууме?

можно узнать, что лично вы переписывали «по новому в каждом проекте» на С++?

нельзя

> нельзя

а примеры с другими людьми? а то такие голословные фразы как «характерная черта» - надо бы хоть чем-то подтверждать

>т.е. для написания IDE готова, а для прочей гуйни - нет? ню-ню


IDE это сугубо профессиональный инструмент. Плюс он занимает много памяти. Однако разработчику это легче ему простить чем, скажем простому юзеру жуткие тормоза какого-нибудь графического редактора или ещё какой гуйни\сложной проги.

>нельзя

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

Каких-таких сферических нормальных языках в вакууме?

в языках с поддержкой функций высших порядков, алгебраических типов данных, замыканий, продолжений: многочисленные Lisp'ы, всё семейство ML, Haskell; в той или иной мере все динамические языки - Python, Ruby, REBOL

значительно меньше проблем с языками с полноценным ООП: Objective-C, Smalltalk, Eiffel. выбирать есть из чего

а примеры с другими людьми?

если бы хоть одна задача из решаемых паттернами GoF, решалась бы нативными средствами C++ из коробки, необходимости в этой книге не было бы. есть возражения?

>многочисленные Lisp'ы, всё семейство ML, Haskell;

Эти языки почти не используются в широких сферах. Я конечно с ними мало знаком, но там широкое применение математики, если я прав. А в чём выигрыш перед плюсами, где всё то же самое делается гораздо легче и без супер-пупер математических знаний? Не надо про быдлокодеров: на С++ написано очень много хорошего.

значительно меньше проблем с языками с полноценным ООП: Objective-C, Smalltalk, Eiffel. выбирать есть из чего

Чем с ними легче, и чем ООП из С++ не полноценный?

Хватит тебя уже кормить, а то растолстеешь

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

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

а это вообще к чему? (с)

А в чём выигрыш перед плюсами, где всё то же самое делается гораздо легче

тем, что в плюсах «всё то же самое» делается гораздо сложней

супер-пупер математических знаний

это, например, каких?

чем ООП из С++ не полноценный?

http://letoverlambda.com/back-cover.png

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


Даже в Qt есть документация. Хотя там почти всё очевидно.
// К сожалению более внятных и точных аргументов тут дать не могу, ибо обсуждаемую книгу прочесть пока не могу.

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

Лисперы только болтать умеют, а на практике от них толку чуть больше нуля. Если вы такие умные - почему ваш софт не используется так широко, как на С\С++? Даже если отбросить плохие проекты на языках семейства С, то лисп займёт ничтожно малую долю. Так что подходите к вопросу с нужной стороны.

а это вообще к чему?

какое слово тебе не понятно? :)

Лисперы только болтать умеют

в этом треде очень не хватает Love5an'а :)

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

> какое слово тебе не понятно? :)

мне непонятно как «задачи из решаемых паттернами GoF» могут вынуждать все «переписывать по новому в каждом проекте»

>тем, что в плюсах «всё то же самое» делается гораздо сложней

Где сложнее? Я вам наоборот говорю о том, что там всё куда проще. Как пример я уже приводил классы с инкапсуляцией (кто считает что она не нужна могу поведать о сём таинстве на примере).

http://letoverlambda.com/back-cover.png

Вам показать ту картинку с таблицей?

супер-пупер математических знаний

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

Или нарисовать кучу диалогов, в которых добавлено\удалено\изменено нужное кол-во виджетов на нужные (с ограничением, предусмотренным внутри класса которое можно изменить при желании отделным методом.



Ну вот С выполнит задачу с лёгкостью, с использованием наследования и классов с объектами.


Беседа окончена, я пойду дописывать плагин и спать. Желаю переварить и не лопнуть от толщины.

s\Ну вот С выполнит задачу с лёгкостью\Ну вот С++ выполнит задачу с лёгкостью

мне непонятно как «задачи из решаемых паттернами GoF» могут вынуждать все «переписывать по новому в каждом проекте»

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

однако в самом языке средств для выражения этих идиом нет. каждый раз, испытывая необходимость в паттерн-матчинге, надо реализовывать паттерн visitor. для sum-типов - паттерн composite. вместо функций высших порядков - паттерн strategy. для решения проблемы отрицательной изменчивости при наследовании - паттерн bridge. для реализации виртуального конструктора - паттерн abstract factory. для реализации eval - паттерн interpreter

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

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

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

Где сложнее?

в C++

Вам показать ту картинку с таблицей?

что за картинка? покажи, я картинки люблю

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

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

>>Удобно для работы с GUI

ни разу. GUI - это декларативное описание разметки плюс реактивная система событий/поведений. ни для первого, ни для второго ООП не удобен

какой мягкий tcl/tk наброс ;]

какой мягкий tcl/tk наброс ;]

не совсем. в такой формулировке - нет, потому что Tk всё-таки event-driven, а не reactive

хотя вообще да, конечно же :)

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

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

ты правда считаешь, что ответил на мой вопрос?

да

как по мне ты либо троллишь

а можно по существу?

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

эээ.. не готова для конечного пользователя? ты же сам написал про мобильные приложения. Или там пользователь не достаточно конечен?

круг которых шире быдлофофисов

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

Нека, ты, кстати, что меня в жабрах удалил?

> event-driven, а не reactive

А в чем разница?

>не готова для конечного пользователя? ты же сам написал про мобильные приложения. Или там пользователь не достаточно конечен?


Разумеется, в плане PC.