Skip to main content
gamedev.net
🔒 Locked

Alternative object-oriented input/output models?

Started by MaulingMonkey 5 replies 1.8k views
Original Post
MaulingMonkey
MaulingMonkey
I've been doing a lot of prototyping in C++ for the standard library of an imaginary new programming language that I've been working on. In the latest section I focused on, a generic server class, I discovered std::streambuf, and it's wonderful array of obfuscation (for implementing socket i/o). Part of the problem is the poor name choices. Another is the number of odd quirks (such as returning something other than EOF to signal the EOF character, as EOF is returned to indicate an end of file, and the useage of macros to automate this). Another may be the inherit binding of buffering and actual i/o into the same class (I'm unsure if this is an actual drawback or not). In any case, something needs to change, and I plan to do it :). I've allways liked iostreams to a point - there's annoying quirks like binary mode still converting numbers to text, but one can live with them by wrapping them. I've gotten to the point where this no longer contents me, I want a fresh clean and working model. I'm looking for some of the existing alternatives to the standard iostreams, as well as opinions on their pros and cons that people have experienced with them. It dosn't even have to be a C++ alternative, I'm more interested in their modelings than their exact implementation. A feature that may or may not be of importance is the handling of character data - there will be string literals as per C++ in this language, however, they'll be extracted during the compilation and replaced with placeholder string-ids, whereas a secondary file will be created that maps these ids to actual strings. This is to attempt to help localization, by providing direct language support for multiple locales rather than relying on macro hackery or the like. Opinions, criticisms, etc. greatly appreciated.
snk_kid
snk_kid
Quote:
Original post by MaulingMonkey
Another is the number of odd quirks (such as returning something other than EOF to signal the EOF character, as EOF is returned to indicate an end of file, and the useage of macros to automate this).


Which part of the I/O stream library are you referring to, stream buffers? if stream buffers did you use the character traits for testing of EOF? can you show a scenario, and which macros are are you talking about?

Quote:
Original post by MaulingMonkey
Another may be the inherit binding of buffering and actual i/o into the same class (I'm unsure if this is an actual drawback or not).


Although the i/o stream interface and stream buffer are together the stream buffer isn't used directly most of the time if at all (i've forgotten the complete details).

for example the stream insertion/extraction operators are implementated in terms of locale, facets, stream buffer iterators and character traits do the job of parsing/formating to and from types.

Quote:
Original post by MaulingMonkey
I'm looking for some of the existing alternatives to the standard iostreams, as well as opinions on their pros and cons that people have experienced with them. It dosn't even have to be a C++ alternative, I'm more interested in their modelings than their exact implementation.


The only other explicit model used that i'm aware of is using the decorator design pattern for streams, i haven't used that model for quite some time and i didn't have much exprinice with it then so i can't say the pros & cons of it and VS standard c++ iostreams & locales.

Although one time i spoke to Washu and he mentioned that he had written his own C++ I/O library that used templates and the vistor pattern, i don't remember the details.

Quote:
Original post by MaulingMonkey
A feature that may or may not be of importance is the handling of character data - there will be string literals as per C++ in this language, however, they'll be extracted during the compilation and replaced with placeholder string-ids, whereas a secondary file will be created that maps these ids to actual strings. This is to attempt to help localization, by providing direct language support for multiple locales rather than relying on macro hackery or the like.


lol which macros?

I think a good idea would be to read the book Standard C++ IOStreams and Locales: Advanced Programmer's Guide and Reference get a complete understanding of the framework & internals might give you some better ideas, the link is to the co-author of that book her website has some very good articles (including some stuff on expression templates [smile]).
MaulingMonkey
MaulingMonkey
Quote:
Original post by snk_kid
Quote:
Original post by MaulingMonkey
Another is the number of odd quirks (such as returning something other than EOF to signal the EOF character, as EOF is returned to indicate an end of file, and the useage of macros to automate this).


Which part of the I/O stream library are you referring to, stream buffers? if stream buffers did you use the character traits for testing of EOF? can you show a scenario, and which macros are are you talking about?


Correct, stream buffers. Unforunately, I didn't bookmark everything, but I'll include an example from here which is a c++ streambuffer for zlib compressed files (note: overflow means "write to" in streambufferneese):

