E>А вообще-то три коммента у меня есть
E>1) Задавая "умный" вопрос стоит быть таки уверенным в его однозначном ответе. А то можно и опозорится

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

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

A>Вообще-то нормальные люди так и делают — проверяют ВЕЗДЕ на наличие памяти,
A>бросают исключения, ловят, сообщают пользователю, и сохраняют текущее состояние
A>данных до начала операции (транзакции).

Расскажи, пожалуйста, что делают люди когда им не удалось создать простой объект по причине отсутствия памяти? Какие у них есть варианты.

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

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

A>>Вообще-то нормальные люди так и делают — проверяют ВЕЗДЕ на наличие памяти,
A>>бросают исключения, ловят, сообщают пользователю, и сохраняют текущее состояние
A>>данных до начала операции (транзакции).

AJD>Расскажи, пожалуйста, что делают люди когда им не удалось создать простой объект по причине отсутствия памяти? Какие у них есть варианты.

Ты что не ПОНЯЛ? Они же бросают исключения, ловят, сообщают пользователю, и, вообще, сохраняют текущее состояние данных до начала операции (транзакции)! Подожди... Они сохраняют состояние после проверки на наличиа памяти или до? Блин, запутался...

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

A>>>>>Попроси оператор присваивания написать вот для такого обьекта:
A>>>>>Если тебе не нравятся массивы, заданные указателем, сделай вектора.
RO>>>>Так если вектора, то ничего не нужно писать вообще, дефолтный оператор справится.
A>>>Что произойдет, если первый массив скопировался, а на второй не хватило памяти?
RO>>Исключение и basic exception guarantee.

A>1) Изясняйся по русски.

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

A>2) Что с ТВОИМИ данными будет?

http://en.wikipedia.org/wiki/Exception_handling#Exception_safety

Здесь не стоит заморачиваться потому, что на современных компьютерах памяти много, и кончается она редко. А если всё же кончается, то твоя программа переезжает в своп и начинает сильно-сильно тормозить, и никакие try — catch не помогут.

Хотя при желании можно реализовать strong exception guarantee, это я и делал ниже.

A>>>>>А дальше смотри что будет:
A>>>>>3) Поймать все исключения.
RO>>>>п. 3 — ???
A>>>что делает new при нехватке памяти?

RO>>Кидается. Но зачем их ловить-то? Их надо дальше передавать. Вот тебе strong exception guarantee без catch:
RO>>>>

RO>>HelloSutter& HelloSutter::operator =(HelloSutter other)
RO>>{
RO>>    swap(other);
RO>>    return *this;
RO>>}
RO>>

A>Ах! Какой ты умный!
A>1) Что такое swap? Я подозреваю, что это ОБМЕН переменных.
A> То есть твой "оператор присваивания" МЕНЯЕТ other. :)))

RTFM: swap(other) может обозначать AnyEnclosingNamespace::swap(other), а может и this->swap(other). Имелось в виду второе.

A>2) Кто его писать будет?

Тот же, кто и operator =. Выглядит он просто:

void HelloSutter::swap(HelloSutter& other)
{
    std::swap(member1, other.member1);
    std::swap(member2, other.member2);
    . . .
    std::swap(memberN, other.memberN);
}

// по вкусу:
namespace std
{
    void swap(HelloSutter& x, HelloSutter& y)
    {
        x.swap(y);
    }
}

A>Смеюсь и показываю пальцем.

A>3) Зачем вообще исключения ловят, передавали бы уж дальше, до самого exit.

Их ловят там, где можно обработать. Обработка точно не входит в юрисдикцию данного класса. Например:

try
{
    doc.saveAs(path); // вызвает много вспомогательных функций (и операторов)
}
catch(std::exception const& e)
{
    logEvent("Failed to save: " + e.what());
    blameUser("Throw away your computer, it can't save my file!");
}

Вот у меня встречное предложение.

class Storage
{
private:
    std::vector<X> xs_;
    std::deque<Y> ys_;
    std::list<Z> zs_;
};

Тот же вопрос: как написать operator =? Только давай строго сформулируем требования:

• Strong exception guarantee: или нет исключения и операция завершилась успешно, или есть исключение и класс не претерпел никаких изменений.
• Exception transparency: все исключения вылетают дальше без изменений, чтобы можно было обработать.
• Эффективность: отсутствие значительных затрат производительности на реализацию вышеперечисленного.

A>Эта... Ты когда-нибудь работал? ВУЗ закончил?
Да, нет.

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

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

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

Вообще-то, в дебаге область локальных переменных заполняется 0xCC, а не нулями.

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

A>-в каких ситуациях перегрузка левого ++ лучше чем правого ++?

Странный вопрос. Если уж перегружать, то оба... Еще бы меня насторожил экзаменатор, использующий термины "левый" и "правый" вместо "префиксный" и "постфиксный" соответственно.

в каком случае нужно определять перегруженный оператор как член класса,
а в каком френд функцию
или другой вариант вопроса: каким образом лучше перегрузить оператор XXX(любой на выбор)

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

E>>1) Задавая "умный" вопрос стоит быть таки уверенным в его однозначном ответе. А то можно и опозорится

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

Даже в этом случае ИМХО важно чтобы твои знания в этом вопросе сильно превосходили твоё невежество и амбиции...

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

A>Просто, если ты студент, то специально для тебя проведу ликбез.

Я не студент, н тоже с радостью бы послушал...

E>Хотя на месте MS я бы из STL тоде не использовал
Хотя на месте MS я бы их STL тоже не использовал

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

RO>И перевод нехороший, и текст устаревший.
Мне стало так интересно, что я даже прочёл сегодня вечером оригинал и оба перевода. Что-то я грандиозных отличий не заметил

RO>А вообще я не понимаю смысла в таких переводах. Толку от айтишника, который прочитал много умных книг и статей, но по-английски не понимает?
1) По-английски можно понимать в разной степени
2) Разные людичитают местные форумы

А вообще в статье мне многое показалось своеобразным. Ну, например, любовь к написанию константы слева от сравнения в if'е. Или любовь к тому, чтобы при программировании ображения списка человек рисовал картинки. Скаежм я после этой статьи даже взял да и написал функцию, которая переворачивала односвязанный список. При этом я ничего нигде не рисовал и функция работала
Да и вообще много спорного. Хотя идеология более или менее разумная.

RO>Здесь не стоит заморачиваться потому, что на современных компьютерах памяти много, и кончается она редко. А если всё же кончается, то твоя >программа переезжает в своп и начинает сильно-сильно тормозить, и никакие try — catch не помогут.

у Саттера кажется, было рассуждение по поводу нужно ли проверять ошибки распределения памяти в new. сводится оно примерно к следующему:
в системах с виртуальной памятью память "есть" всегда , если же ее нет то значит система в состоянии аварийного завершения.
единственное что тут можно сделать это записать ошибку в лог (что может тоже не сработать т.к. места на диске уже нет)

AA>Странный вопрос. Если уж перегружать, то оба... Еще бы меня насторожил экзаменатор, использующий термины "левый" и "правый" вместо "префиксный" и "постфиксный" соответственно.

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

E>А вообще в статье мне многое показалось своеобразным. Ну, например, любовь к написанию константы слева от сравнения в if'е.

раньше так писал, сейчас перестал. имхо это должно решаться на уровне стандарта о кодировании.

>Или любовь к тому, чтобы при программировании ображения списка человек рисовал картинки. Скаежм я после этой статьи даже взял да и написал функцию, >которая переворачивала односвязанный список. При этом я ничего нигде не рисовал и функция работала
я всегда рисую , если задача непонятна. но списки настолько заезжены что можно сразу код писать.
один раз меня интервьюировал индус в Экспедии, я как раз писал на доске вставку в сортированный список. задача ерундовая,
но т.к. я волновался, то написал лишний ненужный if. потом он меня спросил — а можно ли сократить или оптимизировать код —
я поправил. правда в Экспедию меня все равно не взяли

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

S>>Другое дело std::rotate. Его для разных категорий итераторов по-разному реализовать нужно.

RO>Зачем rotate, лучший пример таких разных реализаций — lower_bound.

ИМХО, lower_bound пример упрощенный.
С другой стороны, этим он и хорош. Алгоритм очевиден, надо только правильно все оформить.

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

A>>Просто, если ты студент, то специально для тебя проведу ликбез.
RO>Я крайне рад тому, что в этом отношении составляю компанию Андрею Александреску, поскольку имею возможность выслушать превосходную лекцию. Жду с нетерпением.
Мне тоже очень хочется послушать эту лекцию Надеюсь подчерпнуть много нового.

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

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

AA>Вообще-то, в дебаге область локальных переменных заполняется 0xCC, а не нулями.

Вообще-то, кроме MSVS есть и более другие IDE.

Да и для MSVS всё не так просто: http://rsdn.ru/forum/message/1237078.1.aspx

Автор: Кодёнок
Дата: 23.06.05

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

A>в каком случае нужно определять перегруженный оператор как член класса,
A>а в каком френд функцию
A>или другой вариант вопроса: каким образом лучше перегрузить оператор XXX(любой на выбор)

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

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

E>>А вообще в статье мне многое показалось своеобразным. Ну, например, любовь к написанию константы слева от сравнения в if'е.
A>раньше так писал, сейчас перестал. имхо это должно решаться на уровне стандарта о кодировании.

Аналогично. Если пишешь if(1 == f()), то надо писать и if(2 != f()), и if(3 < f()), а это уже совсем некрасиво и непонятно.

>>Или любовь к тому, чтобы при программировании ображения списка человек рисовал картинки. Скаежм я после этой статьи даже взял да и написал функцию, >которая переворачивала односвязанный список. При этом я ничего нигде не рисовал и функция работала :)
A>я всегда рисую , если задача непонятна. но списки настолько заезжены что можно сразу код писать.

По-хорошему, приступая к задаче, нужно сперва ее обдумать с использованием карандаша и бумаги (мела и доски, и т. п.), а от компьютера держаться подальше. Если проект большой, то будет больше людей, больше умных слов вроде «Use case», «Workflow», «UML», но принцип тот же. Ведь цель собеседования в том, чтобы на примере простых задач показать и умение писать на таком-то ЯП, и умение решать задачи вообще, и, просто, свой подход к этому делу.

RO>По-хорошему, приступая к задаче, нужно сперва ее обдумать с использованием карандаша и бумаги (мела и доски, и т. п.), а от компьютера >держаться подальше. Если проект большой, то будет больше людей, больше умных слов вроде «Use case», «Workflow», «UML», но принцип тот же. >Ведь цель собеседования в том, чтобы на примере простых задач показать и умение писать на таком-то ЯП, и умение решать задачи вообще, и, >просто, свой подход к этому делу.

+1. поддерживаю в этом вопросе Джоела. я кстати все собеседования провожу у доски, у меня кандидаты обычно что-то рисуют —
диаграммы классов, или структурные схемы. даю небольшую задачку на дизайн классов, или прошу нарисовать схему системы которую он спроектировал на предыдущей работе. если человек может объяснить что и зачем он делал, и понимает как работает вообще все, а не только те куски кода что он непосредственно писал — значит хороший кандидат!