Libstdc++-porting-howto

The latest C++-standard (ISO-14882) requires that the standard C++-library is defined in namespace std::. Thus, in order to use classes from the standard C++-library, you can do one of three things:

Because there are many compilers which still use an implementation that does not have the standard C++-library in namespace std::, some care is required to support these as well.

Namespace back-portability-issues are generally not a problem with g++, because versions of g++ that do not have libstdc++ in std:: use -fno-honor-std (ignore std::, :: = std::) by default. That is, the responsibility for enabling or disabling std:: is on the user; the maintainer does not have to care about it. This probably applies to some other compilers as well.

The following sections list some possible solutions to support compilers that cannot ignore std::.

	  namespace Gtk {
	  using std::string;
	  class Window { ... }
	  }
	

	  namespace std { }
	  using namespace std;
	

I have seen ios::nocreate being used for input-streams, most probably because the author thought it would be more correct to specify nocreate "explicitly". So you can simply leave it out for input-streams.

For output streams, "nocreate" is probably the default, unless you specify std::ios::trunc ? To be safe, you can open the file for reading, check if it has been opened, and then decide whether you want to create/replace or not. To my knowledge, even older implementations support app, ate and trunc (except for app ?).

Phil Edwards <pedwards@disaster.jaj.com> writes: It was considered and rejected. Not all environments use file descriptors. Of those that do, not all of them use integers to represent them.

When using libstdc++-v3, you can use

	  #include <fstream>
	

For a portable solution (among systems which use filedescriptors), you need to implement a subclass of std::streambuf (or std::basic_streambuf<..>) which opens a file given a descriptor, and then pass an instance of this to the stream-constructor. For an example of this, refer to fdstream example by Nicolai Josuttis.

All new headers can be seen in this source-code.

The old C++-headers (iostream.h etc.) are available, but gcc generates a warning that you are using deprecated headers.

The following are not proper uses of iterators, but may be working fixes for existing uses of iterators.

Glibc 2.0.x and 2.1.x define the <ctype.h> -functionality as macros (isspace, isalpha etc.). Libstdc++-v3 "shadows" these macros as described in the section about c-headers.

Older implementations of libstdc++ (g++-2 for egcs 1.x and g++-3 for gcc 2.95.x), however, keep these functions as macros, and so it is not back-portable to use fully qualified names. For example:

	#include <cctype>
	int main() { std::isspace('X'); }
      

	std:: (__ctype_b[(int) ( ( 'X' ) )] & (unsigned short int)
	_ISspace )  ;
      

One solution I can think of is to test for -v3 using autoconf-macros, and define macros for each of the C-functions (maybe that is possible with one "wrapper" macro as well ?).

Another solution which would fix g++ is to tell the user to modify a header-file so that g++-2 (egcs 1.x) and g++-3 (gcc 2.95.x) define a macro which tells <ctype.h> to define functions instead of macros:

	// This keeps isalnum, et al from being propagated as macros.
	#if __linux__
	#define __NO_CTYPE 1
	#endif

	[ now include <ctype.h> ]
      

Another problem arises if you put a using namespace std; declaration at the top, and include <ctype.h>. This will result in ambiguities between the definitions in the global namespace (<ctype.h>) and the definitions in namespace std:: (<cctype>).

The solution to this problem was posted to the libstdc++-v3 mailing-list: Benjamin Kosnik <bkoz@redhat.com> writes: ‘ --enable-cshadow-headers is currently broken. As a result, shadow headers are not being searched.... ’ This is now outdated, but gcc 3.0 still does not have fully compliant "shadow headers".

At least some older implementations don't have std::ios_base, so you should use std::ios::badbit, std::ios::failbit and std::ios::eofbit and std::ios::goodbit.

One solution is to add an autoconf-test for this:

	AC_MSG_CHECKING(for container::at)
	AC_TRY_COMPILE(
	[
	#include <vector>
	#include <deque>
	#include <string>
	
	using namespace std;
	],
	[
	deque<int> test_deque(3);
	test_deque.at(2);
	vector<int> test_vector(2);
	test_vector.at(1);
	string test_string("test_string");
	test_string.at(3);
	],
	[AC_MSG_RESULT(yes)
	AC_DEFINE(HAVE_CONTAINER_AT)],
	[AC_MSG_RESULT(no)])
      

	#ifdef HAVE_CHAR_TRAITS
	#define CPP_EOF std::char_traits<char>::eof()
	#else
	#define CPP_EOF EOF
	#endif
      

There are two functions for deleting the contents of a string: clear and erase (the latter returns the string).

	void 
	clear() { _M_mutate(0, this->size(), 0); }
      

	basic_string& 
	erase(size_type __pos = 0, size_type __n = npos)
	{ 
	return this->replace(_M_check(__pos), _M_fold(__pos, __n),
	_M_data(), _M_data()); 
	}
      

These are not supported any more - use stringstreams instead.

Libstdc++-v3 provides the new i/ostringstream-classes, (<sstream>), but for compatibility with older implementations you still have to use i/ostrstream (<strstream>):

	#ifdef HAVE_SSTREAM
	#include <sstream>
	#else
	#include <strstream>
	#endif
      

You can then use output-stringstreams like this:

	#ifdef HAVE_SSTREAM
	std::ostringstream oss;
	#else
	std::ostrstream oss;
	#endif
	oss << "Name=" << m_name << ", number=" << m_number << std::endl;
	...
	#ifndef HAVE_SSTREAM
	oss << std::ends; // terminate the char*-string
	#endif
	// str() returns char* for ostrstream and a string for ostringstream
	// this also causes ostrstream to think that the buffer's memory
	// is yours
	m_label.set_text(oss.str());
	#ifndef HAVE_SSTREAM
	// let the ostrstream take care of freeing the memory
	oss.freeze(false);
	#endif
      

Input-stringstreams can be used similarly:

	std::string input;
	...
	#ifdef HAVE_SSTREAM
	std::istringstream iss(input);
	#else
	std::istrstream iss(input.c_str());
	#endif
	int i;
	iss >> i; 
      

	std::istringstream iss(numerator);
	iss >> m_num;
	// this is not possible with istrstream
	iss.clear();
	iss.str(denominator);
	iss >> m_den;
      

	template <class X>
	void fromString(const string& input, X& any)
	{
	#ifdef HAVE_SSTREAM
	std::istringstream iss(input);
	#else
	std::istrstream iss(input.c_str());
	#endif
	X temp;
	iss >> temp;
	if (iss.fail())
	throw runtime_error(..)
	any = temp;
	}
      

I have read the Josuttis book on Standard C++, so some information comes from there. Additionally, there is information in "info iostream", which covers the old implementation that gcc 2.95.x uses.

Please send any experience, additions, corrections or questions to fnatter@gmx.net or for discussion to the libstdc++-v3-mailing-list.