Средства оптимизации.

gprof

и valgrind

Вопрос номер 3. http://company.yandex.ru/inside/job/mail_dev.xml

> Вопрос номер 3. http://company.yandex.ru/inside/job/mail_dev.xml

ответ: голову.

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

// wbr

вот первый вопрос интересный, кто что скажет? :)

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

  private:
    int* i;
};

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

  private:
    char* i;
};


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

Перечислите все проблемы, которые вы видите в данном коде:

это не вступительное задание яндекса?

ну да, вон же анонимус ссылку дал :)

> вот первый вопрос интересный, кто что скажет? :)

я вижу только срезку и двойное освобождение.

А вообще - стоит ли? в яндексе на нас могут обидеться - им новое тестовое задание делать придется...

интересно могут ли господа из яндекса вычислить по кукисам и реферерам участников этой дискуссии? и как нибудь отомстить - отключить фильтрацию спама в почте/сделать чтоб поиск тебе самое нужное не находил/еще чего :-)

или наоборот добавить лор в выдачу по каким-нибудь ФГМным запросам :-)

> интересно могут ли господа из яндекса вычислить по кукисам и реферерам участников этой дискуссии? и как нибудь отомстить - отключить фильтрацию спама в почте/сделать чтоб поиск тебе самое нужное не находил/еще чего :-)

а что, кто-то из участников дискуссии всё ещё пользуется яндексом?!

// wbr

> я вижу только срезку и двойное освобождение.

что есть "срезка" в данном контексте?

// wbr

>>и как нибудь отомстить - отключить фильтрацию спама в почте/сделать чтоб поиск тебе самое нужное не находил/еще чего :-)

на гмыле? :D

> на гмыле? :D

"но учтите - у нас длинные руки!" (c)...

// wbr

> ну да, вон же анонимус ссылку дал :)

упс:) я же Ъ, я ссылку не то что не открывал но даже и не смотрел, думал это ссылка на faq какой-то

>Перечислите все проблемы, которые вы видите в данном коде:

Все проблемы в данном коде, это одна: он написан на C++.

>а что, кто-то из участников дискуссии всё ещё пользуется яндексом?!

Я пользуюсь, гугель всё-таки не всегда находит что надо, каких-нибудь не самых известных бардОв например то один, то другой проиндексировать забывает.

Кроме того, у яндекса блогсёрч адекватней, особенно если нужно английское слово + русская аудитория.

> вот первый вопрос интересный, кто что скажет? :)

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

private:
int* i;
};

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

private:
char* i;
};


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

> Перечислите все проблемы, которые вы видите в данном коде:

1. i плохое имя, надо mpData и т.п.
2. в деструкторе нет проверки на то, что i != NULL;
3. delete [] i
4. деструктор надо обьявить виртуальным
5. раз типы данных разные, надо в Bar прописать mDataBar вместо i
6. надо делать проверки параметров, на <= 0, на >= maх
7. параметры имеют неправильные название, должно быть inCount например
8. внутренние данные должны быть protected, а не private
9. надо задать оператор == для Foo
10. if( f ) delete f;
11. if( b ) delete b;
12. if( f && b ) *f=*b
13. по хорошему int main( void )

вот то что на первый взгляд нашел

>>2. в деструкторе нет проверки на то, что i != NULL;
>>10. if( f ) delete f;
>>11. if( b ) delete b;

низачот.

>>1. i плохое имя, надо mpData и т.п.
>>5. раз типы данных разные, надо в Bar прописать mDataBar вместо i
>>8. внутренние данные должны быть protected, а не private
>>9. надо задать оператор == для Foo

Ну это вопросы проектирования.

14. удаление объектов должно быть в обратном порядке

Самое главное не сказал. У Foo нету конструктора по умолчанию, поэтому создать наследника от него нельзя. Даже если в Foo добавить конструктор по умолчанию, то private наследование не даст создать объект Bar'a.

>>2. в деструкторе нет проверки на то, что i != NULL;
>>10. if( f ) delete f;
>>11. if( b ) delete b;
> низачот.

а это почему?

> У Foo нету конструктора по умолчанию, поэтому создать наследника от
него нельзя

ну это просмотрел

>>>11. if( b ) delete b;

>> низачот.

>

>а это почему?

Проверять на 0 значение, передаваемое delete/delete[] не нужно.

> Проверять на 0 значение, передаваемое delete/delete[] не нужно.

а вот фиг - код собранный msvc++ прекрасно падает на таком

+1 к valgrind - мегаполезная штука, особенно вместе с kcachegrind. Правда он считатет не время а кол-во инструкций/обращений к памяти/промахов мимо кэша => применим больше к алгоритмам а не системному софту с большим количеством системных вызовов.

> а вот фиг - код собранный msvc++ прекрасно падает на таком

версия msvc?

потому, что проверка на 0 в delete действительно не нужна.

// wbr

