Thread: What do you guys think about this?

I agree on the true/false vs. 1/0 issue.

Originally Posted by Bubba

Still not implemented in MSVC .NET 2005. Calling delete on a NULL pointer will cause an exception. I know it's not supposed to be that way, but then when does MS listen to anyone but themselves?

What? This compiles and runs fine in 2005:

Code:

int main()
{
    delete (char*)0;
}

As I am now the person evaluating programmers this company will hire, I can tell you that I would consider this a black mark against you (if I was interviewing you).

Its not your teachers job to make the language/code simpler. Its your teachers job to ensure you can handle any programming task put before you. Even if that means knowing where/when to ask for help.

>>Should have perhaps mentioned that the OU (Open University) course I'm currently doing insists on i=i+1 instead of i++...

Great, so when you get out into the real world, find that all C++ code contains these operators, you will be have difficulty reading it (as opposed to someone who was taught to use them).

Its not like all the code that contains these operators (or the programmers who wrote it) are going away soon.

If something as simple (IMHO) as as these operators confuses you then you are going to have issues reading 'real world' code.

Erm, I wasn't stating my original post as my opinion, or implying that I was confused by it. What precisely is it that you would see as a black mark against me? There's nothing actually wrong with i=i+1, just as there's nothing (as far as I can see) wrong with i++.

Please explain

What precisely is it that you would see as a black mark against me?

I think novacain's reasoning is that since your teachers teach in this way, the students are likely to be unable to deal with real world code. You thus will be lumped in that category (of probably incompetent programmers), even if you are actually different.

Some justification, again quoted. (MT262 is the course I'm doing currently). To be fair, the course isn't a C++ course as such, it's more a general programming principles course that happens to use C++.

C++ has #defines which can look like functions:

Code:

#define squareit(x) (x*x)

Then you can use it to square numbers:

Code:

int MyInt;  
int NumberThree;  	
NumberThree = 3;  	
MyInt = squareit(NumberThree); // Now MyInt has the value 9.

BUT some programmers combine ++ and 'function' calls.

These clever people would write

Code:

MyInt = squareit(NumberThree++);

and would expect MyInt to be 9 and NumberThree to be 4. Instead, MyInt would be 9 but NumberThree would be 5, try it if you don't believe me :-)

Moral: don't use ++. Ok it is safe in some places, but explaining exactly where is beyond MT262.

BTW You don't know what (in a library) is a genuine function and what is a macro, and they can and do change over time. Code gets broken that way.

>> I read somewhere that using i++ actually results in more optimized code

I could be wrong, but I doubt that.

Moral: don't use ++. Ok it is safe in some places, but explaining exactly where is beyond MT262.

Actually, I think that the moral in this case is to avoid macros as pseudo-functions. If it was an actual (inline) function, the use of ++ would not be a problem here.

For example, the code would also fail in:

Code:

MyInt = squareit(NumberThree + 1);

Since that would be expanded to:

Code:

MyInt = NumberThree + 1 * NumberThree + 1;

which leads to:

Code:

MyInt = NumberThree + NumberThree + 1;

The more correct macro definition would be:

Code:

#define squareit(x) ((x)*(x))

>I read somewhere that using i++ actually results in more optimized code
In C++, this can easily be the case with classes that overload the operator. For primitive types, you can expect identical machine code from i=i+1, i+=1, ++i, and i++ when used as standalone statements. Anything less would get a compiler laughed out of business, since this is a supremely trivial optimization.

Moral: don't use ++. Ok it is safe in some places, but explaining exactly where is beyond MT262.

Some canned example:

int x = getc(f++);
[Warning 666] Expression with side effects passed to repeated parameter 1 in macro 'getc'

Moral: choose good tools.

Moral: don't use ++. Ok it is safe in some places, but explaining exactly where is beyond MT262.

It's beyond MT262 because they cannot justify this.

It is sadly ironic that a programming course uses what is widely considered bad practice (macros) to justify the removal of a style that is widely considered a standard and good practice (increment and decrement operators).

It's sadly ironic and ridiculous.

It is sadly ironic that a programming course uses what is widely considered bad practice (macros) to justify the removal of a style that is widely considered a standard and good practice (increment and decrement operators).

haha, I checked out Stroustrup's technical FAQ on macros, and what RobR's tutor mentioned was indeed an example, except that it was about... what's wrong with using macros.

One of the most common subtle problems is that a function-style macro doesn't obey the rules of function argument passing. For example:

Code:

#define square(x) (x*x)

void f(double d, int i)
{
	square(d);	// fine
	square(i++);	// ouch: means (i++*i++)
	square(d+1);	// ouch: means (d+1*d+1); that is, (d+d+1)
	// ...
}

The "d+1" problem is solved by adding parentheses in the "call" or in the macro definition:

Code:

#define square(x) ((x)*(x))	/* better */

However, the problem with the (presumably unintended) double evaluation of i++ remains.