Is C++ a type-safe language ??

[Nitin Bhardwaj]

Hi all,

It is said that C++ is a strongly typed language and thus a type-safe
language (unlike C). So how does one explain the following behaviour :

int main(void)
{
char *p = NULL;
p = "A String Literal";//the compiler isuues no error/warning here
// but ideally it should...as p is a non-const
// pointer and the string literal has the type
// const char *
// So, a conversion from const-ptr TO non-const
// should elicite warning/error from the compiler !!

return 0;
}

I've tried it on both MSVC++ 6 compiler on Windows 2000 ( Intel P IV )
and GNU C++ compiler gcc 3.x RedHat GNU\Linux ( Intel P IV )

Thanks in advance.

[John Harrison]

On 1 Jul 2004 21:58:16 -0700, Nitin Bhardwaj <ni*************@hotmail.com>
wrote:

Hi all,

It is said that C++ is a strongly typed language and thus a type-safe
language (unlike C). So how does one explain the following behaviour :

int main(void)
{
char *p = NULL;
p = "A String Literal";//the compiler isuues no error/warning here
// but ideally it should...as p is a non-const
// pointer and the string literal has the type
// const char *
// So, a conversion from const-ptr TO non-const
// should elicite warning/error from the compiler !!

return 0;
}

I've tried it on both MSVC++ 6 compiler on Windows 2000 ( Intel P IV )
and GNU C++ compiler gcc 3.x RedHat GNU\Linux ( Intel P IV )

Thanks in advance.

It's clearly non-type safe but is done for backward compatibility. When C
was invented there was no const and when C introduced const it was felt
that too much existing code would break if the above was forbidden.
C++ has retained this.

john

[Rufus V. Smith]

"Nitin Bhardwaj" <ni*************@hotmail.com> wrote in message
news:17**************************@posting.google.c om...

Hi all,

It is said that C++ is a strongly typed language and thus a type-safe
language (unlike C). So how does one explain the following behaviour :

int main(void)
{
char *p = NULL;
p = "A String Literal";//the compiler isuues no error/warning here
// but ideally it should...as p is a non-const
// pointer and the string literal has the type
// const char *
// So, a conversion from const-ptr TO non-const
// should elicite warning/error from the compiler !!

return 0;
}

I've tried it on both MSVC++ 6 compiler on Windows 2000 ( Intel P IV )
and GNU C++ compiler gcc 3.x RedHat GNU\Linux ( Intel P IV )

const-ness is definitely one of the thornier issues in type safety.

next question?

Rufus

[Alf P. Steinbach]

* Nitin Bhardwaj:

It is said that C++ is a strongly typed language and thus a type-safe
language (unlike C).
That is incorrect.

However, C++ supports type-safety in more ways than C.

So it's possible to program in C++ in (more or less) type-safe ways.
So how does one explain the following behaviour :

int main(void)
{
char *p = NULL;
p = "A String Literal";//the compiler isuues no error/warning here
// but ideally it should...as p is a non-const
// pointer and the string literal has the type
// const char *
// So, a conversion from const-ptr TO non-const
// should elicite warning/error from the compiler !!

return 0;
}

I've tried it on both MSVC++ 6 compiler on Windows 2000 ( Intel P IV )
and GNU C++ compiler gcc 3.x RedHat GNU\Linux ( Intel P IV )

It's backward compatibility with C.

There are other far more horrendous compatibility-derived issues.

For instance, automatic conversion of array type to pointer type and
treating pointers as arrays, in the context of an array of objects.

On the other hand, in some respects C++ is more type-safe than e.g.
Java.

For example, template support enables static type-checking in many
situations where it's not possible in (old non-generic) Java; C++ har
more stringent type-checking (although not 100%) at link time; C++
constructors enforce class invariants while Java constructors do not.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[jeffc]

"Nitin Bhardwaj" <ni*************@hotmail.com> wrote in message
news:17**************************@posting.google.c om...

Hi all,

It is said that C++ is a strongly typed language and thus a type-safe
language (unlike C). So how does one explain the following behaviour :

I would say "strongly typed" is not exactly the same thing as "type-safe".
"strong" is a relative word, is it not?

[Anonymous]

This link gives a good explanation.
http://www.glenmccl.com/ansi_014.htm
--
Use our news server 'news.foorum.com' from anywhere.
More details at: http://nnrpinfo.go.foorum.com/

