|
This thread is locked; no one can reply to it. |
1
2
|
'NULL' was not declared in this scope |
BAF
Member #2,981
December 2002
|
You have null be a keyword that means NULL (a value which could never be held by any variable). Doesn't have a literal definition, just a symbolic one to the compiler. |
Arthur Kalliokoski
Second in Command
February 2005
|
Quote: (a value which could never be held by any variable) And what would that value be, without going to 96 bit ints or whatever? Even if it's a #define, any equivalent sequence of bits could be in a regular integer variable. They all watch too much MSNBC... they get ideas. |
Thomas Fjellstrom
Member #476
June 2000
|
Quote: And what would that value be, without going to 96 bit ints or whatever? Even if it's a #define, any equivalent sequence of bits could be in a regular integer variable. It would have to be a compile time thing. Its hard to do if you never plan for this sort of feature ahead of time. Perl has a special "undef" flag on scalars, its not 0, its not any kind of null or "" (empty string), its special and perl complains loudly if you use undefined variables (if you tell it to of course, but I always do, it finds so many bugs, and has trained me to not use undefined variables). -- |
X-G
Member #856
December 2000
|
That would not work for C++. It works in dynamically typed languages because you can have a Null type, which can only be a single value -- null (or None, or Nothing, or whatever you like). That way, you can assign the null constant to any variable at any point. Python and PHP both work this way. C++ is not dynamically typed, so this solution is out. As far as I know, Perl's undef construct is different; it directly manipulates the relevant symbol table, removing the identifier associated with a particular variable. PHP can do this too, I believe. Obviously, this will not work for a statically typed language like C++. -- |
Thomas Fjellstrom
Member #476
June 2000
|
Quote: That would not work for C++. Obviously not, it was just for comparison's sake. As I mentioned, anything C++ could do would have to be magic compiler syntax that ends up being mostly useless since you wouldn't be able to check the undef/nullity state at runtime with any sort of accuracy. -- |
Tobias Dammers
Member #2,604
August 2002
|
It does not have anything to do with dynamic vs. static typing, nor with compiled vs. interpreted. For example, C#, being compiled (at least half-way), and with basically static typing, DOES have a null keyword, and C#'s null does not compare equal to zero. --- |
X-G
Member #856
December 2000
|
That doesn't change the fact that C++ does not have anything like variable type flags; a long int may be 32 bit, say, and nothing more or nothing less, and each of those 32 bits are accessible. There is no "metadata" to say "this is null". In other words, null is indistinguishable from a particular value that datatype can contain, such as the number zero. -- |
Tobias Dammers
Member #2,604
August 2002
|
An int cannot be null; a pointer can, though, and C++ is capable of adding type information to those. --- |
bamccaig
Member #7,536
July 2006
|
// nullcmp.cs using System; namespace NullCmp { public class Program { private static int Main(string[] args) { System.Console.WriteLine("(null==0)={0}", (null == 0)); return(0); } } }
prompt>csc nullcmp.cs Microsoft (R) Visual C# 2005 Compiler version 8.00.50727.1434 for Microsoft (R) Windows (R) 2005 Framework version 2.0.50727 Copyright (C) Microsoft Corporation 2001-2005. All rights reserved. test.cs(10,46): warning CS0472: The result of the expression is always 'false' since a value of type 'int' is never equal to 'null' of type 'int?' prompt>test (null==0)=False Interestingly, apparently "null" is of type "int?". I'm curious how it is stored under the surface.
prompt>csc nullcmp2.cs /unsafe Microsoft (R) Visual C# 2005 Compiler version 8.00.50727.1434 for Microsoft (R) Windows (R) 2005 Framework version 2.0.50727 Copyright (C) Microsoft Corporation 2001-2005. All rights reserved. prompt>test (0==null)=True (0==null)=True I may have done something wrong or perhaps the results don't represent the actual implementation, but it seems possible that C# is storing null as 0. There's a good chance I'm overlooking something or lack the understanding to see the difference. I don't actually know how pointers or unsafe code works in C# yet so this is all just a guess. -- acc.js | al4anim - Allegro 4 Animation library | Allegro 5 VS/NuGet Guide | Allegro.cc Mockup | Allegro.cc <code> Tag | Allegro 4 Timer Example (w/ Semaphores) | Allegro 5 "Winpkg" (MSVC readme) | Bambot | Blog | C++ STL Container Flowchart | Castopulence Software | Check Return Values | Derail? | Is This A Discussion? Flow Chart | Filesystem Hierarchy Standard | Clean Code Talks - Global State and Singletons | How To Use Header Files | GNU/Linux (Debian, Fedora, Gentoo) | rot (rot13, rot47, rotN) | Streaming |
Arthur Kalliokoski
Second in Command
February 2005
|
Quote: An int cannot be null
Third time I've posted this... They all watch too much MSNBC... they get ideas. |
Tobias Dammers
Member #2,604
August 2002
|
Quote: NULL == NIL == NADA == NOTHING == 0 == ZILCH.
Not true. Conceptually, Null is something very different from zero, and most languages (but not C / C++) treat it as such - even though in many of them, NULL (or the language equivalent) compares equal to zero due to implicit conversions. Quote: Interestingly, apparently "null" is of type "int?". I'm curious how it is stored under the surface. In C#, null is of type Null (a class that can only ever carry the null value). Since you're comparing it to an int, though, the compiler applies an implicit conversion, using a type that can both be assigned a null value AND be equality-compared to an int. The best match for these constraints is a nullable int (int?), so that's what the null in your example is treated as. If you were comparing it to a bool, you'd get a bool?. For a string (which is a reference type and thus nullable by default), you'd get a string (not a string?). --- |
bamccaig
Member #7,536
July 2006
|
According to Pointers in C#, if you cast a pointer to an int you get the memory address though. In theory, null still could be a special circumstance, but to me at least, it seems more likely that 0 is the actual "address"/value stored in the pointer. Abstracting it doesn't really change the underlying implementation. -- acc.js | al4anim - Allegro 4 Animation library | Allegro 5 VS/NuGet Guide | Allegro.cc Mockup | Allegro.cc <code> Tag | Allegro 4 Timer Example (w/ Semaphores) | Allegro 5 "Winpkg" (MSVC readme) | Bambot | Blog | C++ STL Container Flowchart | Castopulence Software | Check Return Values | Derail? | Is This A Discussion? Flow Chart | Filesystem Hierarchy Standard | Clean Code Talks - Global State and Singletons | How To Use Header Files | GNU/Linux (Debian, Fedora, Gentoo) | rot (rot13, rot47, rotN) | Streaming |
Tobias Dammers
Member #2,604
August 2002
|
In fact, using unsafe code, it is. In unsafe mode, C# allows pointers which work pretty much like those in C++, and they can be cast to and from integers - just like in C++. And in that case, a null pointer (as opposed to a null reference!) IS stored as integer zero, and converts to 0 when cast to int. --- |
bamccaig
Member #7,536
July 2006
|
A pointer is essentially an integer. An integer can store any combination of bits and, therefore, there is no "special" value (0, excluded) for NULL to be without abstracting pointers and adding metadata to them. There would be absolutely no advantage to that. If anything, it would slow the process down and consume more memory than necessary. References are essentially pointers that are managed by the language/compiler. I'm going to assume that more than likely, null is still represented as 0 for references (that can have a null reference) on an assembler (or intermediate) level and the whole interaction is abstracted from the programmer so it seems more complex than it really is. There may be more to references than I think, in which case I could be mistaken, but I can't think of any reason for them to be more complex than that. -- acc.js | al4anim - Allegro 4 Animation library | Allegro 5 VS/NuGet Guide | Allegro.cc Mockup | Allegro.cc <code> Tag | Allegro 4 Timer Example (w/ Semaphores) | Allegro 5 "Winpkg" (MSVC readme) | Bambot | Blog | C++ STL Container Flowchart | Castopulence Software | Check Return Values | Derail? | Is This A Discussion? Flow Chart | Filesystem Hierarchy Standard | Clean Code Talks - Global State and Singletons | How To Use Header Files | GNU/Linux (Debian, Fedora, Gentoo) | rot (rot13, rot47, rotN) | Streaming |
|
1
2
|