Pass by reference but with default parameter

[Joshua Maurice]

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

I see the type safety value for allowing integral constant expressions
in array sizes like your code example, but I strongly disagree with
the value in allowing your other example of
void* ptr = true - true;
Allowing this is \less\ type safety. Surely there's some more sensible
language rules than "integral constant expressions of 0"? And yes, I
suppose the new nullptr is one such way.

Ex:
int const x = 0;
int * y = x;
This nonsense does not compile in C89, but apparently it's legal C+
+03. (At least according to Comeau.) I call that bad language design
in C++. What's the rule for C? That an int literal 0 is implicitly
convertible to the null pointer? Why did C++ change that?

 

[Victor Bazarov]

[..]
I see the type safety value for allowing integral constant expressions
in array sizes like your code example, but I strongly disagree with
the value in allowing your other example of
void* ptr = true - true;
Allowing this is \less\ type safety. Surely there's some more sensible
language rules than "integral constant expressions of 0"? And yes, I
suppose the new nullptr is one such way.

Ex:
int const x = 0;
int * y = x;
This nonsense does not compile in C89, but apparently it's legal C+
+03. (At least according to Comeau.) I call that bad language design
in C++. What's the rule for C? That an int literal 0 is implicitly
convertible to the null pointer? Why did C++ change that?

Change what? An int literal 0 is still convertible to any pointer and
yields a null pointer of that type. C++ didn't change that. C++
allowed an expression containing a single 'const int' to be used
wherever a literal with the same value can be used. And that's how NULL
came to be defined as '0' in C++. The alternative was to allow the
implicit conversion from void* to any pointer, which sucks even louder
(and is valid in C, BTW). Integral const expression with value 0 is not
as frequent. Where in production code did you see 'true - true',
really? And why in hell would you name your constant integral zero 'x'?
It would be named 'zero' or 'nil' or some such. If you object the
style, don't give examples that have none.

V

 

[Joshua Maurice]

[..]
I see the type safety value for allowing integral constant expressions
in array sizes like your code example, but I strongly disagree with
the value in allowing your other example of
    void* ptr = true - true;
Allowing this is \less\ type safety. Surely there's some more sensible
language rules than "integral constant expressions of 0"? And yes, I
suppose the new nullptr is one such way.

Ex:
  int const x = 0;
  int * y = x;
This nonsense does not compile in C89, but apparently it's legal C+
+03. (At least according to Comeau.) I call that bad language design
in C++. What's the rule for C? That an int literal 0 is implicitly
convertible to the null pointer? Why did C++ change that?

Change what?  An int literal 0 is still convertible to any pointer and
yields a null pointer of that type.  C++ didn't change that.  C++
allowed an expression containing a single 'const int' to be used
wherever a literal with the same value can be used.  And that's how NULL
came to be defined as '0' in C++.

With that phrasing, then yes, I guess no alternative. Is that the
actual standardeze, that you're able to use a const int in place of an
int literal? And because 0 is convertible to a null pointer, then any
const integral expression of 0 is convertible to the null pointer. I
can live with that. Still don't like it.

The alternative was to allow the
implicit conversion from void* to any pointer, which sucks even louder
(and is valid in C, BTW).  Integral const expression with value 0 is not
as frequent.  Where in production code did you see 'true - true',
really?

Meh, then why introduce nullptr? Either it's a problem or it's not.

And why in hell would you name your constant integral zero 'x'?
  It would be named 'zero' or 'nil' or some such.  If you object the
style, don't give examples that have none.

None of my code was suggested to be an example of good style. Sorry to
give the impression.

 

[Victor Bazarov]

Meh, then why introduce nullptr? Either it's a problem or it's not.

It is a problem. Think overloading.

void foo(int);
void foo(char*);

int main() {
foo(NULL);
}

Which 'foo' do you think will be called? Now, 'nullptr' is not
convertible to 'int' implicitly, yet convertible to any pointer. Let's
change the code to

int main() {
foo(nullptr);
}

Which 'foo' will be called?

[..]

V

 

[Joshua Maurice]

It is a problem.  Think overloading.

    void foo(int);
    void foo(char*);

    int main() {
        foo(NULL);
    }

Which 'foo' do you think will be called?  Now, 'nullptr' is not
convertible to 'int' implicitly, yet convertible to any pointer.  Let's
change the code to

    int main() {
       foo(nullptr);
    }

Which 'foo' will be called?

That was a rhetorical, and sarcastic, question. You claimed that "int
* x = true - true" is not a big problem, but you also support the
introduction of nullptr. I was pointing out this apparent
contradiction, that const int expressions convertible to null pointer
are not a big enough problem with regards to the points of my post,
but they're enough of a problem to warrant introducing nullptr.

 

[James Kanze]

On Sep 22, 11:22 am, "Francesco S. Carta" <[email protected]> wrote:

[...]

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

The rule is:

A null pointer constant is an integral constant
expression (5.19) rvalue of integer type that evaluates
to zero. A null pointer constant can be converted to a
pointer type; [...]

Nothing about a literal in there; something like "(1-1)" is a
perfectly legal null pointer constant, both in C and in C++.
(There are differences: "((void*)0)" is a legal null pointer
constant in C, but not in C++, and "nullptr", if it is defined
as above, is one in C++, but not in C.)

Normally, integers are not implicitly convertible to pointers.
There is a specific exception for the integer literal 0.

There is a specific exception for integral constant expressions
evaluating to 0 (of integral type---an enum is not a null
pointer constant).

 

[Scooser]

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

Simply use overloading instead of a default parameter.

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

inline bool Func1()
{
A * dummy ( 0 );
return Func1(dummy);
}