[SaltPeter]

"Nitin Bhardwaj" <ni*************@hotmail.com> wrote in message
news:17**************************@posting.google.c om...

Hi all,

It is said that C++ is a strongly typed language and thus a type-safe
language (unlike C). So how does one explain the following behaviour :

int main(void)
{
char *p = NULL;
p = "A String Literal";//the compiler isuues no error/warning here
// but ideally it should...as p is a non-const
// pointer and the string literal has the type
// const char *
// So, a conversion from const-ptr TO non-const
// should elicite warning/error from the compiler !!
Ideally, what your compiler should do is generate an error about NULL
not being defined.

So you are suggesting that this should be illegal as well?
int n = 5;

Or are you suggesting that a literal 5 should also be treated as an
lvalue?

Try compiling with the commented line:

#include <iostream>
#include <stdio.h>

// main.cpp

int main()
{
const char *p = NULL;
p = "an rvalue";

//char *pc = p; // fails
const char *pc = p;

std::cout << " pc is not " << pc << std::endl;

return 0;
}

return 0;
}

I've tried it on both MSVC++ 6 compiler on Windows 2000 ( Intel P IV )
and GNU C++ compiler gcc 3.x RedHat GNU\Linux ( Intel P IV )

Thanks in advance.

[Nitin Bhardwaj]

"SaltPeter" <Sa*******@Jupiter.sys> wrote in message news:<Lt**********************@news20.bellglobal.c om>...

"Nitin Bhardwaj" <ni*************@hotmail.com> wrote in message
news:17**************************@posting.google.c om...

Hi all,

It is said that C++ is a strongly typed language and thus a type-safe
language (unlike C). So how does one explain the following behaviour :

int main(void)
{
char *p = NULL;
p = "A String Literal";//the compiler isuues no error/warning here
// but ideally it should...as p is a non-const
// pointer and the string literal has the type
// const char *
// So, a conversion from const-ptr TO non-const
// should elicite warning/error from the compiler !!
Ideally, what your compiler should do is generate an error about NULL
not being defined.

I had provided a code snippet & not the whole program :-) , Inclusion
of standard header(s) was assumed.

So you are suggesting that this should be illegal as well?
int n = 5;

Or are you suggesting that a literal 5 should also be treated as an
lvalue?

Try compiling with the commented line:

#include <iostream>
#include <stdio.h>

You do not need to seperately #include <stdio.h> to have NULL defined,
<iostream.h> is enough for that !!

// main.cpp

int main()
{
const char *p = NULL;
p = "an rvalue";

//char *pc = p; // fails
Thats what I was pointing out: Here the expression fails because the
type of 'p' is const char * and 'pc' is char *....so the compiler
gives 'cannot convert from const char * to char *'. But why doesn't
give in the following case ?

char *str = "String Literal";

Here also type of "String Literal" is const char * and type of str is
char * !!
const char *pc = p;

std::cout << " pc is not " << pc << std::endl;

return 0;
}

return 0;
}

I've tried it on both MSVC++ 6 compiler on Windows 2000 ( Intel P IV )
and GNU C++ compiler gcc 3.x RedHat GNU\Linux ( Intel P IV )

Thanks in advance.

[Sam Holden]

On 5 Jul 2004 23:52:12 -0700,
Nitin Bhardwaj <ni*************@hotmail.com> wrote:

"SaltPeter" <Sa*******@Jupiter.sys> wrote in message news:<Lt**********************@news20.bellglobal.c om>...

const char *p = NULL;
p = "an rvalue";

//char *pc = p; // fails

Thats what I was pointing out: Here the expression fails because the
type of 'p' is const char * and 'pc' is char *....so the compiler
gives 'cannot convert from const char * to char *'. But why doesn't
give in the following case ?

char *str = "String Literal";

Here also type of "String Literal" is const char * and type of str is
char * !!

It's a special case, in order to make C programmers happy. The ancient
standard draft I have available lists it as deprecated but I don't know
if that stuck - someone else certainly will though.

--
Sam Holden

[John Harrison]

Thats what I was pointing out: Here the expression fails because the
type of 'p' is const char * and 'pc' is char *....so the compiler
gives 'cannot convert from const char * to char *'. But why doesn't
give in the following case ?

