Здравствуйте, Олег К., Вы писали:
ОК>operator T () const объявлен но не определен (может определили за пределами структуры но меня ломает лезть в статью).
Пропускают определение целенаправленно, так что тут всё корректно.
ОК>Компилятор видимо пропустил.
Правильно сделал. Никогда не сталкивался с конструкцией вида:
? В С++ достаточно много приёмов завязанных только на объявление, допустим идентификация типа по результату вызова фиктивной функции.
ОК>Я бы написал operator T () const { return T(); } но это все мелочи.
Сделал бы лишнюю работу.
ОК>У меня вообще посыл был в том что это все ненужные навороты.
Когда всякие автогенераторы пишешь, парсеры, библиотеки и т.п. подобные вещи необходимы и сильно уменьшают время разработки.
ОК>>operator T () const объявлен но не определен (может определили за пределами структуры но меня ломает лезть в статью). N>Пропускают определение целенаправленно, так что тут всё корректно.
Не думаю.
ОК>>Компилятор видимо пропустил. N>Правильно сделал. Никогда не сталкивался с конструкцией вида: N>
Ты путаешь немного, имхо. Страуструп когда объясняет такие конструкции все равно пишет пустые тела или какой-нибудь минимальный return а не просто объявления (как ты тут написал).
N>В С++ достаточно много приёмов завязанных только на объявление, допустим идентификация типа по результату вызова фиктивной функции.
ОК>>Я бы написал operator T () const { return T(); } но это все мелочи. N>Сделал бы лишнюю работу.
Не думаю и не повредило бы.
ОК>>У меня вообще посыл был в том что это все ненужные навороты. N>Когда всякие автогенераторы пишешь, парсеры, библиотеки и т.п. подобные вещи необходимы и сильно уменьшают время разработки.
-1. Ненужный код и ненужная дополнительная complexity.
Здравствуйте, Олег К., Вы писали:
ОК>>>operator T () const объявлен но не определен (может определили за пределами структуры но меня ломает лезть в статью). N>>Пропускают определение целенаправленно, так что тут всё корректно. ОК>Не думаю.
Это не вопрос для размышлений, это приём такой, старый и действенный.
ОК>>>Компилятор видимо пропустил. N>>Правильно сделал. Никогда не сталкивался с конструкцией вида: N>>
N>>?
ОК>Ты путаешь немного, имхо. Страуструп когда объясняет такие конструкции все равно пишет пустые тела или какой-нибудь минимальный return а не просто объявления (как ты тут написал).
Не путаю, тут тот же случай. Реализация просто не нужна, поэтому во избежание ошибок и недоразумений её лучше не писать.
ОК>>>Я бы написал operator T () const { return T(); } но это все мелочи. N>>Сделал бы лишнюю работу. ОК>Не думаю и не повредило бы.
Повредила бы. Лишний код, простор для ошибок.
ОК>>>У меня вообще посыл был в том что это все ненужные навороты. N>>Когда всякие автогенераторы пишешь, парсеры, библиотеки и т.п. подобные вещи необходимы и сильно уменьшают время разработки. ОК>-1. Ненужный код и
Ты только что рассказывал как ты лишний код пишешь
ОК>ненужная дополнительная complexity.
При профессиональном подходе — наоборот. Введение локальной сложности сильно упрощает систему в целом. Многократно проверено.
Признаюсь, это я напутал. Пошел к Страуструпу сейчас на страничку. Он в самом деле просто объявляет а не определяет приватные функции. Надо будет посмотреть еще в книге.
How do we avoid this? The simplest solution is to prevent copying by making the operations that copy private:
class Handle {
private:
string name;
X* p;
Handle(const Handle&); // prevent copying
Handle& operator=(const Handle&);
public:
Handle(string n)
:name(n), p(0) { /* acquire the X called "name" and let p point to it */ }
~Handle() { delete p; /* release X called "name" */ }
// ...
};
void f(const string& hh)
{
Handle h1(hh);
Handle h2 = h1; // error (reported by compiler)
// ...
}
Здесь.
ОК>>>>operator T () const объявлен но не определен (может определили за пределами структуры но меня ломает лезть в статью). N>>>Пропускают определение целенаправленно, так что тут всё корректно. ОК>>Не думаю. N>Это не вопрос для размышлений, это приём такой, старый и действенный.
Нелогичность тут, однако. Как поступит компилятор с просто объявленными (но неопределенными) public и protected функциями которые нигде не вызываются?
ОК>>>>Компилятор видимо пропустил. N>>>Правильно сделал. Никогда не сталкивался с конструкцией вида: N>>>
N>>>?
ОК>>Ты путаешь немного, имхо. Страуструп когда объясняет такие конструкции все равно пишет пустые тела или какой-нибудь минимальный return а не просто объявления (как ты тут написал). N>Не путаю, тут тот же случай. Реализация просто не нужна, поэтому во избежание ошибок и недоразумений её лучше не писать.
ОК>>>>Я бы написал operator T () const { return T(); } но это все мелочи. N>>>Сделал бы лишнюю работу. ОК>>Не думаю и не повредило бы. N>Повредила бы. Лишний код, простор для ошибок.
ОК>>>>У меня вообще посыл был в том что это все ненужные навороты. N>>>Когда всякие автогенераторы пишешь, парсеры, библиотеки и т.п. подобные вещи необходимы и сильно уменьшают время разработки. ОК>>-1. Ненужный код и N>Ты только что рассказывал как ты лишний код пишешь
Вообще-то, повторюсь, я бы такие навороты не стал писать в первую очередь.
ОК>>ненужная дополнительная complexity. N>При профессиональном подходе — наоборот. Введение локальной сложности сильно упрощает систему в целом. Многократно проверено.
Ты, видимо, мало поддерживал кода написанного другими с таким же мнением как и у тебя.
Здравствуйте, Олег К., Вы писали:
N>>Это не вопрос для размышлений, это приём такой, старый и действенный.
ОК>Нелогичность тут, однако. Как поступит компилятор с просто объявленными (но неопределенными) public и protected функциями которые нигде не вызываются?
Скомпилирует, при возможности. А затем линкер сообщит о проблеме. Во избежание компиляции их делают private. Двойная защита.
N>>Ты только что рассказывал как ты лишний код пишешь ОК>Вообще-то, повторюсь, я бы такие навороты не стал писать в первую очередь.
Значит ты используешь более бедные средства и твой код может быть небезопасен, менее расширяем и реиспользуем.
Во всём нужна мера, но это не значит, что имеет смысл игнорировать языковые конструкции там где они будут полезны.
ОК>>>ненужная дополнительная complexity. N>>При профессиональном подходе — наоборот. Введение локальной сложности сильно упрощает систему в целом. Многократно проверено.
ОК>Ты, видимо, мало поддерживал кода написанного другими с таким же мнением как и у тебя.
Не в обиду: учитывая, что ты показал недопонимание базовых конструкций? Не удивительно.
Я много всякого кода поддерживал, в том числе занимался портированием STL и модифицировал boost. Бедный на язык код, как правило поддерживается много хуже (с С++ у меня хорошо). Сейчас вот как раз с подобным маюсь.
При решении задачи — первым делом нужно подготовить псевдоязык/библиотеку, как набор терминов этой задачи. Вот люди у которых проблема с языковыми конструкциями не умеют и библиотеки делать, отсюда решение задачи осуществляется неподходящими методами и поддержка сильно осложняется.
N>>>Это не вопрос для размышлений, это приём такой, старый и действенный.
ОК>>Нелогичность тут, однако. Как поступит компилятор с просто объявленными (но неопределенными) public и protected функциями которые нигде не вызываются? N>Скомпилирует, при возможности. А затем линкер сообщит о проблеме. Во избежание компиляции их делают private. Двойная защита.
На счет прайвит понять можно но вот компилировать код в котором объявлены но не определены public и protected функции это уже непростительно.
N>>>Ты только что рассказывал как ты лишний код пишешь ОК>>Вообще-то, повторюсь, я бы такие навороты не стал писать в первую очередь. N>Значит ты используешь более бедные средства и твой код может быть небезопасен, менее расширяем и реиспользуем.
Проблемы нужно решать по мере их поступления а не пытаться решить все возможные проблемы в будущем. Это про небезопасность и, как правило, ничего небезопасного в будущем не случалось.
N>Во всём нужна мера, но это не значит, что имеет смысл игнорировать языковые конструкции там где они будут полезны.
Я считаю что процентов 20 — 30 языка достаточно чтобы писать нормальный и простой код. Я концентрируюсь на бизнес задачах а не на технологиях ради технологий. Ну и разумеется стараюсь чтобы код был debuggable and maintainable.
Здесь же я вижу технологии ради технологий которые потом расползутся по куче проектов и которые не добавляют никакой ценности бизнесу.
ОК>>>>ненужная дополнительная complexity. N>>>При профессиональном подходе — наоборот. Введение локальной сложности сильно упрощает систему в целом. Многократно проверено.
ОК>>Ты, видимо, мало поддерживал кода написанного другими с таким же мнением как и у тебя. N>Не в обиду: учитывая, что ты показал недопонимание базовых конструкций? Не удивительно.
Это ненужная мелочь и плюсами я сейчас почти не занимаюсь.
Я лично никогда не писал в своем коде конвержн операторов и никогда не делал приватных копиконструкторов только потому что кто-то (О БОЖЕ!) в будущем случайно сможет попытаться создать копию объекта и из этого ничего хорошего не выйдет.
Но если ты меня так хочешь тыкнуть, то и я тебя могу тыкнуть с твоим дополнительным значением для иньюма. Первое. Ты вводишь ненужное имя в код которое потом нигде не используется. И второе. Почему ты решил что ты знаешь лучше компилятора сколько байт ему надо выделить под иньюм? Непонимание базовых вещей с твоей стороны!
N>Я много всякого кода поддерживал, в том числе занимался портированием STL и модифицировал boost. Бедный на язык код, как правило поддерживается много хуже (с С++ у меня хорошо). Сейчас вот как раз с подобным маюсь.
Да что там этот буст и стл? Только сам язык и темплейты. Ты бы поподдерживал проекты которым не один десяток лет и в которых дохрена бизнес логики с подобными наворотами.
N>При решении задачи — первым делом нужно подготовить псевдоязык/библиотеку, как набор терминов этой задачи. Вот люди у которых проблема с языковыми конструкциями не умеют и библиотеки делать, отсюда решение задачи осуществляется неподходящими методами и поддержка сильно осложняется.
Каюсь, я библиотеками тоже не занимаюсь но подчеркну еще раз мысль которая до тебя не доходит. Хороший software engineer это не тот кто помнит все ньюансы языка а тот кто более просто и понятно решит насущую проблему. Пора бы уже давно вырасти из мелких деталей.
Здравствуйте, Олег К., Вы писали:
ОК>>>Нелогичность тут, однако. Как поступит компилятор с просто объявленными (но неопределенными) public и protected функциями которые нигде не вызываются? N>>Скомпилирует, при возможности. А затем линкер сообщит о проблеме. Во избежание компиляции их делают private. Двойная защита.
ОК>На счет прайвит понять можно но вот компилировать код в котором объявлены но не определены public и protected функции это уже непростительно.
С чего вдруг? Даже Страуструп тебе написал, что это нормально.
N>>Значит ты используешь более бедные средства и твой код может быть небезопасен, менее расширяем и реиспользуем.
ОК>Проблемы нужно решать по мере их поступления а не пытаться решить все возможные проблемы в будущем. Это про небезопасность и, как правило, ничего небезопасного в будущем не случалось.
Мне этот тезис сразу представил аналогию: можно не мыться, а проблемы (часотку) решать по мере поступления.
Я к тому, что нормальных разработчик в ходе разработки поддерживает определённую гигиену: исключает возможность для ошибок, исключает преждевременную оптимизацию и пессимизацию, выдерживает чёткий стиль и закономерности разработки.
N>>Во всём нужна мера, но это не значит, что имеет смысл игнорировать языковые конструкции там где они будут полезны.
ОК>Я считаю что процентов 20 — 30 языка достаточно чтобы писать нормальный и простой код. Я концентрируюсь на бизнес задачах а не на технологиях ради технологий. Ну и разумеется стараюсь чтобы код был debuggable and maintainable.
Не знаю, не видел. Дело твоё
ОК>Здесь же я вижу технологии ради технологий которые потом расползутся по куче проектов и которые не добавляют никакой ценности бизнесу.
С точки зрения бизнеса есть эмпирическое правило: поддержка в 3-5 раз дороже разработки. Програмист обеспечивающий более поддерживаемый и расширяемый код более эффективен. Отсюда — много требований к балансу.
ОК>Я лично никогда не писал в своем коде конвержн операторов и никогда не делал приватных копиконструкторов только потому что кто-то (О БОЖЕ!) в будущем случайно сможет попытаться создать копию объекта и из этого ничего хорошего не выйдет.
Т.е. ты писал опасный код, хотя с теми же затратами мог писать безопасный
ОК>Но если ты меня так хочешь тыкнуть, то и я тебя могу тыкнуть с твоим дополнительным значением для иньюма. Первое. Ты вводишь ненужное имя в код которое потом нигде не используется. И второе. Почему ты решил что ты знаешь лучше компилятора сколько байт ему надо выделить под иньюм? Непонимание базовых вещей с твоей стороны!
Не, это профессиональная контузия, слишком много дел имел с мобильными платформами и их зоопарком компиляторов. Имя специально вводится техническое, а размеры, как раз, нужно знать, иначе выравнивание на армах начинает глючить.
N>>Я много всякого кода поддерживал, в том числе занимался портированием STL и модифицировал boost. Бедный на язык код, как правило поддерживается много хуже (с С++ у меня хорошо). Сейчас вот как раз с подобным маюсь.
ОК>Да что там этот буст и стл? Только сам язык и темплейты. Ты бы поподдерживал проекты которым не один десяток лет и в которых дохрена бизнес логики с подобными наворотами.
Я сейчас поддерживаю проект которому ~20 лет и С++ шные компоненты писали люди с достаточно смутными программерскими талантами и посредственным знанием средств С++ и их целей Это довольно мучительно.
ОК>Каюсь, я библиотеками тоже не занимаюсь но подчеркну еще раз мысль которая до тебя не доходит. Хороший software engineer это не тот кто помнит все ньюансы языка а тот кто более просто и понятно решит насущую проблему. Пора бы уже давно вырасти из мелких деталей.
Все нюансы языка — да, можно не знать. Но 90% — надо Хорошему инженеру в этой области. ремарк, в частности, особых нюансов не употреблял, а пример который был приведён — достаточно примитивен и все его особенности С++ программист точно обязан понимать.
Я когда делал протокол для одной социальной сети функция запроса по RESTful протоколу выглядела примерно так:
С помощью возвращаемого результата — запрос можно было прибить, при необходимости.
on_succ и on_fail вызывались в соответствующих случаях.
Парсинг ответа (в xml или json формате) осуществлялся автоматически по структуре SomeInfo (аналогично бустовской сериализации).
Конкретные реализации получаемых структур данных в 99% случаев формировались кодогенератором на основании, фактически, определения протокола. Т.е. добавление новой, даже сложной структуры данных протокола занимало минут 10-20, а при изменении требований можно было переписать кодогенератор и перегенерировать всю структуру протокола. function — это довольно сложная шаблонная структура, сериализация — тоже, но результат — компактен, красив и расширяем. Когда, после реализации основной части протокола, потребовалось сделать кеширование, проверку капчи и автоматические переподключения и перенаправления — это было сделано без проблем.
Здравствуйте, Vain, Вы писали:
V>Здравствуйте, MTD, Вы писали:
_>>>тебе мыщьха недостаточно? MTD>>Как-то странно озабоченного балабола сравнивать с очень умными и грамотными людьми V>Он не просто балабол, он заливать любит, ни одному его слову не верю
ну и правильно, ибо вместе со своими фоточками и ссылочками на катлетки — он рассаживает вирусную заразу гоморологической лихорадки мавсесяна по всему миру, ацкий лесбис пентагона
ОК>>>>Нелогичность тут, однако. Как поступит компилятор с просто объявленными (но неопределенными) public и protected функциями которые нигде не вызываются? N>>>Скомпилирует, при возможности. А затем линкер сообщит о проблеме. Во избежание компиляции их делают private. Двойная защита.
ОК>>На счет прайвит понять можно но вот компилировать код в котором объявлены но не определены public и protected функции это уже непростительно.
N>С чего вдруг? Даже Страуструп тебе написал, что это нормально.
Я не об этом. Страуструп привел пример приватных функций а не паблик или протектид. В случае с прайвит функцией можно объявить ее и если она не используется то все ок. В случае с паблик или протектид функцией если ты к примеру напишешь какую-то либу в которой будет объявлена эта функция но не будет ее кода, то уже потом чей-то клиентский код не сможет ее использовать из-за отсутствущей функции (из-за ее вызова). То есть тут разница в поведении для прайвит и не прайвит функций.
N>>>Значит ты используешь более бедные средства и твой код может быть небезопасен, менее расширяем и реиспользуем.
ОК>>Проблемы нужно решать по мере их поступления а не пытаться решить все возможные проблемы в будущем. Это про небезопасность и, как правило, ничего небезопасного в будущем не случалось.
N>Мне этот тезис сразу представил аналогию: можно не мыться, а проблемы (часотку) решать по мере поступления.
Аналогия некоректна. Организм потеет и выделяет жиры с течением времени а код нет и у меня что-то ни разу не было случая чтобы я стал копировать чужие объекты которые нельзя копировать. Большинство объектов все-таки реализуют какую-то функциональность и ты используешь их ради этой функциональности.
N>Я к тому, что нормальных разработчик в ходе разработки поддерживает определённую гигиену: исключает возможность для ошибок, исключает преждевременную оптимизацию и пессимизацию, выдерживает чёткий стиль и закономерности разработки.
Тут вопрос сколько этой гигиены нужно сделать. Ты исходишь из какой-то возможности ошибок. А ты просто не совершай эти ошибки в первую очередь и будет тебе счастье.
Вот здесь хороший пример. Предполагаю что ты только за такую гигиену.
print (cow_count, galosh_count); // Компилятор это проглотит, несмотря на то, что я перепутал порядок аргументов, а хотелось бы увидеть ошибку
Чувак начинает городить огород только потому что он может перепутать порядок аргументов. Это более наглядный пример. Мой ответ: а ты просто передавай аргументы в правильном порядке и все.
От всего не застрахуешься. Вдруг мне завтра прийдет в голову сделать мемсет по случайным участкам памяти? В общем не надо доводить код до маразма.
N>>>Во всём нужна мера, но это не значит, что имеет смысл игнорировать языковые конструкции там где они будут полезны.
ОК>>Я считаю что процентов 20 — 30 языка достаточно чтобы писать нормальный и простой код. Я концентрируюсь на бизнес задачах а не на технологиях ради технологий. Ну и разумеется стараюсь чтобы код был debuggable and maintainable.
N>Не знаю, не видел. Дело твоё
ОК>>Здесь же я вижу технологии ради технологий которые потом расползутся по куче проектов и которые не добавляют никакой ценности бизнесу.
N>С точки зрения бизнеса есть эмпирическое правило: поддержка в 3-5 раз дороже разработки. Програмист обеспечивающий более поддерживаемый и расширяемый код более эффективен. Отсюда — много требований к балансу.
Ты сыплешь тут какими-то книжными фразами.
ОК>>Я лично никогда не писал в своем коде конвержн операторов и никогда не делал приватных копиконструкторов только потому что кто-то (О БОЖЕ!) в будущем случайно сможет попытаться создать копию объекта и из этого ничего хорошего не выйдет.
N>Т.е. ты писал опасный код, хотя с теми же затратами мог писать безопасный
И нафиг? От всего, повторюсь, не застрахуешься. Просто не делай глупости в коде и все. Выше я привел ссылку на более наглядный пример когда такие страховки доходят до маразма.
ОК>>Но если ты меня так хочешь тыкнуть, то и я тебя могу тыкнуть с твоим дополнительным значением для иньюма. Первое. Ты вводишь ненужное имя в код которое потом нигде не используется. И второе. Почему ты решил что ты знаешь лучше компилятора сколько байт ему надо выделить под иньюм? Непонимание базовых вещей с твоей стороны!
N>Не, это профессиональная контузия, слишком много дел имел с мобильными платформами и их зоопарком компиляторов. Имя специально вводится техническое, а размеры, как раз, нужно знать, иначе выравнивание на армах начинает глючить.
Ясно.
N>>>Я много всякого кода поддерживал, в том числе занимался портированием STL и модифицировал boost. Бедный на язык код, как правило поддерживается много хуже (с С++ у меня хорошо). Сейчас вот как раз с подобным маюсь.
ОК>>Да что там этот буст и стл? Только сам язык и темплейты. Ты бы поподдерживал проекты которым не один десяток лет и в которых дохрена бизнес логики с подобными наворотами.
N>Я сейчас поддерживаю проект которому ~20 лет и С++ шные компоненты писали люди с достаточно смутными программерскими талантами и посредственным знанием средств С++ и их целей Это довольно мучительно.
Я не знаю что за код ты там поддерживаешь но 20 лет назад еще темплейтов толком не было. Не ожидай что они могли писать код в стиле "меня Александреску в полнолуние укусил."
ОК>>Каюсь, я библиотеками тоже не занимаюсь но подчеркну еще раз мысль которая до тебя не доходит. Хороший software engineer это не тот кто помнит все ньюансы языка а тот кто более просто и понятно решит насущую проблему. Пора бы уже давно вырасти из мелких деталей.
N>Все нюансы языка — да, можно не знать. Но 90% — надо
Да ну? Вещи которыми ты не пользуешься забываются. Если ты считаешь что 90% надо, то ты видимо пихаешь в свой код все конструкции языка какие только можно. Я даже видел код где было это ромбо-видное наследование. Чуваки тоже считали также как и ты. Надеюсь ты не будешь утверждать что без этого ромбо-видного наследования не обойтись?
N>Хорошему инженеру в этой области. ремарк, в частности, особых нюансов не употреблял, а пример который был приведён — достаточно примитивен и все его особенности С++ программист точно обязан понимать.
Каюсь, ступил с той конструкцией т.к. давно уже не читал книг по плюсам и занимаюсь сейчас другими вещами. Ремарк, кстати, тоже возвращал строку по значению но это все мелочи на которые я могу закрыть глаза. Я о более глобальной картине — о том что та написанная гуйня совсем не нужна.
И даже абсолютное знание всех 100% языка != умению программировать и решать задачи.
N>Я когда делал протокол для одной социальной сети функция запроса по RESTful протоколу выглядела примерно так: N>
N>С помощью возвращаемого результата — запрос можно было прибить, при необходимости. N>on_succ и on_fail вызывались в соответствующих случаях. N>Парсинг ответа (в xml или json формате) осуществлялся автоматически по структуре SomeInfo (аналогично бустовской сериализации).
Как все надуманно и сложно. Реальным пацанам впадлу писать не темплейтные функции, да?
N>Конкретные реализации получаемых структур данных в 99% случаев формировались кодогенератором на основании, фактически, определения протокола. Т.е. добавление новой, даже сложной структуры данных протокола занимало минут 10-20, а при изменении требований можно было переписать кодогенератор и перегенерировать всю структуру протокола. function — это довольно сложная шаблонная структура, сериализация — тоже, но результат — компактен, красив и расширяем. Когда, после реализации основной части протокола, потребовалось сделать кеширование, проверку капчи и автоматические переподключения и перенаправления — это было сделано без проблем.
Здравствуйте, Олег К., Вы писали:
ОК>>>>>Нелогичность тут, однако. Как поступит компилятор с просто объявленными (но неопределенными) public и protected функциями которые нигде не вызываются? N>>>>Скомпилирует, при возможности. А затем линкер сообщит о проблеме. Во избежание компиляции их делают private. Двойная защита.
ОК>>>На счет прайвит понять можно но вот компилировать код в котором объявлены но не определены public и protected функции это уже непростительно.
N>>С чего вдруг? Даже Страуструп тебе написал, что это нормально.
ОК>Я не об этом. Страуструп привел пример приватных функций а не паблик или протектид.
Во всех местных примерах функции приёма — тоже приватные.
ОК>В случае с прайвит функцией можно объявить ее и если она не используется то все ок. В случае с паблик или протектид функцией если ты к примеру напишешь какую-то либу в которой будет объявлена эта функция но не будет ее кода, то уже потом чей-то клиентский код не сможет ее использовать из-за отсутствущей функции (из-за ее вызова). То есть тут разница в поведении для прайвит и не прайвит функций.
Ты что-то придумал. Какая паблик, откуда она взялась? Ну ладно, сделали случайно template<class T> operator T(); пабликом, как отсутствие реализации помешает использовать класс и в чём будет разница в поведении?
ОК>>>Проблемы нужно решать по мере их поступления а не пытаться решить все возможные проблемы в будущем. Это про небезопасность и, как правило, ничего небезопасного в будущем не случалось.
N>>Мне этот тезис сразу представил аналогию: можно не мыться, а проблемы (часотку) решать по мере поступления.
ОК>Аналогия некоректна. Организм потеет и выделяет жиры с течением времени а код нет и у меня что-то ни разу не было случая чтобы я стал копировать чужие объекты которые нельзя копировать. Большинство объектов все-таки реализуют какую-то функциональность и ты используешь их ради этой функциональности.
Код со временем портится. В него вносятся изменения, разработчики уходят и т.п. Чистый код будет меньше подвержен проблемам, аналогия в самый раз.
Хороший программист пишет такой код в использовании которого максимально сложно ошибиться. Это не то же самое, что примитивный код.
N>>Я к тому, что нормальных разработчик в ходе разработки поддерживает определённую гигиену: исключает возможность для ошибок, исключает преждевременную оптимизацию и пессимизацию, выдерживает чёткий стиль и закономерности разработки.
ОК>Тут вопрос сколько этой гигиены нужно сделать. Ты исходишь из какой-то возможности ошибок. А ты просто не совершай эти ошибки в первую очередь и будет тебе счастье.
Я всегда предпочитаю двойную защиту, с обеих сторон.
ОК>Вот здесь хороший пример. Предполагаю что ты только за такую гигиену.
Это достаточно глупая статья, в добавок человек не знаком с трудом классиков Каноничным примером (я про него слышал >10 лет назад) является типизация физических переменных, таким образом, что при операциях проверяется размерность.
ОК>Чувак начинает городить огород только потому что он может перепутать порядок аргументов. Это более наглядный пример. Мой ответ: а ты просто передавай аргументы в правильном порядке и все.
Предпочту типизировать и стандартизировать, хотя и не до такого уровня.
ОК>От всего не застрахуешься. Вдруг мне завтра прийдет в голову сделать мемсет по случайным участкам памяти? В общем не надо доводить код до маразма.
А не надо юзать мемсет И работа с памятью — это больной подход. С++ плох именно тем, что есть много способов выстрелить себе в ногу и специалист должен знать именно ту тропку и высокоуровневые методы при использовании которых выстрел в ногу исключён. Твоё предположение о мемсете — это низкоуровневость, и соответственно опасность (и неэффективность).
N>>С точки зрения бизнеса есть эмпирическое правило: поддержка в 3-5 раз дороже разработки. Програмист обеспечивающий более поддерживаемый и расширяемый код более эффективен. Отсюда — много требований к балансу.
ОК>Ты сыплешь тут какими-то книжными фразами.
Это не книжные фразы (более того, я такого в книгах не встречал), это выведено из самого, что ни есть практичного опыта.
N>>Т.е. ты писал опасный код, хотя с теми же затратами мог писать безопасный
ОК>И нафиг? От всего, повторюсь, не застрахуешься.
Да, но к этому нужно стремиться (с поправками на предполагаемое время жизни продукта и т.п.)
ОК>Просто не делай глупости в коде и все.
Ошибок нет только у того, кто ничего не делает. А защита от дурака — обязательная часть в разработке.
ОК>Выше я привел ссылку на более наглядный пример когда такие страховки доходят до маразма.
Оно маразм, только из-за отсутствия в С++ дешёвых инструментов для уникализации типа. Для переменных чуть сложнее счётчиков — я почти всегда типизирую (например в последнем проекте уникализировал uidы относящиеся к разным типам).
ОК>>>Да что там этот буст и стл? Только сам язык и темплейты. Ты бы поподдерживал проекты которым не один десяток лет и в которых дохрена бизнес логики с подобными наворотами.
N>>Я сейчас поддерживаю проект которому ~20 лет и С++ шные компоненты писали люди с достаточно смутными программерскими талантами и посредственным знанием средств С++ и их целей Это довольно мучительно.
ОК>Я не знаю что за код ты там поддерживаешь но 20 лет назад еще темплейтов толком не было. Не ожидай что они могли писать код в стиле "меня Александреску в полнолуние укусил."
Я сказал — проект. Значительная часть кода там моложе, но всё-равно довольно древняя. Особенно комы бесят, которые совершенно не к месту.
N>>Все нюансы языка — да, можно не знать. Но 90% — надо
ОК>Да ну? Вещи которыми ты не пользуешься забываются. Если ты считаешь что 90% надо, то ты видимо пихаешь в свой код все конструкции языка какие только можно. Я даже видел код где было это ромбо-видное наследование. Чуваки тоже считали также как и ты. Надеюсь ты не будешь утверждать что без этого ромбо-видного наследования не обойтись?
Я считаю виртуальное наследование антипаттерном, а случаи его применения явным симптомом проблем с архитектурой (создание универсальных всемогутеров). В остальном — нужно применять подходящие конструкции языка в нужном месте. И шаблоны, и RTTI, и объявление без реализации
ОК>Каюсь, ступил с той конструкцией т.к. давно уже не читал книг по плюсам и занимаюсь сейчас другими вещами. Ремарк, кстати, тоже возвращал строку по значению но это все мелочи на которые я могу закрыть глаза.
std::string — очень проблемный класс в стандартной библиотеке, раньше я его применял, но потом пришлось перейти на ATL/MFC вариант или для кустомных платформ свои реализации с тем же интерфейсом. Их можно возвращать без ссылки.
ОК>Я о более глобальной картине — о том что та написанная гуйня совсем не нужна.
Хз, не вчитывался.
ОК>И даже абсолютное знание всех 100% языка != умению программировать и решать задачи.
Само собой, нужно быть комплексным и язык знать, и уметь его применить с толком, и многое другое.
N>>С помощью возвращаемого результата — запрос можно было прибить, при необходимости. N>>on_succ и on_fail вызывались в соответствующих случаях. N>>Парсинг ответа (в xml или json формате) осуществлялся автоматически по структуре SomeInfo (аналогично бустовской сериализации).
ОК>Как все надуманно и сложно.
Чего надуманного и сложного? Запись предельно компактна, протокол расширяем, а процесс контролируем.
ОК>Реальным пацанам впадлу писать не темплейтные функции, да?
Там где нужна темплейтная функция — очевидно глупо обходиться без неё
ОК>>>>Проблемы нужно решать по мере их поступления а не пытаться решить все возможные проблемы в будущем. Это про небезопасность и, как правило, ничего небезопасного в будущем не случалось.
N>>>Мне этот тезис сразу представил аналогию: можно не мыться, а проблемы (часотку) решать по мере поступления.
ОК>>Аналогия некоректна. Организм потеет и выделяет жиры с течением времени а код нет и у меня что-то ни разу не было случая чтобы я стал копировать чужие объекты которые нельзя копировать. Большинство объектов все-таки реализуют какую-то функциональность и ты используешь их ради этой функциональности.
N>Код со временем портится. В него вносятся изменения, разработчики уходят и т.п. Чистый код будет меньше подвержен проблемам, аналогия в самый раз.
Тут имелось в виду что организм потеет спонтанно. С кодом такого не происходит. Каждый раз поддерживай код в валидном состоянии и тестируй как меняешь его и до чесотки у тебя не дойдет.
N>Хороший программист пишет такой код в использовании которого максимально сложно ошибиться. Это не то же самое, что примитивный код.
Ага. Запихав туда предварительно темплейты и паттерны и создав гигантскую иерархию классов.
Чем проще код, тем проще в нем разобраться и тем меньше ошибок сделаешь в нем в дальнейшем. И потом, новому человеку прийдется все равно разбираться что же делает твоя мега-функция прежде чем ее хоть как-то использовать.
N>>>Я к тому, что нормальных разработчик в ходе разработки поддерживает определённую гигиену: исключает возможность для ошибок, исключает преждевременную оптимизацию и пессимизацию, выдерживает чёткий стиль и закономерности разработки.
ОК>>Тут вопрос сколько этой гигиены нужно сделать. Ты исходишь из какой-то возможности ошибок. А ты просто не совершай эти ошибки в первую очередь и будет тебе счастье.
N>Я всегда предпочитаю двойную защиту, с обеих сторон.
Двойной мало. Надо бы хотя бы тройную.
ОК>>Вот здесь хороший пример. Предполагаю что ты только за такую гигиену.
N>Это достаточно глупая статья, в добавок человек не знаком с трудом классиков Каноничным примером (я про него слышал >10 лет назад) является типизация физических переменных, таким образом, что при операциях проверяется размерность.
Ну почему глупая? Код ведь делает то что он должен делать с твоей точки зрения!
ОК>>Чувак начинает городить огород только потому что он может перепутать порядок аргументов. Это более наглядный пример. Мой ответ: а ты просто передавай аргументы в правильном порядке и все.
N>Предпочту типизировать и стандартизировать, хотя и не до такого уровня.
Предпочту послать два инта и не париться!
ОК>>От всего не застрахуешься. Вдруг мне завтра прийдет в голову сделать мемсет по случайным участкам памяти? В общем не надо доводить код до маразма. N>А не надо юзать мемсет И работа с памятью — это больной подход. С++ плох именно тем, что есть много способов выстрелить себе в ногу и специалист должен знать именно ту тропку и высокоуровневые методы при использовании которых выстрел в ногу исключён. Твоё предположение о мемсете — это низкоуровневость, и соответственно опасность (и неэффективность).
Это я тебе привел просто радикальный пример который ты не понял. Чтобы ты там не городил, это все можно обойти и тут ты ничего поделать не можешь. Другой пример неправильный каст и все твои проверки пойдут насмарку.
И если тебе так нужна эта безопасность то ты, скорее всего, выбрал не тот инструмент. Тебе надо в мэнэджд языки.
N>>>С точки зрения бизнеса есть эмпирическое правило: поддержка в 3-5 раз дороже разработки. Програмист обеспечивающий более поддерживаемый и расширяемый код более эффективен. Отсюда — много требований к балансу.
ОК>>Ты сыплешь тут какими-то книжными фразами.
N>Это не книжные фразы (более того, я такого в книгах не встречал), это выведено из самого, что ни есть практичного опыта.
Ну так начни писать книги! У тебя это хорошо получается! Звучит умно.
N>>>Т.е. ты писал опасный код, хотя с теми же затратами мог писать безопасный
ОК>>И нафиг? От всего, повторюсь, не застрахуешься. N>Да, но к этому нужно стремиться (с поправками на предполагаемое время жизни продукта и т.п.)
К этому как раз-таки не нужно стремиться.
ОК>>Просто не делай глупости в коде и все. N>Ошибок нет только у того, кто ничего не делает. А защита от дурака — обязательная часть в разработке.
Ну я вижу что ты готов городить огород только потому что якобы кто-то в будущем неправильно используют какой-то код. Некоторые даже городят в своем коде который никому кроме них не нужен.
ОК>>Выше я привел ссылку на более наглядный пример когда такие страховки доходят до маразма. N>Оно маразм, только из-за отсутствия в С++ дешёвых инструментов для уникализации типа. Для переменных чуть сложнее счётчиков — я почти всегда типизирую (например в последнем проекте уникализировал uidы относящиеся к разным типам).
Я говорю маразм и ты вроде тут согласен со мной. Только почему ты думаешь что твои страховки как-то отличаются от этого маразма? Или это потому что твой код это твой код а его код это его код?
ОК>>>>Да что там этот буст и стл? Только сам язык и темплейты. Ты бы поподдерживал проекты которым не один десяток лет и в которых дохрена бизнес логики с подобными наворотами.
N>>>Я сейчас поддерживаю проект которому ~20 лет и С++ шные компоненты писали люди с достаточно смутными программерскими талантами и посредственным знанием средств С++ и их целей Это довольно мучительно.
ОК>>Я не знаю что за код ты там поддерживаешь но 20 лет назад еще темплейтов толком не было. Не ожидай что они могли писать код в стиле "меня Александреску в полнолуние укусил."
N>Я сказал — проект. Значительная часть кода там моложе, но всё-равно довольно древняя. Особенно комы бесят, которые совершенно не к месту.
Вот ты говоришь что комы там не к месту. Охотно верю. Только почему ты считаешь что твой последователь не будет говорить такого о твоих проверках, к примеру?
N>>>Все нюансы языка — да, можно не знать. Но 90% — надо
ОК>>Да ну? Вещи которыми ты не пользуешься забываются. Если ты считаешь что 90% надо, то ты видимо пихаешь в свой код все конструкции языка какие только можно. Я даже видел код где было это ромбо-видное наследование. Чуваки тоже считали также как и ты. Надеюсь ты не будешь утверждать что без этого ромбо-видного наследования не обойтись?
N>Я считаю виртуальное наследование антипаттерном, а случаи его применения явным симптомом проблем с архитектурой (создание универсальных всемогутеров). В остальном — нужно применять подходящие конструкции языка в нужном месте. И шаблоны, и RTTI, и объявление без реализации
Вот ты говоришь универсальные всемогутеры. А почему твой код нельзя назвать универсальным всемчекером? По аналогии.
На счет шаблонов и RTTI я с тобой не согласен. Можно писать нормальный код без этого мракобесия с шаблонами и уж RTTI вообще точно не нужен. Не нужно тебе в ООП знать тип объекта. Вместо этого надо правильно создать иерархию (если уж она тебе так нужна) и задействовать виртуальные функции.
ОК>>Каюсь, ступил с той конструкцией т.к. давно уже не читал книг по плюсам и занимаюсь сейчас другими вещами. Ремарк, кстати, тоже возвращал строку по значению но это все мелочи на которые я могу закрыть глаза. N>std::string — очень проблемный класс в стандартной библиотеке, раньше я его применял, но потом пришлось перейти на ATL/MFC вариант или для кустомных платформ свои реализации с тем же интерфейсом. Их можно возвращать без ссылки.
Хе-хе. То есть ты вместо того чтобы стандартный класс посылать по ссылке и возвращать ссылку на него решил задействовать другой вариант только потому что внутри они реализованны иначе?
Имхо это неправильный подход. Используй класс правильно а не пытайся обойти возможные накладные расходы таким путем. Это, кстати, противоречит ООП; тебе не надо знать как внутри сделан класс.
ОК>>Я о более глобальной картине — о том что та написанная гуйня совсем не нужна. N>Хз, не вчитывался.
Да я это вообще-то с самого начала тут твержу. Мне пофиг как он там возвращает стринги но сам весь его код считаю ненужным наворотом.
ОК>>И даже абсолютное знание всех 100% языка != умению программировать и решать задачи. N>Само собой, нужно быть комплексным и язык знать, и уметь его применить с толком, и многое другое.
Хе-хе. Я вижу твою логику. Пока ты не зазубришь стандарт, пока не прочтешь Страуструпа, Александреску, Саттера и Мейерса — ты просто сам себя не сможешь чувствовать С++ программистом.
N>>>С помощью возвращаемого результата — запрос можно было прибить, при необходимости. N>>>on_succ и on_fail вызывались в соответствующих случаях. N>>>Парсинг ответа (в xml или json формате) осуществлялся автоматически по структуре SomeInfo (аналогично бустовской сериализации).
ОК>>Как все надуманно и сложно.
N>Чего надуманного и сложного? Запись предельно компактна, протокол расширяем, а процесс контролируем.
А тебе не приходит в голову что можно еще проще сделать?
ОК>>Реальным пацанам впадлу писать не темплейтные функции, да? N>Там где нужна темплейтная функция — очевидно глупо обходиться без неё
Ну это все от лукавого. Писали ведь программисты код без темплейтов и ничего. Не сомневаюсь что и без темплейтов в твоем случае можно обойтись.
Вообще то о чем я тебе тут толкую называется over-engineering. Может слышал такой термин?
Здравствуйте, Олег К., Вы писали:
N>>Код со временем портится. В него вносятся изменения, разработчики уходят и т.п. Чистый код будет меньше подвержен проблемам, аналогия в самый раз.
ОК>Тут имелось в виду что организм потеет спонтанно. С кодом такого не происходит. Каждый раз поддерживай код в валидном состоянии и тестируй как меняешь его и до чесотки у тебя не дойдет.
К сожалению оно хорошо только на словах А по факту внесение изменений в код, как правило, добавляет ошибок, и чем дальше — тем больше.
N>>Хороший программист пишет такой код в использовании которого максимально сложно ошибиться. Это не то же самое, что примитивный код.
ОК>Ага. Запихав туда предварительно темплейты и паттерны и создав гигантскую иерархию классов.
Гигантская иерархия классов — скорее всего плохой дизайн. Темплейты позволяют сделать код намного более компактным, нужно быть совсем диким, чтобы их избегать
Паттерны — это как раз средство повышение понятности кода, если видишь какое-нибудь слово "visitor" или "proxy" то дальше можно не вникать и так понятно что будет, что есть серьёзное упрощение для восприятия (конечно при грамотном разработчике).
ОК>Чем проще код, тем проще в нем разобраться и тем меньше ошибок сделаешь в нем в дальнейшем.
Да, поэтому нужно использовать шаблоны, защиты и т.п. Потому что это сильно упрощает.
ОК>И потом, новому человеку прийдется все равно разбираться что же делает твоя мега-функция прежде чем ее хоть как-то использовать.
Отсюда возникает потребность сделать её интерфейс максимально читабельным и исключающим ошибки.
N>>Это достаточно глупая статья, в добавок человек не знаком с трудом классиков Каноничным примером (я про него слышал >10 лет назад) является типизация физических переменных, таким образом, что при операциях проверяется размерность.
ОК>Ну почему глупая? Код ведь делает то что он должен делать с твоей точки зрения!
Глупая — потому что писал ламер.
N>>Предпочту типизировать и стандартизировать, хотя и не до такого уровня.
ОК>Предпочту послать два инта и не париться!
-> снизить читаемость и повысить вероятность глупых ошибок.
ОК>>>От всего не застрахуешься. Вдруг мне завтра прийдет в голову сделать мемсет по случайным участкам памяти? В общем не надо доводить код до маразма. N>>А не надо юзать мемсет И работа с памятью — это больной подход. С++ плох именно тем, что есть много способов выстрелить себе в ногу и специалист должен знать именно ту тропку и высокоуровневые методы при использовании которых выстрел в ногу исключён. Твоё предположение о мемсете — это низкоуровневость, и соответственно опасность (и неэффективность).
ОК>Это я тебе привел просто радикальный пример который ты не понял.
Я всё понял, этому примеру тоже сто лет в обед.
ОК>Чтобы ты там не городил, это все можно обойти и тут ты ничего поделать не можешь. Другой пример неправильный каст и все твои проверки пойдут насмарку.
Я расчитываю на то что с моим кодом будет работать программист
С++ опасный язык, да.
ОК>И если тебе так нужна эта безопасность то ты, скорее всего, выбрал не тот инструмент. Тебе надо в мэнэджд языки.
Такой довод я тоже слышал. Но 1. менеджед языки не везде применимы (а там где применимы я их и юзаю), 2. на С++ можно и нужно писать безопасно, хотя можно опасно.
N>>Это не книжные фразы (более того, я такого в книгах не встречал), это выведено из самого, что ни есть практичного опыта.
ОК>Ну так начни писать книги! У тебя это хорошо получается! Звучит умно.
Я даже статьёй не могу разродиться, а ты — книги Не дави на больную тему
N>>Да, но к этому нужно стремиться (с поправками на предполагаемое время жизни продукта и т.п.)
ОК>К этому как раз-таки не нужно стремиться.
Если предположить, что правило верно, то при разработке безопасность и архитектура выходит на первый план, так как они способны существенно облегчить поддержку и снизить совокупную стоимость.
ОК>>>Выше я привел ссылку на более наглядный пример когда такие страховки доходят до маразма. N>>Оно маразм, только из-за отсутствия в С++ дешёвых инструментов для уникализации типа. Для переменных чуть сложнее счётчиков — я почти всегда типизирую (например в последнем проекте уникализировал uidы относящиеся к разным типам).
ОК>Я говорю маразм и ты вроде тут согласен со мной. Только почему ты думаешь что твои страховки как-то отличаются от этого маразма? Или это потому что твой код это твой код а его код это его код?
Нет, потому что он уникализировал счётчики, это спорный момент.
N>>Я сказал — проект. Значительная часть кода там моложе, но всё-равно довольно древняя. Особенно комы бесят, которые совершенно не к месту.
ОК>Вот ты говоришь что комы там не к месту. Охотно верю. Только почему ты считаешь что твой последователь не будет говорить такого о твоих проверках, к примеру?
Комы не к месту по вполне объективным причинам (избыточные и кривые абстрагирования, они не используются по назначению, они увели от терминов предметной области). Необходимость типизации в сколько то сложных проектам — вполне объективна.
N>>Я считаю виртуальное наследование антипаттерном, а случаи его применения явным симптомом проблем с архитектурой (создание универсальных всемогутеров). В остальном — нужно применять подходящие конструкции языка в нужном месте. И шаблоны, и RTTI, и объявление без реализации
ОК>Вот ты говоришь универсальные всемогутеры. А почему твой код нельзя назвать универсальным всемчекером? По аналогии.
К сожалению — нельзя, но хотелось бы.
ОК>На счет шаблонов и RTTI я с тобой не согласен. Можно писать нормальный код без этого мракобесия с шаблонами
В наше время мракобесие — это без шаблонов. Тебя без них даже на приличную работу не возьмут.
ОК>и уж RTTI вообще точно не нужен. Не нужно тебе в ООП знать тип объекта. Вместо этого надо правильно создать иерархию (если уж она тебе так нужна) и задействовать виртуальные функции.
Иерархия и виртуальные функции имеют определённую область применения, достаточно узкую, при грамотной разработке. Иерархия больше 2 уровней (если не считать технические моменты, типа внедрения счётчиков) это уже повод задуматься.
ОК>Хе-хе. То есть ты вместо того чтобы стандартный класс посылать по ссылке и возвращать ссылку на него решил задействовать другой вариант только потому что внутри они реализованны иначе?
Есть часто встречающаяся ошибка, многие думают, что std::string это класс строки, хотя это класс-контейнер строки. При реальной работе с классом-строкой работать намного удобнее, к сожалению такого в stl нет.
ОК>Имхо это неправильный подход. Используй класс правильно а не пытайся обойти возможные накладные расходы таким путем. Это, кстати, противоречит ООП; тебе не надо знать как внутри сделан класс.
Я использую правильно
ОК>>>И даже абсолютное знание всех 100% языка != умению программировать и решать задачи. N>>Само собой, нужно быть комплексным и язык знать, и уметь его применить с толком, и многое другое.
ОК>Хе-хе. Я вижу твою логику. Пока ты не зазубришь стандарт, пока не прочтешь Страуструпа, Александреску, Саттера и Мейерса — ты просто сам себя не сможешь чувствовать С++ программистом.
Стандарт я не зубрю, а без прочтения классиков (или их аналогов) — да, ты не можешь считаться грамотным программистом.
N>>Чего надуманного и сложного? Запись предельно компактна, протокол расширяем, а процесс контролируем.
ОК>А тебе не приходит в голову что можно еще проще сделать?
Проще, видимо, нельзя. Всё что можно — сокрыто, всё что можно — автоматизировано, интерфейс отображает только суть.
N>>Там где нужна темплейтная функция — очевидно глупо обходиться без неё
ОК>Ну это все от лукавого. Писали ведь программисты код без темплейтов и ничего. Не сомневаюсь что и без темплейтов в твоем случае можно обойтись.
Можно, но код при этом получится сложнее, разработка дольше и опаснее. Есть правило: проект может быть успешно выполнен даже плохими средствами. Средства только повышают вероятность успешного исхода.
ОК>Вообще то о чем я тебе тут толкую называется over-engineering. Может слышал такой термин?
Слышал. Только это к теме не относится, так как ты предлагаешь недоинжиниринг.
Здравствуйте, Олег К., Вы писали:
А>>>>>>Объясните нубу, почему столько шуму вокруг них?
N>>>>>remark — гуру С++, большое количество очень славных постов в С++ теме. K>>>>Он ещё гуру многопоточности и мулитипроцессорности.
ОК>>>Ну, если он в таком же духе бангалорит реальный код, то software engineer из него никудышный. K>>Из его постов на этом сайте и тех срачах в которых он имел неосторожность отписаться у меня сложилось другое мнение.
ОК>Ну а у меня сложилось мнение прямо противоположное твоему. Кто из нас прав?
Я прочитл ваш спор с Ником. По статье у меня сложилось мнение, что он больше концепт никий предлагал, а не какой-то рабочее решение.
Здравствуйте, Олег К., Вы писали:
BB>>jazzer остался.
ОК>Да джаззер, ремарк и сам топикстартер переусложняют свой код. На счет Кодта — хочется надеяться что человек понимает что можно использовать в реальном коде а что нет.
Они все понимают. И ты не поверишь, но переусложнение кода только в голове. Мне кажется, на кажого из них влияет их специфика и, как следствие, они пишут вот такой вот код. Думаю, что твои задачи сильно отличаются от их и поэтому тебе их код кажется переусложнением. Метафора — это как говорить на английском с руским акцентом, вроде и правильно, а что-то не то.
N>>>Код со временем портится. В него вносятся изменения, разработчики уходят и т.п. Чистый код будет меньше подвержен проблемам, аналогия в самый раз.
ОК>>Тут имелось в виду что организм потеет спонтанно. С кодом такого не происходит. Каждый раз поддерживай код в валидном состоянии и тестируй как меняешь его и до чесотки у тебя не дойдет.
N>К сожалению оно хорошо только на словах А по факту внесение изменений в код, как правило, добавляет ошибок, и чем дальше — тем больше.
Я тоже самое могу сказать про твои аргументы. Они хороши только на словах. На деле же чем больше кода, тем больше и дольше надо разбираться что же эта гуйня все-таки делает.
N>>>Хороший программист пишет такой код в использовании которого максимально сложно ошибиться. Это не то же самое, что примитивный код.
ОК>>Ага. Запихав туда предварительно темплейты и паттерны и создав гигантскую иерархию классов.
N>Гигантская иерархия классов — скорее всего плохой дизайн.
Это был сарказм с моей стороны, вообще-то.
N>Темплейты позволяют сделать код намного более компактным, нужно быть совсем диким, чтобы их избегать
Да чего уж там. Нужно быть совсем диким если не запихнешь в проект multiple inheritance, RAII, design patterns, all kinds of casts, boost и т.д. и т.п.
N>Паттерны — это как раз средство повышение понятности кода, если видишь какое-нибудь слово "visitor" или "proxy" то дальше можно не вникать и так понятно что будет, что есть серьёзное упрощение для восприятия (конечно при грамотном разработчике).
Я еще ни одной задачи не видел где нужны были бы эти паттерны. Зато видел кучу кода где они были как корове седло.
ОК>>Чем проще код, тем проще в нем разобраться и тем меньше ошибок сделаешь в нем в дальнейшем. N>Да, поэтому нужно использовать шаблоны, защиты и т.п. Потому что это сильно упрощает.
Ну конечно. Согласно тебе — меньше кода — больше возможности для ошибок. Больше кода — меньше ошибок. Что-то не то тут с логикой.
ОК>>И потом, новому человеку прийдется все равно разбираться что же делает твоя мега-функция прежде чем ее хоть как-то использовать. N>Отсюда возникает потребность сделать её интерфейс максимально читабельным и исключающим ошибки.
У нас видимо разное понимание читабельности.
N>>>Это достаточно глупая статья, в добавок человек не знаком с трудом классиков Каноничным примером (я про него слышал >10 лет назад) является типизация физических переменных, таким образом, что при операциях проверяется размерность.
ОК>>Ну почему глупая? Код ведь делает то что он должен делать с твоей точки зрения!
N>Глупая — потому что писал ламер.
Ну это не обоснование. Мое ответ что чувак придумал себе несуществующую проблему и борется с ней. Ты, я так понимаю, тоже борешься с такими проблемами но только другими методами.
N>>>Предпочту типизировать и стандартизировать, хотя и не до такого уровня.
ОК>>Предпочту послать два инта и не париться!
->> снизить читаемость и повысить вероятность глупых ошибок.
That's fucking gross! Ты меня читаешь? Ты не борись с вероятностью того что сделаешь глупые ошибки. Ты их просто не допускай в первую очередь. И тестируй, разумеется.
Это уже overkill и я смотрю у тебя мозг действительно обглодан всяким Александреску.
ОК>>>>От всего не застрахуешься. Вдруг мне завтра прийдет в голову сделать мемсет по случайным участкам памяти? В общем не надо доводить код до маразма. N>>>А не надо юзать мемсет И работа с памятью — это больной подход. С++ плох именно тем, что есть много способов выстрелить себе в ногу и специалист должен знать именно ту тропку и высокоуровневые методы при использовании которых выстрел в ногу исключён. Твоё предположение о мемсете — это низкоуровневость, и соответственно опасность (и неэффективность).
ОК>>Это я тебе привел просто радикальный пример который ты не понял. N>Я всё понял, этому примеру тоже сто лет в обед.
Ну так где защита от такой глупости? Слабо предоставить?
ОК>>Чтобы ты там не городил, это все можно обойти и тут ты ничего поделать не можешь. Другой пример неправильный каст и все твои проверки пойдут насмарку. N>Я расчитываю на то что с моим кодом будет работать программист
То есть ты считаешь что другой будет идиотом и не сможет передать параметры в правильном порядке?
N>С++ опасный язык, да.
Дело не в языке а руках.
ОК>>И если тебе так нужна эта безопасность то ты, скорее всего, выбрал не тот инструмент. Тебе надо в мэнэджд языки. N>Такой довод я тоже слышал. Но 1. менеджед языки не везде применимы (а там где применимы я их и юзаю), 2. на С++ можно и нужно писать безопасно, хотя можно опасно.
Ты не понял аргумента. Если ты так опасаешься что в плюсах можно выстрелить себе в ного, то кардинально смени вид деятельности. Перейди на .НЕТ например.
N>>>Это не книжные фразы (более того, я такого в книгах не встречал), это выведено из самого, что ни есть практичного опыта.
ОК>>Ну так начни писать книги! У тебя это хорошо получается! Звучит умно.
N>Я даже статьёй не могу разродиться, а ты — книги Не дави на больную тему
Упаси бог от еще одного ремарка!
N>>>Да, но к этому нужно стремиться (с поправками на предполагаемое время жизни продукта и т.п.)
ОК>>К этому как раз-таки не нужно стремиться.
N>Если предположить, что правило верно, то при разработке безопасность и архитектура выходит на первый план, так как они способны существенно облегчить поддержку и снизить совокупную стоимость.
Это оправдывание своего бангалорства в стиле "меня александреску в полнолуние покусал."
В большинстве ВУЗах не учат software engineering-у. Учат языкам и в мире С++ программистов есть убеждение что пока они все фичи не выучат и впихнут в реальный проект то они не будут себя чувствовать гуру.
В общем ситуация такова. Фишки знают но программировать нормально не умеют.
ОК>>>>Выше я привел ссылку на более наглядный пример когда такие страховки доходят до маразма. N>>>Оно маразм, только из-за отсутствия в С++ дешёвых инструментов для уникализации типа. Для переменных чуть сложнее счётчиков — я почти всегда типизирую (например в последнем проекте уникализировал uidы относящиеся к разным типам).
ОК>>Я говорю маразм и ты вроде тут согласен со мной. Только почему ты думаешь что твои страховки как-то отличаются от этого маразма? Или это потому что твой код это твой код а его код это его код? N>Нет, потому что он уникализировал счётчики, это спорный момент.
Спорный, не спорный. Проблема в первую очередь надуманная что до тебя не доходит и вряд ли когда дойдет.
N>>>Я сказал — проект. Значительная часть кода там моложе, но всё-равно довольно древняя. Особенно комы бесят, которые совершенно не к месту.
ОК>>Вот ты говоришь что комы там не к месту. Охотно верю. Только почему ты считаешь что твой последователь не будет говорить такого о твоих проверках, к примеру?
N>Комы не к месту по вполне объективным причинам (избыточные и кривые абстрагирования, они не используются по назначению, они увели от терминов предметной области). Необходимость типизации в сколько то сложных проектам — вполне объективна.
Субъективна, ты хотел сказать.
N>>>Я считаю виртуальное наследование антипаттерном, а случаи его применения явным симптомом проблем с архитектурой (создание универсальных всемогутеров). В остальном — нужно применять подходящие конструкции языка в нужном месте. И шаблоны, и RTTI, и объявление без реализации
ОК>>Вот ты говоришь универсальные всемогутеры. А почему твой код нельзя назвать универсальным всемчекером? По аналогии.
N>К сожалению — нельзя, но хотелось бы.
А-а-а... Я понимаю... Ты стараешься, стараешься, и так и не смог покрыть весь код всевозможными проверками и защитами?
ОК>>На счет шаблонов и RTTI я с тобой не согласен. Можно писать нормальный код без этого мракобесия с шаблонами N>В наше время мракобесие — это без шаблонов. Тебя без них даже на приличную работу не возьмут.
На счет работы я знаю но это никоим образом не аргумент. В C++ community, как я сказал уже выше, люди считают что пока не заучат все фишки то они не могут считать себя программистами. Ну и соответсвенно пихают и куда ни попадя. Страуструп, кстати, сам говорит что не нужно знать все из плюсов чтобы нормально программировать но только эти слова остались незамеченными в море деталей языка С++.
ОК>>и уж RTTI вообще точно не нужен. Не нужно тебе в ООП знать тип объекта. Вместо этого надо правильно создать иерархию (если уж она тебе так нужна) и задействовать виртуальные функции. N>Иерархия и виртуальные функции имеют определённую область применения, достаточно узкую, при грамотной разработке. Иерархия больше 2 уровней (если не считать технические моменты, типа внедрения счётчиков) это уже повод задуматься.
Повод задуматься когда видишь RTTI, плюсовский или самопальный.
ОК>>Хе-хе. То есть ты вместо того чтобы стандартный класс посылать по ссылке и возвращать ссылку на него решил задействовать другой вариант только потому что внутри они реализованны иначе? N>Есть часто встречающаяся ошибка, многие думают, что std::string это класс строки, хотя это класс-контейнер строки. При реальной работе с классом-строкой работать намного удобнее, к сожалению такого в stl нет.
Я не понял что ты тут хочешь сказать. Класс строки, контейнер строки — одна и та же фигня и если уж быть совсем точным то это контейнер кэрикторов. Только в чем у тебя проблема тут? То что накладно возвращать строки из функции? Но если следовать твоей логике, то ты также должен жаловаться что дорого возвращать вектор из функции (через return). Однако мне кажется ты все-таки не возвращаешь вектора из функции подобным образом?
ОК>>Имхо это неправильный подход. Используй класс правильно а не пытайся обойти возможные накладные расходы таким путем. Это, кстати, противоречит ООП; тебе не надо знать как внутри сделан класс. N>Я использую правильно
То-то ты сменил стандартную строку на МФЦшную.
ОК>>>>И даже абсолютное знание всех 100% языка != умению программировать и решать задачи. N>>>Само собой, нужно быть комплексным и язык знать, и уметь его применить с толком, и многое другое.
ОК>>Хе-хе. Я вижу твою логику. Пока ты не зазубришь стандарт, пока не прочтешь Страуструпа, Александреску, Саттера и Мейерса — ты просто сам себя не сможешь чувствовать С++ программистом. N>Стандарт я не зубрю, а без прочтения классиков (или их аналогов) — да, ты не можешь считаться грамотным программистом.
Кто такие (эти классики)? (на всякий случай, это стеб)
Прочитать стоит, конечно же, но также стоит и иметь свою голову на плечах. Кто сказал что нужно так программировать как говорят какие-то дяди?
N>>>Чего надуманного и сложного? Запись предельно компактна, протокол расширяем, а процесс контролируем.
ОК>>А тебе не приходит в голову что можно еще проще сделать?
N>Проще, видимо, нельзя. Всё что можно — сокрыто, всё что можно — автоматизировано, интерфейс отображает только суть.
Ох и не повезет кому-то поддерживать данное творение.
N>>>Там где нужна темплейтная функция — очевидно глупо обходиться без неё
ОК>>Ну это все от лукавого. Писали ведь программисты код без темплейтов и ничего. Не сомневаюсь что и без темплейтов в твоем случае можно обойтись.
N>Можно, но код при этом получится сложнее, разработка дольше и опаснее. Есть правило: проект может быть успешно выполнен даже плохими средствами. Средства только повышают вероятность успешного исхода.
Все что я тут вижу это средства ради средств а не для решения насущных задач.
ОК>>Вообще то о чем я тебе тут толкую называется over-engineering. Может слышал такой термин?
N>Слышал. Только это к теме не относится, так как ты предлагаешь недоинжиниринг.
Такого термина нету. Если задача решена, то она решена. Решил задачу меньшими жертвами — лучше. Наворотил сверх меры и надобности — хуже. Это и есть over-engineering.
BB>>>jazzer остался.
ОК>>Да джаззер, ремарк и сам топикстартер переусложняют свой код. На счет Кодта — хочется надеяться что человек понимает что можно использовать в реальном коде а что нет. K>Они все понимают.
Я так не думаю.
K>И ты не поверишь, но переусложнение кода только в голове. Мне кажется, на кажого из них влияет их специфика и, как следствие, они пишут вот такой вот код.
Не думаю. Они так мыслят и ставят себя в такие рамки (что без этого ну никак нельзя).
Я нечто подобное замечал за китайцами. Они привыкли мыслить сложно (иероглифы какие-то) и также и пишут код.
K>Думаю, что твои задачи сильно отличаются от их и поэтому тебе их код кажется переусложнением. Метафора — это как говорить на английском с руским акцентом, вроде и правильно, а что-то не то.
ОК>В большинстве ВУЗах не учат software engineering-у. Учат языкам и в мире С++ программистов есть убеждение что пока они все фичи не выучат и впихнут в реальный проект то они не будут себя чувствовать гуру.
ОК>В общем ситуация такова. Фишки знают но программировать нормально не умеют.
Кстати, у нашего каа-питона нашел пост. Там в самом низу пройдись по ссылке. Что думаешь о коде?
Это то что я выше сказал "фишки знают но программировать нормально не умеют." С питоном полностью согласен.
Надеюсь он не против что я кинул сюда эту ссылку. Если что не так, то заранее прошу прощения.
ОК>>Ну а у меня сложилось мнение прямо противоположное твоему. Кто из нас прав? K>Я прочитл ваш спор с Ником. По статье у меня сложилось мнение, что он больше концепт никий предлагал, а не какой-то рабочее решение.
То есть ты согласен что практическая ценность того творения равна нулю?
