Sign in to follow this  
exa_einstein

WTF??!! NULL is not defined in MSVC60??!!

Recommended Posts

I tried to compile a system of some nested classes and what happenned.. (small code dump:)

// in header file of the class

class gravityobjectsystem:public spaceobject
{
	spaceobject* soa;
	int nso;
public:
	gravityobjectsystem();
	virtual ~gravityobjectsystem();

///...........
// and then in .cpp file ...

gravityobjectsystem::gravityobjectsystem()  //constructor
{
	nso=0;
	soa=NULL;
}
//....
I thought that this sholdn't be a problem, but MSVC6.0 came with two errors: error C2065: 'NULL' : undeclared identifier //??????!!!!!! error C2440: '=' : cannot convert from 'int' to 'class spaceobject *' does somebody had any similar problem? I though NULL is valid zero pointer really EVERYWHERE? ISN'T??!! WTF?!!! helpme... (i don't want to #define my own NULL) exa_einstein

Share this post


Link to post
Share on other sites
I know this, but question here is a little more about that "Has the NULL disappeared?" bug in visualC? (I have really checked everything)

ok,ok. now I use soa=(spaceobject*)0; because soa doesn't look like normal integer with it...

Share this post


Link to post
Share on other sites
NULL is #defined or whatnot in various library headers. If you don't include any of these in your project, then NULL is just an undeclared identifier. If you really want you can always add
#ifndef NULL
#define NULL 0
#endif
to your code, although switching to simply using 0 might be just as good. Only a few rare systems using something other than 0 for NULL. I'd switch, but I'm too lazy at the moment. Actually, if it's a big enough project, I'd probably just make my own const variable that matched the naming convention of the rest of my constants, and was in the proper namespace, too, if I was using namespaces.

Share this post


Link to post
Share on other sites
class Null
{

public:

template <typename TYPE>
operator TYPE*() const
{
return 0;
}

};

const Null null;

GravityObjectSystem::GravityObjectSystem()
{
aDescriptiveName = 0;
anotherDescriptiveName = null;
}

Simple, clean, unambiguous.

Enigma

Share this post


Link to post
Share on other sites
Hi,

Quote:
Original post by exa_einstein
I thought that this sholdn't be a problem, but MSVC6.0 came with two errors:

error C2065: 'NULL' : undeclared identifier //??????!!!!!!
error C2440: '=' : cannot convert from 'int' to 'class spaceobject *'

does somebody had any similar problem? I though NULL is valid zero pointer really EVERYWHERE? ISN'T??!! WTF?!!!


You thought wrong. NULL is *not* defined everywhere. One of these days, try to compile the following code:


int main() {
void* ptr = NULL;

return 0;
}




I just did, and GCC gave me the following:


test.c: In function `main':
test.c:2: `NULL' undeclared (first use in this function)
test.c:2: (Each undeclared identifier is reported only once
test.c:2: for each function it appears in.)


That is because NULL is not a symbol defined by default, but is contained in stdlib.h. (And also happens to be defined in windows.h, and some other headers.)

Vovan

Share this post


Link to post
Share on other sites
Quote:
Simple, clean, unambiguous.

Correction: overcomplicated, clean, and potentially ambiguous.

1. Overcomplicated. In C++ you use 0. If you feel an irrational need to use the word NULL instead of the numeric constant zero, you just # define NULL 0 or include one of the standard headers that is supposed to do that for you. Defining a template class to emulate the numeric constant zero is ridiculous.

2. Clean. For what its worth, you did a good job formatting it, so I'll give it a 8.5. Technically, you should have used T for TYPE since it's shorter and just as obvious since it is well known.

3. Potentially ambiguous. You unnecessarily introduced several additional names into whatever namespace you would define this class and its instance, and when other people attempt to define their own versions of "null", you have created the potential for naming conflicts. No one will get such conflicts using 0 or the standard NULL macro.

However, it is interesting since I never would have thought of it and nostalgic since it brings to mind an old topic.

Share this post


Link to post
Share on other sites
Hi,

Quote:
Original post by null_pointer
2. Clean. For what its worth, you did a good job formatting it, so I'll give it a 8.5. Technically, you should have used T for TYPE since it's shorter and just as obvious since it is well known.


LOL, you didn't take points off for the fact that he used hard tabs for indentation instead of spaces? :P

Seriously, I think the C-style NULL pre-proc symbol works just as well in C++. Don't really see a reason to wrap it in an object of its own. :)

Vovan

Share this post


Link to post
Share on other sites
In C++, the standard requires NULL to be defined if you include the clocale, cstddef, cstdio, cstdlib, cstring, ctime and cwchar headers. If you don't include any of these headers, you have no guarantee that NULL will be defined. (Of course other headers may include these headers themselves, so you may get NULL defined even if you don't include them directly, but you can't rely on such implementation specific behaviour.)

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
LOL, you didn't take points off for the fact that he used hard tabs for indentation instead of spaces? :P


I never understood the hatred of hard tabs. Whats wrong with everyone being able to configure their editors to display the indentation however they feel comfortable with? Not to mention it saves just a tiny bit of space.

Share this post


Link to post
Share on other sites
Hi,

Quote:
Original post by Anonymous Poster
I never understood the hatred of hard tabs. Whats wrong with everyone being able to configure their editors to display the indentation however they feel comfortable with? Not to mention it saves just a tiny bit of space.


Well, the space argument is silly. If we want to save space, why don't we just type all the code on one line. Dropping newlines would also save a bit of space. ;)

As far as configuring your editor, well, not all editors can be configured. :) What with people who use notepad, or it's glorified brother - vi?

I guess my own "fear" of tabs comes from my experience in college classes. Every Java project there had to go cleanly through checkstyle, and that program complains about tabs. :)