char *str = "String Literal";

Here also type of "String Literal" is const char * and type of str is
char * !!

No it isn't, the type of "String Literal" is const char [15], it's an
array not a pointer.

The conversion of this array or const char to char* is explicitly allowed
by 4.2 paragraph 2 of the standard. It's purpose is compatibility with C.
In the very old days C did not have const and so code like your example
was commonplace.

Nevertheless it is an error to use this to modify a string literal.

One excemption from type safety rules for the purpose of bacwards
compatibility does not make C++ a non-type safe language. It is still more
type safe than any other language in common use (AFAIK).

john

[SaltPeter]

"Nitin Bhardwaj" <ni*************@hotmail.com> wrote in message
news:17**************************@posting.google.c om...

"SaltPeter" <Sa*******@Jupiter.sys> wrote in message news:<Lt**********************@news20.bellglobal.c om>...

"Nitin Bhardwaj" <ni*************@hotmail.com> wrote in message
news:17**************************@posting.google.c om...

Hi all,

It is said that C++ is a strongly typed language and thus a type-safe
language (unlike C). So how does one explain the following behaviour :

int main(void)
{
char *p = NULL;
p = "A String Literal";//the compiler isuues no error/warning here
// but ideally it should...as p is a non-const
// pointer and the string literal has the type
// const char *
// So, a conversion from const-ptr TO non-const
// should elicite warning/error from the compiler !!

Ideally, what your compiler should do is generate an error about NULL not being defined.

I had provided a code snippet & not the whole program :-) , Inclusion
of standard header(s) was assumed.

No, its not assumed. Your case is the perfect example why. iostream.h is
deprecated and should not be included in any modern code. Basicly, without
including the headers, NULL could be anything. Surely, you aren't expecting
folks to rely on a crystal ball to substitute values for undefined
constants.

So you are suggesting that this should be illegal as well?
int n = 5;

Or are you suggesting that a literal 5 should also be treated as an
lvalue?

Try compiling with the commented line:

#include <iostream>
#include <stdio.h>

You do not need to seperately #include <stdio.h> to have NULL defined,
<iostream.h> is enough for that !!

iostream.h is not part of the C++ standard anymore.
#include <iostream>

And as Benny Hill use to say...
When you ASSUME, you make an ASS out of U and ME, lol.

// main.cpp

int main()
{
const char *p = NULL;
p = "an rvalue";

//char *pc = p; // fails
Thats what I was pointing out: Here the expression fails because the
type of 'p' is const char * and 'pc' is char *....so the compiler
gives 'cannot convert from const char * to char *'. But why doesn't
give in the following case ?

char *str = "String Literal";

Here also type of "String Literal" is const char * and type of str is
char * !!

How do you figure that an array of chars all of a sudden denotes a pointer
to char? I'm baffled. I can see the str pointer(the lvalue), but how do you
magicly deduce that the string literal, in this case: an array of
characters, has become a pointer, or a constant pointer? Its just an array
of characters, thats it.

const char *pc = p;

std::cout << " pc is not " << pc << std::endl;

return 0;
}

return 0;
}

I've tried it on both MSVC++ 6 compiler on Windows 2000 ( Intel P IV )
and GNU C++ compiler gcc 3.x RedHat GNU\Linux ( Intel P IV )

Thanks in advance.

[Richard Herring]

In message <ZA********************@news20.bellglobal.com>, SaltPeter
<Sa*******@Jupiter.sys> writes

"Nitin Bhardwaj" <ni*************@hotmail.com> wrote in message
news:17**************************@posting.google. com...

"SaltPeter" <Sa*******@Jupiter.sys> wrote in message

news:<Lt**********************@news20.bellglobal. com>...

> "Nitin Bhardwaj" <ni*************@hotmail.com> wrote in message
> news:17**************************@posting.google.c om...
> > Hi all,
> >
> > It is said that C++ is a strongly typed language and thus a type-safe
> > language (unlike C). So how does one explain the following behaviour :
> >
> > int main(void)
> > {
> > char *p = NULL;
> > p = "A String Literal";//the compiler isuues no error/warning here
> > // but ideally it should...as p is a non-const
> > // pointer and the string literal has the type
> > // const char *
> > // So, a conversion from const-ptr TO non-const
> > // should elicite warning/error from the compiler !!
>
> Ideally, what your compiler should do is generate an error aboutNULL > not being defined.

I had provided a code snippet & not the whole program :-) , Inclusion
of standard header(s) was assumed.

