LINUX.ORG.RU
ФорумTalks

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

 


1

0

День добрый.
Посоветуйте каких-то проектов в качестве хорошего кода на C++, а то я что не ткну все на С. Хочется в них найти ответы на вопросы в духе «так правильно обрабатывать ошибки используя исключения», «так правильно вести логи», и т. д.
Желательно проекты без гуя, не большие по размеру.

Пока смотрю newsbeuter, ncmpcpp. Что еще есть?

★★★★★

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

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

Кому разумеется? Все телепаты, извини, в отпуске. Хорошо, PC, так PC.

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

Нека, ты, может быть, имел ввиду Desktop?

Кстати, а с какими реальными тормозами жабы столкнулся лично ты? То есть не прочитанное где-то в language-comparsions, а самостоятельно полученное?

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

>Нека, ты, может быть, имел ввиду Desktop?

Причем тут нека? Из джаббера вас тоже не удалял, и не помню там.


Кстати, а с какими реальными тормозами жабы столкнулся лично ты? То есть не прочитанное где-то в language-comparsions, а самостоятельно полученное?



Автодополнение в NetBeans, Eclipse. В Eclipse вообще тормозит графика.

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

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

event-driven programming or event-based programming is a programming paradigm in which the flow of the program is determined by events—i.e., sensor outputs or user actions (mouse clicks, key presses) or messages from other programs or threads

Reactive programming is a programming paradigm oriented around data flows and the propagation of change. This means that it should be possible to express static or dynamic data flows with ease in the programming languages used, and that the underlying execution model will automatically propagate changes through the data flow

грубо говоря, event-driven программирование - более низкоуровневое: нет модели синхронизации, нет моделей распространения изменений, нет поддержки непрерывных поведений

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

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

Надеюсь, про desktop ты понял) В жабрах юзер vannadis.

Автодополнение в NetBeans, Eclipse. В Eclipse вообще тормозит графика.

gcj или openJDK используешь? http://www.linux.org.ru/view-message.jsp?msgid=2839175 посмотри, например, тут. Да и вообще на эту тему было ооочень много топиков на ЛОРе.

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

>Надеюсь, про desktop ты понял)

Не понятно к чему про него.


gcj или openJDK используешь?



А хрен его знает, стоят оба. Но нетбинсом ещё более-менее удобно пользоваться.

А из джаббера не удалял. Добавьтесь на flareguner at gmail.com, я туда переехал.

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

> gcj или openJDK используешь?

на сановской JDK тормозят на четырехядернике + 4Гб ОЗУ - NetBeans, Eclipse, SmartSVN, iReport и т.д. ( даже примитивная нокиевская тулза для конвертирования видео - и то тормозит в плане отрисовки ), может джава сама по себе и не медленная, но гуй на ней в большинстве случаев тормозит - может это связано больше с руками авторов, но тем не менее

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

>>Не понятно к чему про него.

Жаль, что кэп тоже в отпуске.

А хрен его знает, стоят оба. Но нетбинсом ещё более-менее удобно пользоваться.

Тебе привели ссылку на то, что с gcj приложения тормозят. Я это, кстати, и от себя могу подтвердить. Действительно тормозят и очень сильно. Потому надо использовать сановский openJDK. Неужели без кэпа трудно пойти и проверить, что подцепляется у конкретно тебя, и изменить на нужное, если требуется? и уже после этого писать - да, всё опять тормозит(или не тормозит, что вероятнее).

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

>>на сановской JDK тормозят на четырехядернике + 4Гб ОЗУ - NetBeans, Eclipse, SmartSVN, iReport и т.д.

У меня NetBeans и Eclipse как раз перестали тормозить после замены gcj. одно ядро, 2Гб памяти.

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

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

>Тебе привели ссылку на то, что с gcj приложения тормозят.

Да у меня ЕМНИП юзается JDK, страшных прямо тормозов нет. Только эклипс.

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

>>Да у меня ЕМНИП юзается JDK,

Прям-таки JDK? Или всё же OpenJDK?

ЕМНИП

А проверить?

страшных прямо тормозов нет.

То есть мы уже приходим к выводу, что она не так уж и тормозит, как было сказано тобой выше?

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

>Или всё же OpenJDK?

OpenJDK.

А проверить?


лень, пока что на Qt пишу)

То есть мы уже приходим к выводу, что она не так уж и тормозит, как было сказано тобой выше?



Netbeans почти не тормозит, кроме комплита. А Эклипс тот ещё тормоз.


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

в этом треде, не хватает Луговского :)

да, в этом треде явный недостаток святости

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

>>Netbeans почти не тормозит, кроме комплита. А Эклипс тот ещё тормоз.

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

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

Я нигде язык не обвинял. Просто он мало подходит для написания десктопного софта, иначе его бы активнее использовали.


Память не изменила.

[code]
Product Version: NetBeans IDE 6.8 (Build 200912041610)
Java: 1.6.0_0; OpenJDK Client VM 16.0-b10
System: Linux version 2.6.30-2-686 running on i386; UTF-8; ru_RU (nb)
Userdir: /home/georg/.netbeans/6.8
[/code]

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

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

Что же первые гуи на Смолтоке писались-то? Кэй наверно не в курсе =) Хотя да, там немного другое, правильное ООП

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

>А у Си-шников каша головного мозг.

Мусье в курсе, что на Си объектную модель можно налабать похлеще, чем в плюсах? :)

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

Как сделать наследование на чистом С?

#define BASE_CLASS \
  int a; \
  int b; \
  int c

struct BaseClass {
  BASE_CLASS;
};

#define DERIVED_CLASS \
  BASE_CLASS; \
  int d

