Icecream 1.0.0

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

То есть сказать какие проблемы это вызовет ты не можешь.

А для чего они так сделали - тебя не интересует. Ради любопытства поинтересуйся что советует по этому поводу google разработчикам под android. Уверен, что после этого тебя неподецки расколбасит.

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

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

То есть сказать какие проблемы это вызовет ты не можешь.

Ну скажу я вам слово «инкапсуляция», но для вас это - пустой звук.

А для чего они так сделали - тебя не интересует.

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

Код только выглядит как объектно-ориентированный, но на самом деле это обычный C с синтаксическим сахаром предоставляемым плюсами. Сопровождать такое можно лишь постепенно переписывая проект либо на плюсы либо на чистый C, что кому ближе.

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

То есть сказать какие проблемы это вызовет ты не можешь.

Ну скажу я вам слово «инкапсуляция», но для вас это - пустой звук.

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

В телепаты метишь?

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

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

Что конкретно у вас не получается? Возможно ваша задача не укладывается в объектно-ориентированную парадигму и вам нужно попробовать другой подход? ООП - не единственная парадигма программирования.

Что конкретно у вас не получается? Возможно ваша задача не укладывается в объектно-ориентированную парадигму и вам нужно попробовать другой подход? ООП - не единственная парадигма программирования.

У меня все получается. А уж как у google получается, можно только обзавидоваться. Но в своих советах разработчикам под android она, например, советует не использовать методы, а работать с полями напрямую, если возможно. Ибо упирается в производительность. В плюсах «flto» пока то же до ума не довели.

С юниттесты я уже говорил. Большинство тестов возможны через дефайн private и protected в public. Но это криво и не всегда спасает.

Ну вот как вас понять, с одной стороны:

У меня все получается.

Хотя до этого вы же писали:

упираешься рогом в производительность или необходимость модульного тестирования.

Видимо для вас «упереться рогом» это критерий успеха либо у меня шизофрения.

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

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

Видимо для вас «упереться рогом» это критерий успеха либо у меня шизофрения.

Ну словоблуд же вы. Но это на вашей совести.

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

Забавный вы. Вы в курсе что LTO пока не доведена до ума в gcc? Тут уже должен работать оптимизированный линковщик, но его пока нет. Когда-нибудь будет. Сейчас - нет. А живем мы не когда-нибудь а сейчас.

Изучите возможность использования статических объектов в своем проекте а лучше поучите ООП или вообще откажитесь от его использования.

Телепат? Нет. Хреновый из вас телепат. Работа десятков тысяч мелких объектов как раз и упирается в такие вызовы методов. Ну и в конструкторы и деструкторы. Но это тоже легко оптимизируется. :)

Ну что, на C++ свет клином сошелся и других языков нет? Вы его пытаетесь использовать не по назначению, судя по вашим бедам.

Беды у вас. У меня все работает. Для моих целей мог подойти только Си, но это усложнило бы другие части программы.

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

Работа десятков тысяч мелких объектов...

Это особенность разработанной вами архитектуры, видимо неудачно разработанной раз результат не устраивает.

Вы даже не узнали зачем так сделали разработчики упомянутые в теме.

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

Вы никак понять не можете что инструментом надо вначале научиться пользоваться а уж потом разглагольствовать о его недостатках.

Мне эта поделка напомнила один кошмар написанный на С программистом до этого яростно использовавшим ассемблер. Код из С операторов в столбик, разделенный тут и там аккуратными метками. Иногда попадаются for, while, но очень редко, в основном все сделано через if goto. С виду вроде С, но на самом деле asm. У вас тоже самое.

Это особенность разработанной вами архитектуры, видимо неудачно разработанной раз результат не устраивает.

Забавно. То есть вы принципиально не допускаете возвожность существования задач в которой необходимы десятки тысяч объектов?

И в очередной раз придумываете про «не устраивает».

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

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

ООП - у вас это фетишь. И по этому видно, что вы теоретик.

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

Я решал задачи молекулярной механики там многие десятки тысяч объектов, но в отличие от вас, эти куски писались на чистом C, иногда даже ассемблере и никакого соплежуйства с public данными не было. Если понять для чего нужен и должен использоваться ООП и не пихать его куда не надо, то никаких проблем с его использованием не будет.

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

у меня, конечно, арч а не генту, но пересборка моего репозитория может занимать бешеное количество часов. Настолько бешеное, но я даже и не пробовал ни разу этого делать - если что-то пересобрано на archlinux.fr - юзаю это. Подозреваю, весь арч за сутки не пересобрать даже на самом топовом убер-железе, если там будет использоваться всего одна машина.

И часто ты собираешь весь репозиторий?

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

если вы не просто писали нечто где «десятки тысяч объектов», а еще и оптимизировали написанное, то, должно быть, знаете, что за лишние 50% производительности можно и старушку-процентщицу топором зарубить, не то что какое-то лишнее сраное поле пабликом сделать

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

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

Откуда ж у тебя сколько говна в голове?

шел бы ты отсюда, петушок

GCC 4.8 Release Series

GCC now uses C++ as its implementation language. This means that to build GCC from sources, you will need a C++ compiler that understands C++ 2003. For more details on the rationale and specific changes, please refer to the C++ conversion page.

Одна из причин миграции была как раз скорость компиляции С++-компилятором

(К сожалению, я сейчас не могу уже откопать тот тред, когда кому-то в первый раз удалось поменять конпелятор, там были детальные сравнения скорости конпеляции в разных ситуациях, и С++ выигрывал во всех)

UPD: официальная причина миграции - понятность и управляемость кода: http://gcc.gnu.org/wiki/cxx-conversion

вот тут слайды с доводами: http://airs.com/ian/cxx-slides.pdf

Религиозный бред не обсуждаю, я инженер а не саентолог.

Религиозный бред не обсуждаю, я инженер а не саентолог.

Судя по тому, что вы считаете парадигмы ООП догмой, то вы ближе саентологам, чем думаете.