C++ “delete” used in comma separated multiple array name

[marhuum]

Is it valid to use single C++ “delete” in comma separated multiple array name, e.g.
delete [] objA, objB, arrayA, numA;

And so is the qualifiers used such as

 const int a=1, int b=3, char c=’n’;

?

[salem c]

> delete [] objA, objB, arrayA, numA;
No.

> const int a=1, int b=3, char c=’n’;
This isn't even syntactically valid.

But const int a = 1, b = 2;
would make b const.

This is easy for you to verify by simply trying it and observing error messages.

[dhayden]

This appears to be one of those sad cases in C++ where the syntax is legal but the meaning is not what you might think. delete [] objA, objB, arrayA, numA; is virtually identical to delete [] objA; objB; arrayA; numA;, or arranging it better:

delete [] objA;
objB;
arrayA;
numA;

Arranged like this, it's clearer what it does: first it deletes the array pointed to by objA. Then it evaluates objB and throws away the value. Then it does the same for arrayA and numA.

This works because delete[] objA is actually an expression. Does anyone know what the type and value of a delete expression is??

[dutch]

Does anyone know what the type and value of a delete expression is?

Apparently it's void (not much of an "expression").

int main() { auto val = (delete new int); }

delete.cpp:6:10: error: variable has incomplete type 'void'
    auto val = (delete new int);
         ^

Also: http://eel.is/c++draft/expr.delete

The delete-expression's result has type void.

[MikeyBoy]

Why is it that so many inexperienced C++ programmers are so desperate to use the comma operator all over the place, and yet so reluctant to read up on what it actually means? We see it time and time again here, where beginners use it in their code without having the slightest idea what it actually does.

Is there some weird urbam myth that it magically makes the compiler read your mind to find out what you really wanted your code to do, or something?

[Repeater]

If I had to guess, it's the same mindset that gives us this sort of thing:

if (x == 7 || 8)
{
  

People not yet thinking in the language structure, but thinking in words as if describing what they want to another person, and then trying to write that as code.

[dhayden]

When lots of people make the same mistake, you have to blame the source, not the student.

I like to compare computer languages to the electrical code. Electrical code and fittings are designed to be as foolproof as possible. It's hard to screw it up. C++ is the opposite, delete a,b,c and if (x=y) and if (x == 7 || 8) are all legal code, logical to a beginner, but don't do what you might expect. In a perfect language, it would be really hard to make these sorts of mistakes. The syntax would prevent it.

Getting to the original issue, I think it's because:

int *a,*b,*c;   // make 3 integers
delete a,b,c; // delete 3 pointers?  The compiler doesn't complain. 

[MikeyBoy]

I guess it's one unintended benefit the comma operator provides - it helps to teach lazy students not to assume that if their code compiles, it must be right. They have to do the work of understanding what the code they've written actually means, and what the right code is to do the job they want.

[Duthomhas]

It is a design characteristic of C and C++ — the syntax encourages “shortcuts”. New programmers are especially susceptible to syntax that reduces typing.

Indeed, if I were to present someone code like the following, many people would have an immediate impulse to “fix” it:

  auto a = f();
  auto b = g();
  if (a < b)
    ...

...except the “fix” is wrong, and would break code when least expected and giving someone a nice headache trying to figure out what went wrong.

Hint: think about side-effects.

[dhayden]

Hmm.... I see this side effect:

auto a = f();
auto b = g();  // f() guaranteed to be called before g()
if (a < b)
    ...

vs:

if (f() < g()) // f() and g() called in undefined order
    ...

Am I missing others?

[Duthomhas]

Nope, that’s it. :O)

[George P]

I can see people wanting to "fix" using auto, they have a pathological aversion to the keyword.

[Duthomhas]

Heh, I admit I didn’t think of that one... but yes, that could become a source of error as well.

The primary use of auto should be to preserve ODR.

The reason for not using auto should be to enforce required data type.

People with a didactic anti-auto mentality are time wasters.

IMNSHO.

[helios]

I really do not like that evaluation order is undefined for subexpressions of the same precedence. Also, that order of member initialization depends on order of declaration. Some poor fool can come along thinking "I'm going to tidy things up a bit!" and utterly break your stuff. Good luck debugging events that happen outside of a function.

[George P]

I have to admit I do have a semi-pathological aversion to using namespace std;, I won't use it. I will suggest to others to not use it, but that is about as far as I go.

I use auto for reducing the amount of typing (and source of typo errors) when creating STL iterators, etc.

Maybe I'm spoiled by MSVC's IDE "intellisense" feature that can display for auto a tooltip of the underlying data type when hovering the mouse pointer over the code for a second or two.

[dhayden]

I really do not like that evaluation order is undefined for subexpressions of the same precedence.

It isn't just subexpressions of the same precedence. In f() + g() * h(), the functions could be evaluated in any order. The only requirement is that * occurs before +. In general, operators are evaluated in a specific order, but operands are not. There are well known exceptions, such as short circuit || and &&, and probably lesser known exceptions too, but I find it handy to assume that operands are evaluated in undefined order, except for the well known exceptions.