Здравствуйте, superman, Вы писали:
S>хм.. чисто ради любопытства, а что ты об ссылках думаеш?
Первое мое знакомство со ссылками состоялось в глубоком детстве, когда я в школе проходил рассказ про В.И.Ленина, который в ссылке прятал революционные книжки от жандармов. Но это высший пилотаж. Я до сих пор не понимаю, как можно спрятать в ссылке революционные книжки. И не смог бы ответить на такой вопрос на собеседовании.
А так, вообще, чего о них думать? Ссылки — они и есть ссылки. Одна из конструкций языка, временами удобная.
Здравствуйте, elcste, Вы писали:
E>Проблема этого кода в том, что он ill-formed (с первого беглого взгляда бросается в глаза void main).
Вот любопытно: чего бОльшая часть народу цепляется именно к несчастному void main () тогда как реально критичные ошибки опускаются "на потом"?
E> Как все это сделать правильно? Да очень просто: int main() {}
Занудство!
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Sergey, Вы писали:
S>а у него в подкорке уже было проштамповано, что по умолчанию надо выбирать первый вариант.
ААААА!!!! Все пропало!!! А я списки пользую только тогда когда без них никак не написать
S> Чтобы он не думал
Программист, который не думает должен быть утилизирован, ИМХО
S> что писать, i++ или ++i, а первый вариант выбирал бы только в том случае, если ему в данном куске кода действительно нужно знать, что было в i до инкремента. А не писал по привычке i++. Привычка должна быть другая — писать по умолчанию ++i.
У меня для POD типов при наличии нормального компилера привычка писать постфиксный вариант как более удобный.
S> Чтобы человек не забывал писать explicit, определив в классе конструктор конверсии. Чтобы он не писал код вда: S>Чтобы написав в деструкторе delete, не забывал запретить (или определить) у класса конструктор копирования и оператор присваивания.
Ну, тут претензий никаких... Вопрос "чистоплотности" кода..
Скажите дохтур, я обречен?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
E>>Проблема этого кода в том, что он ill-formed (с первого беглого взгляда бросается в глаза void main). CC>Вот любопытно: чего бОльшая часть народу цепляется именно к несчастному void main () тогда как реально критичные ошибки опускаются "на потом"?
Так ведь это первое, что бросается в глаза. Зачем смотреть на остальное, если уже есть ответ?
E>> Как все это сделать правильно? Да очень просто: int main() {} CC>Занудство!
Занудство, да. А что Вы предлагаете? Считать ошибки? Так их насчитать можно бесконечно много — никто же не знает, что этот код должен был делать по замыслам его автора. Телепаты в отпуске, ага.
Здравствуйте, elcste, Вы писали:
Да очень просто: int main() {} (со второго беглого взгляда видно, что никакого observable behavior тут и быть не могло).
Или хотя бы #define void int
По-моему, изящно получилось. Это вам не ссылки инициализировать. Так программы писать, чтобы они при этом не глючили — вот настоящее мастерство, и сразу видна старая школа!
Здравствуйте, elcste, Вы писали:
E>>>Проблема этого кода в том, что он ill-formed (с первого беглого взгляда бросается в глаза void main). CC>>Вот любопытно: чего бОльшая часть народу цепляется именно к несчастному void main () тогда как реально критичные ошибки опускаются "на потом"? E>Так ведь это первое, что бросается в глаза. Зачем смотреть на остальное, если уже есть ответ?
Ответ неправильный кста. Код хреновый не потому что void main () — вполне может быть что код писан был под VC6
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, elcste, Вы писали:
E>>Проблема этого кода в том, что он ill-formed (с первого беглого взгляда бросается в глаза void main). CC>Вот любопытно: чего бОльшая часть народу цепляется именно к несчастному void main () тогда как реально критичные ошибки опускаются "на потом"?
А я, когда увидел код, прицепился к delete i и невиртуальному деструктору... только потом сообразил, что в коде ещё и main есть
Здравствуйте, FDSC, Вы писали:
FDS>Ну дак вы же после ссылки уже отправите, до констант даже не дойдёт...
Там где я собеседовал, был некоторый минимум вопросов который задавался всегда, после него уже принималось решение о целесообразности продолжения.
так что после ссылки был бы еще один шанс.
ну а с константами вроде все правильно, сonst метод не может модифицировать объект за исключением грубой силы типа const_cast<A*>(this) или совершенно честных mutable полей ...
Здравствуйте, pavel_turbin, Вы писали:
FDS>>Чем это хуже?
_>только тем, что компилятор не проверяет наличие инициализации существующим объектом.
_>в вашем примере ни кто не мешает написать
_>
_>ScopedLocker<что-то> Locker(0); // будет компилиться
_>
Да, тут труба, ваш код с дефолтным конструктором не компилируется
Error 1 error C2758: 'ScopedLocker::m_synch' : must be initialized in constructor base/member initializer list f:\prg\tmp\070530cpplinks\cpplinks\cpplinks.cpp 29
Здравствуйте, superman, Вы писали:
S>ИМХО та проблема, которую ты пытаешся решить.. Повторюсь, она оригинальна, но собственно говоря малозначима, если вообще хоть сколько-нибудь значима. я не могу придумать такого варианта использзования, где нам было бы важно содержим мы этот объект или только ссылаемся не него.
Нам это не важно, но это лишнее напоминание программисту, что это поле вовсе не внутренний объект, а именно указатель на ВНЕШНИЕ данные. Если программист это забудет, он может в итоге долго копаться в коде, не понимая, где же у него баг. А ссылка как раз способствует такому забыванию
S>и ещё.. четвёртый недостаток. В самих методах класа, содержащего указатель, ты должен либо положиться на то что указатель обязательно проинициализирован конструктором или постоянно проверять, а проинициализирован ли он. ссылка бы обеспечила бы нам уверенность что она проинициализированна.. собственно в этом и вся разница, и все её приимущества.
Здравствуйте, Sergey, Вы писали:
S>Здравствуйте, FDSC, Вы писали:
S>>>А умение понимать чужой код у нас теперь типа не котируется? Если в программе этих ссылок как грязи, а человек не понимает ни списков инициализации, ни ссылок — как он будет в ней разбираться?
FDS>>А вы его ему кода не давали, вы просили его написать. Разница принципиальная, согласитесь
S>Мне надо, чтобы человек знал, что такое списки инициализации. Чтобы он знал, чем отличается
S>
S>C::C(const B *s) : x_(b)
S>{}
S>
S>от S>
S>C::C(const B *s)
S>{
S> x_.assign(s);
S>}
S>
S>и знал, почему первый вариант предпочтительнее.
b — это у нас что такое? s что ли? И почему первый вариант предпочтительнее?
S>Чтобы он не догадался о существовании списков инициализации и об этом отличии на собеседовании, а у него в подкорке уже было проштамповано, что по умолчанию надо выбирать первый вариант.
Обращайтесь на кафедру систем пластического деформирования
S> Чтобы он не думал, что писать, i++ или ++i, а первый вариант выбирал бы только в том случае, если ему в данном куске кода действительно нужно знать, что было в i до инкремента. А не писал по привычке i++. Привычка должна быть другая — писать по умолчанию ++i
Так, а чем вам i++ не угодило то? Честно скажу, когда я вижу ++i всегда заменяю на i++, потому что ++i раздражает
FDS>Нам это не важно, но это лишнее напоминание программисту, что это поле вовсе не внутренний объект, а именно указатель на ВНЕШНИЕ данные. Если программист это забудет, он может в итоге долго копаться в коде, не понимая, где же у него баг. А ссылка как раз способствует такому забыванию
ИМХО глупости. во первых не на ДАННЫЕ а на ОБЪЕКТ. внешний или внутрениий — без разницы. Вы пытаетесь решить несуществующую проблему.
S>>и ещё.. четвёртый недостаток. В самих методах класа, содержащего указатель, ты должен либо положиться на то что указатель обязательно проинициализирован конструктором или постоянно проверять, а проинициализирован ли он. ссылка бы обеспечила бы нам уверенность что она проинициализированна.. собственно в этом и вся разница, и все её приимущества.
FDS>Проверять не надо FDS>Об этом писал здесь http://rsdn.ru/forum/message/2508595.1.aspx
Да глупости, надо проверять, надо!
ты показал как в Конструкторе сделать так что бы в конструкторе не надо было проверять. да согласен, выход. А в другом методе который пытается этот указатель использовать? а ей может кто-то гарантировать что завтра не будет изменён конструктор котороый вчера гарантировал инициализацию?
Здравствуйте, 0x8000FFFF, Вы писали:
FFF>Понимаете — настоящему программисту все равно на каком языке писать...
FFF>Мне же вот ничего не мешает писать на C++ сервер, который получает звук с Flash компоненты на сайте (тут пишу на AS2), через Red5 — тут надо писать на Java и транслирует его на сервер, и обратно выдает синтетическое видео с анимацией.
И? Что из этого следует? Мне то же приходилось использовать в одном приложении два языка. Но что из этого? Тем более, это означает, что программист просто не успеет изучить тонкости работы все языков
Здравствуйте, superman, Вы писали:
S>Здравствуйте, FDSC, Вы писали:
FDS>>Нам это не важно, но это лишнее напоминание программисту, что это поле вовсе не внутренний объект, а именно указатель на ВНЕШНИЕ данные. Если программист это забудет, он может в итоге долго копаться в коде, не понимая, где же у него баг. А ссылка как раз способствует такому забыванию
S>ИМХО глупости. во первых не на ДАННЫЕ а на ОБЪЕКТ. внешний или внутрениий — без разницы. Вы пытаетесь решить несуществующую проблему.
Я считаю, что разница есть. Если объект внешний, программисту хотя бы бросится в глаза, если где-то будет несанкционированное изменение, что это именно указатель. А так, кто его знает, приватный объектик, может он только внутри класса и используется и создаётся. Это грабли
S>>>и ещё.. четвёртый недостаток. В самих методах класа, содержащего указатель, ты должен либо положиться на то что указатель обязательно проинициализирован конструктором или постоянно проверять, а проинициализирован ли он. ссылка бы обеспечила бы нам уверенность что она проинициализированна.. собственно в этом и вся разница, и все её приимущества.
FDS>>Проверять не надо FDS>>Об этом писал здесь http://rsdn.ru/forum/message/2508595.1.aspx
S>Да глупости, надо проверять, надо! S>ты показал как в Конструкторе сделать так что бы в конструкторе не надо было проверять. да согласен, выход. А в другом методе который пытается этот указатель использовать?
Зачем там его проверять? Если конструктор гарантирует, дальше будет всё нормально: указатель-то константный
Обрати внимание на слова const, я в main специально привёл попытку обнулить указатель
S> а ей может кто-то гарантировать что завтра не будет изменён конструктор котороый вчера гарантировал инициализацию?
Это ошибка, ну дак на то он и конструктор, что бы гарантировать
Здравствуйте, FDSC, Вы писали:
S>> а ей может кто-то гарантировать что завтра не будет изменён конструктор котороый вчера гарантировал инициализацию?
FDS>Это ошибка, ну дак на то он и конструктор, что бы гарантировать
P.S. Кстати, инициализация-то всё равно будет гарантированно. Другой вопрос, что указатель может быть инициализирован нулём
FDS>Так, а чем вам i++ не угодило то? Честно скажу, когда я вижу ++i всегда заменяю на i++, потому что ++i раздражает
потому что в общем случае постинкр. подразумевает копирование
Здравствуйте, FDSC, Вы писали:
FDS> Так, а чем вам i++ не угодило то? Честно скажу, когда я вижу ++i всегда заменяю на i++, потому что ++i раздражает
эстет!
а должно раздражать i++ !
это менее эфективно т.к. требует сохранения старого состояния i. стоит оговориться, что для фундаментальных типов это ниразу не проблема — компилятор должен бы соптимизировать и поменять назад на ++i, а вот для нефундаментальных увы и ах.. компилятор не осилит.
Здравствуйте, FDSC, Вы писали:
FDS>А я, когда увидел код, прицепился к delete i и невиртуальному деструктору... только потом сообразил, что в коде ещё и main есть
Ну вот: один правильный человек уже есть
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, superman, Вы писали:
S>>Здравствуйте, FDSC, Вы писали:
S>>>>и ещё.. четвёртый недостаток. В самих методах класа, содержащего указатель, ты должен либо положиться на то что указатель обязательно проинициализирован конструктором или постоянно проверять, а проинициализирован ли он. ссылка бы обеспечила бы нам уверенность что она проинициализированна.. собственно в этом и вся разница, и все её приимущества.
FDS>>>Проверять не надо FDS>>>Об этом писал здесь http://rsdn.ru/forum/message/2508595.1.aspx
S>>Да глупости, надо проверять, надо! S>>ты показал как в Конструкторе сделать так что бы в конструкторе не надо было проверять. да согласен, выход. А в другом методе который пытается этот указатель использовать?
FDS>Зачем там его проверять? Если конструктор гарантирует, дальше будет всё нормально: указатель-то константный FDS>Обрати внимание на слова const, я в main специально привёл попытку обнулить указатель
млин, а если Вася пупкин завтра перепишет твой конструктор? или добавит ещё один который такой гаринтии давать не будет?
S>> а ей может кто-то гарантировать что завтра не будет изменён конструктор котороый вчера гарантировал инициализацию?
FDS>Это ошибка, ну дак на то он и конструктор, что бы гарантировать
Здравствуйте, superman, Вы писали:
S>млин, а если Вася пупкин завтра перепишет твой конструктор? или добавит ещё один который такой гаринтии давать не будет?
А если вася пупкин перепишет твой конструктор так что все сломаеццо.
Это сродни вопросу "а что будет если программа будет работать неправильно?"
А если вася пупкин в ваш класс добавит конструктор по умолчанию и там ссылку проинитит адресом локальной переменной или вообще *NULL
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