No, its not assumed. Your case is the perfect example why. iostream.h is
deprecated and should not be included in any modern code. Basicly, without
including the headers, NULL could be anything. Surely, you aren't expecting
folks to rely on a crystal ball to substitute values for undefined
constants.

Oh, come off it. NULL is cited all over the place in the Standard, and
defined in *seven* different standard headers, any of which could be
included by any of the others. You would have to be out of your mind to
define it as anything else.

--
Richard Herring

[Bill Seurer]

Richard Herring wrote:

NULL is cited all over the place in the Standard

Actually it isn't. I just searched on an older PDF copy of the standard
and there were about 20 mentions all of which were in the descriptions
of the C headers that define NULL or in some discussions of them in the
appendices.

[Richard Herring]

In message <cc***********@news.rchland.ibm.com>, Bill Seurer
<se****@us.ibm.com> writes

Richard Herring wrote:

NULL is cited all over the place in the Standard
Actually it isn't.

It doesn't appear on every line of every page, I'll grant you.
I just searched on an older PDF copy of the standard and there were
about 20 mentions all of which were in the descriptions of the C
headers that define NULL
And all those headers are part of the C++ standard.
or in some discussions of them in the appendices.

And in the discussion of streambufs. That's not a C feature.

Be that as it may, my point stands. If you include _any_ standard
header, you can no longer safely assume that NULL is not defined.

--
Richard Herring

[SaltPeter]

"Richard Herring" <ju**@[127.0.0.1]> wrote in message
news:iy**************@baesystems.com...

In message <ZA********************@news20.bellglobal.com>, SaltPeter
<Sa*******@Jupiter.sys> writes

"Nitin Bhardwaj" <ni*************@hotmail.com> wrote in message
news:17**************************@posting.google. com...

"SaltPeter" <Sa*******@Jupiter.sys> wrote in messagenews:<Lt**********************@news20.bellglobal. com>...

> "Nitin Bhardwaj" <ni*************@hotmail.com> wrote in message
> news:17**************************@posting.google.c om...
> > Hi all,
> >
> > It is said that C++ is a strongly typed language and thus a type-safe > > language (unlike C). So how does one explain the following behaviour : > >
> > int main(void)
> > {
> > char *p = NULL;
> > p = "A String Literal";//the compiler isuues no error/warning here > > // but ideally it should...as p is a non-const
> > // pointer and the string literal has the type
> > // const char *
> > // So, a conversion from const-ptr TO non-const
> > // should elicite warning/error from the compiler !!
>
> Ideally, what your compiler should do is generate an error about

NULL

> not being defined.

I had provided a code snippet & not the whole program :-) , Inclusion
of standard header(s) was assumed.

No, its not assumed. Your case is the perfect example why. iostream.h is
deprecated and should not be included in any modern code. Basicly, withoutincluding the headers, NULL could be anything. Surely, you aren't expectingfolks to rely on a crystal ball to substitute values for undefined
constants.

Oh, come off it. NULL is cited all over the place in the Standard, and
defined in *seven* different standard headers, any of which could be
included by any of the others. You would have to be out of your mind to
define it as anything else.

Wrong, both by fact and principle. The issue is not over where NULL is
defined but rather if NULL is defined. Read the OP's original quest. His
code ignores the include directives used in his program. Therefore:

int main()
{
char *p = NULL
// ....
}

can't be compiled. Code posted in the newsgroup should specify the headers
included.

I strongly disagree with your point of view and the OP's point of view that
included headers should be assumed. All of which is rather relevent since it
turns out he was using iostream.h rather than iostream. That was the whole
point of the NULL issue.

--
Richard Herring

[Richard Herring]

In message <5M********************@news20.bellglobal.com>, SaltPeter
<Sa*******@Jupiter.sys> writes

"Richard Herring" <ju**@[127.0.0.1]> wrote in message
news:iy**************@baesystems.com...

In message <ZA********************@news20.bellglobal.com>, SaltPeter
<Sa*******@Jupiter.sys> writes

