extending basic_streambuf

Yup. It's a good book. I've done that with GLUT as a back-end to render text a couple years ago. My implementation was quite rough, but I plan to rework it.

However, I don't think using streams to render arbitrary graphical objects or to deal with events would be a good idea.

I definitely agree with arbitrary graphical objects, if such a thing was done it would be quite low level like say pixel_traits to help with differnt pixel formats. So you can send/retrieve/edit single pixels, range or a blitting the whole thing.

I can see you wanting to write stream filters of some form (I have found that proxies do work nicely) to put/get whole images to/from a stream, while converting to/from an abitrary image format.

I don't think it is that good an idea to work out such a framework to beam pixels to the screen, though, again, for bitmaps it might work, as an extention of the bitmap font approach for text. Individual pixels fall more into the 'unformatted' I/O paradigm.

hmm... more stuff for me to write about in my upcoming (REAL SOON NOW!) article. Of course, every new thing I want to add to it delay it that much longer... *sigh*

my first thought was "so elegant it's practicly unusable" but it's a really cute idea.

Fruny i'm very interested about this article please do tell what its about? is it all about unformatted I/O? i was going to take the unbuffed example from the book was a little interesting because buffering can be annoying with certain things.

Quote:

Original post by snk_kid Fruny i'm very interested about this article please do tell what its about? is it all about unformatted I/O? i was going to take the unbuffed example from the book was a little interesting because buffering can be annoying with certain things.

I have a few things I want to deal with.

• Threads like this one.
  
  
• iostream.h
  
  
• The standard stream objects (people here forget about the tandard error stream). Remind people they are objects, not functions [rolleyes]. Talk about consoles, stream redirection, pipes...
  
  
• How to do formatting. How many know what the IOStream manipulators are, what they are for, and how to actually set formatting options (something that *is* easier to do with printf). Pimping out boost::format will be good at this point.
  
  
• "How to do binary IO". The perennial question on the forums. I do have written a set of proxies that do let you do unformatted IO using the formatted IO syntax, though in its current form it relies on boost::mpl to solve some function template ambiguity, at which point, I lose all the VC6 users, but well... I am not planning to discuss the details of the templates code though. [headshake] (Oh, by the way Vandevoorde/Josuttis' "C++ Templates" book is worth picking up too).
  
  
• Deep vs. shallow copy obviously needs to be addressed. Maybe a word about object factories...
  
  
• The previous bullet raises the question: "How many people here do not know you can overload the stream operations?" Which may have to be explained too.
  
  
• And then, yeah, how to create your own stream target. I'm reworking my glutstream code to work with SDL (If you want to make it work with DX, we could talk about it at some point. At the very least, remind me to send you a copy for proofreading.) Which will probably also mean explaining how to write your own manipulators (including dealing with the pword/iword fun stuff).
  

In its current form, the 'article' is just a bunch of one-line to one-paragraph chunks of information I want to eventually convey.

I am not a great writer.

Thinking about rendering fonts that is very good idea, i've been lazy, what i normally do using a some simple print string method from some graphics library. I take an ostringstream to write my message with any values assiocated with it, once done return a string and usually need to pass C-style string to the function no probs.

iword, pword is very clever way of extending iostream libs without extending by inheritance.

How did you go about implementing formatting did you take a simple or "refined" approach, thats another problem the lack of information about locales and there uses.

Another thing that would need to be explained if extending by using iword/pword how callback functions work cause i would think your would eventually need to use the stream callbacks when working with iword/pword way of extending.

Extending iostream library for rendering strings is really good idea because then you can easily add internationlization into games if locales are used.

This might be helpful i had a look at the book's website and someone managed to implement all the code examples from the book here.

Goodluck with your article thats gonna be abit of tough job.

How did you go about implementing formatting did you take a simple or "refined" approach, thats another problem the lack of information about locales and there uses.

Simple approach. You really don't need to know much about locales unless you want to write a facet. Even just changing locales is relatively painless. For example, locales are where IOStreams' number-to-string conversion code is.

Another thing that would need to be explained if extending by using iword/pword how callback functions work cause i would think your would eventually need to use the stream callbacks when working with iword/pword way of extending.

I have found the example in the book reasonably clear. A stream callback function's only task is to take care of the memory-management associated with the use of pword as a pointer to some custom data.