Re: [Corelinux-develop] conclusions of the previous g++ related threads

[Frank V. C. <fr...@co...>]

Christophe Prud'homme wrote:
> 
> Ok let's have a short description of what happened:
> 
> - g++ 2.96 is more c++ compliant and find a lot more erronous code
>   * in you throw an exception in a member function of a class
>     be careful with its signature in any subclasses that is don't forget to
>     write throw(exceptxxx)
>   * g++ is even more restrictive also for type correctness
>     2.95 let int (*) (ThreadContext*) converted automatically to int (*)
>     (void*) without explicit casting
>     2.96 doesn't allow it without an explicit cast
>     solution:
>      typedef int (* CloneFunctionType)(void *);
> 
>      CloneFunctionType(ThreadContext::cloneFrameFunction)
> 
>     in Thread.cpp
>    * friend foo is wrong
>       friend class foo is correct
> 
> All those changes have been done (plus the cpp one with ##) in my corelinux
> copy.
> I need to create some defects for this but also for the new libcorelinux-dbg
> packages(I didn't create it for redhat yet) and the changes for the macros
> arguments (mentionned a while ago now)
> 
> when is the next release ?

Hans may more may not have anything for libcorelinux, in which case just
let me know. I didn't add anything to core.

> will we release also the first clfw ?

I have been grappling with the desire/need for Class class in clfw as it
would be a very useful way to capture desclarative information about
objects. For example, LibraryObjectDefinitions could be an object that
describes alot of stuff about the object it represents, as well as being
it's factory and re-director. As you know, we start to step into the
mini-marshaling domain (CORBA like) and that is not small things to
consider.

So there are some downsides to a quasi-static Class in the library
themselves. One solution is to put in meta-object processing which could
take dynamic definitions (IDL-like) and work that way, but that is even
more management code required. I've done this, and it is very powerful,
very big, and some people may not like it.

I would like to continue this discussion. But, in the short term I have
no problem releasing a 0.0.0 of clfw with just the Library Load
abstraction, and quickly whack a FunctionLibrary together without the
benefit of a more intelligent framework.

Thoughts?

> 
> regards
> C.
> --
>  Christophe Prud'homme                | Pierre: Je suis désolé Thérèse, je ne
>  MIT, 77, Mass Ave, Rm 3-243          |         sais pas ce qui m'a pris...
>  Cambridge MA 02139                   |         c'est une catastrophe.
>  Tel (Office) : (00 1) (617) 253 0229 | Thérèse: Ce n'est rien Pierre,
>  Fax (Office) : (00 1) (617) 258 8559 |          je n'ai rien senti....
>  http://augustine.mit.edu/~prudhomm   | -- Le Pere Noel est une ordure
>                           Following the hacker spirit
> _______________________________________________
> Corelinux-develop mailing list
> Cor...@li...
> http://lists.sourceforge.net/mailman/listinfo/corelinux-develop

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
http://PythPat.sourceforge.net
Pythons Pattern Package