int zipstreambuf::overflow(int c){	if (!(mode&ios::out) || !opened || allocate()==EOF) return EOF;	if (gptr() && egptr() > gptr()) return EOF;	setg(0,0,0);	// make sure there is a put area	if (!pptr()) setp(base(),base());	int w = pptr() -pbase();	if (c != EOF)	{		*pptr() = c;		++w;	}	if (gzwrite(file,pbase(),w))	{		setp(base(),ebuf()-1);                //-----VVVVVVVVV---------- this line		return zapeof(c);                //-----^^^^^^^^^---------- that line	}	setp(0,0);	return EOF;}


As to the definition of zapeof, we can find it here:

Quote:
#define zapeof ( c ) ((c)&0377)


Added by James A.

Bednar (jbednar@cs.utexas.edu): No definition was included in this file; took one from an old version of iostream.h. The purpose appears to be to make EOF into a regular char.

Definition at line 24 of file zipiostream.h.


(Notice the author uses the word "appears", he himself does not seem to know for sure if this is the case).



Quote:
Quote:
Original post by MaulingMonkey
Another may be the inherit binding of buffering and actual i/o into the same class (I'm unsure if this is an actual drawback or not).


Although the i/o stream interface and stream buffer are together the stream buffer isn't used directly most of the time if at all (i've forgotten the complete details).


The reason I'm seeing this as a drawback is that each stream implementation then is forced to implement what it sees as adequate buffering. This is easier via inheritence and aggregation, so it may not be an actual problem, although the decoupling of the two would allow greater flexibility in how the user of the class has his data buffered, it would also mean some extra overhead I believe, unless template magic is brought into the picture (which is fine by me).

Quote:
for example the stream insertion/extraction operators are implementated in terms of locale, facets, stream buffer iterators and character traits do the job of parsing/formating to and from types.

Quote:
Original post by MaulingMonkey
I'm looking for some of the existing alternatives to the standard iostreams, as well as opinions on their pros and cons that people have experienced with them. It dosn't even have to be a C++ alternative, I'm more interested in their modelings than their exact implementation.


The only other explicit model used that i'm aware of is using the decorator design pattern for streams, i haven't used that model for quite some time and i didn't have much exprinice with it then so i can't say the pros & cons of it and VS standard c++ iostreams & locales.


A keyword is better than nothing! I'll google on that, thanks.

Quote:
Although one time i spoke to Washu and he mentioned that he had written his own C++ I/O library that used templates and the vistor pattern, i don't remember the details.


I'll try searching the forum some for that post, I'd be most interested in it.

Quote:
Quote:
Original post by MaulingMonkey
A feature that may or may not be of importance is the handling of character data - there will be string literals as per C++ in this language, however, they'll be extracted during the compilation and replaced with placeholder string-ids, whereas a secondary file will be created that maps these ids to actual strings. This is to attempt to help localization, by providing direct language support for multiple locales rather than relying on macro hackery or the like.


lol which macros?


Oh sure, make me download an example :P. From the beta8 of freeciv2.0.0:

Quote:
add_line(_("%s of the %s"),
get_government_name(game.player_ptr->government),
get_nation_name_plural(game.player_ptr->nation));


(buried somewhere in client/text.c)

Notice the use of _(...) - this is a macro used in L10N (and L18N I believe) as a shorthand for gettext(...), and is used to mark the string for translation - note that it requires a function call and thus makes it unavailable for use in this manner:

const char * strings[] = { _("String 1") , _("String 2") };

The automagic replacement tool xgettext will replace the strings if written normally with an N_(...) wrapper which gets compiled to nothing, signifying that these points need to have their alternate translations manually inserted by then calling gettext.

Quote:
I think a good idea would be to read the book Standard C++ IOStreams and Locales: Advanced Programmer's Guide and Reference get a complete understanding of the framework & internals might give you some better ideas, the link is to the co-author of that book her website has some very good articles (including some stuff on expression templates [smile]).


Oy, my poor book budget... I'll definately consider it however :).
snk_kid
snk_kid
Quote:
Original post by MaulingMonkey
Correct, stream buffers. Unforunately, I didn't bookmark everything, but I'll include an example from here which is a c++ streambuffer for zlib compressed files (note: overflow means "write to" in streambufferneese):

*** Source Snippet Removed ***

As to the definition of zapeof, we can find it here:

Quote:
#define zapeof ( c ) ((c)&0377)


Added by James A.

Bednar (jbednar@cs.utexas.edu): No definition was included in this file; took one from an old version of iostream.h. The purpose appears to be to make EOF into a regular char.

Definition at line 24 of file zipiostream.h.


(Notice the author uses the word "appears", he himself does not seem to know for sure if this is the case).


I went to have a look at the code and the first thing i came across was this

Quote:

/*
wrapping the zlib with iostream using gzFile
setbuf NYI Jean-Louis Ardoint 1996
*/


That does say alot as it's extending the classic IOStream library which is pre-standard and deprecated, most of the classic stuff are now type aliases to templated classes that are prefixed with basic_ and i'm sure quite abit has changed since the classic versions.

So std::basic_streambuf has a second template type parameter which is the character traits type (defaults to std::char_traits< CharT > where CharT is character type parameter) that has nested typedefs and static methods to perform basic character conversion, comparison etc including "eof" static method.

for locale sensitive stuff there are the facets, std::ctype/_byname for character stuff and std::collate/_byname for strings (even has a hash function).

This is why i was asking about macros because the new (well standard) I/O stream lib don't use any explicit macros (except maybe implementators internally maydo but not for EOF), overflow method signature is actually:

int_type overflow(int_type c = traits::eof());


where int_type is forward typedef from the nested typedef of the character traits type.

Some other things i noticed was the "allocate()" free/member function i couldn't find that in my IOstream book unless that is part of zlib library.

It looks like that code needs sorting out or rewritten but i only glanced at the code.

Quote:
Original post by MaulingMonkey
The reason I'm seeing this as a drawback is that each stream implementation then is forced to implement what it sees as adequate buffering.


a stream buffer can be unbuffered in which case characters are just transferred to device directly.

Quote:
Original post by MaulingMonkey
This is easier via inheritence and aggregation, so it may not be an actual problem, although the decoupling of the two would allow greater flexibility in how the user of the class has his data buffered, it would also mean some extra overhead I believe, unless template magic is brought into the picture (which is fine by me).


Unless there is something i'm missing i think there is adequate loose coupling, a stream doesn't know where characters are being transportated and it can be changed at run-time, has no clue of the underlaying device characters are being transportated to.

std::basic_ios maintains a pointer to std::basic_streambuf it can refer to any concreate sub-type of basic_streambuf, usually concreate types of std::basic_(i/o)stream assigns specific concreate types of std::basic_streambuf (e.g. basic_fstream & basic_filebuf) by passing all the way up to std::basic_ios via a protectated constructor but you can change it at run-time to something else.

I'm interested to read what you have in mind.

Quote:
Original post by MaulingMonkey
I'll try searching the forum some for that post, I'd be most interested in it.


hehe its not in the forums, it was converstation on gamedev chat room it might have been logged how-ever or you could speak to Washu there unless he comments on it here.

Quote:
Original post by MaulingMonkey
Oh sure, make me download an example :P. From the beta8 of freeciv2.0.0:

Quote:
add_line(_("%s of the %s"),
get_government_name(game.player_ptr->government),
get_nation_name_plural(game.player_ptr->nation));


(buried somewhere in client/text.c)

Notice the use of _(...) - this is a macro used in L10N (and L18N I believe) as a shorthand for gettext(...), and is used to mark the string for translation - note that it requires a function call and thus makes it unavailable for use in this manner:

const char * strings[] = { _("String 1") , _("String 2") };

The automagic replacement tool xgettext will replace the strings if written normally with an N_(...) wrapper which gets compiled to nothing, signifying that these points need to have their alternate translations manually inserted by then calling gettext.


sorry [wink]

have a look at standard library locale, facets and character traits, its sounds almost exactly what you have in mind, you can extend these aswell, add new facet types and stuff.

[Edited by - snk_kid on March 10, 2005 5:46:55 PM]
MaulingMonkey
MaulingMonkey
Quote:
Original post by snk_kid
Quote:
Original post by MaulingMonkey
Correct, stream buffers. Unforunately, I didn't bookmark everything, but I'll include an example from here which is a c++ streambuffer for zlib compressed files (note: overflow means "write to" in streambufferneese):

*** Source Snippet Removed ***

As to the definition of zapeof, we can find it here:

Quote:
#define zapeof ( c ) ((c)&0377)


Added by James A.

Bednar (jbednar@cs.utexas.edu): No definition was included in this file; took one from an old version of iostream.h. The purpose appears to be to make EOF into a regular char.

Definition at line 24 of file zipiostream.h.


(Notice the author uses the word "appears", he himself does not seem to know for sure if this is the case).


I went to have a look at the code and the first thing i came across was this

Quote:

/*
wrapping the zlib with iostream using gzFile
setbuf NYI Jean-Louis Ardoint 1996
*/


That does say alot as it's extending the classic IOStream library which is pre-standard and deprecated, most of the classic stuff are now type aliases to templated classes that are prefixed with basic_ and i'm sure quite abit has changed since the classic versions.


Some, but not much. Looking at modern documentation the behavior is still the same and the functions still exist, and they remain named as they were before - the only difference is that they're defined in basic_* and templatized. The zapeof function/macro is still defined in the headers, as I used it in the test socketbuf class I wrote in my attempt to understand these stream buffers on my compiler (G++ 3.4.2). I believe I've seen versions that return something even more elaborate in the place of zapeof, invoking the character traits template parameter.

Now, why in the world should I have to worry about this kind of stuff when I'm simply trying to wrap existing functionality around a new i/o device?

Quote:
So std::basic_streambuf has a second template type parameter which is the character traits type (defaults to std::char_traits< CharT > where CharT is character type parameter) that has nested typedefs and static methods to perform basic character conversion, comparison etc including "eof" static method.

for locale sensitive stuff there are the facets, std::ctype/_byname for character stuff and std::collate/_byname for strings (even has a hash function).

This is why i was asking about macros because the new (well standard) I/O stream lib don't use any explicit macros (except maybe implementators internally maydo but not for EOF), overflow method signature is actually:

int_type overflow(int_type c = traits::eof());


where int_type is forward typedef from the nested typedef of the character traits type.


Quote:
Some other things i noticed was the "allocate()" free/member function i couldn't find that in my IOstream book unless that is part of zlib library.

It looks like that code needs sorting out or rewritten but i only glanced at the code.

Quote:
Original post by MaulingMonkey
The reason I'm seeing this as a drawback is that each stream implementation then is forced to implement what it sees as adequate buffering.


a stream buffer can be unbuffered in which case characters are just transferred to device directly.


And if that's "adequate" than all is good and well. But if it's found to be inadequate, you have to reimplement your streambuf derived class. You don't have to reimplement std::vector to change allocators, I fail to see why you should have to reimplement ___::socketbuf to change buffer implementations.

Wait, let me rephrase that: I don't see why a class concerning I/O implementation (which is poorly named as a type of buffer) should have to be reimplemented to change buffer implementations.

Quote:
Quote:
Original post by MaulingMonkey
This is easier via inheritence and aggregation, so it may not be an actual problem, although the decoupling of the two would allow greater flexibility in how the user of the class has his data buffered, it would also mean some extra overhead I believe, unless template magic is brought into the picture (which is fine by me).


Unless there is something i'm missing i think there is adequate loose coupling, a stream doesn't know where characters are being transportated and it can be changed at run-time, has no clue of the underlaying device characters are being transportated to.


There's no problem when it comes to the client useage's view of coupling - you send characters to a std::ostream and it will end up somewhere, end of story.

The problem is in extending the library. You have some oddly named classes that combine buffering and I/O implementation, with a lot of redundancy, and then have some badly named functions. I think my favorite one is "showmanyc", which returns the number of available input characters. One would think it'd instead have something to do with screen display.

Yes, you can still extend the library. I see that it's possible, considering I was able to get a simple handle i/o streambuf class working. But I'd hardly call it intuitive.

Quote:
std::basic_ios maintains a pointer to std::basic_streambuf it can refer to any concreate sub-type of basic_streambuf, usually concreate types of std::basic_(i/o)stream assigns specific concreate types of std::basic_streambuf (e.g. basic_fstream & basic_filebuf) by passing all the way up to std::basic_ios via a protectated constructor but you can change it at run-time to something else.

I'm interested to read what you have in mind.


I still havn't gotten around to doing a more thorough research on this as of this posting, but from the vauge mental picture I have in my mind, it'd be something like this:

struct basic_io //derived: handle_io , socket_io , stream_io , etc...
{
//consults how much the OS has buffered:
virtual size_t available_input( void ) const = 0;

//implement i/o:
virtual void read( size_t , void * ) = 0;
virtual void write( size_t , const void * ) = 0;
};

struct basic_buffer
{
basic_io & io;
virtual void sync( void ) const = 0;
};

struct basic_obuffer : public basic_buffer
{
virtual void write( size_t , const void * ) = 0;
};

struct basic_ibuffer : public basic_buffer
{
virtual void read( size_t , void * ) = 0;
};

template < typename CharT , typename TraitsT = char_traits< CharT > >
class basic_iostream
{
//basic_io & io; //used within buffer_in/out construction, but only actually ends up defined in iostream derivations that decide they need to control the specific io device - aka, basic_fstream would define "file_io & io;" to allow is_open() checks and the like)
basic_ibuffer &buffer_in;
basic_obuffer &buffer_out;
locale & locale;
};[/quote]

The basic_iostream class in that example is obviously unpolished, aka it dosn't inherit from basic_istream and basic_ostream - but it is not the focus of this point right now anyways :).

<!--QUOTE--><blockquote>Quote:<table border="0" cellpadding="4" cellspacing="0" width="95%"><tr><td class="quote"><!--/QUOTE--><!--STARTQUOTE--><!--QUOTE--><blockquote>Quote:<table border="0" cellpadding="4" cellspacing="0" width="95%"><tr><td class="quote"><!--/QUOTE--><!--STARTQUOTE-->Original post by MaulingMonkey
I'll try searching the forum some for that post, I'd be most interested in it.
<!--QUOTE--></td></tr></table></blockquote><!--/QUOTE--><!--ENDQUOTE-->

hehe its not in the forums, it was converstation on gamedev chat room it might have been logged how-ever or you could speak to Washu there unless he comments on it here.<!--QUOTE--></td></tr></table></blockquote><!--/QUOTE--><!--ENDQUOTE-->

Well damn.

<!--QUOTE--><blockquote>Quote:<table border="0" cellpadding="4" cellspacing="0" width="95%"><tr><td class="quote"><!--/QUOTE--><!--STARTQUOTE--><!--QUOTE--><blockquote>Quote:<table border="0" cellpadding="4" cellspacing="0" width="95%"><tr><td class="quote"><!--/QUOTE--><!--STARTQUOTE-->Original post by MaulingMonkey
Oh sure, make me download an example :P. From the beta8 of freeciv2.0.0:

<!--QUOTE--><blockquote>Quote:<table border="0" cellpadding="4" cellspacing="0" width="95%"><tr><td class="quote"><!--/QUOTE--><!--STARTQUOTE--> add_line(_("%s of the %s"),
get_government_name(game.player_ptr->government),
get_nation_name_plural(game.player_ptr->nation));<!--QUOTE--></td></tr></table></blockquote><!--/QUOTE--><!--ENDQUOTE-->

(buried somewhere in client/text.c)

Notice the use of _(...) - this is a macro used in L10N (and L18N I believe) as a shorthand for gettext(...), and is used to mark the string for translation - note that it requires a function call and thus makes it unavailable for use in this manner:

const char * strings[] = { _("String 1") , _("String 2") };

The automagic replacement tool xgettext will replace the strings if written normally with an N_(...) wrapper which gets compiled to nothing, signifying that these points need to have their alternate translations manually inserted by then calling gettext.
<!--QUOTE--></td></tr></table></blockquote><!--/QUOTE--><!--ENDQUOTE-->

sorry [wink]

have a look at standard library locale, facets and character traits, its sounds almost exactly what you have in mind, you can extend these aswell, add new facet types and stuff.<!--QUOTE--></td></tr></table></blockquote><!--/QUOTE--><!--ENDQUOTE-->

I havn't stared too closely at it, but unless someone secretly introduced a standard that requires mucking around with the linking method used, it's not quite the same :). Basically, even if you track all the static strings by address and replace them depending on locale with external strings loaded from .dll/.so files for example, this will not be quite the same method I had envisioned (although extremely close). Basically, instead of storing the raw character data inside the object files to later be compiled into a section of the program binary, the textual data would be extracted to a secondary output file, which could then be combined with other text data files into a single textual 'lookup table' which could either be directly linked into the binary (achieving the same results as C/C++) or dynamically loaded in at run time from a file format not designed for binary code.
snk_kid
snk_kid
Quote:
Original post by MaulingMonkey
Some, but not much. Looking at modern documentation the behavior is still the same and the functions still exist, and they remain named as they were before - the only difference is that they're defined in basic_* and templatized.