>
>"Nitin Bhardwaj" <ni*************@hotmail.com> wrote in message
>news:17**************************@posting.google. com...
>> "SaltPeter" <Sa*******@Jupiter.sys> wrote in message
>news:<Lt**********************@news20.bellglobal. com>...
>> > "Nitin Bhardwaj" <ni*************@hotmail.com> wrote in message
>> > news:17**************************@posting.google.c om...
>> > > Hi all,
>> > >
>> > > It is said that C++ is a strongly typed language and thus atype-safe >> > > language (unlike C). So how does one explain the followingbehaviour : >> > >
>> > > int main(void)
>> > > {
>> > > char *p = NULL;
>> > > p = "A String Literal";//the compiler isuues no error/warninghere >> > > // but ideally it should...as p is a non-const
>> > > // pointer and the string literal has the type
>> > > // const char *
>> > > // So, a conversion from const-ptr TO non-const
>> > > // should elicite warning/error from the compiler !!
>> >
>> > Ideally, what your compiler should do is generate an error about
>NULL
>> > not being defined.
>>
>> I had provided a code snippet & not the whole program :-) , Inclusion
>> of standard header(s) was assumed.
>
>No, its not assumed. Your case is the perfect example why. iostream.h is
>deprecated and should not be included in any modern code. Basicly,without >including the headers, NULL could be anything. Surely, you aren'texpecting >folks to rely on a crystal ball to substitute values for undefined
>constants.
Oh, come off it. NULL is cited all over the place in the Standard, and
defined in *seven* different standard headers, any of which could be
included by any of the others. You would have to be out of your mind to
define it as anything else.

Wrong, both by fact and principle.

Sounds grand, but on deeper analysis means little. Which fact above is
wrong? Which principle?
The issue is not over where NULL is
defined
No. The issue is the type of a string literal, and why the standard
allows conversion of const pointer to non-const pointer in those
circumstances. Your nitpicking over NULL is a digression from the real
point.
but rather if NULL is defined.
.... but if you insist on such nitpicking, the issue is not _if_ NULL is
defined, but _how_ it might be defined, and consequently whether one can
deduce the OP's intention.
Read the OP's original quest. His
code ignores the include directives used in his program. Therefore:

int main()
{
char *p = NULL
If that had merely been
char * p;
the OP's original question would have been substantively identical, and
the answer the same. NULL is an irrelevancet.
// ....
}

can't be compiled. Code posted in the newsgroup should specify the headers
included.

I strongly disagree with your point of view
Then you misunderstand it. My point is not that included headers should
be assumed, but that the absence of anything that might be defined - per
the standard - in included standard headers must not be assumed. It's in
the same category as things like defining identifiers with leading
underscores.
and the OP's point of view that
included headers should be assumed.
All of which is rather relevent since it
turns out he was using iostream.h rather than iostream.
Hardly. Whichever standard headers he included, there would only be two
possible outcomes:
(a) NULL is undefined
(b) NULL is defined as a null pointer constant.
(c) There is no (c)
Therefore no crystal ball is required to deduce what the OP must have
meant by NULL.
That was the whole
point of the NULL issue.

--
Richard Herring

[SaltPeter]

"Richard Herring" <ju**@[127.0.0.1]> wrote in message
news:ee**************@baesystems.com...

In message <5M********************@news20.bellglobal.com>, SaltPeter
<Sa*******@Jupiter.sys> writes

"Richard Herring" <ju**@[127.0.0.1]> wrote in message
news:iy**************@baesystems.com...

In message <ZA********************@news20.bellglobal.com>, SaltPeter
<Sa*******@Jupiter.sys> writes
>
>"Nitin Bhardwaj" <ni*************@hotmail.com> wrote in message
>news:17**************************@posting.google. com...
>> "SaltPeter" <Sa*******@Jupiter.sys> wrote in message
>news:<Lt**********************@news20.bellglobal. com>...
>> > "Nitin Bhardwaj" <ni*************@hotmail.com> wrote in message
>> > news:17**************************@posting.google.c om...
>> > > Hi all,
>> > >
>> > > It is said that C++ is a strongly typed language and thus atype-safe

>> > > language (unlike C). So how does one explain the following

behaviour :

