Boost logo

Boost :

From: Dirk Gregorius (dirk_at_[hidden])
Date: 2004-10-15 13:01:43


> Boost.Tokenizer is currently not the only option for this
> kind of job. There is also splitting facility incorporated
> in the StringAlgo library.
Thanks for the hint. This is something I really was looking for.
When do you think will this code be in the official release ( I will
download it now anyway )?

> Note, that you will need to load whole file into a string before
> processing, since all these facilities need at lease a forward
> iterator, so streambuf_iterator is not sufficient.
This is exactly what I do.

ifstream is( "file.txt" );
string file_string( ( istreambuf_iterator<char>( is ) ),
istreambuf_iterator<char>() );

This reads in the whole file into file_string in one step.

A question regarding your design of this library. In your help file I read:
"The library interface functions and classes are defined in namespace
boost::algorithm, and they are lifted into namespace boost via using
declaration"

I try to use also more namespaces in my code. boost makes heavy use of
namespaces as far as I can say this. Is it common style to have the
implementation "deeper" in nested namespaces and "lift up" the interface
again to the first level? How is this done? So you must use using
declarations in the header files if I understand that correctly - which is a
"NoNo" in a lot of books. I once used nested namespaces in my code, but
found it very inconvinient to use, so I rewrote it, although it was logical
very well grouped together. Can you give any design considerations / hints
if I want to do the same? I found it very hard to find any
discussions/papers regarding the proper use of namespaces. For me it seems
as if namespace are only understood as facility to avoid nameclashes. In my
opinion they also make the code more understandable and also allow some kind
of abstraction by grouping logical dependent entities together.

Best regards,

-Dirk


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk