Save class information for custom types in bstream

[GoogleCodeExporter]

class Foo;
out << Foo should save enough information to make safety check when the stream 
is loaded.

Original issue reported on code.google.com by hugo.arregui on 19 Jan 2012 at 3:28

[GoogleCodeExporter]

My suggestion:

out::XX<Foo> << a << b;

XX should be responsible for adding a begin<type> end<type> with the typeinfo

Original comment by hugo.arregui on 19 Jan 2012 at 3:29

[GoogleCodeExporter]

I guess we should find a way to preserve the current syntax:

mili::bostream bos;
MyClass a;

bos << a;

This should add "MyClass" to the stream when the debug flag is on, 
automatically. And the implementer of the extension shouldn't be bothered to 
write much code.

How? hm... maybe something like:

friend bostream& operator<<(bostream& out, const MyClass& obj)
{
      ADD_DEBUG_INFO_IF_NECESSARY(out, obj);     // sucks, but a macro accessing out._str should do it

      //your custom code here
}

Original comment by billybiset on 19 Jan 2012 at 1:22

[GoogleCodeExporter]

Billy, 

this: out::XX<Foo>() << a << b;

could be used for custom classes, and leave the out << a for primitive types. 
So we preserve current syntax to already supported cases, and then this new 
style for the others.

Two importants things about this solution:

a) the compiler could raise and error if the users violates the syntax (using 
"out << a" with not primitives for example)

b) It doesn't use macros :-)

What you think?

Original comment by hugo.arregui on 19 Jan 2012 at 2:04

[GoogleCodeExporter]

Yes, the only thing that worries me is that this invalidates some current code, 
but I think it's not that serious. Just that whenever those changes are in, the 
other projects should change right away.

e.g. Proteins and other classes overload this operator and it's used in 
projects like the parallel-clusterer and I think some of the ones from 
FuD/recabs and FuD/combeng.

Original comment by billybiset on 19 Jan 2012 at 2:11

[GoogleCodeExporter]

The problem is that you can do this kind of things:

struct A{
    unsigned int id;
    std::string name;
    long double a;    

    A()
    : id(0), name(), a(0) {}

    friend bostream& operator<<(bostream& out, const A& o){
        out << o.id << o.name << o.a;
        return out;
    }
};

int main (){
    unsigned int id;
    std::string name;
    long double a;    
    A object;
    bostream bos;
    bos << object ;
    bistream bis (bos.str());
    bis >> id >> name >> a;    
    return 0;
}

And it's not related to BSTREAM_DEBUG define.

Original comment by lukas.vs...@gmail.com on 19 Jan 2012 at 4:12

[GoogleCodeExporter]

Yes, the fact that you know how something is implemented doesn't mean that you 
have to worry about it being used wrong, but it is always better to have more 
strict type checking rules, etc.

In this case, the library is built for speed and compression. The decorators 
and policies that Hugo suggests are a great enhancement if they are optional, 
but I don't want to add information to the stream unless necessary.

Bear in mind that this is used in High Performance Computing where networking 
is usually a bottleneck :)

Original comment by billybiset on 19 Jan 2012 at 4:27

[GoogleCodeExporter]

Original comment by hugo.arregui on 21 Feb 2012 at 8:33