>> > >
>> > > int main(void)
>> > > {
>> > > char *p = NULL;
>> > > p = "A String Literal";//the compiler isuues no error/warning

here

>> > > // but ideally it should...as p is a non-const
>> > > // pointer and the string literal has the type
>> > > // const char *
>> > > // So, a conversion from const-ptr TO non-const
>> > > // should elicite warning/error from the compiler !!
>> >
>> > Ideally, what your compiler should do is generate an error

about >NULL
>> > not being defined.
>>
>> I had provided a code snippet & not the whole program :-) , Inclusion >> of standard header(s) was assumed.
>
>No, its not assumed. Your case is the perfect example why. iostream.h is >deprecated and should not be included in any modern code. Basicly,

without

>including the headers, NULL could be anything. Surely, you aren't

expecting

>folks to rely on a crystal ball to substitute values for undefined
>constants.

Oh, come off it. NULL is cited all over the place in the Standard, and
defined in *seven* different standard headers, any of which could be
included by any of the others. You would have to be out of your mind to
define it as anything else.

Wrong, both by fact and principle.

Sounds grand, but on deeper analysis means little. Which fact above is
wrong? Which principle?

NULL isn't defined in the standard, although rather heavily used and
implied. Example: iterating to past-the-end in an STL container.

The issue is not over where NULL is
defined
No. The issue is the type of a string literal, and why the standard
allows conversion of const pointer to non-const pointer in those
circumstances. Your nitpicking over NULL is a digression from the real
point.

A literal string is NOT a pointer. You are referring to a rule that doesn't
apply here. Its an array of const characters which in the OP's case was used
to initialize a pointer. There is a fine line one needs to walk when one
starts saying statements like: "a temporary integer variable therefore
implies a pointer-to-int". Its does not.

but rather if NULL is defined.
... but if you insist on such nitpicking, the issue is not _if_ NULL is
defined, but _how_ it might be defined, and consequently whether one can
deduce the OP's intention.

Read the OP's original quest. His
code ignores the include directives used in his program. Therefore:

int main()
{
char *p = NULL

If that had merely been
char * p;
the OP's original question would have been substantively identical, and
the answer the same. NULL is an irrelevancet.

NULL, like any constant is relevent. Here, try to compile this:

#include <iostream>

#define NULL ((void *)0)

int()
{
int *p = NULL
std::cout << p;
}

Note the NULL definition using C's definition (does not compile, not allowed
in C++ to initialize a pointer). This solves the issue of why NULL can't and
must not be "assumed".

// ....
}

can't be compiled. Code posted in the newsgroup should specify the

headersincluded.

I strongly disagree with your point of view

Then you misunderstand it. My point is not that included headers should
be assumed, but that the absence of anything that might be defined - per
the standard - in included standard headers must not be assumed. It's in
the same category as things like defining identifiers with leading
underscores.

and the OP's point of view that
included headers should be assumed.

All of which is rather relevent since it
turns out he was using iostream.h rather than iostream.

Hardly. Whichever standard headers he included, there would only be two
possible outcomes:
(a) NULL is undefined
(b) NULL is defined as a null pointer constant.
(c) There is no (c)
Therefore no crystal ball is required to deduce what the OP must have
meant by NULL.

c) explained above. ((void *)0) is illegal in C++.

That was the whole
point of the NULL issue.

--
Richard Herring

[Old Wolf]

"SaltPeter" <Sa*******@Jupiter.sys> wrote

I had provided a code snippet & not the whole program :-) , Inclusion
of standard header(s) was assumed.

No, its not assumed. Your case is the perfect example why. iostream.h is
deprecated and should not be included in any modern code.

iostream.h was never in any standard. Therefore it cannot be
deprecated.

[SaltPeter]

"Old Wolf" <ol*****@inspire.net.nz> wrote in message
news:84**************************@posting.google.c om...

"SaltPeter" <Sa*******@Jupiter.sys> wrote

I had provided a code snippet & not the whole program :-) , Inclusion
of standard header(s) was assumed.

No, its not assumed. Your case is the perfect example why. iostream.h is
deprecated and should not be included in any modern code.

iostream.h was never in any standard. Therefore it cannot be
deprecated.

Thats not correct, the old header was deprecated by the ISO/ANSI C++
committee.
http://www.parashift.com/c++-faq-lit...standards.html

[Victor Bazarov]

