Pass by reference but with default parameter

Discussion in 'C++' started by Manu, Sep 22, 2009.

  1. Manu

    Manu Guest

    Hi,

    Check the following code.


    bool Func1(A* ptr = NULL)
    {
    ptr = Func2();
    }

    void main()
    {
    A* ptr1;
    Func1(ptr1);
    }

    In the above case the value of ptr1 will be some junk value.
    As a result i modified the code like

    bool Func1(A*& ptr)
    {
    ptr = Func2();
    }

    Now it works fine.

    But I need a function with a default parameter as NULL but at the same time
    the parameter has to be passed as reference.
    How can I achieve it??

    Regards,
    R Manu
    Manu, Sep 22, 2009
    #1
    1. Advertising

  2. Manu

    Ian Collins Guest

    Manu wrote:
    > Hi,
    >
    > Check the following code.
    >
    >
    > bool Func1(A* ptr = NULL)
    > {
    > ptr = Func2();
    > }


    That really is a silly idea, what happens if you call Func1() ?

    > void main()
    > {
    > A* ptr1;
    > Func1(ptr1);
    > }
    >
    > In the above case the value of ptr1 will be some junk value.
    > As a result i modified the code like
    >
    > bool Func1(A*& ptr)
    > {
    > ptr = Func2();
    > }
    >
    > Now it works fine.
    >
    > But I need a function with a default parameter as NULL but at the same time
    > the parameter has to be passed as reference.


    Why?

    > How can I achieve it??


    You can't have a null reference.

    --
    Ian Collins
    Ian Collins, Sep 22, 2009
    #2
    1. Advertising

  3. On 22 Set, 12:54, "Manu" <> wrote:
    > Hi,
    >
    > Check the following code.
    >
    > bool Func1(A* ptr = NULL)
    > {
    >     ptr = Func2();
    >
    > }


    First off, you missed to return an appropriate value, and secondarily,
    it would be better to use the 0 (zero) literal instead of NULL. But
    that's not what you're asking for.

    >
    > void main()
    > {
    >     A* ptr1;
    >     Func1(ptr1);
    >
    > }
    >
    > In the above case the value of ptr1 will be some junk value.


    And being junk, you shouldn't pass it around.
    If you want a pointer to something but you can't appropriately set it
    in the declaration, initialize it to 0.

    > As a result i modified the code like
    >
    > bool Func1(A*& ptr)
    > {
    >     ptr = Func2();
    >
    > }
    >
    > Now it works fine.
    >
    > But  I need a function with a default parameter as NULL but at the same time
    > the parameter has to be passed as reference.
    > How can I achieve it??


    As Ian pointed out, you cannot have a null reference.

    If you detail better your needs and your aims you could get some good
    advice about the implementation. What exactly are Func1 and Func2
    meant to do?

    Have good time,
    Francesco
    --
    Francesco S. Carta, hobbyist
    http://fscode.altervista.org
    Francesco S. Carta, Sep 22, 2009
    #3
  4. Manu

    James Kanze Guest

    On Sep 22, 12:19 pm, "Francesco S. Carta" <> wrote:
    > On 22 Set, 12:54, "Manu" <> wrote:


    > > bool Func1(A* ptr = NULL)
    > > {
    > > ptr = Func2();
    > > }


    > First off, you missed to return an appropriate value,


    Not to mention that he's modifying a local variable.

    > and secondarily, it would be better to use the 0 (zero)
    > literal instead of NULL.


    Why? Everywhere I've worked, using NULL has been preferred.

    > > void main()


    Just a nit, but "void main()" won't compile with a conformant
    compiler. The function main must return int.

    > > {
    > > A* ptr1;
    > > Func1(ptr1);
    > > }


    > > In the above case the value of ptr1 will be some junk value.


    > And being junk, you shouldn't pass it around.
    > If you want a pointer to something but you can't appropriately
    > set it in the declaration, initialize it to 0.


    > > As a result i modified the code like


    > > bool Func1(A*& ptr)
    > > {
    > > ptr = Func2();
    > > }


    > > Now it works fine.


    > > But I need a function with a default parameter as NULL but
    > > at the same time the parameter has to be passed as
    > > reference.
    > > How can I achieve it??


    > As Ian pointed out, you cannot have a null reference.


    > If you detail better your needs and your aims you could get
    > some good advice about the implementation. What exactly are
    > Func1 and Func2 meant to do?


    He can write something like:

    bool Func1( A* const& ptr = NULL ) ;

    If he needs a non-const reference, something like:

    extern A* defaultParam ;
    bool Func1( A* const& ptr = defaultParam ) ;

    will work, but he really has to make sure that he doesn't
    actually modify the defaultParam somewhere (since it's not
    const).

    --
    James Kanze
    James Kanze, Sep 22, 2009
    #4
  5. On 22 Set, 16:30, James Kanze <> wrote:
    > On Sep 22, 12:19 pm, "Francesco S. Carta" <> wrote:
    >
    > > On 22 Set, 12:54, "Manu" <> wrote:
    > > > bool Func1(A* ptr = NULL)
    > > > {
    > > >     ptr = Func2();
    > > > }

    > > First off, you missed to return an appropriate value,

    >
    > Not to mention that he's modifying a local variable.


    Missed that...

    > > and secondarily, it would be better to use the 0 (zero)
    > > literal instead of NULL.

    >
    > Why?  Everywhere I've worked, using NULL has been preferred.


    Just because my reference book (TC++PL) suggests so.

    A rationale is given - something along the lines that a pure zero
    could lead to less problems, due to the stricter C++ type checking,
    but don't ask me to support that rationale, it's outside of my
    knowledge: I just trusted the author.

    Of course, were I to work on a team/project where NULL is expected to
    be used, I would use it without any complain, even though I dislike
    it.

    > > > void main()

    >
    > Just a nit, but "void main()" won't compile with a conformant
    > compiler.  The function main must return int.


    Completely overlooked that... never mind.

    Have good time,
    Francesco
    --
    Francesco S. Carta, hobbyist
    http://fscode.altervista.org
    Francesco S. Carta, Sep 22, 2009
    #5
  6. Manu

    Balog Pal Guest

    "James Kanze" <>

    >> and secondarily, it would be better to use the 0 (zero)
    >> literal instead of NULL.

    >
    > Why? Everywhere I've worked, using NULL has been preferred.


    0 is always there. To have NULL you must #include something.
    Balog Pal, Sep 22, 2009
    #6
  7. On 22 Set, 18:20, Victor Bazarov <> wrote:
    > Balog Pal wrote:
    > > "James Kanze" <>

    >
    > >>> and secondarily, it would be better to use the 0 (zero)
    > >>> literal instead of NULL.
    > >> Why?  Everywhere I've worked, using NULL has been preferred.

    >
    > > 0 is always there. To have NULL you must #include something.

    >
    > Yes, that's true.  In production environment, however, standard headers
    > are pretty much always included (directly or indirectly) which basically
    > makes "NULL" pretty much "always there" as well.
    >
    > Another reason to prefer 'NULL' - it's much more effective to do the
    > search-and-replace on "NULL" than on "0" when time comes to switch to
    > using 'nullptr' (the new keyword, when your compiler starts supporting it).


    Interesting. Just out of curiosity, am I allowed to define and use
    "const int nullptr = 0;" in my code?

    I know that it seems that I'm contradicting myself, but the idea of
    being able to spot all nullified pointers with a search is indeed
    useful, while I still dislike using the NULL macro.

    Well, I could define "const int NULL = 0;" as suggested by my book...
    I don't know, whatever.

    Have good time,
    Francesco
    --
    Francesco S. Carta, hobbyist
    http://fscode.altervista.org
    Francesco S. Carta, Sep 22, 2009
    #7
  8. Francesco S. Carta wrote:
    > [..] Just out of curiosity, am I allowed to define and use
    > "const int nullptr = 0;" in my code?


    Right now you are, of course. After C++0x support is introduced in the
    compiler you use, it's likely to fail, 'nullptr' is going to be a new
    keyword (see table 3), and you can't use a keyword as the name of a
    variable.

    > I know that it seems that I'm contradicting myself, but the idea of
    > being able to spot all nullified pointers with a search is indeed
    > useful, while I still dislike using the NULL macro.
    >
    > Well, I could define "const int NULL = 0;" as suggested by my book...


    Only if you never include any of the standard headers that might lead to
    the definition of the macro 'NULL'... A tall order, AFAICT.

    V
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
    Victor Bazarov, Sep 22, 2009
    #8
  9. Manu

    Jerry Coffin Guest

    In article <h9aad9$pa3$>,
    says...
    >
    > Hi,
    >
    > Check the following code.
    >
    >
    > bool Func1(A* ptr = NULL)
    > {
    > ptr = Func2();
    > }


    For this to accomplish anything useful, it probably needs to be
    something like:
    *ptr = Func();

    A default should usually be a 'in' parameter -- one that specifies
    HOW the function does its job, but for which there is a reasonable
    default behavior. Otherwise, you're typically looking at a function
    that really does two different things, which is a problem in itself
    (there are a few exceptions, but they're pretty unusual).

    A reference, however, signals an 'inout' parameter -- one that's
    modified by the function in question. To make it an 'in', you'd want
    a reference to const.

    For this case, you can simply define an object to be used as the
    default, and then compare to that when needed:

    const A default_value;

    bool Func1(A const &value = default_value) {
    use(value);
    }

    --
    Later,
    Jerry.
    Jerry Coffin, Sep 22, 2009
    #9
  10. On 22 Set, 19:22, Victor Bazarov <> wrote:
    > Francesco S. Carta wrote:
    > > [..]  Just out of curiosity, am I allowed to define and use
    > > "const int nullptr = 0;" in my code?

    >
    > Right now you are, of course.  After C++0x support is introduced in the
    > compiler you use, it's likely to fail, 'nullptr' is going to be a new
    > keyword (see table 3), and you can't use a keyword as the name of a
    > variable.


    Ah, very good to know! When my compiler will support it I'll have just
    to remove that declaration and the code will be ready to go.

    > > I know that it seems that I'm contradicting myself, but the idea of
    > > being able to spot all nullified pointers with a search is indeed
    > > useful, while I still dislike using the NULL macro.

    >
    > > Well, I could define "const int NULL = 0;" as suggested by my book...

    >
    > Only if you never include any of the standard headers that might lead to
    > the definition of the macro 'NULL'...  A tall order, AFAICT.


    Yes, a tall order indeed. I'll go for nullptr in my code.

    Thanks a lot,
    have good time,
    Francesco
    --
    Francesco S. Carta, hobbyist
    http://fscode.altervista.org
    Francesco S. Carta, Sep 22, 2009
    #10
  11. Manu

    James Kanze Guest

    On Sep 22, 6:01 pm, "Francesco S. Carta" <> wrote:
    > On 22 Set, 16:30, James Kanze <> wrote:


    > > On Sep 22, 12:19 pm, "Francesco S. Carta"
    > > <> wrote:


    > > > and secondarily, it would be better to use the 0 (zero)
    > > > literal instead of NULL.


    > > Why? Everywhere I've worked, using NULL has been preferred.


    > Just because my reference book (TC++PL) suggests so.


    > A rationale is given - something along the lines that a pure
    > zero could lead to less problems, due to the stricter C++ type
    > checking, but don't ask me to support that rationale, it's
    > outside of my knowledge: I just trusted the author.


    It's more a question of style than anything else. There are
    very good arguments against either choice; neither is perfect
    (which is why the next version of the standard adds nullptr).
    My own preference leans to NULL, although I understand the
    arguments against it.

    --
    James Kanze
    James Kanze, Sep 22, 2009
    #11
  12. On 22 Set, 23:22, James Kanze <> wrote:
    > On Sep 22, 6:01 pm, "Francesco S. Carta" <> wrote:
    >
    > > On 22 Set, 16:30, James Kanze <> wrote:
    > > > On Sep 22, 12:19 pm, "Francesco S. Carta"
    > > > <> wrote:
    > > > > and secondarily, it would be better to use the 0 (zero)
    > > > > literal instead of NULL.
    > > > Why?  Everywhere I've worked, using NULL has been preferred.

    > > Just because my reference book (TC++PL) suggests so.
    > > A rationale is given - something along the lines that a pure
    > > zero could lead to less problems, due to the stricter C++ type
    > > checking, but don't ask me to support that rationale, it's
    > > outside of my knowledge: I just trusted the author.

    >
    > It's more a question of style than anything else.  There are
    > very good arguments against either choice; neither is perfect
    > (which is why the next version of the standard adds nullptr).
    > My own preference leans to NULL, although I understand the
    > arguments against it.


    Got it, I'll try to be more careful when using sentences like "it
    would be better to". If it is matter of style, then there is no
    "better" or "worse", thanks for the further details - of course, I
    didn't recognize it as being "matter of style" :-/

    Have good time,
    Francesco
    --
    Francesco S. Carta, hobbyist
    http://fscode.altervista.org
    Francesco S. Carta, Sep 22, 2009
    #12
  13. On Sep 22, 11:22 am, "Francesco S. Carta" <> wrote:
    > On 22 Set, 19:22, Victor Bazarov <> wrote:
    >
    > > Francesco S. Carta wrote:
    > > > [..]  Just out of curiosity, am I allowed to define and use
    > > > "const int nullptr = 0;" in my code?

    >
    > > Right now you are, of course.  After C++0x support is introduced in the
    > > compiler you use, it's likely to fail, 'nullptr' is going to be a new
    > > keyword (see table 3), and you can't use a keyword as the name of a
    > > variable.

    >
    > Ah, very good to know! When my compiler will support it I'll have just
    > to remove that declaration and the code will be ready to go.
    >
    > > > I know that it seems that I'm contradicting myself, but the idea of
    > > > being able to spot all nullified pointers with a search is indeed
    > > > useful, while I still dislike using the NULL macro.

    >
    > > > Well, I could define "const int NULL = 0;" as suggested by my book....

    >
    > > Only if you never include any of the standard headers that might lead to
    > > the definition of the macro 'NULL'...  A tall order, AFAICT.

    >
    > Yes, a tall order indeed. I'll go for nullptr in my code.


    Slight correction.
    const int NULL = 0;
    will not work, nor will
    const int nullptr = 0;
    There is a rule which says that the int literal "0" is implicitly
    convertible to the null pointer (or some mostly equivalent phrasing).
    Specifically, an integer object with the value "0" is \not\. Normally,
    integers are not implicitly convertible to pointers. There is a
    specific exception for the integer literal 0. Your NULL and nullptr
    will not work if they are ints. They must be C PreProcessor macros
    until you get a C++0x compliant compiler which implements the nullptr
    magic correctly.

    PS: NULL vs 0 in C++03 is a silly holy war IMHO. Neither way buys you
    particularly much. NULL as defined by the standard is (almost)
    equivalent to just typing 0. There's nothing gained either way.
    Whichever is more readable I guess. (I like 0 btw. Personal preference
    with no real basis in reality. Maybe because it's shorter?)
    Joshua Maurice, Sep 22, 2009
    #13
  14. On 23 Set, 00:09, Joshua Maurice <> wrote:
    > On Sep 22, 11:22 am, "Francesco S. Carta" <> wrote:
    >
    >
    >
    > > On 22 Set, 19:22, Victor Bazarov <> wrote:

    >
    > > > Francesco S. Carta wrote:
    > > > > [..]  Just out of curiosity, am I allowed to define and use
    > > > > "const int nullptr = 0;" in my code?

    >
    > > > Right now you are, of course.  After C++0x support is introduced in the
    > > > compiler you use, it's likely to fail, 'nullptr' is going to be a new
    > > > keyword (see table 3), and you can't use a keyword as the name of a
    > > > variable.

    >
    > > Ah, very good to know! When my compiler will support it I'll have just
    > > to remove that declaration and the code will be ready to go.

    >
    > > > > I know that it seems that I'm contradicting myself, but the idea of
    > > > > being able to spot all nullified pointers with a search is indeed
    > > > > useful, while I still dislike using the NULL macro.

    >
    > > > > Well, I could define "const int NULL = 0;" as suggested by my book...

    >
    > > > Only if you never include any of the standard headers that might lead to
    > > > the definition of the macro 'NULL'...  A tall order, AFAICT.

    >
    > > Yes, a tall order indeed. I'll go for nullptr in my code.

    >
    > Slight correction.
    >   const int NULL = 0;
    > will not work, nor will
    >   const int nullptr = 0;
    > There is a rule which says that the int literal "0" is implicitly
    > convertible to the null pointer (or some mostly equivalent phrasing).
    > Specifically, an integer object with the value "0" is \not\. Normally,
    > integers are not implicitly convertible to pointers. There is a
    > specific exception for the integer literal 0. Your NULL and nullptr
    > will not work if they are ints. They must be C PreProcessor macros
    > until you get a C++0x compliant compiler which implements the nullptr
    > magic correctly.


    I'm bordering heavily on madness. I don't know who or what to trust
    anymore.

    My book says that "const int NULL = 0; whatever* ptr = NULL;" is fine.
    GCC 3.4.5 allows me doing "const int nullptr = 0; whatever* ptr =
    nullptr;" - and it properly sets ptr to zero, with all warnings turned
    on.

    I think I'll have to take a break.

    Have good time,
    Francesco
    --
    Francesco S. Carta, hobbyist
    http://fscode.altervista.org
    Francesco S. Carta, Sep 22, 2009
    #14
  15. On Sep 22, 3:23 pm, "Francesco S. Carta" <> wrote:
    > On 23 Set, 00:09, Joshua Maurice <> wrote:
    >
    > > On Sep 22, 11:22 am, "Francesco S. Carta" <> wrote:

    >
    > > > On 22 Set, 19:22, Victor Bazarov <> wrote:

    >
    > > > > Francesco S. Carta wrote:
    > > > > > [..]  Just out of curiosity, am I allowed to define and use
    > > > > > "const int nullptr = 0;" in my code?

    >
    > > > > Right now you are, of course.  After C++0x support is introduced in the
    > > > > compiler you use, it's likely to fail, 'nullptr' is going to be a new
    > > > > keyword (see table 3), and you can't use a keyword as the name of a
    > > > > variable.

    >
    > > > Ah, very good to know! When my compiler will support it I'll have just
    > > > to remove that declaration and the code will be ready to go.

    >
    > > > > > I know that it seems that I'm contradicting myself, but the idea of
    > > > > > being able to spot all nullified pointers with a search is indeed
    > > > > > useful, while I still dislike using the NULL macro.

    >
    > > > > > Well, I could define "const int NULL = 0;" as suggested by my book...

    >
    > > > > Only if you never include any of the standard headers that might lead to
    > > > > the definition of the macro 'NULL'...  A tall order, AFAICT.

    >
    > > > Yes, a tall order indeed. I'll go for nullptr in my code.

    >
    > > Slight correction.
    > >   const int NULL = 0;
    > > will not work, nor will
    > >   const int nullptr = 0;
    > > There is a rule which says that the int literal "0" is implicitly
    > > convertible to the null pointer (or some mostly equivalent phrasing).
    > > Specifically, an integer object with the value "0" is \not\. Normally,
    > > integers are not implicitly convertible to pointers. There is a
    > > specific exception for the integer literal 0. Your NULL and nullptr
    > > will not work if they are ints. They must be C PreProcessor macros
    > > until you get a C++0x compliant compiler which implements the nullptr
    > > magic correctly.

    >
    > I'm bordering heavily on madness. I don't know who or what to trust
    > anymore.
    >
    > My book says that "const int NULL = 0; whatever* ptr = NULL;" is fine..
    > GCC 3.4.5 allows me doing "const int nullptr = 0; whatever* ptr =
    > nullptr;" - and it properly sets ptr to zero, with all warnings turned
    > on.
    >
    > I think I'll have to take a break.


    I might be mistaken. Comeau disagrees with me.
    int const NULL = 0;
    int * x = NULL; //ok
    int NULL_2 = 0;
    int * y = NULL_2; //fails
    Really weird. I'll have to review the standard. This seems
    extraordinarily broken.
    Joshua Maurice, Sep 22, 2009
    #15
  16. Manu

    Balog Pal Guest

    "Francesco S. Carta" <>

    >I'm bordering heavily on madness. I don't know who or what to trust

    anymore.

    >My book says that "const int NULL = 0; whatever* ptr = NULL;" is fine.


    And what is the problem with that? It is all fine.

    Unless, certainly you #include some header. That brings in that NULL macro.
    Turning your code to say

    const int 0 = 0;

    that is not really fine.


    >GCC 3.4.5 allows me doing "const int nullptr = 0; whatever* ptr =

    nullptr;" - and it properly sets ptr to zero, with all warnings turned
    on.

    Why not. But be prepared, that gcc 6.0 or whatever that will support the
    NEXT version of the C++ standard will reject that.

    >I think I'll have to take a break.
    Balog Pal, Sep 22, 2009
    #16
  17. On Sep 22, 3:41 pm, Joshua Maurice <> wrote:
    > On Sep 22, 3:23 pm, "Francesco S. Carta" <> wrote:
    >
    > > On 23 Set, 00:09, Joshua Maurice <> wrote:

    >
    > > > On Sep 22, 11:22 am, "Francesco S. Carta" <> wrote:

    >
    > > > > On 22 Set, 19:22, Victor Bazarov <> wrote:

    >
    > > > > > Francesco S. Carta wrote:
    > > > > > > [..]  Just out of curiosity, am I allowed to define and use
    > > > > > > "const int nullptr = 0;" in my code?

    >
    > > > > > Right now you are, of course.  After C++0x support is introduced in the
    > > > > > compiler you use, it's likely to fail, 'nullptr' is going to be a new
    > > > > > keyword (see table 3), and you can't use a keyword as the name of a
    > > > > > variable.

    >
    > > > > Ah, very good to know! When my compiler will support it I'll have just
    > > > > to remove that declaration and the code will be ready to go.

    >
    > > > > > > I know that it seems that I'm contradicting myself, but the idea of
    > > > > > > being able to spot all nullified pointers with a search is indeed
    > > > > > > useful, while I still dislike using the NULL macro.

    >
    > > > > > > Well, I could define "const int NULL = 0;" as suggested by my book...

    >
    > > > > > Only if you never include any of the standard headers that might lead to
    > > > > > the definition of the macro 'NULL'...  A tall order, AFAICT.

    >
    > > > > Yes, a tall order indeed. I'll go for nullptr in my code.

    >
    > > > Slight correction.
    > > >   const int NULL = 0;
    > > > will not work, nor will
    > > >   const int nullptr = 0;
    > > > There is a rule which says that the int literal "0" is implicitly
    > > > convertible to the null pointer (or some mostly equivalent phrasing).
    > > > Specifically, an integer object with the value "0" is \not\. Normally,
    > > > integers are not implicitly convertible to pointers. There is a
    > > > specific exception for the integer literal 0. Your NULL and nullptr
    > > > will not work if they are ints. They must be C PreProcessor macros
    > > > until you get a C++0x compliant compiler which implements the nullptr
    > > > magic correctly.

    >
    > > I'm bordering heavily on madness. I don't know who or what to trust
    > > anymore.

    >
    > > My book says that "const int NULL = 0; whatever* ptr = NULL;" is fine.
    > > GCC 3.4.5 allows me doing "const int nullptr = 0; whatever* ptr =
    > > nullptr;" - and it properly sets ptr to zero, with all warnings turned
    > > on.

    >
    > > I think I'll have to take a break.

    >
    > I might be mistaken. Comeau disagrees with me.
    >   int const NULL = 0;
    >   int * x = NULL; //ok
    >   int NULL_2 = 0;
    >   int * y = NULL_2; //fails
    > Really weird. I'll have to review the standard. This seems
    > extraordinarily broken.


    Ahh, probably mentions that it must be a compile-time expression of
    int 0. I'm sorry. I'm entirely wrong. That's still horribly broken as
    language design.
    Joshua Maurice, Sep 22, 2009
    #17
  18. On 23 Set, 00:43, "Balog Pal" <> wrote:
    > "Francesco S. Carta" <>
    >
    > >I'm bordering heavily on madness. I don't know who or what to trust

    >
    > anymore.
    >
    > >My book says that "const int NULL = 0; whatever* ptr = NULL;" is fine.

    >
    > And what is the problem with that?  It is all fine.
    >
    > Unless, certainly you #include some header. That brings in that NULL macro.
    > Turning your code to say
    >
    > const int 0 = 0;
    >
    > that is not really fine.
    >
    > >GCC 3.4.5 allows me doing "const int nullptr = 0; whatever* ptr =

    >
    > nullptr;" - and it properly sets ptr to zero, with all warnings turned
    > on.
    >
    > Why not. But be prepared, that gcc 6.0  or whatever that will support the
    > NEXT version of the C++ standard will reject that.


    Fine, now it seems clear that you overlooked one of my sentences,
    where I've said that I will "prepare" my code for the next standard by
    defining nullptr and that I will delete that definition when my
    compiler will support it as a keyword.

    [deep breath] I feel healthier now ;-)

    Cheers,
    Francesco
    --
    Francesco S. Carta, hobbyist
    http://fscode.altervista.org
    Francesco S. Carta, Sep 22, 2009
    #18
  19. On 23 Set, 00:48, Joshua Maurice <> wrote:
    > On Sep 22, 3:41 pm, Joshua Maurice <> wrote:
    > > I might be mistaken. Comeau disagrees with me.
    > >   int const NULL = 0;
    > >   int * x = NULL; //ok
    > >   int NULL_2 = 0;
    > >   int * y = NULL_2; //fails
    > > Really weird. I'll have to review the standard. This seems
    > > extraordinarily broken.

    >
    > Ahh, probably mentions that it must be a compile-time expression of
    > int 0. I'm sorry. I'm entirely wrong. That's still horribly broken as
    > language design.


    No problem, exceptions get thrown, the important thing is to catch
    them.

    About your last sentence, paraphrasing http://www.research.att.com/~bs/bs_faq2.html#char
    I would say that nobody ever accused standards of being logical - but
    that's just a joke, because I don't find this particular point to be
    broken.

    Cheers,
    Francesco
    --
    Francesco S. Carta, hobbyist
    http://fscode.altervista.org
    Francesco S. Carta, Sep 23, 2009
    #19
  20. Joshua Maurice schrieb:
    >> I might be mistaken. Comeau disagrees with me.
    >> int const NULL = 0;
    >> int * x = NULL; //ok
    >> int NULL_2 = 0;
    >> int * y = NULL_2; //fails
    >> Really weird. I'll have to review the standard. This seems
    >> extraordinarily broken.

    >
    > Ahh, probably mentions that it must be a compile-time expression of
    > int 0. I'm sorry. I'm entirely wrong. That's still horribly broken as
    > language design.


    Any value that evaluates to zero and is an integral constant (int, char,
    bool etc.) converts to a null pointer. You can even do:
    void* ptr = true - true;
    ....because true-true equals false.

    That's why it is good style to use a symbolic constant as null pointer
    (NULL or better yet nullptr) to document that you're assigning a pointer
    value and not an int.

    A const variable initialized with an integral constant is also an
    integral constant; for example, you can use it as size of an array:
    const int size = 42;
    char array[size];

    --
    Thomas
    Thomas J. Gritzan, Sep 23, 2009
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jerry
    Replies:
    20
    Views:
    7,931
    Roedy Green
    Sep 9, 2005
  2. blufox
    Replies:
    2
    Views:
    552
  3. Mr A
    Replies:
    111
    Views:
    2,108
  4. Stuart Redmann
    Replies:
    5
    Views:
    477
    Stuart Redmann
    Dec 14, 2007
  5. AzamSharp
    Replies:
    2
    Views:
    177
Loading...

Share This Page