It was actually quite abit more than just changing the original classes to templates, you can read about it more here: New Features in Standard IOStreams Comparing Classic and Standard IOStreams even mentions your EOF stuff [smile].

Quote:
Original post by MaulingMonkey
The zapeof function/macro is still defined in the headers, as I used it in the test socketbuf class I wrote in my attempt to understand these stream buffers on my compiler (G++ 3.4.2). I believe I've seen versions that return something even more elaborate in the place of zapeof, invoking the character traits template parameter.

Now, why in the world should I have to worry about this kind of stuff when I'm simply trying to wrap existing functionality around a new i/o device?


It isn't part of the standard that must be a zlib stream thing, i never come across it before in any implementation of the standard c++ library i've look into. if you want to convert the integer EOF to a character then you would do:

template < typename CharT, typename Traits = std::char_traits<CharT> ... >struct my_streambuf : public std::basic_streambuf< CharT, Traits > { .....   void some_func() {     char_type c = Traits::to_char_type(Traits::eof());  }};


where char_type is a type alias declared in std::basic_streambuf.

Quote:
Original post by MaulingMonkey
And if that's "adequate" than all is good and well. But if it's found to be inadequate, you have to reimplement your streambuf derived class. You don't have to reimplement std::vector to change allocators, I fail to see why you should have to reimplement ___::socketbuf to change buffer implementations.

Wait, let me rephrase that: I don't see why a class concerning I/O implementation (which is poorly named as a type of buffer) should have to be reimplemented to change buffer implementations.


Okay i had to re-read this bit and bits before things started to make sense, i actually misinterpreted what you said earlier here:

Quote:
Original post by MaulingMonkey
Another may be the inherit binding of buffering and actual i/o into the same class.


it was late so... i actually thought you where talking about something else i really need to read more carefully [wink]

I don't think your wrong or wright in the matter i'll just say from what i've read std::basic_streambuf's main responiability is the transport layer of the I/O streams framework and better definition is:

Quote:

The Stream Buffer Classes.

The stream buffer classes represent the abstraction of a connection to an external device. The main task of the stream buffer is transport of characters to and from this external device, and buffering of these characters in an internal buffer.

The external devices are seen as sequences of characters. In the following, we will therefore simply talk of sequences when we mean the abstraction of an external device.

Stream buffers are used by streams for actual transport of characters to and from a device, whereas the streams themselves are responsible for parsing and formatting the text input and output.


The abit about streams themselves is quite simplified, you can read about the stream buffers more here streambuf: The Stream Buffer Classes that is actually a book excerpt from the book i mentioned earlier very good read recommended especially about how in & output is handled for basic_filebuf.

