Crash on GetNext()!!!
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 05/05/2006 at 01:18, xxxxxxxx wrote:
I agree that scenarios exist (especially after a little research) where NULL may be '\0' or (void* )0 (bad ideas if you ask me).
Who knows (that's rhetorical) what other implementations are in use for embedded or more esoteric systems.I'd have to consult the book you reference, but actually,
my feeling is that none of these is correct (I know, I'm better than all of them - lol). Since pointer arithmetic has standardized an 'unset pointer' to a value of 0 so that it is basically an address for no other purpose (one usually reserved by the basic system), the (!p) usage would seem more appropriate in that it is independent of bit-size, whereas comparing to 0 (or the equivalent NULL definition) would need to be converted to the appropriate size to cover the bits. For instance, if NULL is defined: #define NULL 0, that means that it is interpreted as an int (by default), but all memory addressing on 32+ bit systems is at least long int which should be: #define NULL 0L. (!p) covers all bits irrespective (they all have to be 0 for the result to return TRUE), if the NULL == 0 holds, of course.On the other hand, NULL won't work in situations where the pointer is used as a 'stop'. I do this quite often with arrays, as a synonym for the last index:
MyClass* firstItem;
MyClass* lastItem;for (MyClass* item = firstItem; item != lastItem; item++);
lastItem doesn't point to an existent last item in the array or list, but one beyond it for loop cessation. In this situation, comparing lastItem to NULL (because it is in reality invalid not unset) would be catastrophic. It doesn't represent an unset pointer, but an invalid pointer in a linear block of memory.
But, if it is a linked list, the NULL check holds (though I'm using the boolean equivalent here, I think) :
for (MyClass* item = firstItem; item; item = item->GetNext());
Note the subtle difference.
Since my main languages have been C and Java (I skipped class on C++ for quite a while), I'd have to see what Meyers recommends. Always willing to learn. By the way, is it not true that a new C++ standard is in the works - yikes! More to learn.
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 05/05/2006 at 01:28, xxxxxxxx wrote:
hmm, maybe I got it in the wrong direction? Your statements seem feasible. I got to get that book again, not that my mind plays tricks with me and I am pointing to the exact opposite direction here and Ben curses me for this and I die a painful death.
My brother must have this lying around anywhere, so I´ll be checking this once I visit him again and let you know about it.
About new C++ standard in the works - there is? I haven´t heard of it, but yikes! hits the spot very well.
My brother is also Java and C++ programmer btw. (for Volkswagen). I seem to always sourround myself with guys like you...tss ;-D
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 05/05/2006 at 01:30, xxxxxxxx wrote:
Yep, C++ is weird - which is why I skipped class. Understanding how a computer works and how a language implements this knowledge are two different things, I suppose. This may be why Assembly is appealing to some - the specifications and results are about as direct as you can achieve without doing the electronics yourself.
Would this be the book:
"Effective C++ : 55 Specific Ways to Improve Your Programs and Designs (3rd Edition) (Paperback)"
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 05/05/2006 at 01:31, xxxxxxxx wrote:
yep, this should be the book! Although for me it was 50 ways to improve your programs and designs (I had the 2nd Edition then I guess).
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 05/05/2006 at 01:38, xxxxxxxx wrote:
Just wanted to add, (void* )0 seems to be the C macro you´re talking about right?
I don´t know why C++ does not use NULL like in Smalltalk where it´s a specially defined NULL-object that you can refer to instead of a numeral representation. Then we wouldn´t have to discuss this.
And I think Java does not need to worry about all this at all? But I don´t know nothing about Java actually, only that you don´t have to worry about memory and pointers.
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 05/05/2006 at 02:05, xxxxxxxx wrote:
Yes, the (void* )0 was a C implementation of NULL - interesting, but it means a conversion from a defined pointer type to void - ugly ain't it.
Well, this was the 'decided upon' definition of 'NULL' for pointers way back, I guess. Whoever made the decision decided that the memory address of an unset pointer should be equal to zero - this may have its roots in assembly (it has been quite some time). The problem isn't the standard notion of null pointer equals zero as much as how it gets interpreted into each language based upon its syntax and purpose.
Java does indeed have a null reference. You do have to worry about class allocation (new) and validity (delete) just as in C++. Even though references to instances are handled automatically by garbage collection (when there are none, the memory is released), the references to them are still subject to validation. Most of the time, this is not a concern since you may have members still referencing and the instance will persist, but if you are getting the instance reference from, say, a method, you might want to check.
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 05/05/2006 at 02:11, xxxxxxxx wrote:
Quote: Originally posted by kuroyume0161 on 05 May 2006
>
> * * *
>
> Yes, the (void* )0 was a C implementation of NULL - interesting, but it means a conversion from a defined pointer type to void - ugly ain't it.
>
> * * *hihi, yep
> Quote: Java does indeed have a null reference. You do have to worry about class allocation (new) and validity (delete) just as in C++. Even though references to instances are handled automatically by garbage collection (when there are none, the memory is released), the references to them are still subject to validation. Most of the time, this is not a concern since you may have members still referencing and the instance will persist, but if you are getting the instance reference from, say, a method, you might want to check.
>
> * * *
>
> * * *Ah I see. Well, that sounds way easier though. I´ve been interested in Java since I´ve heard that ZBrush is coded in Java, which sounds like Java can be effectively used to create such applications (and I am thinking about writing sth like ZBrush just for learning purposes...darn, where is Father time?).
Samir
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 05/05/2006 at 02:18, xxxxxxxx wrote:
All of this is interesting, if not off topic.
It is interesting to note why 0 was used. At some point, someone was realizing that memory references (pointers) must become invalid for one reason or another (during initialization or when the memory is released). And a value had to be established (since memory addresses are just numbers). -1 might have been a candidate, but think of the consequences. -1 in 16-bit is 0xFFFF, which is a possibly valid 32-bit address, 0x0000FFFF. And so on for memory address sizes. Any other value could lead to similar results. But 0, to some extent, is 0 at all levels (though floating point has the odd distinction of 0 and -0 (because of the sign bit)).
This link is interesting (C reference) : Null Pointers
And this supports your understanding: C++ Null Pointers
I agree that unitialized pointers are not 'unset' pointers. When you initialize pointers, it should be to NULL (and I never use 0 in this case, oddly enough).
The things we learn...
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 05/05/2006 at 02:27, xxxxxxxx wrote:
Thanks for the links. Will check these out.
Off topic? Naaahh.
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 05/05/2006 at 06:36, xxxxxxxx wrote:
Hi all,
Well, I found my problem!!!
I somewhat missed the following statement in the SDK doc:
The compiler options for Pointer-to-member representation must be set to "General-Purpose Always" and "Point to Single-Inheritance Classes" in C++ tab/C++ language (/vmg /vms). If not set the plugin will crash instantly!Well, the plugin was able to do a lot of things (volumetric shaders, creating objects, some motion handler, etc.) but it crashed on several things...so it was not crashing instantly unfortunately (it would have been easier to find the error in this case...)
Now everything is working perfectly!
Best regards,
Ben -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 05/05/2006 at 06:52, xxxxxxxx wrote:
great that it wasn´t anything anybody suggested.
Thanks for letting us know and glad you found the prob.Best
Samir -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 05/05/2006 at 10:34, xxxxxxxx wrote:
Very good, Ben!
Note that it is a good idea to use one of the included projects (either the api_lib or cinema4dsdk) as a basis for your plugin's. Then these settings will be already proper.