struct DerivedClass {
  DERIVED_CLASS;
};

И это только один из вариантов

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

Мда :))) А где модификаторы доступа, конструкторы/деструкторы, методы и прочее ? А вообще молодец, повеселил. Эдак и на ассемблере можно ООП нацарапать.

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

Ну видел я это чудо раньше. Только вот разве весело заниматься онанизмом вприсядку ? :) Насчет «А _зачем_ они нужны ?» - это сразу говорит о многом. ООП на С - вот что не нужно нормальному человеку, только отдельным упоротым этого не понять. Кому надо ООП - тот берет соответствующий инструмент (язык). Специально для вас сразу уточню - С++ вовсе не тот инструмент, который я понимаю под образцом ООП :). Что, впрочем, не умаляет другие его достоинства.

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

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

Насчет «А _зачем_ они нужны ?» - это сразу говорит о многом

О чём же? Я за ночь сломал свой либастрал

Кому надо ООП - тот берет соответствующий инструмент (язык)

Ну это очевидно

С++ вовсе не тот инструмент, который я понимаю под образцом ООП :)

Слава Богу

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

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

я клоню к тому, что несмотря на то, что такое вот «наследование» сделать можно (но это такой костыль, каких еще поискать), до нормально ООП там как до Луны ползком. Что касается «_нИнужных_» модификаторов - наличие как минимум private/public - нормальным людям будет полезно.

+ приведенный как пример костыль очень хорошо показывает, как «удобно» будет реализовано всё остальное :) Лично мне такое «ООП» напоминает написание ОС на ассемблере (всякие там Колибри и пр.) - дрочат люди - ну и пусть себе. Только агитировать за подобное не надо :))

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

>наличие как минимум private/public - нормальным людям будет полезно

Нормальные люди не полезут своими корявыми ручонками к тем полям структур, у которых написано /* do not touch it, it's private! */. Иными умельцами тот же private/public в С++ обходится в одну строчку кода.

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

> Нормальные люди не полезут своими корявыми ручонками к тем полям структур, у которых написано /* do not touch it, it's private! */.

вы это серьезно?

Иными умельцами тот же private/public в С++ обходится в одну строчку кода.


давайте пример

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

>> Иными умельцами тот же private/public в С++ обходится в одну строчку кода.

давайте пример

наверное, имеется в виду #define private public

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

> наверное, имеется в виду #define private public

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

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

>вы это серьезно?

Когда речь идёт о С - да. На С++, естественно, _надо_ использовать эти модификаторы доступа

давайте пример

tailgunner уже дал :)

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

Что же первые гуи на Смолтоке писались-то?

а почему бы и нет? GUI и на прологе пишут, было бы желание

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

> можно. получается лучше, чем в C++ :)

не буду оригинальным - где можно посмотреть на лучшую реализацию на ассемблере?

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

наличие как минимум private/public - нормальным людям будет полезно

а можно развернуть мысль? чем оно будет так полезно нормальным людям?

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

не буду оригинальным - где можно посмотреть на лучшую реализацию на ассемблере?

в этих ваших интернетах нынче хрен что найдёшь :(

http://thesz.livejournal.com/772934.html

вот здесь есть три упоминания про ОО-ассемблеры, один из них (Зефировский) в сети точно светился, но сходу найти не получается. вечером ещё поищу

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

Не нужно писать /* do not touch it, it's private! */

да нет, меня интересует - когда это действительно нужно? собственно, если явно указать интерфейс (комментарием, документацией) - кто будет осознанно его нарушать?

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

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

И компилятор это проверит.

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

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

> вот здесь есть три упоминания про ОО-ассемблеры

По-моему, thesz шутил :) Хотя ОО-ассемблеры были, но с Си++ их сравнивать просто глупо.

tailgunner ★★★★★
()

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

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

> вот здесь есть три упоминания про ОО-ассемблеры

если бы тебе дали вместо прямой ссылки на документацию или исходники «три упоминания» из гугля, ты бы как отреагировал?

вечером ещё поищу


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

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

По-моему, thesz шутил :)

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

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

> собственно, если явно указать интерфейс (комментарием, документацией) - кто будет осознанно его нарушать?

Гыгыгы.

Извините, не удержался. Ты правда думаешь, что люди осознанно совершают такие «нарушения»? Ты еще спроси, кто осознанно будет нарушать типизацию.

в случае C++ это упрощается рекомендуемой идиомой pImpl

pimpl сделан для сокращения времен компиляции. И pimpl-объект нельзя разместить на стеке, например.

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

если бы тебе дали вместо прямой ссылки на документацию или исходники «три упоминания» из гугля, ты бы как отреагировал?

спокойно :) лучше это, чем ничего, n'est-ce pas?

была сказана без всяких на то оснований

ну вот ещё. я редко говорю безосновательно, врождённая вежливость не позволяет

обосрать С++ - это так круто ;)

круто и некруто - это уровень детского сада. хочешь хаскель покритикую? или Tcl?

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

> спокойно :) лучше это, чем ничего, n'est-ce pas?

в данном случае - лучше ничего

я редко говорю безосновательно


справка от психиатра и ЛОРа где? ;)

круто и некруто - это уровень детского сада. хочешь хаскель покритикую? или Tcl?


давай

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

Ты правда думаешь, что люди осознанно совершают такие «нарушения»?

такие - да. это чем-то похоже на работу с объектами по офсетам

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

>Хотя ОО-ассемблеры были,

Тот же TASM с незапамятных времен имел поддержку.
По большому счету, все что для этого нужно(синтаксически) - возможность «наследования» структур, остальное дополняется макросами(а препроцессор С нервно курил по сравнению макроассемблерами)

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