"SaltPeter" <Sa*******@Jupiter.sys> wrote...

"Old Wolf" <ol*****@inspire.net.nz> wrote in message
news:84**************************@posting.google.c om...

"SaltPeter" <Sa*******@Jupiter.sys> wrote

> I had provided a code snippet & not the whole program :-) , Inclusion > of standard header(s) was assumed.

No, its not assumed. Your case is the perfect example why. iostream.h is deprecated and should not be included in any modern code.

iostream.h was never in any standard. Therefore it cannot be
deprecated.

Thats not correct, the old header was deprecated by the ISO/ANSI C++
committee.
http://www.parashift.com/c++-faq-lit...standards.html

I think you're confused about what is deprecated. Read that FAQ chapter
carefully. C headers that have the .h form are deprecated. C++ headers
have never had standard form with .h, so they simply cannot be deprecated.
Deprecated means "OK in this edition of the Standard, but may not be OK
later, so don't rely on them".

Better yet, get yourself a copy of the Standard. You will see no mention
of <iostream.h> in it.

V

[SaltPeter]

"Victor Bazarov" <v.********@comAcast.net> wrote in message
news:tj3Ic.66153$Oq2.42680@attbi_s52...

"SaltPeter" <Sa*******@Jupiter.sys> wrote...

"Old Wolf" <ol*****@inspire.net.nz> wrote in message
news:84**************************@posting.google.c om...

"SaltPeter" <Sa*******@Jupiter.sys> wrote
>
> > I had provided a code snippet & not the whole program :-) , Inclusion > > of standard header(s) was assumed.
>
> No, its not assumed. Your case is the perfect example why.

iostream.h

is > deprecated and should not be included in any modern code.

iostream.h was never in any standard. Therefore it cannot be
deprecated.

Thats not correct, the old header was deprecated by the ISO/ANSI C++
committee.
http://www.parashift.com/c++-faq-lit...standards.html

I think you're confused about what is deprecated. Read that FAQ chapter
carefully. C headers that have the .h form are deprecated. C++ headers
have never had standard form with .h, so they simply cannot be deprecated.
Deprecated means "OK in this edition of the Standard, but may not be OK
later, so don't rely on them".

Better yet, get yourself a copy of the Standard. You will see no mention
of <iostream.h> in it.

V

You've got a point about the use of "deprecated", it doesn't mean
admonished, replaced or removed.

[Richard Herring]

In message <8J*********************@news20.bellglobal.com>, SaltPeter
<Sa*******@Jupiter.sys> writes

"Richard Herring" <ju**@[127.0.0.1]> wrote in message
news:ee**************@baesystems.com...

In message <5M********************@news20.bellglobal.com>, SaltPeter
<Sa*******@Jupiter.sys> writes

>
>"Richard Herring" <ju**@[127.0.0.1]> wrote in message
>news:iy**************@baesystems.com...
>> In message <ZA********************@news20.bellglobal.com>, SaltPeter
>> <Sa*******@Jupiter.sys> writes
>> >
>> >"Nitin Bhardwaj" <ni*************@hotmail.com> wrote in message
>> >news:17**************************@posting.google. com...
>> >> "SaltPeter" <Sa*******@Jupiter.sys> wrote in message
>> >news:<Lt**********************@news20.bellglobal. com>...
>> >> > "Nitin Bhardwaj" <ni*************@hotmail.com> wrote in message
>> >> > news:17**************************@posting.google.c om...
>> >> > > Hi all,
>> >> > >
>> >> > > It is said that C++ is a strongly typed language and thus a
>type-safe
>> >> > > language (unlike C). So how does one explain the following
>behaviour :
>> >> > >
>> >> > > int main(void)
>> >> > > {
>> >> > > char *p = NULL;
>> >> > > p = "A String Literal";//the compiler isuues noerror/warning >here
>> >> > > // but ideally it should...as p is a non-const
>> >> > > // pointer and the string literal has the type
>> >> > > // const char *
>> >> > > // So, a conversion from const-ptr TO non-const
>> >> > > // should elicite warning/error from the compiler !!
>> >> >
>> >> > Ideally, what your compiler should do is generate an errorabout >> >NULL
>> >> > not being defined.
>> >>
>> >> I had provided a code snippet & not the whole program :-) ,Inclusion >> >> of standard header(s) was assumed.
>> >
>> >No, its not assumed. Your case is the perfect example why. iostream.his >> >deprecated and should not be included in any modern code. Basicly,
>without
>> >including the headers, NULL could be anything. Surely, you aren't
>expecting
>> >folks to rely on a crystal ball to substitute values for undefined
>> >constants.
>>
>> Oh, come off it. NULL is cited all over the place in the Standard, and
>> defined in *seven* different standard headers, any of which could be
>> included by any of the others. You would have to be out of your mind to
>> define it as anything else.
>
>Wrong, both by fact and principle.
Sounds grand, but on deeper analysis means little. Which fact above is
wrong? Which principle?

