Interesting C/C++ interview questions

User avatar
шпиён
Уже с Приветом
Posts: 3459
Joined: 29 Oct 2002 20:08
Location: US

Post by шпиён »

tchicago wrote:
шпиён wrote:
tchicago wrote:Зависит от:

a) Сложности объекта исключения. Во многих случаях это не просто несколько байт памяти.
б) Архитектуры приложения/библиотеки. Некоторые библитеки действительно используют механизм исключений для доставки пользователю результатов работы (с точки зрения разработчика библиотеки это исключительная ситуация, с точки зрения ее пользователя - нет)


А причем тут производительность? При таких условиях о ней УЖЕ мечтать не приходится.


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


Приложения, где требуется производительность и в критически-важном по скоросте месте происходит частый (сравнимый по частоте со внутренними итерациями) throw/catch? Ну приведите. Хотя мало ли неправильно написанного кода на свете.


tchicago wrote:
tchicago wrote:в) Наличия собственного аллокатора памяти или свойств стандартного.


Вам известны аллокаторы, производительность которых (на new И на delete) сравнима с отсутсвием аллокации? ;)


неверно поставлен вопрос. Надо так:
"Вам известны аллокаторы, производительность которых (на new И на delete) сравнима с производительностью инлайнового конструктора копирования копирующего vptrинлайнового пустого деструктора)?"


Вот так совсем правильно - можно отвечать. Только какая разница-то, если throw/catch все равно может быть сколь угодно долгим? :pain1:
User avatar
шпиён
Уже с Приветом
Posts: 3459
Joined: 29 Oct 2002 20:08
Location: US

Post by шпиён »

A. Fig Lee wrote:
tchicago wrote:
A. Fig Lee wrote:Ну если на одном С++ программируешь... А если прыгаешь с С на С++ и обратно...
Лучше уж одного стиля придерживатся.

Code: Select all

#ifndef COPY_STRING
...
#endif


Unrelated. Чето я смотрел-смотрел на это, но так и не понял зачем делать это различие между c и с++. У Вас new/delete переопределены?

Ну дак в одном случае бай дефоулт используем delete, а в С - используем free.
Поетому и разные. Чтоб не помнить как удалять. Чтоб не думать, когда программируешь. :wink:


Фигля, как уже не раз тут говорилось - не думать вредно. Вам привести разницу между malloc() и new[], или сами догадаетесь?
Почему бы Вам не использовать malloc() и в C++? :pain1:
User avatar
A. Fig Lee
Уже с Приветом
Posts: 12072
Joined: 17 Nov 2002 03:41
Location: английская колония

Post by A. Fig Lee »

шпиён wrote:Фигля, как уже не раз тут говорилось - не думать вредно. Вам привести разницу между malloc() и new[], или сами догадаетесь?
Почему бы Вам не использовать malloc() и в C++? :pain1:


Штирлиц, ну Вы даете! Я ж там и обьекты создаю, шо ж я теперь - для одного буду ню применять, а для другого - маллоk?
Голова опухнет. Инкапсулейшн знаете зачем - чтоб думать не надо было когда программируешь.
Верить нельзя никому - даже себе. Мне - можно!
User avatar
шпиён
Уже с Приветом
Posts: 3459
Joined: 29 Oct 2002 20:08
Location: US

Post by шпиён »

A. Fig Lee wrote:
шпиён wrote:Фигля, как уже не раз тут говорилось - не думать вредно. Вам привести разницу между malloc() и new[], или сами догадаетесь?
Почему бы Вам не использовать malloc() и в C++? :pain1:


Штирлиц, ну Вы даете! Я ж там и обьекты создаю, шо ж я теперь - для одного буду ню применять, а для другого - маллоk?
Голова опухнет. Инкапсулейшн знаете зачем - чтоб думать не надо было когда программируешь.


Ну если не думать - то и получится кю.
Возврат malloc() неплохо бы проверять. А new bad_alloc бросает. Хотите похожести - хоть new(nothrow) пишите.
User avatar
A. Fig Lee
Уже с Приветом
Posts: 12072
Joined: 17 Nov 2002 03:41
Location: английская колония

Post by A. Fig Lee »

шпиён wrote:Ну если не думать - то и получится кю.
Возврат malloc() неплохо бы проверять. А new no_memory бросает. Хотите похожести - хоть new(nothrow) пишите.


Штирлиц, если нет места для стринга, то там бесполезно проверять - надо память докупать.
Верить нельзя никому - даже себе. Мне - можно!
User avatar
A. Fig Lee
Уже с Приветом
Posts: 12072
Joined: 17 Nov 2002 03:41
Location: английская колония

Post by A. Fig Lee »

шпиён wrote:
tchicago wrote:
roadman wrote:Достоинства и недостатки двух методов обработки exception

Code: Select all

class exep
{
public:
   exep(int err) : _error(err) {}
   int get_code() const { return _error; }
private:
   int _error;
};

int main()
{
   try
   {
      throw new exep(1);
   }
   catch (exep* x)
   {
      cout << x->get_code();
      delete x;
   }

   try
   {
      exep x(1);
      throw x;
   }
   catch (exep& x)
   {
      cout << x.get_code();
   }



А почему этот вопрос никто не удостоил вниманием? Все слишком просто или слишком сложно? :mrgreen:


С первого взгляда кажется просто.
1) Лишняя аллокация/деаллокация памяти. Да еще и лик может быть, если из catch своё исключение бросится до delete.
2) Лишнее копи-конструирование, что для приведенного в примере exep не хуже копирования указателя в случае 1, но для больших/сложных классов может быть дорого.
На мой взгляд, метод 2 однозначно лучше, т.к. за расчет на высокую скорость обработки исключений надо anyway бить лопатой по голове.


А со второго? :wink: в чем разница между бросанием с нью и передачей бай референсе?
Именно ексепшн имеется ввиду.
P.S. Седни думать заставили...
Кстати, шпиен, где написано что нью бросает ексепшн? В стандарте? В АРМ такого нет. Настолько привык к етим догмам, что и не думал..
Верить нельзя никому - даже себе. Мне - можно!
User avatar
A. Fig Lee
Уже с Приветом
Posts: 12072
Joined: 17 Nov 2002 03:41
Location: английская колония

Post by A. Fig Lee »

Да, совсем необязательно в дерайвед классе ексепшн дерайвать из базового. мона и свои бросать. Страуструп все предусмотрел! :umnik1:
Верить нельзя никому - даже себе. Мне - можно!
VBez
Уже с Приветом
Posts: 491
Joined: 23 Feb 2004 11:25

Post by VBez »

Vovka wrote:Тех, кто дестракторы делает виртуальными _всегда_, я бы сам никогда до программирования не допустил бы. :)


Кстати, если не ошибаюсь у нас есть такое ОБЯЗАТЕЛЬНОЕ требование от QAев :mrgreen:

Return to “Работа и Карьера в IT”