string and const char

Discussion in 'C++' started by Mike, Jul 27, 2010.

  1. Mike

    Mike Guest

    Hi
    I've compiled this on Linux:

    string vlstr = str+"sounds/rain.wav"; //str is a string as well

    but with VC2008 I get:
    -----
    error C2784: 'std:: _String_iterator <_Elem,_Traits,_Alloc> std::
    operator + (_String_iterator <_Elem,_Traits,_Alloc>::
    difference_type , std:: _String_iterator <_Elem,_Traits,_Alloc>) ":
    template argument for 'std:: _String_iterator <_Elem,_Traits,_Alloc>"
    could not be derived from' const char [16].
    -------
    Many thanks
     
    Mike, Jul 27, 2010
    #1
    1. Advertising

  2. On Jul 27, 9:20 pm, Mike <> wrote:
    > Hi
    > I've compiled this on Linux:
    >
    > string vlstr = str+"sounds/rain.wav";  //str is a string as well
    >
    > but with VC2008 I get:
    > -----
    > error C2784: 'std:: _String_iterator <_Elem,_Traits,_Alloc> std::
    > operator + (_String_iterator <_Elem,_Traits,_Alloc>::
    > difference_type , std:: _String_iterator <_Elem,_Traits,_Alloc>) ":
    > template argument for 'std:: _String_iterator <_Elem,_Traits,_Alloc>"
    > could not be derived from' const char [16].
    > -------
    > Many thanks


    Hi

    It's not true.
    I compiled and ran the following code under GCC 4.5.0 and VS 2008:

    #include <string>
    #include <iostream>
    int main()
    {
    using namespace std;
    string str;
    string vlstr = str + "sounds/rain.wav";
    cout << vlstr << '\n';
    return 0;
    }

    Regards,
    -- Saeed Amrollahi
     
    Saeed Amrollahi, Jul 27, 2010
    #2
    1. Advertising

  3. Mike

    Bo Persson Guest

    Saeed Amrollahi wrote:
    > On Jul 27, 9:20 pm, Mike <> wrote:
    >> Hi
    >> I've compiled this on Linux:
    >>
    >> string vlstr = str+"sounds/rain.wav"; //str is a string as well
    >>
    >> but with VC2008 I get:
    >> -----
    >> error C2784: 'std:: _String_iterator <_Elem,_Traits,_Alloc> std::
    >> operator + (_String_iterator <_Elem,_Traits,_Alloc>::
    >> difference_type , std:: _String_iterator <_Elem,_Traits,_Alloc>) ":
    >> template argument for 'std:: _String_iterator
    >> <_Elem,_Traits,_Alloc>" could not be derived from' const char [16].
    >> -------
    >> Many thanks

    >
    > Hi
    >
    > It's not true.
    > I compiled and ran the following code under GCC 4.5.0 and VS 2008:
    >
    > #include <string>
    > #include <iostream>
    > int main()
    > {
    > using namespace std;
    > string str;
    > string vlstr = str + "sounds/rain.wav";
    > cout << vlstr << '\n';
    > return 0;
    > }
    >


    Yes, but you also included the <string> header, which I guess Mike
    didn't.


    Bo Persson
     
    Bo Persson, Jul 27, 2010
    #3
  4. Mike

    Mike Guest

    Thanks. on Lin I had string.h but apparently on Win we need string
    without .h
     
    Mike, Jul 28, 2010
    #4
  5. On Jul 28, 8:48 am, Mike <> wrote:
    > Thanks. on Lin I had string.h but apparently on Win we need string
    > without .h


    Hi

    If you want to code using Standard C++, use <string>
    on both Linux/GCC and Windows/VS.

    Regards,
    -- Saeed Amrollahi
     
    Saeed Amrollahi, Jul 28, 2010
    #5
  6. On 28 juil, 11:26, Saeed Amrollahi <> wrote:
    > On Jul 28, 8:48 am, Mike <> wrote:
    >
    > > Thanks. on Lin I had string.h but apparently on Win we need string
    > > without .h

    >
    > If you want to code using Standard C++, use <string>
    > on both Linux/GCC and Windows/VS.


    Please note that <string.h> and <string> are not related.
    The equivalent of <string.h> in C++ is <cstring>.

    --
    Michael
     
    Michael Doubez, Jul 28, 2010
    #6
  7. Michael Doubez <> wrote:
    > The equivalent of <string.h> in C++ is <cstring>.


    Actually both are standard C++ (unless I'm completely misremembering).
    Their difference is that the former is guaranteed to pull all the names
    defined by the header in the global namespace, while the latter is not
    (guaranteed, that is; most practical implementations do it nevertheless).
    Basically the idea with the former is to act as a standardized "hack" to
    try to maintain some compatibility with pre-standard C++ code.
     
    Juha Nieminen, Jul 28, 2010
    #7
  8. On 28 juil, 19:17, Juha Nieminen <> wrote:
    > Michael Doubez <> wrote:
    > > The equivalent of <string.h> in C++ is <cstring>.

    >
    >   Actually both are standard C++ (unless I'm completely misremembering)..
    > Their difference is that the former is guaranteed to pull all the names
    > defined by the header in the global namespace, while the latter is not
    > (guaranteed, that is; most practical implementations do it nevertheless).


    No. In this case, those are C headers.

    Concerning string.h, this is adressed in 20.4.6/5+6. <cstring> and
    <string.h> have the smame content except for modification with memchr
    for wide char types.

    > Basically the idea with the former is to act as a standardized "hack" to
    > try to maintain some compatibility with pre-standard C++ code.


    What you refer to are the pre-standard STL header which .h form was
    deprecated. I don't remember what used to be the <string> header name
    (maybe stl_string.h).

    However, the point was here was that <string> and <string.h> are not
    related at all.

    --
    Michael
     
    Michael Doubez, Jul 29, 2010
    #8
  9. Michael Doubez <> wrote:
    > On 28 juil, 19:17, Juha Nieminen <> wrote:
    >> Michael Doubez <> wrote:
    >> > The equivalent of <string.h> in C++ is <cstring>.

    >>
    >>   Actually both are standard C++ (unless I'm completely misremembering).
    >> Their difference is that the former is guaranteed to pull all the names
    >> defined by the header in the global namespace, while the latter is not
    >> (guaranteed, that is; most practical implementations do it nevertheless).

    >
    > No. In this case, those are C headers.


    If they are defined in the C++ standard, then they are C++ headers.

    Just because they happen to have the same symbols and functionality as
    the equivalent standard C headers doesn't make them any "less C++". A
    piece of C++ code which happens to also be valid C doesn't make it any
    "less" C++.
     
    Juha Nieminen, Jul 29, 2010
    #9
  10. On 29 juil, 14:47, Juha Nieminen <> wrote:
    > Michael Doubez <> wrote:
    > > On 28 juil, 19:17, Juha Nieminen <> wrote:
    > >> Michael Doubez <> wrote:
    > >> > The equivalent of <string.h> in C++ is <cstring>.

    >
    > >>   Actually both are standard C++ (unless I'm completely misremembering).
    > >> Their difference is that the former is guaranteed to pull all the names
    > >> defined by the header in the global namespace, while the latter is not
    > >> (guaranteed, that is; most practical implementations do it nevertheless).

    >
    > > No. In this case, those are C headers.

    >
    >   If they are defined in the C++ standard, then they are C++ headers.
    >
    >   Just because they happen to have the same symbols and functionality as
    > the equivalent standard C headers doesn't make them any "less C++". A
    > piece of C++ code which happens to also be valid C doesn't make it any
    > "less" C++.


    Yes. I meant they are the headers inherited from C and not for
    backward compatibility reason (contrary to pre-standard stl headers
    which are deprecated).

    However, this was not the point here; it was Saeed Amrollahi's
    confusion about <string> being the <.h suffix>-less version of
    <string.h>.

    --
    Michael
     
    Michael Doubez, Jul 29, 2010
    #10
  11. Michael Doubez <> wrote:
    > Yes. I meant they are the headers inherited from C and not for
    > backward compatibility reason (contrary to pre-standard stl headers
    > which are deprecated).


    My point was that there exist two sets of "C" headers: Those which
    use the same name as C (eg. "stdio.h") and those which use the C++
    variant ("cstdio"). They are not simply two names for the same thing,
    but the former actually do something differently than the latter
    (namely, putting everything into the global namespae). My point was
    that the former was included in the standard to keep compatibility
    with pre-standard programs (which typically included <stdio.h> and
    assumed everything was in global namespace instead of including <cstdio>
    and assuming the symbols are in the std namespace).
     
    Juha Nieminen, Jul 30, 2010
    #11
  12. On 30 juil, 14:12, Pete Becker <> wrote:
    > On 2010-07-30 06:46:53 -0400, Juha Nieminen said:
    >
    > > Michael Doubez <> wrote:
    > >> Yes. I meant they are the headers inherited from C and not for
    > >> backward compatibility reason (contrary to pre-standard stl headers
    > >> which are deprecated).

    >
    > >   My point was that there exist two sets of "C" headers: Those which
    > > use the same name as C (eg. "stdio.h") and those which use the C++
    > > variant ("cstdio"). They are not simply two names for the same thing,
    > > but the former actually do something differently than the latter
    > > (namely, putting everything into the global namespae). My point was
    > > that the former was included in the standard to keep compatibility
    > > with pre-standard programs

    >
    > It's there to keep compatibility with C code. All of it, not just pre-standard.


    I have noticed that in the current standard[98], the D annexe that
    specify it is identified by [depr] and relevant section is
    [depr.c.headers].

    What 'depr' stands for ?
    (I am thinking hard 'deprecated' but since the annex starts with
    deprecated features, it may be only an unfortunate naming :) )

    --
    Michael
     
    Michael Doubez, Jul 30, 2010
    #12
    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. Santa
    Replies:
    1
    Views:
    1,153
    Mark A. Odell
    Jul 17, 2003
  2. Replies:
    24
    Views:
    904
    Netocrat
    Oct 30, 2005
  3. lovecreatesbeauty
    Replies:
    1
    Views:
    1,149
    Ian Collins
    May 9, 2006
  4. Gary
    Replies:
    9
    Views:
    1,526
    CBFalconer
    Aug 24, 2006
  5. Javier
    Replies:
    2
    Views:
    621
    James Kanze
    Sep 4, 2007
Loading...

Share This Page