Вопросы на внимательность, вполне обычные.

Но что в них раздражает, так это несоблюдение нотации.

С нормальными названиями классов, CDrinks, CMartini, CAnimal, CGroundHog, лично мне было бы легче сосредоточиться, а так как есть – здорово запутывает и отвлекает от основной задачи.

Здравствуйте, Sealcon190, Вы писали:

S>С нормальными названиями классов, CDrinks, CMartini, CAnimal, CGroundHog, лично мне было бы легче сосредоточиться, а так как есть – здорово запутывает и отвлекает от основной задачи.

Нормальными для кого? Для тебя? Им что нужно было спросить тебя какой coding style лично ты предпочитешь? Если неиспользование одного специфичного(из нескольких десятков) стайла напрягает, то это очень тревожный знак. На такие вещи стоит обращать внимания лишь когда встречается Drinks, CMartini, ground_hog одновременно.

Здравствуйте, Аноним, Вы писали:

А>Нормальными для кого?
Вроде как для M$ и её продуктов (ну там Win API, ATL, MFC и т. д...)...

Здравствуйте, Erop, Вы писали:

А>>Нормальными для кого?
E>Вроде как для M$ и её продуктов (ну там Win API, ATL, MFC и т. д...)...

"Нормальность" очень сомнительный и трудноопределяемый критерий. Я бы говорил, скорее, о стандартности, и рассматривал бы соответствующую или самую распространенную библиотеку

Здравствуйте, Dmi3S, Вы писали:

DS>"Нормальность" очень сомнительный и трудноопределяемый критерий. Я бы говорил, скорее, о стандартности, и рассматривал бы соответствующую или самую распространенную библиотеку

По-твоему это нормально – когда имена классов ничем не отличаются от имён объектов?

Здравствуйте, Аноним, Вы писали:

А>Нормальными для кого? Для тебя? Им что нужно было спросить тебя какой coding style лично ты предпочитешь?

Нет, разумеется, на собеседованиях вообще желательно называть классы martini, drink, а объекты СDrinks, CCocktail. Все переменные-члены классов пообзывать чем-нить вроде i, j, k, x, y. А переменные в функциях наоборот m_iter1, m_alcohol. Ещё и имена функциям придумать позабористее, чтоб на апишные были похожи.

А на вопрос соискателя чё за нах сказать: “нам что, нужно было спросить тебя какой кодинг-стайл ты предпочитаешь? Дык если тебя взять на работу – ты может ещё и документацию попросишь? Тревожный знак, братан, какой же ты после этого программист?”

Здравствуйте, Sealcon190, Вы писали:

S>А на вопрос соискателя чё за нах сказать: “нам что, нужно было спросить тебя какой кодинг-стайл ты предпочитаешь? Дык если тебя взять на работу – ты может ещё и документацию попросишь? Тревожный знак, братан, какой же ты после этого программист?”
Ты кодинг-стайл говном-то не подменяй. Если кодинг-стайл другой — это одно, а если вместо него то, что ты описал, то другое.

Здравствуйте, Sealcon190, Вы писали:

S>Здравствуйте, Dmi3S, Вы писали:

DS>>"Нормальность" очень сомнительный и трудноопределяемый критерий. Я бы говорил, скорее, о стандартности, и рассматривал бы соответствующую или самую распространенную библиотеку

S>По-твоему это нормально – когда имена классов ничем не отличаются от имён объектов?

Не знаю, что думает об этом http://rsdn.ru/Users/9585.aspx, но, на мой фзгляд, это вполне нормально. А у тебя есть какие-либо статистические данные подтверждающие, что в этом случае могут быть проблемы?

Кстати, при использовании camel casing, имена объектов скорее всего, будут выглядеть так "имяОбъекта", а емена классов так "ИмяКласса", т.е. разница будет и без всяких там префиксов.

Здравствуйте, Sealcon190, Вы писали:

S>По-твоему это нормально – когда имена классов ничем не отличаются от имён объектов?

Определение "нормальности" в студию. Если говорить о вкусах, то мне не составляет труда читать/писать в стандартном стиле.
Вообще же, приходилось видить разное и забавное: например, стандартный стиль + все имена полей классов с "m_", что по первости без улыбки читать трудно

Здравствуйте, Erop, Вы писали:

