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

можно мне цитату из стандарта, а то что-то я подзабыл, что там конкретно написанно?

  это поначалу так думается. После второй-третьей перекройки исходника вдоль и поперёк начинаешь осознавать обратное 

Программа пишется не один раз. А хорошая программа - далеко не один раз.

ну если это так, то никого не смущает, тот факт, что придется менять переменную m_count на нечто вроде iterator? всех только волнует, что нужно менять m_count++ на ++m_count? и то спорно, примеров пока так никто и не привел.. кто-то "блеснул стилем" и понеслась это круто, а это не круто.. только доказательства какие-то неубедительные..

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

Добавлено @ 04:14
и еще мне нравится забота о компиляторе, несчастненьком, давайте будем все делать за него.. ему молоко за вредность давать нужно.. 

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

Это сообщение отредактировал(а) fish9370 - 18.11.2007, 04:23

Это не совсем верно. В структуре все члены по умолчанию публичные. Чтобы их сделать приватными, нужно это явно указать. А в классе, наоборот, все члены по умолчанию приватные. Чтобы они были публичными, нужно это специально указать.

А больше, действительно, отличий нет.

В Вашем случае, чтобы работало, надо написать:



Здесь метка public: делает всё нижеследующего публичным, как в структуре.

Собственно, без public/private инкапсуляция, как идея, становится неполной. По правилам инкапсулирования, Вы должны пометить private всё то, чем "не положено" пользоваться извне. В результате класс станет "чёрным ящиком", пользоваться которым можно только через небольшое число public членов. Залезть в "чёрный ящик" в обход предусмотренного нельзя, это его private зона.

Добавлено @ 07:10

Мне тоже кажется, что никакой. Но я сам помню, действительно, что начиная с какого-то времени мне стало нравиться использовать префиксную форму. Правда, только в цикле for, а в данном случае я бы тоже написал постфиксно.

Добавлено @ 07:18

Наоборот! В 12 как раз верится. Вот в 5 я бы не поверил. А 12 лет назад у нас не было даже компьютерных факультетов, а, может, и компьютеров (я уже забыл). Все учились самоучками, а самоучка отличается тем, что в его навыках всегда присутствуют вот такие вот "странности". Вполне можно поверить, что он 12 лет успешно использовал struct в крупных проектах.


Это сообщение отредактировал(а) Dims - 18.11.2007, 07:19

  
Dims (и не только), неужели Вы всерьёз полагаете, что человек с таким ником, знающий слово инкапсуляция, не в состоянии разобраться в вопросе, который он задал? Не стоит воспринимать всё так уж буквально.   И кстати, непонятно, как я ухитрился примерно 2 раза по 12 лет назад поступить на компьютерный факультет, когда их ещё не было?  ВМиК МГУ появился в 1970г, хотя в "моё время" С++ не изучали.

Нафлудили то сколько... 0_о

fish9370, тут дело больше не в "понимаю что происходит"/"не понимаю"/"заменю на итератор"/"не заменю", а в рефлексе.
Если ты всегда используешь пре*кремент, и только когда нужно(реально нужно), пост*кремент, то никогда у тебя никаких проблем не возникнет .
Это тоже самое, что рефлекс писать const, писать explicit у конструкторов и подобные мелочи от которых "разницы" нет.

Добавлено через 3 минуты и 43 секунды

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

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

Добавлено @ 11:17

для меня лично человек будет выглядеть более знающим (по крайней мере при первом знакомстве с его кодом), если он напишет ++count, а не count++ в случае если оба варианта в данном контексте равносильны
кроме того, вопрос спорный, что выглядит более логичным
по мне так эти два варианта оба логичны
я еще раз повторяю, тут вопрос в стиле
как говорится, покажи мне свой код, и я скажу кто ты   

Это сообщение отредактировал(а) MAKCim - 18.11.2007, 11:37

Насчёт заботы о компиляторе:
c-cast vs c++-cast
void * vs T *
assignment vs constructor
уже упомянутое T vs const T
int vs enumeration
manual resource managment vs RAII
exception unsafety vs exception safety
Список можно долго продолжать.
Несмотря на то, что, по сути, для "X vs Y" результат будет одинаковым как при использовании X, так и Y, то что во втором "столбце" должно быть как минимум привычкой, а по хорошему - рефлексами, а при использовании конструкций из первого "столбца" внутри должен срабатывать громогласный alarm.

приму к сведению..

ППКС.

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

0_o.
Я понимаю, что не всегда удаётся выдерживать стиль полностью, но, тот короткий список, что я привёл - IMHO, может "не всегда удаваться" только в случае жесткого(очень жесткого) навязывания этого какими-либо внешними факторами, на которые ты никак не можешь повлиять(габаритная, криво спроектированная библиотека, написание wrapper'а к которой - большая потеря времени; начальство, навязывающее некоторый стиль, не соответствующий твоему идеалу и т.п.), но, даже в таких случаях такие места очень просто локализовать, т.о. исключив распространения плохого стиля повсеместно в коде...

Только не в отношении


А это


вообще непонятно что такое.

Это сообщение отредактировал(а) UnrealMan - 19.11.2007, 02:38

Почему?
Где хороши c-cast'ы?
Чем хорошо не делать переменную константной, если ей незачем меняться?



vs


Добавлено через 37 секунд
Пример с цветами конечно неудачный(цвета как раз лучше представлять в виде машинного слова), но, если заменить на кошек, собак и утюги, то будет самое то .

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

Там, где смысл преобразования очевиден и один вид преобразования никак не может быть спутан с другим. Например, если нужно произвести дробное деление, имея две целочисленные величины:

int x, y;
....
double result = (double)x/y;

static_cast здесь не имеет никаких преимуществ. Наоборот, поскольку он занимает гораздо больше места, его присутствие только ухудшит читаемость кода. Приведение в функциональной нотации (которое всё-таки относится к C++-cast) - это почти то же самое, что C-cast.


Дилемма в том, что не всегда точно известно, будет ли переменная меняться. Делая переменную неконстантной, мы оставляем пространство для манёвра - читай делаем код сопровождаемым. Кроме того, const не всегда способствует читаемости, поскольку опять же удлиняет и нагромождает код. Поэтому надобность по умолчанию ("на уровне рефлексов") всюду пичкать const как минимум спорна. "Незачем меняться" - это слабый аргумент для того, чтобы делать саму переменную константной (не хочешь менять - не меняй и всё). Вот если объект обязан быть неизменным в пределах достаточно большой области видимости, тогда другое дело.


Неудачное - это название сравнения "int vs enumeration".