Quote:
Original post by MaulingMonkey
There's no problem when it comes to the client useage's view of coupling - you send characters to a std::ostream and it will end up somewhere, end of story.

The problem is in extending the library. You have some oddly named classes that combine buffering and I/O implementation, with a lot of redundancy, and then have some badly named functions. I think my favorite one is "showmanyc", which returns the number of available input characters. One would think it'd instead have something to do with screen display.

Yes, you can still extend the library. I see that it's possible, considering I was able to get a simple handle i/o streambuf class working. But I'd hardly call it intuitive.


I agree the naming convention is a litte ridiculous and can be intimidating at first its almost a form of elitism [lol].

One thing to note is extending stream functionality via derivation is not the only method the other is via iword/pword, xalloc, stream callbacks which i think there is next nil info on the net about.

Well aleast i got you to come out with what you had in mind so others are not twiddling thumbs trying to guess what you had in mind [smile] lets hope some more people join the discussion.

Oh yeah you might be interested in C++>this if you didn't see that bit before.

[Edited by - snk_kid on March 11, 2005 6:39:14 AM]
MaulingMonkey
MaulingMonkey
Quote:
Original post by snk_kid
Quote:
Original post by MaulingMonkey
Some, but not much. Looking at modern documentation the behavior is still the same and the functions still exist, and they remain named as they were before - the only difference is that they're defined in basic_* and templatized.


