On Jan 7, 2012, at 11:39 AM, Tomaz Canabrava wrote:
Stroustrup answer to that:
Should I use NULL or 0?
In C++, the definition of NULL is 0, so there is only an aesthetic difference. I prefer to avoid macros, so I use 0. Another problem with NULL is that people sometimes mistakenly believe that it is different from 0 and/or not an integer.
Actually, for a modern compiler NULL is not an integer.
C++ did a bit of a change, and 0 gained special meaning. I believe that most of the systems where it made an actual difference are now gone, but it did.
However... the main reason I made the code change is that when I updated to gcc 4.5.2, it started warning on that constructor. It complained that we were setting a pointer value into a non-pointer variable.
So we probably have NULL defined as some pointerish macro or value and which should not be assigned to integer variables, while '0' is a magical constant that the compiler knows to just do the right thing with for both pointers and integers. '0' by the C++ language definition works in all cases, but NULL does not.
This and the associated warning start to become very important for 64-bit code. Mixing integers and pointers leads to major problems.
Bottom line, though, is that we need to remove warnings by fixing the code. The pointer assignments in that initializer could be changed to "NULL", but the integer ones need to stay changed to zero.
As a non-OOP programmer I have to walk inkscape's code to understand it. When the code behavior is unexpected given the assumed data type , it can be confusing. Pointers are no problem until parameters are passed. A few calls later if an incorrect assumption was made about the data type then the code can appear to be inscrutable. The 0 values indicate a data type that don't match up with code behavior.
I realize that Inkscape is an incredible programming achievement. But this bit of info is very helpful to people like me. Thanks, Johan!
Susan Spencer
Sent from my iPhone
On Jan 7, 2012, at 13:54, Jon Cruz <jon@...18...> wrote:
On Jan 7, 2012, at 11:39 AM, Tomaz Canabrava wrote:
Stroustrup answer to that:
Should I use NULL or 0?
In C++, the definition of NULL is 0, so there is only an aesthetic difference. I prefer to avoid macros, so I use 0. Another problem with NULL is that people sometimes mistakenly believe that it is different from 0 and/or not an integer.
Actually, for a modern compiler NULL is not an integer.
C++ did a bit of a change, and 0 gained special meaning. I believe that most of the systems where it made an actual difference are now gone, but it did.
However... the main reason I made the code change is that when I updated to gcc 4.5.2, it started warning on that constructor. It complained that we were setting a pointer value into a non-pointer variable.
So we probably have NULL defined as some pointerish macro or value and which should not be assigned to integer variables, while '0' is a magical constant that the compiler knows to just do the right thing with for both pointers and integers. '0' by the C++ language definition works in all cases, but NULL does not.
This and the associated warning start to become very important for 64-bit code. Mixing integers and pointers leads to major problems.
Bottom line, though, is that we need to remove warnings by fixing the code. The pointer assignments in that initializer could be changed to "NULL", but the integer ones need to stay changed to zero.
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Jan 7, 2012, at 12:17 PM, Susan Spencer wrote:
As a non-OOP programmer I have to walk inkscape's code to understand it. When the code behavior is unexpected given the assumed data type , it can be confusing. Pointers are no problem until parameters are passed. A few calls later if an incorrect assumption was made about the data type then the code can appear to be inscrutable. The 0 values indicate a data type that don't match up with code behavior.
I realize that Inkscape is an incredible programming achievement. But this bit of info is very helpful to people like me.
I think between you and Johan we have a good point to explore.
There are some things about C++ (and OOP in general) that differ from C. Some are stylistic, but then others get to be more functional.
We want to get our code quite clear and easy to work with. We of course also want to get the program powerful, and the code efficient.
I have the feeling that certain underlying principals here overlap with some things I'd been going over recently with people at work. We had been discussing a few things about Microsoft "hungarian" notation, and why it is bad. Part of what we hit upon involved how it interferes with C++ and the OOP approach (where one treats all types as the same, and not different from each other). This aspect becomes quite evident if one considers C++ templates and code that applies to pointers, integers, complex classes, etc. all with no changes.
It probably is a very good idea to capture some of this. At the very least we should get any question a person new to our codebase might ask identified and recorded so we can consider things. In general we get a choice of either changing how some approach to code is used, or changing what people know about our code. Capturing as much as we can in the wiki and making sure it's easy to see and use is probably a very good thing.
On 7-1-2012 20:54, Jon Cruz wrote:
On Jan 7, 2012, at 11:39 AM, Tomaz Canabrava wrote:
Stroustrup answer to that:
Should I use NULL or 0?
In C++, the definition of NULL is 0, so there is only an aesthetic difference. I prefer to avoid macros, so I use 0. Another problem with NULL is that people sometimes mistakenly believe that it is different from 0 and/or not an integer.
Actually, for a modern compiler NULL is not an integer.
C++ did a bit of a change, and 0 gained special meaning. I believe that most of the systems where it made an actual difference are now gone, but it did.
However... the main reason I made the code change is that when I updated to gcc 4.5.2, it started warning on that constructor. It complained that we were setting a pointer value into a non-pointer variable.
So we probably have NULL defined as some pointerish macro or value and which should not be assigned to integer variables, while '0' is a magical constant that the compiler knows to just do the right thing with for both pointers and integers. '0' by the C++ language definition works in all cases, but NULL does not.
This and the associated warning start to become very important for 64-bit code. Mixing integers and pointers leads to major problems.
Bottom line, though, is that we need to remove warnings by fixing the code. The pointer assignments in that initializer could be changed to "NULL", but the integer ones need to stay changed to zero.
Of course the int should be initialized with '0', but pointers should be with 'NULL'. The code was wrong indeed, and was fixed. But it created some other 'wrongness' that heavily annoyed me. (and because I remembered some talk about 0 vs. NULL before, I decided to kill it now so it doesn't spread) Fixed in r10859.
I think _verb_t should be initialized with SP_VERB_INVALID. However, the verb enumeration does not set SP_VERB_INVALID explicitly to 0. But perhaps someone with more knowledge of the swatch code can have a more detailed look at it. For example, line 180 looks like it should also include a test for _verb_t != SP_VERB_INVALID.
Thanks, Johan
On 08-01-12 01:09, Johan Engelen wrote:
...
Of course the int should be initialized with '0', but pointers should be with 'NULL'. The code was wrong indeed, and was fixed. But it created some other 'wrongness' that heavily annoyed me. (and because I remembered some talk about 0 vs. NULL before, I decided to kill it now so it doesn't spread) Fixed in r10859.
Instead of using NULL, we might want to start using nullptr. This will be supported by future compilers (apparently GCC 4.6 already supports it), and a work around can be used right now, as described in the proposal: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2431.pdf
The main advantage of nullptr compared to NULL is that it is more type-safe. Also, if anything it is even more descriptive than NULL.
2012/1/9 Jasper van de Gronde <th.v.d.gronde@...528...>:
The main advantage of nullptr compared to NULL is that it is more type-safe. Also, if anything it is even more descriptive than NULL.
Actually there might be little to no advantage in changing NULL to nullptr because compilers typically define NULL not to 0 but to an implementation-defined value that can be converted without a cast to any pointer type, which is equivalent to nullptr. For example g++ defines NULL to __null which is an internal magic constant. The name "nullptr" just exposes this to the user.
Regards, Krzysztof
participants (5)
-
Jasper van de Gronde -
Johan Engelen -
Jon Cruz -
Krzysztof Kosiński -
Susan Spencer