string and const char

[Mike]

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

 

[Saeed Amrollahi]

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

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

 

[Bo Persson]

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

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

 

[Mike]

Thanks. on Lin I had string.h but apparently on Win we need string
without .h

 

[Saeed Amrollahi]

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

 

[Michael Doubez]

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

 

[Juha Nieminen]

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.

 

[Michael Doubez]

  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

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.

 

[Juha Nieminen]

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

 

[Michael Doubez]

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

 

[Juha Nieminen]

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

 

[Michael Doubez]

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 )