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

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

S>>мы тут на днях встретили в одной библиотеке такой перл:
CC>такое ощущение, что тот кто это писал не подозревал о существовании указателей.

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

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

KA>Читаю эту ветку находясь в отпуске на море... И знаете, такое чуство возникает, что возня какая то у вас там в Москве нездоровая
KA>Не то что бы я там че то, просто я к тому что оторвите взгляд от компа, типа повертите в разные стороны и все такое...
KA>А вы опять за свои копи-конструкторы, констатные методы и прочее ...


Не одной водой морской сыт человек...

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

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

FDS>>>Можно ссылочку (на открытый проект) на пример реального кода, где используются ссылки как поля объектов.

_>>Элементарно.

FDS>Чем не нравится так:
FDS>

FDS>template<class Synch>
FDS>class ScopedLocker
FDS>{
FDS>    Synch * const m_synch;
   
FDS>public:

<skip>

FDS>

FDS>?

FDS>Чем это хуже?

только тем, что компилятор не проверяет наличие инициализации существующим объектом.

в вашем примере ни кто не мешает написать

ScopedLocker<что-то> Locker(0); // будет компилиться

если бы тут была ссылка, то ошибка была бы поймана компилятором.

никто не мешает также добавить дефолтный конструктор

class ScopedLocker
{
 Synch * const m_synch;
....
public:
ScopedLocker(){}
};

тут вообще труба

ScopedLocker<что-то> Locker; // рухнет

ссылка тем и хороша, что она обязывает ее задавать всегда, (ну если memcopy не использовать). Язык С тем и страдет "все можно -- никаких проверок".

Понимаете — настоящему программисту все равно на каком языке писать...

Мне же вот ничего не мешает писать на C++ сервер, который получает звук с Flash компоненты на сайте (тут пишу на AS2), через Red5 — тут надо писать на Java и транслирует его на сервер, и обратно выдает синтетическое видео с анимацией.

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

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

D>>>Причём ещё до начала работы с ним.
sc>>Это точно Спешил. Но надеюсь все поняли, что я имел ввиду

FDS>Вот, видите какой вред от ссылок?

FDS>А если представить себе ещё одно неправильное использование такой структуры блокировки: она незаметно для программиста (ну спешил человек или устал просто и не заметил) попадает во вложенные операторные скобки, а на самом деле должна блокировать всю функцию. Вот вам ещё одна ошибка, которую надо искать.... Правда тогда нужно делать функцию, а потом её обернуть ещё одной с синхронизацией чтобы точно никаких ошибок не было.... а это в C++ будет уже не удобно, скорее всего

В данном случае, если ссылку заменить на указатель, вред точно такой же
Почему же указатели хуже? Потому что Гугл на запрос "pointers are evil" выдает 554 ссылки а на "references are evil" всего 10

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

D>Внимательно посмотри на строчку

D>

D>        ConnectGuard(c);
D>

снимаю шляпу

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

_>

_>// примерная версия
_>int a1 = 0, b1=0;
_>int &a = a1, &b=b;

_>memcpy( &a, &b, sizeof(b) );

_>// прижелании можно использовать __asm
_>__asm lea, eax a

_>

_>и весь C++ идет курит бамбук.

Вот за это нужно бить ногами по рукам

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

CC>>такое ощущение, что тот кто это писал не подозревал о существовании указателей.

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

да нет. могу предположить что просто сначала был только один конструктор, который брал сцылку — то есть предполаголось что обьект Foo нужен — дальше некуда, а потом родилась идея что его и без сцылки на Foo как-то использовать можно, и порефакторили его кривовато от и всё. OpenSorce проект

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

KA>Читаю эту ветку находясь в отпуске на море... И знаете, такое чуство возникает, что возня какая то у вас там в Москве нездоровая
KA>Не то что бы я там че то, просто я к тому что оторвите взгляд от компа, типа повертите в разные стороны и все такое...
KA>А вы опять за свои копи-конструкторы, констатные методы и прочее ...

ты решил это везде запостить? Надеюсь программку то хоть написал?

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

S>>А умение понимать чужой код у нас теперь типа не котируется? Если в программе этих ссылок как грязи, а человек не понимает ни списков инициализации, ни ссылок — как он будет в ней разбираться?

FDS>А вы его ему кода не давали, вы просили его написать. Разница принципиальная, согласитесь

Мне надо, чтобы человек знал, что такое списки инициализации. Чтобы он знал, чем отличается

C::C(const B *s) : x_(b)
{}

от

C::C(const B *s)
{
  x_.assign(s);
}

и знал, почему первый вариант предпочтительнее. Чтобы он не догадался о существовании списков инициализации и об этом отличии на собеседовании, а у него в подкорке уже было проштамповано, что по умолчанию надо выбирать первый вариант. Чтобы он не думал, что писать, i++ или ++i, а первый вариант выбирал бы только в том случае, если ему в данном куске кода действительно нужно знать, что было в i до инкремента. А не писал по привычке i++. Привычка должна быть другая — писать по умолчанию ++i. Чтобы человек не забывал писать explicit, определив в классе конструктор конверсии. Чтобы он не писал код вида:

C::C()
{
   x = new K;
   y = new L;
}

C::~C()
{
   delete x;
   delete y;
}

Чтобы написав в деструкторе delete, не забывал запретить (или определить) у класса конструктор копирования и оператор присваивания.
А вы говорите — "ах, про ссылки спросили! звери, не иначе!".

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

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

FDS>Лично моё мнение: собственно, а чем ссылки лучше константных указателей? Я тут где-то показывал эквивалентный код на указателях, заменяющий ссылку. Чем вам указатели не нравятся? Для тех же объектов синхронизации ведь совершенно без разницы, будете вы туда ссылку передавать или запоминать адрес в константный указатель.

FDS>Или я где-то чего-то не понимаю?

имхо, то, что ты предложил оригинально но малость безполезно.
в этом случае присутствуют те же самые недостатки что и при использовании ссылки:
1. объект, на который мы ссылаемся, может быть уже удалён, а мы и не заметим этого
2. объект нашего класса нельзя скопировать (использовать operator=)
3. лишние движения (передать по ссылке, сохранить взятый адрес) — просто лишний раз запутывают

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

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

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

S> Хуже вопрос только про ++i++ и скобки

А в чем, если не секрет, этот вопрос заключается?

S>А вообще мне у Яндекса очень вопрос нравится, про проблемы в этом кусочке кода:

S>class Foo
S>{
S>public:
S>    Foo(int j) { i=new int[j]; }
S>    ~Foo() { delete i; }
S>private:
S>    int* i;
S>};

S>class Bar: Foo
S>{
S>public:
S>    Bar(int j) { i=new char[j]; }
S>    ~Bar() { delete i; }
S>private:
S>    char* i;
S>};


S>void main()
S>{
S>    Foo* f=new Foo(100);
S>    Foo* b=new Bar(200);
S>    *f=*b;
S>    delete f;
S>    delete b;
S>}

По-моему, как раз очень неудачный вопрос. Проблема этого кода в том, что он ill-formed (с первого беглого взгляда бросается в глаза void main). Как все это сделать правильно? Да очень просто: int main() {} (со второго беглого взгляда видно, что никакого observable behavior тут и быть не могло).

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

FDS> Только вот что-то мне не хочется тратить свою жизнь на изучение того, что мне абсолютно не нужно и легко можно заменить другой вещью из этого же языка. По моему, как раз речь идёт о хламе.

минус много

FDS>Да и языков и библиотек столько, что непонятно, что учить и насколько глубоко

Эт со временем пройдёт.

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


S>а потом возникают вопросы о проблемах с понимением молодых програмистов

Инетерсно, вы нечаянно написали 3-ю "н", или нечаянно заменили "а" на "е"?

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

S>> Хуже вопрос только про ++i++ и скобки

E>А в чем, если не секрет, этот вопрос заключается?

Да как обычном — скомпилируется или нет, почему, как расставить скобки чтобы скомпилировалось. Пустая трата времени в общем.

E>По-моему, как раз очень неудачный вопрос. Проблема этого кода в том, что он ill-formed (с первого беглого взгляда бросается в глаза void main). Как все это сделать правильно? Да очень просто: int main() {} (со второго беглого взгляда видно, что никакого observable behavior тут и быть не могло).

В том контексте, в котором этот вопрос использется у Яндекса — действительно не очень удачный вопрос. Потому что слишком много букв придется соискателю набирать А вот для того, чтобы в ходе беседы определить, как хорошо кандидат замечает баги в чужом коде и вообще насколько критически мыслит — очень даже подходит.

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

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

Не знает этих вещей, или не знает их названий?
Опытный программист вполне может не ответить на вопрос "назовите 15 основный паттернов", хотя на практике использовал их все.
Просто он узнал о них не из книжки банды.

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

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


S>>а потом возникают вопросы о проблемах с понимением молодых програмистов

E__>Инетерсно, вы нечаянно написали 3-ю "н", или нечаянно заменили "а" на "е"?

патсталом

пониманием, нониманием, а не поимением

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

S>Чтобы он не думал, что писать, i++ или ++i, а первый вариант выбирал бы только в том случае, если ему в данном куске кода действительно нужно знать, что было в i до инкремента. А не писал по привычке i++. Привычка должна быть другая — писать по умолчанию ++i.

Ни разу в жизни не использовал ++i. Всегда i++. Жизнь кончена! Пойду в грузчики

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


П>Ни разу в жизни не использовал ++i. Всегда i++. Жизнь кончена! Пойду в грузчики

хм.. чисто ради любопытства, а что ты об ссылках думаеш?

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

S>>> Хуже вопрос только про ++i++ и скобки
E>>А в чем, если не секрет, этот вопрос заключается?

S>Да как обычном — скомпилируется или нет, почему, как расставить скобки чтобы скомпилировалось. Пустая трата времени в общем.

А, т.е. про то, как сделать well-formed... Потому как undefined behavior все равно останется.

S>В том контексте, в котором этот вопрос использется у Яндекса — действительно не очень удачный вопрос. Потому что слишком много букв придется соискателю набирать А вот для того, чтобы в ходе беседы определить, как хорошо кандидат замечает баги в чужом коде и вообще насколько критически мыслит — очень даже подходит.

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