Is my C++ compiler broken?

This is a discussion on Is my C++ compiler broken? within the C++ Programming forums, part of the General Programming Boards category; Example: Code: inline template <typename T> T *NullPtr() { return 0; } Type safety...

  1. #31
    Banned master5001's Avatar
    Join Date
    Aug 2001
    Location
    Visalia, CA, USA
    Posts
    3,685
    Example:
    Code:
    inline
    template <typename T>
    T *NullPtr()
    {
      return 0;
    }
    Type safety

  2. #32
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,537
    Quote Originally Posted by laserlight View Post
    Recall your argument against C89 allowing functions to be used without being declared. Would you agree that that rule in C is perfectly fine, since we can impose the coding standard rule that says "declare functions before use"?
    Well actually, I don't think it's the same.
    I'm all for allowing nullptr because it will increase type safety.
    What I don't really see a problem with is to use NULL for initializing pointers rather than 0.

    This is exactly how it should be used:
    Code:
    int* ptr = NULL;
    This is exactly how it should not be used (and preferably, it should not compile):
    Code:
    int num = NULL;
    However, it is not the same to type:
    Code:
    int* ptr = nullptr;
    As it would be to write
    Code:
    int num = nullptr;
    And I love the idea of the second example failing to compile.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  3. #33
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,588
    What I don't really see a problem with is to use NULL for initializing pointers rather than 0.
    Oh, I do not see a problem with that either. They are, after all, effectively the same.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  4. #34
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,537
    In the current standard, I'd rather use NULL to initialize pointers than 0, because NULL effectively says it's a NULL pointer.
    I see NULL as a type that can only be assigned to pointers.
    0 on the other hand is an integer and so shouldn't really be assigned to pointers, in my opinion.
    In this regard, nullptr is a good addition methinks.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  5. #35
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,588
    In the current standard, I'd rather use NULL to initialize pointers than 0, because NULL effectively says it's a NULL pointer.
    0 also effectively says that it is a null pointer.

    I see NULL as a type that can only be assigned to pointers.
    I think you mean "value" rather than "type".
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  6. #36
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,537
    Quote Originally Posted by laserlight View Post
    0 also effectively says that it is a null pointer.
    Not necessarily to me, but I can accept it (save me, nullptr!).

    I think you mean "value" rather than "type".
    Hmmm. Makes more sense, I guess.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  7. #37
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,299
    I think the abstraction of NULL away from 0 is a sensible one, particularly considering the fact that a NULL pointer does not necessarily have to be represented by all of it's bits being 0. Even though asigning 0 to it must set the pointer to the NULL value used by that platform. Memsetting a pointer to 0 is NOT the same as assigning 0, on obscure platforms!
    When people take away the abstraction we call NULL, and just use 0 instead, they're likely to do the memset thing and write unportable code.

    I welcome the new and better abstraction called nullptr.
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

  8. #38
    Banned master5001's Avatar
    Join Date
    Aug 2001
    Location
    Visalia, CA, USA
    Posts
    3,685
    This is one area where the C standard definition of NULL will at least throw a compile-time error. In C NULL is a pointer. How nullptr has not existed all this time is puzzling.

  9. #39
    Registered User
    Join Date
    Oct 2001
    Posts
    2,129
    --vv
    Quote Originally Posted by N1124 7.17.3
    The macros are
    NULL
    which expands to an implementation-defined null pointer constant;
    Quote Originally Posted by N1124 6.3.2.3.3
    An integer constant expression with the value 0, or such an expression cast to type
    void *, is called a null pointer constant.55) If a null pointer constant is converted to a
    pointer type, the resulting pointer, called a null pointer, is guaranteed to compare unequal
    to a pointer to any object or function.

  10. #40
    Registered Abuser
    Join Date
    Jun 2006
    Location
    Toronto
    Posts
    591
    The discussion on null is all well an good; however the main issue is still un-addressed:
    what are the types of the following expressions:
    (int)NULL
    (long)NULL
    (int)(void *)NULL

    where NULL = nullptr vs any other definition. According to the definition above, they should be int, long, and int.
    Put another way: under what circumstances will "(int)NULL" not evaluate to an integer type?

    Just to clarify: how it is to be used is of no concern. If I want to shoot myself in the foot by assigning NULL to an integer, I should be able to do so warning-free, granted that I inform the compiler of my intention (i.e. an explicit cast).

  11. #41
    Registered User
    Join Date
    Jun 2005
    Posts
    6,245
    Quote Originally Posted by @nthony View Post
    The discussion on null is all well an good; however the main issue is still un-addressed:
    what are the types of the following expressions:
    (int)NULL
    (long)NULL
    (int)(void *)NULL

    where NULL = nullptr vs any other definition. According to the definition above, they should be int, long, and int.
    Put another way: under what circumstances will "(int)NULL" not evaluate to an integer type?
    The conversion (int)something is required to fail (and a compiler error is normally expected) if "something" is of a type that cannot be converted to int.

    Forcing the issue with an explicit conversion does not achieve much if the compiler does not know how to do the conversion.
    Quote Originally Posted by @nthony View Post
    Just to clarify: how it is to be used is of no concern. If I want to shoot myself in the foot by assigning NULL to an integer, I should be able to do so warning-free, granted that I inform the compiler of my intention (i.e. an explicit cast).
    How it is used is of concern. One of the attributes of undefined behaviour is that anything is allowed to happen. Failing to compile your code is one of the acceptable possibilities supported by "anything".

    You may wish to shoot yourself in the foot via an indirect route. However, a compiler (or library) is not required to allow all steps in that indirect route to succeed.

  12. #42
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    Do you only get that warning when casting NULL, or do you also get it when casting a non-NULL pointer?
    I would certainly expect that a C-style cast should tell the compiler to shut up and do what I tell it, so I'd be interested to know why it's doing that, even though I'd never actually do that in real life.
    "I am probably the laziest programmer on the planet, a fact with which anyone who has ever seen my code will agree." - esbo, 11/15/2008

    "the internet is a scary place to be thats why i dont use it much." - billet, 03/17/2010

  13. #43
    Registered Abuser
    Join Date
    Jun 2006
    Location
    Toronto
    Posts
    591
    (int)(void *)0 is also accepted. You share my awe, I fully expected a C-style casting to be "putting the foot down", and what's more is that it is, when it comes to casting to long and char, but just not int (see the above example).

    @grumpy, here's the jaw-dropper though: how pray tell, could it not know how to convert some type to int, that it will readily convert to long and char!?
    It surely cannot be a primitive type (since those can be readily converted), so even if we were to assume it is of type FOO, it makes no sense why any compiler would allow FOO to char and FOO to long conversions where it will not allow FOO to int.

  14. #44
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,537
    Quote Originally Posted by @nthony View Post
    Just to clarify: how it is to be used is of no concern. If I want to shoot myself in the foot by assigning NULL to an integer, I should be able to do so warning-free, granted that I inform the compiler of my intention (i.e. an explicit cast).
    I certainly agree that you should be unable to assign NULL to a non-pointer. Using an explicit cast to make it work is an evil workaround and I'm not sure such a thing should be allowed.

    Quote Originally Posted by @nthony View Post
    @grumpy, here's the jaw-dropper though: how pray tell, could it not know how to convert some type to int, that it will readily convert to long and char!?
    It surely cannot be a primitive type (since those can be readily converted), so even if we were to assume it is of type FOO, it makes no sense why any compiler would allow FOO to char and FOO to long conversions where it will not allow FOO to int.
    It probably happens due implicit conversion.
    It has overloaded one or more operators, for example int, and when invoked, produces a warning.
    However, since it's a nullptr, it may very well provide a void* implicit operator and void* can then be cast to int without a warning, so that would explain that. As for the rest, it may be that that it uses an implicit operator such as void* first and then casting the result to long, skipping the warning altogether.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  15. #45
    Registered User
    Join Date
    Jun 2005
    Posts
    6,245
    Quote Originally Posted by @nthony View Post
    @grumpy, here's the jaw-dropper though: how pray tell, could it not know how to convert some type to int, that it will readily convert to long and char!?
    It surely cannot be a primitive type (since those can be readily converted), so even if we were to assume it is of type FOO, it makes no sense why any compiler would allow FOO to char and FOO to long conversions where it will not allow FOO to int.
    The reason, as suggested by Elysia, is probably that a conversion to int has not been implemented, but a conversion to char or long has. It is possible to get the same effect fairly easily with standard C++ too.

    Code:
    #include <iostream>
    
    class Foo
    {
         public:
    
                 operator char() {return '\0';};
                 operator long() {return 0L;};
                  // whoops!  forgot to implement an operator int().
    };
    
    int main()
    {
          Foo x;   // If a macro named NULL is not defined, I could name my variable NULL.
                      //   However, I won't do that .... 
          std::cout << (char)x;   // fine
          std::cout << (long)x;   //  fine
          std::cout << (int)x;     // error
    }
    As to why your version of g++ is doing it with a NULL pointer ..... the obvious explanations are a deliberate design decision (i.e they decided to do it that way) or an oversight - either way, whatever the type of NULL is, it cannot be converted to an int.

    My guess, incidentally, is that it is deliberate. Quite a few functions in the standard library where a programmer will be tempted - as you are - to pass a NULL accept an int argument or two. There are relatively few functions in the standard library where a programmer will be tempted to pass a NULL to a function expecting a char or a long. Disabling the conversion of NULL (or whatever type NULL is) to int will give the sort of diagnostic you're experiencing, but there was probably no anticipated use cases where a programmer would be silly enough to pass NULL where a char or long is expected.

    If you argue they shouldn't do that. then fine. Find one example where such a conversion of NULL to int is actually necessary for a program to work - portably.

    Otherwise accept the behaviour of the compiler for what it is: diagnosing a code construct that is likely to get you in trouble at some point.

Page 3 of 4 FirstFirst 1234 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Compiler Paths...
    By Cobra in forum C++ Programming
    Replies: 5
    Last Post: 09-26-2006, 04:04 AM
  2. C Compiler and stuff
    By pal1ndr0me in forum C Programming
    Replies: 10
    Last Post: 07-21-2006, 11:07 AM
  3. I can't get this new compiler to work.
    By Loduwijk in forum C++ Programming
    Replies: 7
    Last Post: 03-29-2006, 05:42 AM
  4. how to call a compiler?
    By castlelight in forum C Programming
    Replies: 3
    Last Post: 11-22-2005, 10:28 AM
  5. Help With finding a compiler
    By macman in forum A Brief History of Cprogramming.com
    Replies: 4
    Last Post: 04-15-2005, 08:15 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21