C / C++ / MFC

V.4-Aug-04 3:43

4-Aug-04 3:43

Also note that NULL and 0, '0' are NOT the same.
0 = a value
NULL is nothing, nada, ...

"If I don't see you in this world, I'll see you in the next one... and don't be late." ~ Jimi Hendrix

Tim Smith4-Aug-04 3:55

Tim Smith

4-Aug-04 3:55

NULL is often defined as 0 or 0L. It is implementation specific.

Tim Smith

I'm going to patent thought. I have yet to see any prior art.

Tim Smith4-Aug-04 3:57

Tim Smith

4-Aug-04 3:57

The only time the value is required to be zero is if the array is a global variable. Otherwise the value can't be predicted.

Tim Smith

I'm going to patent thought. I have yet to see any prior art.

STL iterators and post/pre incrementing

digwizfox4-Aug-04 6:16

digwizfox

4-Aug-04 6:16

Also, not mentioned before, is that static arrays are always initialized with zero for each value. I wouldn't recommend making a variable static for that reason alone, but it is interesting to remember that for future reference.

If you have an array that is in a global function and you don't want it to be reallocated on the stack every time the function is called, you could make an array static. The values are all zero the first time the function executes and after that, the values will stay in memory. The initialization only takes place once, even though the function call could be made many times.

Jim Crafton4-Aug-04 2:49

Jim Crafton

4-Aug-04 2:49

Someone on the VCF forums posted this, which I found a little strange, and was wondering if anyone here knew anything more:

"Also, when iterating an STL iterator, pre-increment (++it) should be preferred to post-increment (it++) as the latter creates a copy of the iterator."

Is this really true?

If I have code like:

vector<int> vec;
//populate vec
vector<int>::iterator it = vec.begin();
while ( it != vec.end() ) {
  int& i = *it;
  i = i * 45;
  it ++;
}

Should I change it to:

vector<int> vec;
//populate vec
vector<int>::iterator it = vec.begin();
while ( it != vec.end() ) {
  int& i = *it;
  i = i * 45;
  ++ it;
}

¡El diablo está en mis pantalones! ¡Mire, mire!

Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)!

SELECT * FROM User WHERE Clue > 0
0 rows returned

Antony M Kancidrowski4-Aug-04 2:57

Antony M Kancidrowski

4-Aug-04 2:57

Yes this is true. Similarly with the pre and post-decrement.

post-decrement makes a copy of the iterator.

Basically post-increment and post-decrement move the itterator by one position (forwards or backwards) and return an unmoved copy.

Ant.

I'm hard, yet soft.
I'm coloured, yet clear.
I'm fruity and sweet.
I'm jelly, what am I? Muse on it further, I shall return! - David Williams (Little Britain)

RChin4-Aug-04 3:45

RChin

4-Aug-04 3:45

In addition to Antony's reply, I myself have gotten into the habit of using pre-increments as well, but as I recall from a previous post on this topic, you will only see any performance benefit (if at all), on complex structures. Basic data types such as integers, characters and possibly simple class structures may not improve the performance either way.

I Dream of Absolute Zero

Nitron4-Aug-04 3:58

Nitron

4-Aug-04 3:58

Well, based on what Andrew Koenig says here[^], I would suggest you do this:

vector vec;
//populate vec
vector::iterator it = vec.begin();

while ( it != vec.end() ) 
{  
   int& i = *(it++);  
   i = i * 45;  
}

This way you increment the iterator AND use the result of the post-increment in one step. Wink | ;)

~Nitron.

ññòòïðïðB A start

digwizfox4-Aug-04 6:25

digwizfox

4-Aug-04 6:25

That's a good example and I agree. I've always had a problem with those who say that you're going to get some huge benefit to using pre-increment. But I will admit, by default, I always think pre-increment first, but if a post increment allows me to combine two lines of code into one I'll do that. In the example, post increment is critical. If you did a pre increment in that example, the behavior would be totally wrong as the increment would occur before the multiplication!

It's such a crapshoot to try and figure out what the compiler is going to do for you with all of the advanced compiler options. Make your code work correctly, first and foremost and if your performance meters indicate problems you can always refactor a bit during testing.

Regards,
Shawn

Tim Smith4-Aug-04 4:05

Tim Smith

4-Aug-04 4:05

In general it doesn't matter. But the problem is that you would have to know the implementation to be 100% sure.

Here is the p-code for a pre and post increment

post:

value v = ix;
ix = ix + 1;
return v;

pre:

ix = ix + 1;
return ix;

In 99.99% of the cases, the compiler isn't stupid and realizes it doesn't even need the return type and thus never even saves it. However, if your iterator is complex (something more than just a pointer), then the compiler might not be able to optimize away the extra constructor.

Get use to pre-increment. However, as someone pointed out, it isn't always the best thing either.

Tim Smith

I'm going to patent thought. I have yet to see any prior art.

Anonymous4-Aug-04 17:58

Anonymous

4-Aug-04 17:58

When you use POD then its ok to use i++, but if you use objects that supports pre-increment its best to use ++i as this does not create a temporary copy while i++ does, like stl iterators are best suited to ++i.

sorry

yingkou4-Aug-04 2:33

yingkou

4-Aug-04 2:33

I have made a mistaken

Antony M Kancidrowski4-Aug-04 2:59

Antony M Kancidrowski

4-Aug-04 2:59

That's OK! Unsure | :~

Ant.

I'm hard, yet soft.
I'm coloured, yet clear.
I'm fruity and sweet.
I'm jelly, what am I? Muse on it further, I shall return! - David Williams (Little Britain)

palbano4-Aug-04 4:59

palbano

4-Aug-04 4:59

yingkou wrote:
I have made a mistaken

Yeah that happens sometimes. I made one back in 1987.

"No matter where you go, there your are." - Buckaroo Banzai

-pete

yingkou4-Aug-04 15:19

yingkou

4-Aug-04 15:19

Sorry to interupt you,it is said that two programs in different computer can communicate by named piped in the book of Programming Application For Windows,
can you tell me the details?

thanks a lot