Pass by reference but with default parameter

[Manu]

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

 

[Ian Collins]

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.

 

[Francesco S. Carta]

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

 

[James Kanze]

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.

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

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 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).

 

[Francesco S. Carta]

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

Missed that...

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.

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

 

[Balog Pal]

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

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

 

[Francesco S. Carta]

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

 

[Victor Bazarov]

[..] 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

 

[Jerry Coffin]

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);
}

 

[Francesco S. Carta]

[..]  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.

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

 

[James Kanze]

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.

 

[Francesco S. Carta]

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

 

[Joshua Maurice]

[..]  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.

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?)

 

[Francesco S. Carta]

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.

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

 

[Joshua Maurice]

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.

 

[Balog Pal]

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.

 

[Joshua Maurice]

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.

 

[Francesco S. Carta]

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.


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]

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

 

[Thomas J. Gritzan]

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];