E>Вроде как для M$ и её продуктов (ну там Win API, ATL, MFC и т. д...)...
У кого-то из классиков было довольно убедительное объяснение по этому поводу.
С одной стороны когда создавался MFC C++ был еще на зачаточном уровне и пространства имён были только в проекте, с другой была масса C кода который пользователям хотелось переиспользовать, поэтому и ввели костыль в виде "C"-префикса (т.е. возможно у кого-нибудь в коде и встречается Button, но CButton — мало ввероятно). Поэтому префикс "C" следует считать зарезервированным за МС и никогда не использовать в своих классах (если Вы написали убер класс CImageButton а через пару лет МС добавила в MFC класс с таким же именем, угадайте кому придётся переписывать код .

Здравствуйте, Аноним, Вы писали:

А>если Вы написали убер класс CImageButton а через пару лет МС добавила в MFC класс с таким же именем, угадайте кому придётся переписывать код .

Тому, кто пользуется MFC?

Здравствуйте, Erop, Вы писали:

E>Тому, кто пользуется MFC?

Тому, кто не пользуется namespace-ами.

Здравствуйте, crable, Вы писали:

S>>По-твоему это нормально – когда имена классов ничем не отличаются от имён объектов?

C>Не знаю, что думает об этом http://rsdn.ru/Users/9585.aspx, но, на мой фзгляд, это вполне нормально. А у тебя есть какие-либо статистические данные подтверждающие, что в этом случае могут быть проблемы?

Ну проблемы — это сильно сказано.

Но если где-то есть класс drink, а потом вдруг появляется объект drinks, то мой взгляд начинает об него спотыкаться. Не сильно, но достаточно чтобы повлиять на концентрацию.

Хз, может это я просто такой чайник, а настоящим профи такие мелочи нипочём.

Но в любом случае зачем усложнять жизнь там где в этом нет необходимости?

Здравствуйте, <Аноним>, Вы писали:

А>Поэтому префикс "C" следует считать зарезервированным за МС и никогда не использовать в своих классах (если Вы написали убер класс CImageButton а через пару лет МС добавила в MFC класс с таким же именем, угадайте кому придётся переписывать код .

Вообще классный аргумент! Переименовать класс это ведь такая большая проблема!!!
А для писателей библиотек просто огромная проблема добавить приставку CMYLIB к классу
Давайте так, угадайте за 5 лет работы сколько раз мне требовалось переименовать класс т.к. он конфликтовал с другим?

Sealcon190, я поддержу тебя в этом вопросе, самого жутко расстраивает.
Приставки — это прекрасно! Почему их люди не используют повсеместно? Ну они это как то объясняют (ИМХО, им просто лень лишний раз жать баттоны)

Здравствуйте, zitz, Вы писали:

Z>А для писателей библиотек просто огромная проблема добавить приставку CMYLIB к классу
Такому бы писателю да кое-чего кое-куда огого как.

Z>Приставки — это прекрасно!
<нас всех тошнит>

Z>Почему их люди не используют повсеместно?
namespace это не модно?

Здравствуйте, Dmi3S, Вы писали:

DS>Здравствуйте, zitz, Вы писали:

Z>>А для писателей библиотек просто огромная проблема добавить приставку CMYLIB к классу
DS>Такому бы писателю да кое-чего кое-куда огого как.
Ну приставки — это конечно перебор. И если уж и писать приставку, то без "С", подобно wxWidgets с его wxString, wxButton,...
Ну и создателям Qt за их приставочку Q тоже получается надо кое-чего кое-куда

Z>>Приставки — это прекрасно!
DS><нас всех тошнит>
Не надо ля ля за всех.
Что плохого в приставках?
IMartini — сразу видно, что интерфейс
CMartini — а вот и класс нарисовался
а что такое Martini/martini? переменная, класс, пространство имён, функция или еще чего?

Z>>Почему их люди не используют повсеместно?
DS>namespace это не модно?
Приставки нужны не для уникальной идентификации типов.
Некоторые, например, рекомендуют указатели называть с приставкой "p" (pFirst, pNext,...) и члены классов с приставкой "m" (mInstance, mMember,...) и всё в этом духе. Эти все приставки не для уникальности же рекомендуются, а чтобы сразу видеть, что здесь указатель, а это вот приватный член класса используется. Так что namespace несколько из иной оперы и назначение у них другое.

DS>>Здравствуйте, zitz, Вы писали:

А>Ну и создателям Qt за их приставочку Q тоже получается надо кое-чего кое-куда

Z>>>Приставки — это прекрасно!
DS>><нас всех тошнит>
А>Не надо ля ля за всех.
boostShPtr2stdSet, кому хорошо?
А>Что плохого в приставках?
Приставки не нужны. Как и суффиксы.
А>IMartini — сразу видно, что интерфейс
Что это?
А>CMartini — а вот и класс нарисовался
Виртуальные функции с V, статические — c S, шаблоны — с Ш^WT, в названии так же отражать ограничения на принимаемые аргументы.
А>а что такое Martini/martini? переменная, класс, пространство имён, функция или еще чего?
А что такое mi?
Z>>>Почему их люди не используют повсеместно?
Потому что это даже не костыли.
DS>>namespace это не модно?
А>Приставки нужны не для уникальной идентификации типов.
Z>>А для писателей библиотек просто огромная проблема добавить приставку CMYLIB к классу
z>Так что namespace несколько из иной оперы и назначение у них другое.
Это что, случайная газификация естественного микроводоема?
А>Некоторые, например, рекомендуют указатели называть с приставкой "p" (pFirst, pNext,...) и члены классов с приставкой "m" (mInstance, mMember,...) и всё в этом духе.
"Некоторые" британские ученые, ога. Источники будем приводить?
A>Эти все приставки не для уникальности же рекомендуются, а чтобы сразу видеть, что здесь указатель, а это вот приватный член класса используется.
Если не видно, что это — указатель, а вот это — приватное поле, то, может, что-то не правильно в консерватории?

Здравствуйте, Dmi3S, Вы писали:

DS>boostShPtr2stdSet, кому хорошо?
Ну это конечно перебор. Я привел пример адекватных приставок wxWidgets'a. 1-2 символа не напряжно писать, но информативно. К тому же конфликты имён будут и с использованием пространств имён, ибо обычно в начале написали:
using namespace xxx;
using namespace yyy;
а дальше без явного указания пространств пошли использовать всё подряд. Но тут конечно компилятор спросит в конфликтных местах чего именно хотите и явно указать пространство потребует. Но конечно вопрос насколько это возможно при использовании таких крупных библиотек, ибо маловероятно использование строк из STL, если работаем с виджетами.

А>>IMartini — сразу видно, что интерфейс
DS>Что это?
Не знаете что такое интерфейс? Ну можно обозвать это абстрактным базовым классом с большой натяжкой и обозвать MartiniBase, только тут уже некрасивый суффикс вылазиет...
А>>CMartini — а вот и класс нарисовался
DS>Виртуальные функции с V, статические — c S, шаблоны — с Ш^WT, в названии так же отражать ограничения на принимаемые аргументы.
Ага. Забыли что-то еще про наследование. Обязательно в именах классов отражать от каких классов они унаследованы, как и зачем и обязательно до седьмого колена, чтобы далеко в исходники не лазить...
А>>а что такое Martini/martini? переменная, класс, пространство имён, функция или еще чего?
DS>А что такое mi?
это нота такая. ага.
z>>Так что namespace несколько из иной оперы и назначение у них другое.
DS>Это что, случайная газификация естественного микроводоема?
namespace нужны для избежания конфликта имён и для сбора отдельных запчастей во что-то напоминающее монолитную библиотеку. Приставки и суффиксы нужны чтобы показать who is who.
А>>Некоторые, например, рекомендуют указатели называть с приставкой "p" (pFirst, pNext,...) и члены классов с приставкой "m" (mInstance, mMember,...) и всё в этом духе.
DS>"Некоторые" британские ученые, ога. Источники будем приводить?
Ну скажем урезанная версия венгерской нотации без этих маниакальных nSize, bFlag из-за которых при смене типа переменной, придется менять её имя. Указатель на что-то другое если изменится, то корректировать их использование так и так придется и можно уж и переименовать попутно. Члены классов так же врядли чем-то другим станут. Всякие pcsz и т.п. огород городить перед именем переменной — это конечно перебор, но я этого и не предлагаю. Всё хорошо в меру
DS>Если не видно, что это — указатель, а вот это — приватное поле, то, может, что-то не правильно в консерватории?
Сейчас видно в вашем коде, а завтра в чужом непонятно что за переменная такая. К чему совершать лишние телодвижения типа "Go to Definition", с перескакиванием в другой файл, чтобы узнать что сие перед нами приватное поле, а не глобальная переменная? Современные IDE и примочки к ним конечно могут предоставить и более удобное определение, но наглядность — она и в африке наглядность.
Ну ладно еще с учетом развития в плюсах умных указателей и IDE можно забить на приставки к указателям и другим переменным вместе с полями класса, но как показать, что это именно интерфейс, а не класс? Коммент писать? Макросом добавлять псевдо-ключевое слово interface? Как по мне, так я лучше приставку I напишу. А потом у меня появляется класс Ivan и выглядит он теперь как интерфейс. Если на абстрактных классах реализовывать, а не интерфейсах, то всплывут суффиксы типа "Base" и "Impl".
Опять же если брать STL, то там даже классы с маленькой буквы нормально живут, но они там все на шаблонах, да и кто напишет что-то вроде: "string String" или "vector<int> Vector"?
А вот Query query вполне могут написать. Разница всего в один символ грозит возможностью опечаток с неожиданными текстами ошибок. Вместо: "неизвестный идентификатор" получим ошибку про отсутствие конструктора или еще чего в этом роде, а если перегружен оператор (), то Query("ы") вместо query("ы") (и наоборот), может к интересному результату привести.

Здравствуйте, Аноним, Вы писали:


А>Ну это конечно перебор. Я привел пример адекватных приставок wxWidgets'a.
приставки в популярных библиотеках вызваны суровой необходимостью баиндинга имен на C, что позволяет легко использовать эти библиотеки в других языках. По причине отсутствия namespaces в C, разработчики вынуждены вводить вот такие костыли, да. К C++ это имеет опосредованое отношение.
А>using namespace xxx;
А>using namespace yyy;
А>а дальше без явного указания пространств пошли использовать всё подряд.
using std::ostream;
typedef std::ostream default_stream;
подумайте над этим, перед тем как делать using на весь namespace.
А>Но тут конечно компилятор спросит в конфликтных местах чего именно хотите и явно указать пространство потребует. Но конечно вопрос насколько это возможно при использовании таких крупных библиотек, ибо маловероятно использование строк из STL, если работаем с виджетами.
Не понял смысла предложения.
А>Не знаете что такое интерфейс?
Если мы все еще говорим о C++, то единственное, что мне приходит в голову — это интерфейс класса. В это понятие включаются все публичные методы и поля класса, а так же часть свободных функций, работающих с экземплярами класса. В более расширенном понимании сюда относят и protected методы/поля.
А>Ну можно обозвать это абстрактным базовым классом с большой натяжкой и обозвать MartiniBase
Вы не поверите, но "абстрактный базовый класс" называется в C++ абстрактным базовым классом. Понятия "абстрактный базовый класс с большой натяжкой" это из какого-то другого языка. В котором, впрочем есть ключевое слово Interface.
А>Ага. Забыли что-то еще про наследование. Обязательно в именах классов отражать от каких классов они унаследованы, как и зачем и обязательно до седьмого колена, чтобы далеко в исходники не лазить...
Смотрю, вы меня хорошо поняли. Да, и в реальном проекте наследование до 7 колена как бэ намекает.
А>Сейчас видно в вашем коде, а завтра в чужом непонятно что за переменная такая.
Пойти и задать два простых вопроса. Что за переменная, и почему я не понимаю этого сразу.
А>К чему совершать лишние телодвижения типа "Go to Definition", с перескакиванием в другой файл, чтобы узнать что сие перед нами приватное поле, а не глобальная переменная?
А>Современные IDE и примочки к ним конечно могут предоставить и более удобное определение, но наглядность — она и в африке наглядность.
Узнаю что глобальная переменная -- опозорю на всю контору. Да, и при чем сдесь IDE и ваше незнание сочетания клавиши Ctrl-Tab? Давайте все же о предмете. Про наглядность -- полностью согласен.
А>Ну ладно еще с учетом развития в плюсах умных указателей и IDE
Нету в C++ IDE. Нету.
A>можно забить на приставки к указателям и другим переменным вместе с полями класса, но как показать, что это именно интерфейс, а не класс?
Да я вообще не понимаю, что за интерфейс такой.
А>Опять же если брать STL, то там даже классы с маленькой буквы нормально живут, но они там все на шаблонах, да и кто напишет что-то вроде: "string String" или "vector<int> Vector"?
Шаблоны, похоже, отменяют все правила, да? Хорошо, что boost тоже на стероид^Wшаблонах. А то вот бы я сейчас мучился.
А>А вот Query query вполне могут написать. Разница всего в один символ грозит возможностью опечаток с неожиданными текстами ошибок. Вместо: "неизвестный идентификатор" получим ошибку про отсутствие конструктора или еще чего в этом роде, а если перегружен оператор (), то Query("ы") вместо query("ы") (и наоборот), может к интересному результату привести.
Тяжела и неказиста жизнь простого программиста.

Здравствуйте, Dmi3S, Вы писали:

DS>Да я вообще не понимаю, что за интерфейс такой.
Ну COM с его IUnknown и т.п. суповым набором. интерфейс != абстрактный класс, а потому надо как-то отразить, что за неимением в плюсах "interface" мы это объявили классом, но всёже это является интерфейсом. Ну и использовать ООП подход на интерфеях можно не только для COM... Ну да ладно. Не будем в дебри не по теме заходить, а то сейчас начнется, что это не тру сишный подход и за этим на яву или шарп переходить надо
А>>Опять же если брать STL, то там даже классы с маленькой буквы нормально живут, но они там все на шаблонах, да и кто напишет что-то вроде: "string String" или "vector<int> Vector"?
DS>Шаблоны, похоже, отменяют все правила, да? Хорошо, что boost тоже на стероид^Wшаблонах. А то вот бы я сейчас мучился.
Не отменяют. Просто специфика классов из STL и работы с шаблонами в плюсах минимизируют возможность глупых ошибок от невнимательности. Если бы в STL были CString и CVector, мне бы это не мешало ни капельки. Ну а за неимением выбора, пришлось привыкать, что классы без приставок, да еще и с маленькой буквы.

Я просто не понимаю в чем недостаток той же приставки "С" у классов? Лишний символ писать надо и это напрягает? Или то, что это майкрософт любит использовать и когда-то возможно ваш класс может пересечься с классом из MFC? В общем мне интересно: что в этих приставках не так? Может я о каких-то их недостатках не догадываюсь? Я сейчас без иронии говорю. Просто, пока не поздно, надо отвыкать так классы называть и писать "нормально", если конечно это не Ваше субъективное ИМХО, что приставки — зло. Ну и опять же как нормально? Класс с большой буквы называть без приставок всяких или как в STL — с маленькой?
Если брать делфю, то там по стандартному набору классов видно, что рекомендуется писать приставку "T".
В шарпе без приставок всяких, хотя тот же майкрософт, который в плюсах пишет "С" (почему опять же? одумались со времен MFC и поняли, что приставка не нужна?).
Получается тогда, что надо и в плюсах ориентироваться на стандартную библиотеку STL в оформлении?

Здравствуйте, Аноним, Вы писали:

А>Ну да ладно. Не будем в дебри не по теме заходить, а то сейчас начнется, что это не тру сишный подход и за этим на яву или шарп переходить надо
Да-да, я к этому и клонил

А>Не отменяют. Просто специфика классов из STL и работы с шаблонами в плюсах минимизируют возможность глупых ошибок от невнимательности.
Да вы оптимист.

А>Я просто не понимаю в чем недостаток той же приставки "С" у классов? Лишний символ писать надо и это напрягает?
Ну, кстати, казалось бы старушку за 10 копеек, а ведь 10 старушек -- уже рубль (с)

А>Или то, что это майкрософт любит использовать и когда-то возможно ваш класс может пересечься с классом из MFC?
Я стараюсь не загрязнять global namespace без нужды.

A>В общем мне интересно: что в этих приставках не так?
Не нужны они. Ну сколько же нужно выпить, чтобы не отличить класс от экземпляра по контексту? Или что нужно покурить, чтобы написать так, чтобы было не понятно?

A>Может я о каких-то их недостатках не догадываюсь? Я сейчас без иронии говорю. Просто, пока не поздно, надо отвыкать так классы называть и писать "нормально", если конечно это не Ваше субъективное ИМХО, что приставки — зло.
Я не говорил, что это зло. Я говорил, что они не нужны.

A>Ну и опять же как нормально? Класс с большой буквы называть без приставок всяких или как в STL — с маленькой?
Да нет нормального. Как в проекте принято, так и надо писать. Если бы я начинал сейчас проект в одно лицо, то придерживался бы стандартного варианта. Наверное. Если пишите только под MS — ну возьмите их последний Internal Coding Guidelines, да и следуйте ему. Они там, правда требуют I в интерфейсах, от чего мне станет неприятно в C++. С другой стороны, если у вас в проекте некоторые абстрактные классы используются именно с целью фиксации public contract, и архитектуру проекта сложно описать, не используя термина Interface в java смысле, то тогда уже I вначале никого не покоробит.

А>В шарпе без приставок всяких, хотя тот же майкрософт, который в плюсах пишет "С" (почему опять же? одумались со времен MFC и поняли, что приставка не нужна?).
[:]|||[:], но по теме:

Посадили в клетку 5 обезьян. У них в клетке под потолком висит связка бананов, а под потолок ведет приставная лестница. Конечно, как только они бананы увидели, они тут же бросились к лестнице. Но не тут-то было! Их сбивает с ног мощная струя ледяной воды из брандспойта. Оправившись от шока, обезьяны снова идут на штурм. Но их опять обливают холодной водой! После нескольких попыток обезьяны бросили это дело и перестали подходить к лестнице.

Затем одну обезьяну убрали и посадили новую. Она (разумеется!) сразу полезла к бананам. Ее никто водой не обливал. Но остальные обезьяны набросились на нее и стащили с лестницы. И так несколько раз. «Новенькая» тоже смирилась и сидела спокойно.

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

Наступил момент, когда в клетке не сталось ни одной обезьяны, которую когда-то обливали ледяной водой. И что же? Очередную «новенькую» всё равно оттащили от лестницы!

Почему? Потому что так у них принято!

В MS, кстатии, от "m_" отказались. Не прошло и 15 лет.

А>Получается тогда, что надо и в плюсах ориентироваться на остандартную библиотеку STL в оформлении?
imho, лучше всего ориентироваться на текущий проект. Смена codestyling всегда напрягает людей, да и проект с перемешанными стилями смотрится неоднозначно.

Хотя, на самом деле, лучше взглянуть на содержание C++ Coding Standards. 100 важных тем. Ни одна не касается наименований. Nobody cares. Вот так-то.

Здравствуйте, Dmi3S, Вы писали:

Z>>Приставки — это прекрасно!
DS><нас всех тошнит>

Рад за вас, но это ваши проблемы.

Z>>Почему их люди не используют повсеместно?
DS>namespace это не модно?

Я чесно говоря так и не смог к ним привыкнуть. Зачем городить огород когда можно просто пару букв добавить в название?
Выглядят неймспейсы в коде ИМХО ужастно, типа
namespace::класс
короче куча визуального мусора
Если писать using, так от этого смысл этих неймспесов теряется. Ниже вы предлагаете так делать
using std::ostream;
typedef std::ostream default_stream;
Т.е. я везде где использую класс буду должен написать его псевдоним, да еще и помнить что этот псевдоним — это именно тот класс. Правильно?

DS>Ну сколько же нужно выпить, чтобы не отличить класс от экземпляра по контексту?

Я конечно понимаю что программирование это очень задорно и увлекательно, разбираться в различных контекстах, придумывать псевдонимы и прочие замечательные вещи — это так здорово! Но к сожалению в суровых реалиях, нужно код писать быстро, часто переписывать старые участки — и чем меньше времени на понимание потребуется тем лучше.
Да я пишу перед указателем p, перед членом класса m_, перед статическими переменными st_, перед названием переменной её тип b, dw, i, — потому что мне это удобно. А если тип поменялся — что само по себе событие требующее повышенной внимательности, я переименовываю переменную. С современными инструментами рефакторинга это не составляет вообще никаких проблем.

Здравствуйте, Dmi3S, Вы писали:

A>>В общем мне интересно: что в этих приставках не так?
DS>Не нужны они. Ну сколько же нужно выпить, чтобы не отличить класс от экземпляра по контексту? Или что нужно покурить, чтобы написать так, чтобы было не понятно?

foo()
{
    bar1( bar2() ); // bar -- это класс или функция? :shuffle: 
}

Здравствуйте, Erop, Вы писали:

E>

foo()
E>{
E>    bar1( bar2() ); // bar -- это класс или функция? :shuffle: 
E>}

Функтор?

Здравствуйте, zitz, Вы писали:

namespace Z { void put() { std::puts("
Z>Рад за вас, но это ваши проблемы.
"); }
Спасибо. Я не страдаю.

Z>Я чесно говоря так и не смог к ним привыкнуть.
Z::put();

Z>Зачем городить огород когда можно просто пару букв добавить в название?
Чтобы не добавлять пару букв в название.
Z>Выглядят неймспейсы в коде ИМХО ужастно, типа
Z>namespace::класс
Z>короче куча визуального мусора
using Z::put; put();

Z>Если писать using, так от этого смысл этих неймспесов теряется.
Говорите, это интересно.

Z>Ниже вы предлагаете так делать
Z>using std::ostream;
Z>typedef std::ostream default_stream;
Z>Т.е. я везде где использую класс буду должен написать его псевдоним, да еще и помнить что этот псевдоним — это именно тот класс. Правильно?
Нет. Это пример использования typedef в качестве 1. Импорта отдельного имени вместо всего пространства имен. 2. Зародыша traits.

DS>>Ну сколько же нужно выпить, чтобы не отличить класс от экземпляра по контексту?
Z>Я конечно понимаю что программирование это очень задорно и увлекательно, разбираться в различных контекстах, придумывать псевдонимы и прочие замечательные вещи — это так здорово!
Это не здорово. Это должностные обязанности. В любом языке есть тонкости. А тонкостей C++ хватит на десяток языков. Это не повод их использовать, но хотя бы раз понять их — обязательно.

Z>Но к сожалению в суровых реалиях, нужно код писать быстро, часто переписывать старые участки — и чем меньше времени на понимание потребуется тем лучше.
namespace { Z::put(); }
Частое переписывание старых участков вас не напрягает? В смысле, что что-то со старыми участками не то.

Z>Да я пишу перед указателем p, перед членом класса m_, перед статическими переменными st_, перед названием переменной её тип b, dw, i, — потому что мне это удобно.
namespace Z { put(); }
Я действительно не понимаю, чем это может помочь быстро разобраться в коде. Если перед вами дымятся последствия взрыва на макаронной фабрике, то что они с префиксами, что без — это все равно адский вырвиглаз. Если же соблюдены хотя бы элементарные сан-гигиенические нормы на локальность переменных, размеры и именования функций и т.д., то не думаю, что префиксы могут чем-то помочь.

Z>А если тип поменялся — что само по себе событие требующее повышенной внимательности, я переименовываю переменную.
Может, стоит включить все warnings, и компилятор сам все расскажет о подозрительных преобразованиях? Не доверяете?

Здравствуйте, Erop, Вы писали:

E>

foo()
E>{
E>    bar1( bar2() ); // bar -- это класс или функция? :shuffle: 
E>}

А как бы вы ответили на этот вопрос? Я даже не понимаю, о чем речь.

Здравствуйте, Dmi3S, Вы писали:

DS>А как бы вы ответили на этот вопрос? Я даже не понимаю, о чем речь.

Любой из двух...

Здравствуйте, zitz, Вы писали:



Z>>>Почему их люди не используют повсеместно?
DS>>namespace это не модно?

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

Что-то вроде этого

namespace Impl1
{
}
namespace Impl2
{
}
#ifdef ...
#define Impl Impl2
#endif

Impl::f(1);

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, Dmi3S, Вы писали:

DS>>А как бы вы ответили на этот вопрос? Я даже не понимаю, о чем речь.

E>Любой из двух...

bar1 и bar2 могут быть хоть typedef int. Я не про это. Я про то, что нету "bar" в исходном коде. Я его аж выделил. Ладно.
Чтобы так писать нужна сильная трава, я говорил об этом. Ну или злой умысел, что по умолчанию выключено.

Здравствуйте, Dmi3S, Вы писали:

DS>Чтобы так писать нужна сильная трава, я говорил об этом. Ну или злой умысел, что по умолчанию выключено.

Или немного другой образ мыслей, или плохая клава, или спешка...

Здравствуйте, D14, Вы писали:

D14>Что-то вроде этого

D14>

D14>namespace Impl1
D14>{
D14>}
D14>namespace Impl2
D14>{
D14>}
D14>#ifdef ...
D14>#define Impl Impl2
D14>#endif

D14>Impl::f(1);
D14>

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

Здравствуйте, Erop, Вы писали:

E>Или немного другой образ мыслей, или плохая клава, или спешка...

Плохому программисту клава мешает.

ЗЫ. Не примите на свой счет. Не могу удержаться от идиотской шутки.
ЗЫЫ. Про спешку не буду.

Здравствуйте, Dmi3S, Вы писали:


А>>Сейчас видно в вашем коде, а завтра в чужом непонятно что за переменная такая.
DS>Пойти и задать два простых вопроса. Что за переменная, и почему я не понимаю этого сразу.

Ого, а вы оптимист. Не приходилось поддерживать код N-цадтилетней давности? Который написал неизвестно кто? Или известно, но фиг у него спросишь, т.к. он уже лет несколько как уволился?

Здравствуйте, Draqon, Вы писали:

D>Ого, а вы оптимист. Не приходилось поддерживать код N-цадтилетней давности? Который написал неизвестно кто? Или известно, но фиг у него спросишь, т.к. он уже лет несколько как уволился?

В любом случае это WTF. Основных направлений всего два. Первое — это когда хорошо, ясно написано, но не понятна общая картина происходящего (можно встретить с вероятностью более, чем 0). А второе (с вероятностью over 95%) — непонятна локальная картина, причем в любом месте исходного кода. Обычно даже трудно вывести понятие локальность, т.к. поведение всех функций связано друг с другом с помощью 9001 глобальной переменной. Очень хочется переписать, но не дают. Сжать зубы, терпеть. Искать другую работу или стать героем. В любом случае — для меня это <censored>.
Не думаю, что кто-то из коллег назвал бы меня оптимистом. Просто в первом случае префиксы не нужны, а во втором — тоже не нужны.

Здравствуйте, Sealcon190, Вы писали:

S>С нормальными названиями классов, CDrinks, CMartini, CAnimal, CGroundHog, лично мне было бы легче сосредоточиться, а так как есть – здорово запутывает и отвлекает от основной задачи.

Иногда в одном и том же проекте используются, например, Boost (с STL-way стилем), WTL (с MFC-way стилем), ну и десяток всячеких libastralов. Как же можно работать в таких проектах!?

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, Dmi3S, Вы писали:

A>>>В общем мне интересно: что в этих приставках не так?
DS>>Не нужны они. Ну сколько же нужно выпить, чтобы не отличить класс от экземпляра по контексту? Или что нужно покурить, чтобы написать так, чтобы было не понятно?

E>

foo()
E>{
E>    bar1( bar2() ); // bar -- это класс или функция? :shuffle: 
E>}

А не всё-ли равно? Тем более что в реальном коде будет скорее всего что-то вроде

drink( get_beverage() );

или

drink( martini() );

и уже вполне понятно, что get_beverage это функция, а martini класс, иначе есть большая вероятность, что код написан абы как и наличие всяких там префиксов и суффиксов всё равно не поможет, разве не так?

Здравствуйте, crable, Вы писали:


C>

C>drink( martini() );
C>

C>и уже вполне понятно, что get_beverage это функция, а martini класс, иначе есть большая вероятность, что код написан абы как и наличие всяких там префиксов и суффиксов всё равно не поможет, разве не так?

Не так. Процитированный код -- это не обязательно вызов кода в C++ Это может быть объявлением функции martini, возвращающей drink и не имеющей аргументов...

Здравствуйте, Alexander G, Вы писали:

S>>С нормальными названиями классов, CDrinks, CMartini, CAnimal, CGroundHog, лично мне было бы легче сосредоточиться, а так как есть – здорово запутывает и отвлекает от основной задачи.

AG>Иногда в одном и том же проекте используются, например, Boost (с STL-way стилем), WTL (с MFC-way стилем), ну и десяток всячеких libastralов. Как же можно работать в таких проектах!?

Если не использовать using, то просто дописываете std:: или boost:: — это сразу видно, что код от туда
Над другими библиотеками я делаю обёртки, чтобы минимизировать количество "плохого" кода.
В общем всё от ситуации зависит

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, crable, Вы писали:


C>>

C>>drink( martini() );
C>>

C>>и уже вполне понятно, что get_beverage это функция, а martini класс, иначе есть большая вероятность, что код написан абы как и наличие всяких там префиксов и суффиксов всё равно не поможет, разве не так?

E>Не так. Процитированный код -- это не обязательно вызов кода в C++ Это может быть объявлением функции martini, возвращающей drink и не имеющей аргументов...

Вопрос относился только к выделенной части. Чтобы этот код стал объявлением функции нужно, чтобы drink был именем типа (что в принципе не так страшно, но, пожалуй, лишет нас возможности дать подходящее имя функции 'пить'), но, в данном случае, непреднамеренно объявить функцию невозможно, а специально называть функцию 'martini' уже ненормально. Вообще, если кто-то написал код, в котором это дейсвительно объявление функции и это сошло ему с рук, то что могло помешать этому человеку начхать на все эти суффиксы/префиксы (если они используются) и написать так

Drink( CMaritini() );

Здравствуйте, crable, Вы писали:

C>...то что могло помешать этому человеку начхать на все эти суффиксы/префиксы (если они используются) и написать так
C>

C>Drink( CMaritini() );
C>

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

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, crable, Вы писали:

C>>...то что могло помешать этому человеку начхать на все эти суффиксы/префиксы (если они используются) и написать так
C>>

C>>Drink( CMaritini() );
C>>

E>При просмотре кода, в этом случае видно, что тут скорее всего ошибка...

Какя же тут ошибка, по виду это вызов функции Drink с временным объектом класса CMartini в качестве аргумента. То, что Drink не функция, а тип, а CMartini не класс а функция отсюда не видно. Всё тоже самое, что и в случае с

drink( martini() );

Здравствуйте, zitz, Вы писали:

Z>Да я пишу перед указателем p, перед членом класса m_, перед статическими переменными st_, перед названием переменной её тип b, dw, i, — потому что мне это удобно.
А где конкретный тип переменной играет значение? Обычно компилятор впоне справляется с провверкой типизации, а для прикладного приложения в подавляющем большинстве случаев не важно является ли переменная типа dword или int.

Я бы предпочёл видеть в качестве названия переменной isAlcohilicDrink нежели bFlag и numberOfIceCubesInDrink чем iIce. Одно кончено не запрещает другого, просто на мой взгляд нормальное название переменной играет гораздо большую роль чем использование префиксов, а мой оптыт подсказывает что префиксы чаcто используются именно с переменными типа bNum, где без них вообще крышу сносит.

Здравствуйте, zitz, Вы писали:

Z>Здравствуйте, Alexander G, Вы писали:

S>>>С нормальными названиями классов, CDrinks, CMartini, CAnimal, CGroundHog, лично мне было бы легче сосредоточиться, а так как есть – здорово запутывает и отвлекает от основной задачи.

AG>>Иногда в одном и том же проекте используются, например, Boost (с STL-way стилем), WTL (с MFC-way стилем), ну и десяток всячеких libastralов. Как же можно работать в таких проектах!?

Z>Если не использовать using, то просто дописываете std:: или boost:: — это сразу видно, что код от туда

Со спиритом без using слишком мрачно. А, кроме того, префикс boost не изменит соглашений о вызовах в boost. И свой код, реализующий какой-либо бустовский интерфейс будет тоже содержать всякие void intrusive_ptr_add_ref(T*) и T& it::dereference(). Смешения стилей не избежать.

Z>Над другими библиотеками я делаю обёртки, чтобы минимизировать количество "плохого" кода.

Не вегда целесообразно это.

Здравствуйте, Erop, Вы писали:

foo()
{
    bar1( bar2() ); // bar -- это класс или функция? :shuffle: 
}

Так ли это важно? Сегодня класс, завтра функция.

—Это борщ или помои? — спрашивает возмущенный посетитель столовой.
—А вы что, не можете сами определить?
—Нет!
—Так какая вам разница? — равнодушно отвечает раздатчица.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Erop, Вы писали:

А>

foo()
А>{
А>    bar1( bar2() ); // bar -- это класс или функция? :shuffle: 
А>}

А>Так ли это важно? Сегодня класс, завтра функция.

Послезавтра макрос...

Здравствуйте, crable, Вы писали:

C>Какя же тут ошибка, по виду это вызов функции Drink с временным объектом класса CMartini в качестве аргумента. То, что Drink не функция, а тип, а CMartini не класс а функция отсюда не видно. Всё тоже самое, что и в случае с
C>

C>drink( martini() );
C>

Ну так, IMHO, это и показывает полезность префиксов такого рода...

Здравствуйте, Alexander G, Вы писали:

AG>Смешения стилей не избежать.
Z>>Над другими библиотеками я делаю обёртки, чтобы минимизировать количество "плохого" кода.
AG>Не вегда целесообразно это.

Ну да. Тут главное без фанатизма
Если проект предпологается большой, требующей постоянной поддержки — то лучше один раз помучатся Потраченное время окупится.
Я так и написал:
Z>>В общем всё от ситуации зависит

Здравствуйте, <Аноним>, Вы писали:

А>А где конкретный тип переменной играет значение? Обычно компилятор впоне справляется с провверкой типизации, а для прикладного приложения в подавляющем большинстве случаев не важно является ли переменная типа dword или int.

Мы же код оформляем не для компилятора
Всё это становится важным в момент дописывания кода.

А>Я бы предпочёл видеть в качестве названия переменной isAlcohilicDrink нежели bFlag и numberOfIceCubesInDrink чем iIce. Одно кончено не запрещает другого

Естественно нормальное название гораздо лучше, чем приставка+не_нормальное. Эти вещи сравнивать нельзя, одно дополняет другое.

Здравствуйте, Аноним, Вы писали:

А>>Так ли это важно? Сегодня класс, завтра функция.

А>Послезавтра макрос...

А хоть бы и макрос.

GetSystemInfo, GetVersionEx, GetProcAddress, CreateIconIndirect, CreateFontIndirect — здесь есть и макросы и функции.

Здравствуйте, zitz, Вы писали:

Z>Мы же код оформляем не для компилятора
Z>Естественно нормальное название гораздо лучше, чем приставка+не_нормальное. Эти вещи сравнивать нельзя, одно дополняет другое.
Так какой от этого бенефит для обычного смертного? Какая разница numberOfIceCubesInDrink типа int или dword? И не предлагайте туда присвоить -1, отрицательного количества льда не бывает. Где-то это возможно и надо, если например надо биты считать, но в прикладном программировании имхо это скорее исключение чем правило.

При чём, ни разу не видел чтобы делали префиксы в стиле myclassItem, а вот и целыми и указателями сплошь и рядом. Это на тот случай если MS решит включить этот кусок кода в винду и он там органично смотрелся? Ещё бывают хитрые typedef-ы типа std::string::size_type, не называть же переменную sstIndex.

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, crable, Вы писали:

C>>Какя же тут ошибка, по виду это вызов функции Drink с временным объектом класса CMartini в качестве аргумента. То, что Drink не функция, а тип, а CMartini не класс а функция отсюда не видно. Всё тоже самое, что и в случае с
C>>

C>>drink( martini() );
C>>

E>Ну так, IMHO, это и показывает полезность префиксов такого рода...

Так если никакой разницы, в чём полезность-то?

Здравствуйте, crable, Вы писали:

E>>Ну так, IMHO, это и показывает полезность префиксов такого рода...
C>Так если никакой разницы, в чём полезность-то?

Ну я не знаю что и как ты понимаешь, а мне вот очевидно

    Используешь нотацию => подозрительные места видно
    Не используешь => подозрительные места не видно

IMHO, ты сам это показал довольно убедительно...

Здравствуйте, Sealcon190, Вы писали:

S>С нормальными названиями классов, CDrinks, CMartini, CAnimal, CGroundHog, лично мне было бы легче сосредоточиться, а так как есть – здорово запутывает и отвлекает от основной задачи.

Я когда развлекаюсь программированием чисто для себя вечерами и по выходным, люблю такую нотацию, что типы обозначаю суффиксом _t а данные-члены префиксом m_. И ещё я ненавижу большие буквы Поэтому alcohol_t martini; martini.m_degree = 15;

Но когда выходные кончаются и я выхожу на работу я всё делаю в соответствии с принятым там стилем кодинга. И там для меня не составит труда написать: CAlcohol Martini; Martini.degree_ = 15;

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

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

Здравствуйте, <Аноним>, Вы писали:

А>Так какой от этого бенефит для обычного смертного?

Для вас похоже разницы нет. Может вы переросли это, я нет.
Для меня огромное значение имеет информация которую я могу окинуть взглядом и чем больше она тем лучше. Мне нужно знать когда я дописываю код, член это класса передо мною или нет, переполнится тип или нет, может туда отрицательное значение попасть или нет, банально строка передо мной, массив, число или указатель и так далее, т.е. еще раз:
Всё это становится важным в момент дописывания кода.
Возможно вы делаете сразу идеальную расширяемую архитиктору, код пишите без ошибок и высокой степени абстракции, возможно вы достигли дао программирования и вам всё это не требуется — это прекрасно.
А мне это очень помогает каждый день, пока особых минусов не заметил.
m_p_arrCurrTask — указатель на массив текущих задач, это член класса, значит будет использован за пределами функции которую я редактирую, туда ноль может попасть, нужно проверку делать перед использованием и т.д. Т.е. для меня это большой пласт информации которую я получил только взглянув на переменную.
К классу дописываю C — т.к. для меня важно отличать класс от функции моментально, виртуальным функциям которые вызываются "самостоятельно" при каком то событии, делаю приставку On и так далее. В общем применение приставок довольно обширно.

А>При чём, ни разу не видел чтобы делали префиксы в стиле myclassItem, а вот и целыми и указателями сплошь и рядом.

Я пишу (только не такие длинные и в тех случаях что мне нужно)

А>Ещё бывают хитрые typedef-ы типа std::string::size_type, не называть же переменную sstIndex.

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

Да и вообще каким смыслом нагружать приставку это ваше дело, главное чтобы везде одинаково было. Можно использовать приставку чтобы указать тип (если это важно), можно использовать приставку чтобы указать что это исходящий например параметр outVar (если это важно), можно чтобы указать что это массив arrNumbers (если это важно), можно даже так blobValue. Всё зависит от необходимости, на что следуюет обратить внимание, как с этим проще работать. Можно принципиально не использовать приставки... только зачем?

Здравствуйте, <Аноним>, Вы писали:

А>Так какой от этого бенефит для обычного смертного? Какая разница numberOfIceCubesInDrink типа int или dword? И не предлагайте туда присвоить -1, отрицательного количества льда не бывает. Где-то это возможно и надо, если например надо биты считать, но в прикладном программировании имхо это скорее исключение чем правило.

dw это взят мною "свежак" из последнего кода, там очень важно это dw или dwl или w
Если важен знак то ui или i.
Я же не говорю что нужно повсеместно тип переменной дописывать. Случаи разные бывают
Обычно хватает приставки которая говорит что внутри — число, строка, булево значение.
В приведенном вами примере numberOfIceCubesInDrink = nIceCubesInDrink, для меня это равнозначно. n — это number of, p — это pointer to, m_ — member of

Здравствуйте, zitz, Вы писали:

Да я, собсвтенно сам использую префиксы m_ и g_ даже если подсветка настроена — дифы потом удобнее просматривать.

Z>m_p_arrCurrTask — указатель на массив текущих задач
Меня конкретный тип волнует не так часто. Я бы назвал m_currentTaskList — сегодня это указатель на массив, завтра умный указатель на вектор, после завтра может быть вообще полноценный объект. Если в коде перепутать '.' с '->', то код просто не будет компилироваться.

Z>туда ноль может попасть, нужно проверку делать перед использованием и т.д.
Согласен, в этом случае приставка p действительно имеет смысл.

Z>Да и вообще каким смыслом нагружать приставку это ваше дело, главное чтобы везде одинаково было. Можно использовать приставку чтобы указать тип (если это важно), можно использовать приставку чтобы указать что это исходящий например параметр outVar (если это важно), можно чтобы указать что это массив arrNumbers (если это важно), можно даже так blobValue. Всё зависит от необходимости, на что следуюет обратить внимание, как с этим проще работать. Можно принципиально не использовать приставки... только зачем?
На мой взгляд приставки в большинстве случаев несут на порядок меньше информации чем остальное имя, с другой стороны именно остальным именем в С/C++ гораздо чаще пренебрегают (видимо UNIX культура даёт о себе знать). На заре карьеры мне повезло работать с замечательным промышленным кодом возраста > 15 лет, содержаищим имена переменных вида bufferSizeInBytes и taskDelayInMilliseconds после которых от имён типа dwTimeout меня передёргивает — каждый раз нужно лезть или в исходный код или в случае его отсутствия в документацию чтобы понять в чём этот таймаут определяется в этом месте. И я не думаю что за всё время существования кому-ниблудь на планете захотелось присвоить в таймаут значение > 2x10^9. На самом деле при "нормальном" имени в том или ином виде информация о типе часто присутствует, например isEmpty или hasTasks, но в отличие от приставок она более человечная что ли. С одной стороны это увеличивает абстракцию, с другой уменьшает знание о конкретном типе.

Здравствуйте, zitz, Вы писали:

Z>Я же не говорю что нужно повсеместно тип переменной дописывать. Случаи разные бывают
Именно

Z> nIceCubesInDrink
Nice, very nice cubes

Здравствуйте, zitz, Вы писали:

Z>Здравствуйте, <Аноним>, Вы писали:

А>>Так какой от этого бенефит для обычного смертного? Какая разница numberOfIceCubesInDrink типа int или dword? И не предлагайте туда присвоить -1, отрицательного количества льда не бывает. Где-то это возможно и надо, если например надо биты считать, но в прикладном программировании имхо это скорее исключение чем правило.

Z>dw это взят мною "свежак" из последнего кода, там очень важно это dw или dwl или w
Z>Если важен знак то ui или i.
Z>Я же не говорю что нужно повсеместно тип переменной дописывать. Случаи разные бывают
Z>Обычно хватает приставки которая говорит что внутри — число, строка, булево значение.
Z>В приведенном вами примере numberOfIceCubesInDrink = nIceCubesInDrink, для меня это равнозначно. n — это number of, p — это pointer to, m_ — member of

Зачем столько сложностей? современные IDE имеют семантическую подсветку синтаксиса, там глобальные — локальные — статические мемберы очень наглядно выделяются цветом. А тип объекта узнается во всплывающем попап окне, просто при наведении мышью на переменную.

Здравствуйте, catBasilio, Вы писали:

B>Зачем столько сложностей? современные IDE имеют семантическую подсветку синтаксиса, там глобальные — локальные — статические мемберы очень наглядно выделяются цветом. А тип объекта узнается во всплывающем попап окне, просто при наведении мышью на переменную.

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

Здравствуйте, Tilir, Вы писали:

T>Я когда развлекаюсь программированием чисто для себя вечерами и по выходным, люблю такую нотацию, что типы обозначаю суффиксом _t а данные-члены префиксом m_. И ещё я ненавижу большие буквы Поэтому alcohol_t martini; martini.m_degree = 15;

Меня вот слегка коробит от martini.m_degree = 15. Всё время кажется, что "m_*" — это что-то личное, которое нельзя вот так вот "=15" Другое дело martini.set_degree(15) или martini.degree = 15. То есть, хочется, чтобы запись выглядела ближе к естественному языку. Но аксессоры писать лень(тем более, если это просто get-set), поэтому чаще склоняюсь к martini.degree = 15. Хотя согласен, в этом случае, даже если это просто struct martini { unsigned degree; }, возможны проколы, чего стоит martini::martini(unsigned degreee) : degreee(degreee) {} Но это уже немного не про то...

Здравствуйте, sokel, Вы писали:

S> чего стоит martini::martini(unsigned degreee) : degreee(degreee) {}

Это как бы ill-formed, со всеми вытекающими.

Здравствуйте, Dmi3S, Вы писали:

S>> чего стоит martini::martini(unsigned degreee) : degreee(degreee) {}
DS>Это как бы ill-formed, со всеми вытекающими.
Почему?

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, Dmi3S, Вы писали:

S>>> чего стоит martini::martini(unsigned degreee) : degreee(degreee) {}
DS>>Это как бы ill-formed, со всеми вытекающими.
E>Почему?

 : degreee(degreee)

Инициализация неизвестно чего. Нет такого поля в классе.