It was actually quite abit more than just changing the original classes to templates, you can read about it more here: New Features in Standard IOStreams Comparing Classic and Standard IOStreams even mentions your EOF stuff [smile].


Looks like our definitions differ slightly.

I see some reorganization, addition of locales to streambuf, removing some features that were meant for greater C compatibility (such as fd() and constructors that accept file descriptors, which ironically is the reason I now have to implement my own socketbuf class), some renaming, and templatization. All this seems to be in order to both make the standard iostream library flexible (which it has from the client perspective) and clean up the library (which again it has from the client perspective). For the extender perspective, it's failed to address either concern thoroughly IMNSHO.

Quote:
Quote:
Original post by MaulingMonkey
The zapeof function/macro is still defined in the headers, as I used it in the test socketbuf class I wrote in my attempt to understand these stream buffers on my compiler (G++ 3.4.2). I believe I've seen versions that return something even more elaborate in the place of zapeof, invoking the character traits template parameter.

Now, why in the world should I have to worry about this kind of stuff when I'm simply trying to wrap existing functionality around a new i/o device?


It isn't part of the standard that must be a zlib stream thing, i never come across it before in any implementation of the standard c++ library i've look into. if you want to convert the integer EOF to a character then you would do:


Nope, I'm not including any zlib headers. I've seen it in some of the ancient standard headers. However, I'm a complete dumbass, it turns out another error was interfering with that line with my multitude of crap I have going on in my workspace directory. zapeof isn't in the headers no more. My major bad. It appears to have been replaced with more manual checking of if a given character is equivilant to EOF, with wonderful lines such as:

