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

[Hans D. <dul...@eg...>]

"Frank V. Castellucci" wrote:
> 
> 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 ?

Wow, I feel like I am crawling like a turtle while you are running like
hares.

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

My plan is to have a working EventSemaphore by this weekend. If after this
weekend
I don't have it, I won't include it in the coming release.

> 
> > 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
> _______________________________________________
> Corelinux-develop mailing list
> Cor...@li...
> http://lists.sourceforge.net/mailman/listinfo/corelinux-develop

-- 
Hans Dulimarta, Ph.D.                  dul...@co...
P: 517-432-7589             http://www.egr.msu.edu/~dulimart   
F: 760-281-7691             http://corelinux.sourceforge.net
Elec. & Comp. Engg., Mich. State Univ., E. Lansing, MI 48824