Is C++ a type-safe language ??

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Richard Herring

    #16
    Re: Is C++ a type-safe language ??

    In message <5M1Hc.40890$JG 5.871023@news20 .bellglobal.com >, SaltPeter
    <SaltPeter@Jupi ter.sys> writes[color=blue]
    >
    >"Richard Herring" <junk@[127.0.0.1]> wrote in message
    >news:iyDAwoH+9 86AFwNm@baesyst ems.com...[color=green]
    >> In message <ZADGc.28539$JG 5.587257@news20 .bellglobal.com >, SaltPeter
    >> <SaltPeter@Jupi ter.sys> writes[color=darkred]
    >> >
    >> >"Nitin Bhardwaj" <nitinbhardwaj8 0@hotmail.com> wrote in message
    >> >news:17fa8780. 0407052252.2975 67cc@posting.go ogle.com...
    >> >> "SaltPeter" <SaltPeter@Jupi ter.sys> wrote in message
    >> >news:<LtkFc.19 5935$207.202309 1@news20.bellgl obal.com>...
    >> >> > "Nitin Bhardwaj" <nitinbhardwaj8 0@hotmail.com> wrote in message
    >> >> > news:17fa8780.0 407012058.3fd2d 5d8@posting.goo gle.com...
    >> >> > > Hi all,
    >> >> > >
    >> >> > > It is said that C++ is a strongly typed language and thus a[/color][/color]
    >type-safe[color=green][color=darkred]
    >> >> > > language (unlike C). So how does one explain the following[/color][/color]
    >behaviour :[color=green][color=darkred]
    >> >> > >
    >> >> > > int main(void)
    >> >> > > {
    >> >> > > char *p = NULL;
    >> >> > > p = "A String Literal";//the compiler isuues no error/warning[/color][/color]
    >here[color=green][color=darkred]
    >> >> > > // 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,[/color][/color]
    >without[color=green][color=darkred]
    >> >including the headers, NULL could be anything. Surely, you aren't[/color][/color]
    >expecting[color=green][color=darkred]
    >> >folks to rely on a crystal ball to substitute values for undefined
    >> >constants.[/color]
    >>
    >> 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.[/color]
    >
    >Wrong, both by fact and principle.[/color]

    Sounds grand, but on deeper analysis means little. Which fact above is
    wrong? Which principle?
    [color=blue]
    >The issue is not over where NULL is
    >defined[/color]

    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.
    [color=blue]
    > but rather if NULL is defined.[/color]

    .... 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.
    [color=blue]
    >Read the OP's original quest. His
    >code ignores the include directives used in his program. Therefore:
    >
    >int main()
    >{
    > char *p = NULL[/color]

    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.
    [color=blue]
    > // ....
    >}
    >
    >can't be compiled. Code posted in the newsgroup should specify the headers
    >included.
    >
    >I strongly disagree with your point of view[/color]

    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.
    [color=blue]
    >and the OP's point of view that
    >included headers should be assumed.[/color]

    [color=blue]
    > All of which is rather relevent since it
    >turns out he was using iostream.h rather than iostream.[/color]

    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.
    [color=blue]
    >That was the whole
    >point of the NULL issue.
    >[/color]
    --
    Richard Herring

    Comment

    • SaltPeter

      #17
      Re: Is C++ a type-safe language ??


      "Richard Herring" <junk@[127.0.0.1]> wrote in message
      news:eeAPLAC2bR 7AFwQU@baesyste ms.com...[color=blue]
      > In message <5M1Hc.40890$JG 5.871023@news20 .bellglobal.com >, SaltPeter
      > <SaltPeter@Jupi ter.sys> writes[color=green]
      > >
      > >"Richard Herring" <junk@[127.0.0.1]> wrote in message
      > >news:iyDAwoH+9 86AFwNm@baesyst ems.com...[color=darkred]
      > >> In message <ZADGc.28539$JG 5.587257@news20 .bellglobal.com >, SaltPeter
      > >> <SaltPeter@Jupi ter.sys> writes
      > >> >
      > >> >"Nitin Bhardwaj" <nitinbhardwaj8 0@hotmail.com> wrote in message
      > >> >news:17fa8780. 0407052252.2975 67cc@posting.go ogle.com...
      > >> >> "SaltPeter" <SaltPeter@Jupi ter.sys> wrote in message
      > >> >news:<LtkFc.19 5935$207.202309 1@news20.bellgl obal.com>...
      > >> >> > "Nitin Bhardwaj" <nitinbhardwaj8 0@hotmail.com> wrote in message
      > >> >> > news:17fa8780.0 407012058.3fd2d 5d8@posting.goo gle.com...
      > >> >> > > Hi all,
      > >> >> > >
      > >> >> > > It is said that C++ is a strongly typed language and thus a[/color]
      > >type-safe[color=darkred]
      > >> >> > > language (unlike C). So how does one explain the following[/color]
      > >behaviour :[color=darkred]
      > >> >> > >
      > >> >> > > int main(void)
      > >> >> > > {
      > >> >> > > char *p = NULL;
      > >> >> > > p = "A String Literal";//the compiler isuues no[/color][/color][/color]
      error/warning[color=blue][color=green]
      > >here[color=darkred]
      > >> >> > > // 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[/color][/color][/color]
      about[color=blue][color=green][color=darkred]
      > >> >NULL
      > >> >> > not being defined.
      > >> >>
      > >> >> I had provided a code snippet & not the whole program :-) ,[/color][/color][/color]
      Inclusion[color=blue][color=green][color=darkred]
      > >> >> of standard header(s) was assumed.
      > >> >
      > >> >No, its not assumed. Your case is the perfect example why. iostream.h[/color][/color][/color]
      is[color=blue][color=green][color=darkred]
      > >> >deprecated and should not be included in any modern code. Basicly,[/color]
      > >without[color=darkred]
      > >> >including the headers, NULL could be anything. Surely, you aren't[/color]
      > >expecting[color=darkred]
      > >> >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.[/color]
      > >
      > >Wrong, both by fact and principle.[/color]
      >
      > Sounds grand, but on deeper analysis means little. Which fact above is
      > wrong? Which principle?[/color]

      NULL isn't defined in the standard, although rather heavily used and
      implied. Example: iterating to past-the-end in an STL container.
      [color=blue]
      >[color=green]
      > >The issue is not over where NULL is
      > >defined[/color]
      >
      > 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.[/color]

      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.
      [color=blue]
      >[color=green]
      > > but rather if NULL is defined.[/color]
      >
      > ... 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.
      >[color=green]
      > >Read the OP's original quest. His
      > >code ignores the include directives used in his program. Therefore:
      > >
      > >int main()
      > >{
      > > char *p = NULL[/color]
      >
      > 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.[/color]

      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".
      [color=blue]
      >[color=green]
      > > // ....
      > >}
      > >
      > >can't be compiled. Code posted in the newsgroup should specify the[/color][/color]
      headers[color=blue][color=green]
      > >included.
      > >
      > >I strongly disagree with your point of view[/color]
      >
      > 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.
      >[color=green]
      > >and the OP's point of view that
      > >included headers should be assumed.[/color]
      >
      >[color=green]
      > > All of which is rather relevent since it
      > >turns out he was using iostream.h rather than iostream.[/color]
      >
      > 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.[/color]

      c) explained above. ((void *)0) is illegal in C++.
      [color=blue]
      >[color=green]
      > >That was the whole
      > >point of the NULL issue.
      > >[/color]
      > --
      > Richard Herring[/color]


      Comment

      • Old Wolf

        #18
        Re: Is C++ a type-safe language ??

        "SaltPeter" <SaltPeter@Jupi ter.sys> wrote[color=blue]
        >[color=green]
        > > I had provided a code snippet & not the whole program :-) , Inclusion
        > > of standard header(s) was assumed.[/color]
        >
        > No, its not assumed. Your case is the perfect example why. iostream.h is
        > deprecated and should not be included in any modern code.[/color]

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

        Comment

        • SaltPeter

          #19
          Re: Is C++ a type-safe language ??


          "Old Wolf" <oldwolf@inspir e.net.nz> wrote in message
          news:843a4f78.0 407100630.68932 7a8@posting.goo gle.com...[color=blue]
          > "SaltPeter" <SaltPeter@Jupi ter.sys> wrote[color=green]
          > >[color=darkred]
          > > > I had provided a code snippet & not the whole program :-) , Inclusion
          > > > of standard header(s) was assumed.[/color]
          > >
          > > No, its not assumed. Your case is the perfect example why. iostream.h is
          > > deprecated and should not be included in any modern code.[/color]
          >
          > iostream.h was never in any standard. Therefore it cannot be
          > deprecated.[/color]

          Thats not correct, the old header was deprecated by the ISO/ANSI C++
          committee.



          Comment

          • Victor Bazarov

            #20
            Re: Is C++ a type-safe language ??

            "SaltPeter" <SaltPeter@Jupi ter.sys> wrote...[color=blue]
            > "Old Wolf" <oldwolf@inspir e.net.nz> wrote in message
            > news:843a4f78.0 407100630.68932 7a8@posting.goo gle.com...[color=green]
            > > "SaltPeter" <SaltPeter@Jupi ter.sys> wrote[color=darkred]
            > > >
            > > > > I had provided a code snippet & not the whole program :-) ,[/color][/color][/color]
            Inclusion[color=blue][color=green][color=darkred]
            > > > > of standard header(s) was assumed.
            > > >
            > > > No, its not assumed. Your case is the perfect example why. iostream.h[/color][/color][/color]
            is[color=blue][color=green][color=darkred]
            > > > deprecated and should not be included in any modern code.[/color]
            > >
            > > iostream.h was never in any standard. Therefore it cannot be
            > > deprecated.[/color]
            >
            > Thats not correct, the old header was deprecated by the ISO/ANSI C++
            > committee.
            > http://www.parashift.com/c++-faq-lit...standards.html[/color]

            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


            Comment

            • SaltPeter

              #21
              Re: Is C++ a type-safe language ??


              "Victor Bazarov" <v.Abazarov@com Acast.net> wrote in message
              news:tj3Ic.6615 3$Oq2.42680@att bi_s52...[color=blue]
              > "SaltPeter" <SaltPeter@Jupi ter.sys> wrote...[color=green]
              > > "Old Wolf" <oldwolf@inspir e.net.nz> wrote in message
              > > news:843a4f78.0 407100630.68932 7a8@posting.goo gle.com...[color=darkred]
              > > > "SaltPeter" <SaltPeter@Jupi ter.sys> wrote
              > > > >
              > > > > > I had provided a code snippet & not the whole program :-) ,[/color][/color]
              > Inclusion[color=green][color=darkred]
              > > > > > of standard header(s) was assumed.
              > > > >
              > > > > No, its not assumed. Your case is the perfect example why.[/color][/color][/color]
              iostream.h[color=blue]
              > is[color=green][color=darkred]
              > > > > deprecated and should not be included in any modern code.
              > > >
              > > > iostream.h was never in any standard. Therefore it cannot be
              > > > deprecated.[/color]
              > >
              > > Thats not correct, the old header was deprecated by the ISO/ANSI C++
              > > committee.
              > > http://www.parashift.com/c++-faq-lit...standards.html[/color]
              >
              > 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
              >[/color]

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


              Comment

              • Richard Herring

                #22
                Re: Is C++ a type-safe language ??

                In message <8JKHc.40034$WM 5.2194878@news2 0.bellglobal.co m>, SaltPeter
                <SaltPeter@Jupi ter.sys> writes[color=blue]
                >
                >"Richard Herring" <junk@[127.0.0.1]> wrote in message
                >news:eeAPLAC2b R7AFwQU@baesyst ems.com...[color=green]
                >> In message <5M1Hc.40890$JG 5.871023@news20 .bellglobal.com >, SaltPeter
                >> <SaltPeter@Jupi ter.sys> writes[color=darkred]
                >> >
                >> >"Richard Herring" <junk@[127.0.0.1]> wrote in message
                >> >news:iyDAwoH+9 86AFwNm@baesyst ems.com...
                >> >> In message <ZADGc.28539$JG 5.587257@news20 .bellglobal.com >, SaltPeter
                >> >> <SaltPeter@Jupi ter.sys> writes
                >> >> >
                >> >> >"Nitin Bhardwaj" <nitinbhardwaj8 0@hotmail.com> wrote in message
                >> >> >news:17fa8780. 0407052252.2975 67cc@posting.go ogle.com...
                >> >> >> "SaltPeter" <SaltPeter@Jupi ter.sys> wrote in message
                >> >> >news:<LtkFc.19 5935$207.202309 1@news20.bellgl obal.com>...
                >> >> >> > "Nitin Bhardwaj" <nitinbhardwaj8 0@hotmail.com> wrote in message
                >> >> >> > news:17fa8780.0 407012058.3fd2d 5d8@posting.goo gle.com...
                >> >> >> > > 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[/color][/color]
                >error/warning[color=green][color=darkred]
                >> >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[/color][/color]
                >about[color=green][color=darkred]
                >> >> >NULL
                >> >> >> > not being defined.
                >> >> >>
                >> >> >> I had provided a code snippet & not the whole program :-) ,[/color][/color]
                >Inclusion[color=green][color=darkred]
                >> >> >> of standard header(s) was assumed.
                >> >> >
                >> >> >No, its not assumed. Your case is the perfect example why. iostream.h[/color][/color]
                >is[color=green][color=darkred]
                >> >> >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.[/color]
                >>
                >> Sounds grand, but on deeper analysis means little. Which fact above is
                >> wrong? Which principle?[/color]
                >
                >NULL isn't defined in the standard,[/color]

                "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.
                [color=blue]
                >although rather heavily used and
                >implied. Example: iterating to past-the-end in an STL container.[/color]

                How is iterating to past-the end a use of NULL?[color=blue]
                >[color=green]
                >>[color=darkred]
                >> >The issue is not over where NULL is
                >> >defined[/color]
                >>
                >> 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.[/color]
                >
                >A literal string is NOT a pointer.[/color]

                Did I say it was?
                [color=blue]
                >You are referring to a rule that doesn't
                >apply here.[/color]

                I'm not.
                [color=blue]
                >Its an array of const characters which in the OP's case was used
                >to initialize a pointer.[/color]

                "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."
                [color=blue]
                > 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.[/color]

                Since nobody is saying that, so what? You appear to be arguing against
                several things that nobody is saying.
                [color=blue][color=green][color=darkred]
                >> > but rather if NULL is defined.[/color]
                >>
                >> ... 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.
                >>[color=darkred]
                >> >Read the OP's original quest. His
                >> >code ignores the include directives used in his program. Therefore:
                >> >
                >> >int main()
                >> >{
                >> > char *p = NULL[/color]
                >>
                >> 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.[/color]
                >
                >NULL, like any constant is relevent. Here, try to compile this:
                >
                >#include <iostream>
                >
                >#define NULL ((void *)0)
                >
                >int()[/color]

                Do you mean int main() ?
                [color=blue]
                >{
                >int *p = NULL[/color]

                Needs a semicolon.
                [color=blue]
                >std::cout << p;
                >}
                >
                >Note the NULL definition using C's definition (does not compile, not allowed
                >in C++ to initialize a pointer).[/color]

                Right, so why are you using a C definition in C++ ?
                [color=blue]
                >This solves the issue of why NULL can't and
                >must not be "assumed".[/color]

                Not surprisingly, even with the corrections noted, it fails to compile.
                *However*, the message _my_ compiler gives is "Redefiniti on 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.
                [color=blue][color=green]
                >>[color=darkred]
                >> > // ....
                >> >}
                >> >
                >> >can't be compiled. Code posted in the newsgroup should specify the[/color][/color]
                >headers[color=green][color=darkred]
                >> >included.
                >> >
                >> >I strongly disagree with your point of view[/color]
                >>
                >> 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.
                >>[color=darkred]
                >> >and the OP's point of view that
                >> >included headers should be assumed.[/color]
                >>
                >>[color=darkred]
                >> > All of which is rather relevent since it
                >> >turns out he was using iostream.h rather than iostream.[/color]
                >>
                >> 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.[/color]
                >
                >c) explained above. ((void *)0) is illegal in C++.[/color]

                And nobody but yourself has suggested otherwise.
                [color=blue][color=green][color=darkred]
                >> >That was the whole
                >> >point of the NULL issue.[/color][/color][/color]

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

                Comment

                Working...