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

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

Hans Dulimarta wrote:
> 
> "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.

In the Cathedral and the Bazaar, the credo is "Release Early and Release
Often". While I don't always agree with that, it is an indicator to the
community that there is activity in the project. In addition, because
systems we rely on (compilers,etc.) change, it is inevitable that users
will go to those and end up reporting this things as errors anyway. So
being proactive is a good thing.

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

Cool, I made comments to you follow up message.

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

-- 
Frank V. Castellucci