>> Проверять на 0 значение, передаваемое delete/delete[] не нужно.

>а вот фиг - код собранный msvc++ прекрасно падает на таком

По стандарту delete 0 и free(0) совершенно законны.

> версия msvc?

vs2005 - но повторить не получается, хотя помню такой случай..., ладно - спишем на мои глюки, но в любои случае привычка, всегда делать проверку на NULL перед работой с указателем, не такая уж и плохая - "Це знають ще маленькі діти, що краще перебдіть, ніж недобдіти" (с)

> vs2005 - но повторить не получается, хотя помню такой случай...,

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

> ладно - спишем на мои глюки

возможно. с бОльшей вероятностью указатель был не 0 но старый мусор.

> но в любои случае привычка, всегда делать проверку на NULL перед работой с указателем, не такая уж и плохая - "Це знають ще маленькі діти, що краще перебдіть, ніж недобдіти" (с)

привычка привычкой, но делать это для delete просто бессмысленно.

// wbr

> в то, что были именно такие глюки под 2005 - не верю.

вас никто и не заставляет верить

> возможно. с бОльшей вероятностью указатель был не 0 но старый мусор.

вы тут самый умный - я понял

> привычка привычкой, но делать это для delete просто бессмысленно.

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

>> привычка привычкой, но делать это для delete просто бессмысленно.

> а вам не насрать? да и лучше поставить такую бессмысленную проверку, но при этом не забывать везде проверять параметры, обнулять указатели и т.п., чем быть слишком умным и потом получить креш и думать - вот бл% как хитро получилось, а я и не ожидал

+1

Не забываем, что на некоторых системах NULL != 0, а при реализации местного libc народ мог руководствоваться совершенно странными соображениями. Перестраховаться не помешает (тем паче, что это — 2–3 такта процессора, да и вызов free() или delete происходит не так часто).

Давеча вчера столкнулся с проблемой: знакомый писал и тестировал программу в msvc++ с местным рантаймом, которому было пофиг на освобождение уже освобождённой памяти (по крайней мере, иногда). Попробовал у себя пересобрать|запустить – glibc вместе с libc++ отловили ошибку повторного освобождения, причём неявного (на выходе из функции). Долго искал, потом забил и переписал с плюсов на си.

> Не забываем, что на некоторых системах NULL != 0

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

> а при реализации местного libc народ мог руководствоваться совершенно странными соображениями.

оно или соответствуют стандарту или нет. если нет - плохо. при таком подходе проблем будет вагон с маленькой тележкой и это лишь минорная.

> Перестраховаться не помешает (тем паче, что это — 2–3 такта процессора, да и вызов free() или delete происходит не так часто).

// wbr

> лучше поставить такую бессмысленную проверку
а что же вы не поставили такую проверку после new?!
может он тоже переопределен и не кошерный ))

Для особо критичных мест можно использовать gcov - покажет сколько раз выполнялась каждая строчка программы, а потом можно помочь gcc с предсказанием ветвлений через likely/unlikely, как в ядре.

> а что же вы не поставили такую проверку после new?!

я поставил проверку везде где выполняется действие над указателем, тут же действий "после new" нет

Sun Studio Performance Analyzer

>> Не забываем, что на некоторых системах NULL != 0

> не могли бы вы привести пример таких систем? чисто для расширения кругозора.

Точно не помню, но на какой-то сейчас используемой платформе NULL == -1. И вот ещё нагуглилось:

The Prime 50 series used segment 07777, offset 0 for the null pointer, at least for PL/I. Later models used segment 0, offset 0 for null pointers in C, necessitating new instructions such as TCNP (Test C Null Pointer), evidently as a sop to all the extant poorly-written C code which made incorrect assumptions. Older, word-addressed Prime machines were also notorious for requiring larger byte pointers (char *'s) than word pointers (int *'s).

The Eclipse MV series from Data General has three architecturally supported pointer formats (word, byte, and bit pointers), two of which are used by C compilers: byte pointers for char * and void *, and word pointers for everything else.

Some Honeywell-Bull mainframes use the bit pattern 06000 for (internal) null pointers.

The CDC Cyber 180 Series has 48-bit pointers consisting of a ring, segment, and offset. Most users (in ring 11) have null pointers of 0xB00000000000.

The Symbolics Lisp Machine, a tagged architecture, does not even have conventional numeric pointers; it uses the pair <NIL, 0> (basically a nonexistent <object, offset> handle) as a C null pointer.

Depending on the "memory model" in use, 80*86 processors (PC's) may use 16 bit data pointers and 32 bit function pointers, or vice versa.

The old HP 3000 series computers use a different addressing scheme for byte addresses than for word addresses; void and char pointers therefore have a different representation than an int (structure, etc.) pointer to the same address would have.

valgrind с модулями callgrind/cachegrind и google performance tools. Вот тут (http://xtalk.msk.su/~ott/ru/writings/prog-checking/) есть краткое описание этих вещей