But really, I was just trying to be funny, hence the :P. ;) I thought it was a little odd that null_pointer commented on the use of TYPE instead of T, and neglected to mention hard tabs instead of spaces. :)

Vovan

Share this post


Link to post
Share on other sites
Quote:
I thought it was a little odd that null_pointer commented on the use of TYPE instead of T, and neglected to mention hard tabs instead of spaces. :)


Assigning zero to a pointer is a C++ convention used to express a null pointer, but some of us think that we have to spell out the word N-U-L-L in all of our null pointer expressions for some reason. That's what I was objecting to; not the use of null pointers. :)

As for the tabs, well, the approach is clearly superior to spaces. Some people prefer 2, 3, or 4 spaces. I think that making the source code less flexible just to cope with silly editor deficiencies would be a very bad long term solution.

(And while we're ranting about "infinitely trivial" things, what the heck happened to all the smiley graphics in the posts? Is that only for paying members now? Or mayhap mine actions hath offended the mods?)

Share this post


Link to post
Share on other sites
The smiley codes were replaced with codes you're less likely to type when you don't mean 'em; see the FAQ for details. We were all fed up with things like std::pair showing up as std:[razz]air.

Share this post


Link to post
Share on other sites
The forum FAQs are actually being used? [cool]

BTW the [attention] icon appears to be corrupted in Firefox 9.2. It's got a wierd whitish border around it that makes it hard to figure out that it's a yellow exclamation mark. Um...that is what it is, right? [looksaround]

Share this post


Link to post
Share on other sites
is there anyone on this earth who still thinks that "hard tabs" are a formatting mistake and "spaces" are good white space usage??? (I know there are, but I'm here to say once and for all that a proper formatting convention never ever needs space based alignment and works properly no matter how large a tab is on the viewing system - hence the reason tabs are preferable).

Here's the One Rule:

Every source line is lined up to either -1, 0, or +1 tabs of the line above it.

Here's the One Exception:

A line may be aligned more than one tab less than the line above it if and only if the preceeding line was logically nested multiple levels and did not use braces surrounding the blocks

Share this post


Link to post
Share on other sites
Not using braces is bad. Easy to screw up if you are changing stuff around that block. Difficult to find when you do, especially if it is code you wrote a long time ago and can't remember exactly what it SHOULD look like. I say always use braces! Then this will never happen:

if( x )
   DoSomething( x );
   DoSomethingElse( x );

Use (put the braces however you feel works best, as long as you do put them)
if( x )
{
   DoSomething( x );
   DoSomethingElse( x );
}

and you will never have to find that bug...

- Benny -

Share this post


Link to post
Share on other sites
Hi,

Quote:
Original post by Xai
is there anyone on this earth who still thinks that "hard tabs" are a formatting mistake and "spaces" are good white space usage??? (I know there are, but I'm here to say once and for all that a proper formatting convention never ever needs space based alignment and works properly no matter how large a tab is on the viewing system - hence the reason tabs are preferable).

Here's the One Rule:

Every source line is lined up to either -1, 0, or +1 tabs of the line above it.

Here's the One Exception:

A line may be aligned more than one tab less than the line above it if and only if the preceeding line was logically nested multiple levels and did not use braces surrounding the blocks


Well, I personally, couldn't care less if a person uses tabs or spaces - as long as they don't mix them, because then chances are my tab width setting is different, and everything gets screwed up. However, the Sun coding convention says the following:


Four spaces should be used as the unit of indentation. The exact
construction of the indentation (spaces vs. tabs) is unspecified.
Tabs must be set exactly every 8 spaces (not 4).


So, according to Sun, a tab is *two* units of indentation, hence they pretty much encourage to either use spaces only or mix tabs and spaces. That's why I think, if you adhere to a standard like this, you are better off using spaces only. If you couldn't care less about a standard and just want for your code to look pretty then use tabls all you want. ;)

Vovan

Share this post


Link to post
Share on other sites
Quote:
Original post by benstr
Not using braces is bad. Easy to screw up if you are changing stuff around that block.


News to me. I use lines like:

if (N >= VElements) throw FatalException("Industry::Lib::Vector< T >::AtOK() - Element out of range");
if (VElements == N) return;
for ( SizeT I = 0 ; I < VElements ; ++ I ) VMemory[I]->~T();
do TestVector[i++] = *CopyIn; while ( *(CopyIn++) );


all the time, without problems.

Of course, if YOU find it a problem, it's understandable why you'd avoid the syntax yourself. I just don't think that being braceless is bad for those who don't have problems with it.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this