if (!traits_type::eq_int_type(c, traits_type::eof()))


Quote:
Quote:
Original post by MaulingMonkey
And if that's "adequate" than all is good and well. But if it's found to be inadequate, you have to reimplement your streambuf derived class. You don't have to reimplement std::vector to change allocators, I fail to see why you should have to reimplement ___::socketbuf to change buffer implementations.

Wait, let me rephrase that: I don't see why a class concerning I/O implementation (which is poorly named as a type of buffer) should have to be reimplemented to change buffer implementations.


Okay i had to re-read this bit and bits before things started to make sense, i actually misinterpreted what you said earlier here:

Quote:
Original post by MaulingMonkey
Another may be the inherit binding of buffering and actual i/o into the same class.


it was late so... i actually thought you where talking about something else i really need to read more carefully [wink]


Ahh :).

Quote:
One thing to note is extending stream functionality via derivation is not the only method the other is via iword/pword, xalloc, stream callbacks which i think there is next nil info on the net about.


Multiple ways of doing the same thing? Geeze, I keep learning more and more :P. I'll definately look into it (via dumpster... err, header diving). I've noticed however that most of the derivations of the std::streambuf class on the 'net seems to reimplement allmost all of the functions they can (Yuhck!).

Quote:
Well aleast i got you to come out with what you had in mind so others are not twiddling thumbs trying to guess what you had in mind [smile] lets hope some more people join the discussion.


Hehe, indeed. That said, I'm still interested in even what I don't have in mind. I want to see the options and weight the pros and cons, if that makes sense.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.