NULL isn't defined in the standard,

"C.2.2.3
"The macro NULL, defined in any of <clocale>, <cstddef>, <cstdio>,
<cstlib>, <cstring>, <ctime> or <cwchar>, is an implementation-defined
C++ null pointer constant in this International Standard (18.1)"

18.1.4 says much the same. So its replacement text has to be something
which constitutes a legal C++ null pointer constant.
although rather heavily used and
implied. Example: iterating to past-the-end in an STL container.
How is iterating to past-the end a use of NULL?

>The issue is not over where NULL is
>defined
No. The issue is the type of a string literal, and why the standard
allows conversion of const pointer to non-const pointer in those
circumstances. Your nitpicking over NULL is a digression from the real
point.

A literal string is NOT a pointer.

Did I say it was?
You are referring to a rule that doesn't
apply here.
I'm not.
Its an array of const characters which in the OP's case was used
to initialize a pointer.
"4.2.
"A string literal ... can be converted to an rvalue of type "pointer to
char"... For the purpose of ranking in overload resolution, this
conversion is considered an array-to-pointer conversion followed by a
qualification conversion."
There is a fine line one needs to walk when one
starts saying statements like: "a temporary integer variable therefore
implies a pointer-to-int". Its does not.
Since nobody is saying that, so what? You appear to be arguing against
several things that nobody is saying.

> but rather if NULL is defined.

... but if you insist on such nitpicking, the issue is not _if_ NULL is
defined, but _how_ it might be defined, and consequently whether one can
deduce the OP's intention.

>Read the OP's original quest. His
>code ignores the include directives used in his program. Therefore:
>
>int main()
>{
> char *p = NULL

If that had merely been
char * p;
the OP's original question would have been substantively identical, and
the answer the same. NULL is an irrelevancet.

NULL, like any constant is relevent. Here, try to compile this:

#include <iostream>

#define NULL ((void *)0)

int()

Do you mean int main() ?
{
int *p = NULL
Needs a semicolon.
std::cout << p;
}

Note the NULL definition using C's definition (does not compile, not allowed
in C++ to initialize a pointer).
Right, so why are you using a C definition in C++ ?
This solves the issue of why NULL can't and
must not be "assumed".

Not surprisingly, even with the corrections noted, it fails to compile.
*However*, the message _my_ compiler gives is "Redefinition of 'NULL' is
not identical".

If I remove the erroneous definition of NULL, _my_ compiler has no
problems compiling this:

#include <iostream>
int main()
{
int * p = NULL;
std::cout << p;
}

This solves by example the issue of why NULL can't and must not be
"assumed" _not_ to be defined.

> // ....
>}
>
>can't be compiled. Code posted in the newsgroup should specify theheaders >included.
>
>I strongly disagree with your point of view

Then you misunderstand it. My point is not that included headers should
be assumed, but that the absence of anything that might be defined - per
the standard - in included standard headers must not be assumed. It's in
the same category as things like defining identifiers with leading
underscores.

>and the OP's point of view that
>included headers should be assumed.

> All of which is rather relevent since it
>turns out he was using iostream.h rather than iostream.

Hardly. Whichever standard headers he included, there would only be two
possible outcomes:
(a) NULL is undefined
(b) NULL is defined as a null pointer constant.
(c) There is no (c)
Therefore no crystal ball is required to deduce what the OP must have
meant by NULL.

c) explained above. ((void *)0) is illegal in C++.

And nobody but yourself has suggested otherwise.

>That was the whole
>point of the NULL issue.

NULL is a null pointer constant. That doesn't mean it's ((void*)0) .
--
Richard Herring