Снова двойка

[cd_riper]

Автор крылатого выражения "виртуальное удаление подозрительно" выдал очередной эпический текст

Comments

[leonov]

Только в Factory::m_creators просится map/hash_map, а то цикл с поиском в Factore::Create вызывает чисто эстетическое неприятие.

[cd_riper]

спасибо, кэп, я в курсе, специально для тебя туда и вставил комментарий :)
просто у меня на std::map чаще всего взгляд как на оптимизацию, которая зачастую просто не нужна.

[waqur]

А оно чаще всего так и есть - из-за нелокальности доступа к памяти. Чтобы std::map был выгоднее вектора, в нём должны быть сотни, если не тысячи элементов.

[waqur]

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

Отсутствие кл.сл. explicit в декларации конструктора с одним параметром (в коде в статье на хабре) как нельзя лучше подтверждает эту точку зрения.

[cd_riper]

у меня в коде такая же болезнь. вообще explicit пишу очень редко.
плюс кое где потерял const, плюс кое-где потерял boost::noncopyable

[waqur]

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

[cd_riper]

> они могут составлять сколь угодно длинные цепочки

по стандарту -- можно сделать только одно такое преобразование за раз.

[waqur]

"виртуальное удаление подозрительно"

Это и правда нетривиальная вещь, ведь компилятор генерирует целых три деструктора - scalar deleting destructor, vector deleting destructor и обычный деструктор, и вызывает разные в зависимости от контекста.

Однако ж работает, зараза.

[anonymous]

Кстати, у товарища есть опенсорсные проекты. Код так себе, с пивом потянет, но встречаются такие перлы (отсюда):

Copy Source | Copy HTML

1. char * e(high_scores_label);
2.   for (; *e; ++e);
3.   --e;
4.   char * ee(e - 1);
5.   for (int g(0); g<5; ++g) {

[cd_riper]

жесть!

но это он могет молодой писал, пока не был еще великим учителем и гуру.

на меня самого компромата насобирать можно -- будь здоров. как садишься суппортить свой код N летней давности (особенно, не дай б-г на Delphi!) сам себя громко ненавидишь :)

[kisa_i_osya]

Вау! Гений, чо. (Истрически хихикает, представляя... Не, _такой_ геморрой даже вообразить сложно).

[ext_290530]

да. Однако специализации ICodeGenerator в вашем случае - синглтоны. Зачем их создавать по запросу. Проще в конструкторе конкретного генератора регистрироваться в каком-то одном, хорошо известном, менеджере.
И enum нафиг нужен, лучше, когда ключем является имя языка.

[cd_riper]

> Однако специализации ICodeGenerator в вашем случае - синглтоны

из задачи не понятно, имеет ли реализация этого класса состояние или нет.

> И enum нафиг нужен

я писал о том, что ключ можно использовать любого типа.

[ext_290530]

> из задачи не понятно, имеет ли реализация этого класса состояние или нет.

Тут

class CodeGenerator
{
public:
enum Lang {JAVA, C_PLUS_PLUS, PHP};
CodeGenerator(Lang language) { _language=language; }
std::string generateCode()
{
switch(_language) {
case JAVA: //return generated java code
case C_PLUS_PLUS: //return generated C++ code
case PHP: //return generated PHP code
}
throw new std::logic_error("Bad language");
}
std::string someCodeRelatedThing() // used in generateCode()
{
switch(_language) {
case JAVA: //return generated java-related stuff
case C_PLUS_PLUS: //return generated C++-related stuff
case PHP: //return generated PHP-related stuff
}
throw new std::logic_error("Bad language");
}

private:
Lang _language;
}

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