Re: [boost] StringAlgo - (was: boost::tokenizer )

From: Pavol Droba (droba_at_[hidden])
Date: 2004-10-15 14:25:01

Hi

On Fri, Oct 15, 2004 at 08:01:43PM +0200, Dirk Gregorius wrote:
> > 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 )?
> 

It will be in the official release as soon as the 1.32 gets out. It should
be out any moment, but I don't really know the current state of this
matter.

You can use the latest boost snapshot directly from cvs repository.
See here: 
   http://www.boost.org/more/getting_started.html#CVS

For more instructions how to get there.

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

I'm not very good at explaining the things in short, but I'll try.

Primary goal of namespaces is to avoid name conflics as you have a correctly
said. It is a good practice to structuralize the code into the namespaces.
For a general purpose libraries like Boost, namespace usage is essential
since the author of the library is not able to predics in which user
applications his library will be used.

Boost is also a collection of libraries and therefor larger libraries
tend to have their own namespaces to shield from each other.
So you can see boost::mpl boost::filesystem and etc.

Yet it is not always convenient to write long namespace paths in the
code. Therefor identifiers in the StringAlgo library are "pulled" to the
boost namespace.

But why is the whole library not in the boost namespace in the first place?
First of all, not all identifiers are pulled into the higher namespace, only those,
that are intended for users. This is done by 'using identifier' declaration.
Books are right to not use 'using namespace xxx' declaration because it 
pulls everything, not just the interface part.

'using' declaration only copies the names to the current namespace, not the entities
itself. Therefor they implementation cannot be disrupted by the code in the new
namespace.

Just imagine, that a function foo() in boost::algorithm uses some function bar() from the
same namespace internaly.
Now it is quite possible, if they both would be in the boost namespace, that some other library
would define another fuction bar() with similar, yet a little bit different signature.
Due to complicated rules in name mathing (especialy when templates are involved) it 
might happen, that compiler with actuly use the other one. This is clearly not
wanted. 

Therefor, the whole library resides in the lower namespace and only parts are "pulled"
up.

Anothoer solution, that is recomended by some library authors is to use namespace aliasing.

You write 
namespace mpl=boost::mpl;

and in the code, you can write
mpl::transform instead of boost::mpl::transform.

Best regards,

Pavol