Законен ли такой код?

      char* tranName = new char [128];
      char* tranDets = new char [1024];
      ...
      delete[] tranName, tranDets;

Будет ли полностью освобождена память на которую указывает tranDets?

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

А>Законен ли такой код?

А>

А>      char* tranName = new char [128];
А>      char* tranDets = new char [1024];
А>      ...
А>      delete[] tranName, tranDets;
А>

А>Будет ли полностью освобождена память на которую указывает tranDets?

tranDets будет удален, а вот tranName — нет. Почитайте про оператор ','.

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

А>Законен ли такой код?

А>

А>      char* tranName = new char [128];
А>      char* tranDets = new char [1024];
А>      ...
А>      delete[] tranName, tranDets;
А>

Законен.

А>Будет ли полностью освобождена память на которую указывает tranDets?
Нет, не будет.

Hint: оператор "запятая"

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

А>Законен ли такой код?

А>

А>      char* tranName = new char [128];
А>      char* tranDets = new char [1024];
А>      ...
А>      delete[] tranName, tranDets;
А>

А>Будет ли полностью освобождена память на которую указывает tranDets?

Хм. Какой хороший вопрос для собеседования!

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

А>>

А>>      ...
А>>      delete[] tranName, tranDets;
А>>

А>>Будет ли полностью освобождена память на которую указывает tranDets?

АШ>tranDets будет удален, а вот tranName — нет. Почитайте про оператор ','.
Если почитать про оператор ',' (например у отца-основателя в 6.2 Operator Summary), то можно выяснить, что у него низший приоритет, а потому утечет как раз tranDets.

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

А>>Будет ли полностью освобождена память на которую указывает tranDets?

CC>Хм. Какой хороший вопрос для собеседования!

И если собеседуемый с ходу не отвечает, даем подсказку:

      delete[] tranName, trыnDets;

А>>>Будет ли полностью освобождена память на которую указывает tranDets?

АШ>>tranDets будет удален, а вот tranName — нет. Почитайте про оператор ','.
B>Если почитать про оператор ',' (например у отца-основателя в 6.2 Operator Summary), то можно выяснить, что у него низший приоритет, а потому утечет как раз tranDets.
B>

Да, действительно, я не принял в расчет приоритет.

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

V>

V>      delete[] tranName, trыnDets;

bool* trblnDets
V>

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

CC>Хм. Какой хороший вопрос для собеседования!
А что в нём хорошего?
(Какие выводы по соискателе позволяет сделать тот или иной ответ на этот "хороший" вопрос?)

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

А>Законен ли такой код?

А>

А>      char* tranName = new char [128];
А>      char* tranDets = new char [1024];
А>

даже без делита такой код незаконен, ибо не удовлетворяет базовой гарантии.

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

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

CC>>Хм. Какой хороший вопрос для собеседования!
E>А что в нём хорошего?
E> (Какие выводы по соискателе позволяет сделать тот или иной ответ на этот "хороший" вопрос?)

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

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

АШ>>tranDets будет удален, а вот tranName — нет. Почитайте про оператор ','.
B>Если почитать про оператор ',' (например у отца-основателя в 6.2 Operator Summary), то можно выяснить, что у него низший приоритет, а потому утечет как раз tranDets.
B>

5.18 Comma operator [expr.comma]
1 The comma operator groups left-to-right.

A pair of expressions separated by a comma is evaluated left-to-right and the value of the left expression is discarded. The lvalue-to-rvalue (4.1), array-to-pointer (4.2), and function-to-pointer (4.3) standard conversions are not applied to the left expression. All side effects (1.9) of the left expression, except for the destruction of temporaries (12.2), are performed before the evaluation of the right expression. The type and value of the result are the type and value of the right operand; the result is an lvalue if its right operand is.

кстати можно написать и так

void zx()
{    char* tranName = new char [128];
     char* tranDets = new char [1024];
      
     (delete[]   tranName,delete[]  tranDets);
}

хороший вопрос для собеседования — какой тип у того что в скобках?

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

E> Какие выводы по соискателе позволяет сделать тот или иной ответ на этот "хороший" вопрос?

Вопрос будет состоять из двух частей
1) Расскажите что произойдет в результате выполнения данного кода.
2) Объясните, почему оператор запятая лучше вообще не применять.

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

Где то так...

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

CC>Но если вдруг ответит что память освободится по обоим указателям — серьезный "минус".
CC>Где то так...
IMHO ответ "хрен его знает, я так не пишу, возможно будет вот так, а возможно и так..." тоже подходит

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

А>Законен ли такой код?

А>

А>      char* tranName = new char [128];
А>      char* tranDets = new char [1024];
А>      ...
А>      delete[] tranName, tranDets;
А>

а еще можно сделать tranDets++ гдето по пути
чтоб от этого защитится лучше замутить так

template <class T>
 T  (&  ptr2ref(T *p) ) []
   { return (T (&)[])*p;
   }

int zzz()
{  int* tranDets = new int [128];
   int  tranName  [1024]; 
     

   int(&x)[ ]=ptr2ref( new int [128]);
   int(&y)[ ]=(int(&)[ ]) (  *tranDets );
   int(&z)[ ]=(int(&)[ ]) (   tranName );

   // здес х++ незя

    delete[] x;    
}

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

M>я например боюсь с++ экспертов, они как нааачнут работать крупными мазками, что потом не разберешься, что это...программа ваще или картина — "неизвестная с огурцом".

Про крупные мазки это было сильно.

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

E>IMHO ответ "хрен его знает, я так не пишу, возможно будет вот так, а возможно и так..." тоже подходит
За "я так не пишу" — жирный плюс
А вот "может быть так, а может эдак", если про удаление обоих заикнется — тогда все таки минус. Ну базовые ж вещи! Тем более при прямой работе с памятью.

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

P>чтоб от этого защитится лучше замутить так
По мне так проще указатель в RAII завернуть.

P>

P>template <class T>
P> T  (&  ptr2ref(T *p) ) []
P>   { return (T (&)[])*p;
P>   }

P>int zzz()
P>{  int* tranDets = new int [128];
P>   int  tranName  [1024]; 
     

P>   int(&x)[ ]=ptr2ref( new int [128]);
P>   int(&y)[ ]=(int(&)[ ]) (  *tranDets );
P>   int(&z)[ ]=(int(&)[ ]) (   tranName );

P>   // здес х++ незя

P>    delete[] x;    
P>}
P>

ИМХО тут еще проще запутаться и утворить непотребщину.
Не твори сущностей сверх необходимого (С)

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

CC>Вопрос будет состоять из двух частей
CC>1) Расскажите что произойдет в результате выполнения данного кода.
CC>2) Объясните, почему оператор запятая лучше вообще не применять.

CC>Если на первый вопрос будет восторженный рассказ как это круто писать через "," — есть повод для беспокойства.

Запись "delete x, y, z;" есть способ повысить минимальный уровень требований к осуществляющему code review, если, конечно, писавший такое понимает, что он делает "delete x;". Т.е. способ не подпускать новичков к своему коду, что например может позволить вместо

assert(true); // no preconditions

писать просто

assert(true);

...если Вы понимаете о чем я. Что в конечном итоге может повысить производительность труда, между прочим. Понятно, что такое применимо не для всех проектов.

CC>Если будут резкие возражения по второму вопросу — "минус" собеседуемому. Принцип KISS это наше всё

Это уже не KISS, это уже VB-like.

CC>Если вдруг он не знает про "," — это как раз не страшно.

Это говорит о неполных знаниях языка. А что он еще в языке не знает? operator= позволяет тоже очень хорошо выстрелить себе в ногу — так если он и его не знает — тоже ничего страшного — пусть пользуется лучше функцией very_safe_assign?

CC>Но если вдруг ответит что память освободится по обоим указателям — серьезный "минус".

Я бы сформулировал более жестко.

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

LMA>Запись "delete x, y, z;" есть способ повысить минимальный уровень требований к осуществляющему code review, если, конечно, писавший такое понимает, что он делает "delete x;".

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

LMA> Т.е. способ не подпускать новичков к своему коду, что например может позволить вместо
А какой смысл их не подпускать? В свое время столкнулись с капитальной нехваткой квалифицированных С++шников. Пришлось выбирать лучших из тех что были. И они должны были работать и желательно как можно более эффективно.
А вот такие запутывалки только тормозят понимание кода. Следовательно их использование скорее во вред.

LMA>Что в конечном итоге может повысить производительность труда, между прочим.
Несколько сомнительно, ну да ладно.

CC>>Если будут резкие возражения по второму вопросу — "минус" собеседуемому. Принцип KISS это наше всё
LMA>Это уже не KISS, это уже VB-like.
Что именно понимается под "это"? Почему VB-like?

CC>>Если вдруг он не знает про "," — это как раз не страшно.
LMA>Это говорит о неполных знаниях языка.
Разумеется. Но неполнота бывает разной. Эта как раз не фатальна — можно быстро объяснить как понимать такой код, заодно вбить в голову что самому так писать не следует.
Вообще я лично оценивал всегда как большой плюс, если на пример какого нибудь головоломного заворота кода собеседуемый отвечал что за такой код надо больно бить по рукам и заставлять переписывать. Разумеется если такой ответ приходил на простую конструкцию то эффект был как раз противоположный.
ИМХО некоторые возможности С++ людям со слабой волей лучше и не знать вовсе — не удержатся от применения везде где только можно. Получившуюся помойку потом и сами часто не могут отладить/модифицировать.

LMA> А что он еще в языке не знает?
Это и надо выяснять на собеседовании + испытательный срок еще есть для особо клинических случаев.

CC>>Но если вдруг ответит что память освободится по обоим указателям — серьезный "минус".
LMA>Я бы сформулировал более жестко.
+1