corelinux-develop — Developer centric mail list for CoreLinux++

Re: [Corelinux-develop] Questions (again)

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

Hans - Dulimarta wrote:
> 
> I'm implementing EventSemaphore in the following setup:
> 
> Assuming we have three operations: down(), up(), and zero().

Are these the actual interface method names? While I don't feel the
requirements document quite addresses is, the semantics of an Event are
things more like hold/trigger/waitFor

> When an EvSem is created, its value is initialized to 1 indicating the
> expected event has not occured.

I assume this is 'up', which I would consider 'hold'.

> Any callers who are waiting for the event to occur will do a "lock"
> by calling zero(). When the event actually takes place, the semaphore will
> be released via the down() operation.

Terminology shift, callers 'waitFor' events no? and the owner 'triggers'
them (to trigger an Event)?

> The requirement document (SRS ?) for says that the Many-to-One semaphores
> will automatically lock upon creation and there is no option to create in
> unlock. When I look at the code, lock is similar to down() semaphore
> operation which implies that the creator will be block in the middle of
> the EventSemaphore ctor.
> 
> In the context of the above three operations, how can the creator perform
> a release operation to indicate that the expected event has occured?

There are two things to consider here:

1. As the SemaphoreGroup instantiates the creation of the Semaphore (in
this case EventSemaphore), it can construct and then call 'hold'.

2. The owner of a semaphore is not in a blocked state, the Linux kernel
semaphore has a state change, but the owner is not blocked. Only those
callers 'waiting for' an event are blocked.

Hope this helps.

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

-- 
Frank V. Castellucci

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

[Corelinux-develop] Questions (again)

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

I'm implementing EventSemaphore in the following setup:

Assuming we have three operations: down(), up(), and zero().

When an EvSem is created, its value is initialized to 1 indicating the
expected event has not occured.
Any callers who are waiting for the event to occur will do a "lock"
by calling zero(). When the event actually takes place, the semaphore will
be released via the down() operation.

The requirement document (SRS ?) for says that the Many-to-One semaphores
will automatically lock upon creation and there is no option to create in
unlock. When I look at the code, lock is similar to down() semaphore
operation which implies that the creator will be block in the middle of
the EventSemaphore ctor.

In the context of the above three operations, how can the creator perform
a release operation to indicate that the expected event has occured?

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

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

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

[Christophe Prud'h. <pru...@MI...>]

> Ok, for the short term I am happy with a tarball release of clfw. I
> really would like to learn the rpm spec stuff and will never do so until
> you let me :)
just play with corelinux.spec
that's how I did it (the good old trial and error)

-- 
  Christophe Prud'homme                  |
  MIT, 77, Mass Ave, Rm 3-243            |   In theory, theory and practice
  Cambridge MA 02139                     |   are the same. In practice they
  Tel (Office) : (00 1) (617) 253 0229   |   are different.
  Fax (Office) : (00 1) (617) 258 8559   |
  http://augustine.mit.edu/~prudhomm     |
                          Following the hacker spirit

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

[Gabriel D. R. <Gab...@cm...>]

"Christophe Prud'homme" <pru...@MI...> writes:

| Huh
| 
| sorry I forgot to thank Gaby

Well, there is no need to: I'm just finding a way to help.

-- Gaby

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

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

Christophe Prud'homme wrote:
> 
> > 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.
> 
> Ok we can release something like corelinux bug fixes/updates
> and a clfw preview technology release

Ok, for the short term I am happy with a tarball release of clfw. I
really would like to learn the rpm spec stuff and will never do so until
you let me :)

> A short note on my disponibilities, I would not mind begin working on clfw,
> unfortunately I am very busy until beginning of october. and then I will be
> able to work at full power for corelinux :). I can only do quick things so
> that my projects integrate well with corelinux.

You have contributed more than you ever will realize I suppose, and I am
certainly not anxious about anything. Decisions like the Class class
thing are not easy ones to make. Class libraries are by far and away one
of the more difficult things to produce because you need to anticipate
large use-case scenarios. Without collaboration, it is almost
impossible.

> 
> --
>      Christophe Prud'homme                    |
>      MIT, 77, Mass Ave, Rm 3-243              |
>      Cambridge MA 02139                       |     Friends are relatives
>      Tel (Office) : (00 1) (617) 253 0229     |     you make for yourself.
>      Fax (Office) : (00 1) (617) 258 8559     |
>      http://augustine.mit.edu/~prudhomm       |
>                           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

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

[Christophe Prud'h. <pru...@MI...>]

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

Ok we can release something like corelinux bug fixes/updates
and a clfw preview technology release

A short note on my disponibilities, I would not mind begin working on clfw, 
unfortunately I am very busy until beginning of october. and then I will be 
able to work at full power for corelinux :). I can only do quick things so 
that my projects integrate well with corelinux.


-- 
     Christophe Prud'homme                    |
     MIT, 77, Mass Ave, Rm 3-243              |
     Cambridge MA 02139                       |     Friends are relatives
     Tel (Office) : (00 1) (617) 253 0229     |     you make for yourself.
     Fax (Office) : (00 1) (617) 258 8559     |
     http://augustine.mit.edu/~prudhomm       |
                          Following the hacker spirit

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

[Christophe Prud'h. <pru...@MI...>]

Huh

sorry I forgot to thank Gaby for his help and the light he shade on the 
various c++ topics.

thanks again

C.
-- 
     Christophe Prud'homme                    |
     MIT, 77, Mass Ave, Rm 3-243              |
     Cambridge MA 02139                       |     Friends are relatives
     Tel (Office) : (00 1) (617) 253 0229     |     you make for yourself.
     Fax (Office) : (00 1) (617) 258 8559     |
     http://augustine.mit.edu/~prudhomm       |
                          Following the hacker spirit

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

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

[Christophe Prud'h. <pru...@MI...>]

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 ?
will we release also the first clfw ?

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

Re: [Corelinux-develop] exception and inheritance

[Gabriel D. R. <Gab...@cm...>]

"Christophe Prud'homme" <pru...@MI...> writes:

| YAROGT again!
| 
| I cannot verify this in a C++ textbook/reference, I don't have one handy
| but
| 
| say that we have 
| class A
| {
| public:
|   virtual void f() throw(exceptA);
| }
| 
| class B : public A
| {
|   public:
| 
| // f redefined
| void f(); // is it ok?

No this is wrong.

| void f() throw(exceptA); // or is it this one? or both?

This one is OK.
| 
| }
| 
| it seems that in 2.96 the first one is rejected 
| the second one is the correct one
| I would say that the true prototype is the second one
| the first one is another function which does not throw any exceptions
| 
| any c++ guru?

I'm not a C++ guru but I'll answer it anyway.  Since a virtual
function speficies responsabilities, its overriders cannot safely
allow more exceptions that the initial interface does.

I'd strongly recommand not to use exception-specification -- the
exception (no pun intended) might be throw().

-- Gaby

Re: [Corelinux-develop] YAROGT Part II

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

Gabriel Dos Reis wrote:
> 
> "Frank V. Castellucci" <fr...@co...> writes:
> 
> [...]
> 
> | > * other incomplete friend declaration (without the class token)
> |
> | Well, with my style of class fowarding.
> 
> You can say "friend foo" without a class-key.
> 
> -- Gaby

I checked the standard again, which is what I went on in the first
place. I don't know if Christophe has changed it because of 2.96 choking
on it.

-- 
Frank V. Castellucci

Re: [Corelinux-develop] g++ 2.96

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

Gabriel Dos Reis wrote:
> 
> [ Excuse me if I appear slow to answer, but I'm busy in fixing bugs I
> introduced in current gcc cvs. ]
> 
> "Christophe Prud'homme" <pru...@MI...> writes:
> 
> | > Well, that mess was my fault -- I think the right figure is probably 4.
> | > By now, most the testsuite failures should have gone.
> | Well g++ 2.96 did a very good job at finding some issues in the code
> | especially for the exceptions.
> 
> Hmm, now I'm confused, I'm unsure about the original topic...
> Anyway...
> 
> | one quick question if you don't mind:
> | - is a class forward declaration sufficient for exception
> |   or is the class interface needed also?
> |
> | class except;
> | class A
> | {
> |  public:
> | void f() throw(except);
> | };
> |
> | or
> |
> | <full class definition for except via #include for example>
> | class A
> | {
> |  public:
> | void f() throw(except);
> | };
> |
> | it seems that g++ 2.96 likes the second one and rejects the first one
> 
> Yes, the first construct is ill-formed since
> 
> 15.4/1:
>   [...] A type denoted in an exception-specification shall not be an
>   incomplte type.  A type denoted in an exception-specification shall
>   not denote a pointer or reference to an incomplte type, other than
>   void*, const void*, volatile void*, or const volatile const*.
> 
> -- Gaby

Yes, C. was just pointing out my laziness when I go from quick testing
of interface and definition to releasing and forgetting to replace the
foward declaration.

<grin>

-- 
Frank V. Castellucci

Re: [Corelinux-develop] YAROGT Part II

[Gabriel D. R. <Gab...@cm...>]

Gabriel Dos Reis <Gab...@cm...> writes:

| "Frank V. Castellucci" <fr...@co...> writes:
| 
| [...]
| 
| | > * other incomplete friend declaration (without the class token)
| | 
| | Well, with my style of class fowarding. 
| 
| You can say "friend foo" without a class-key.
      ^^^
Oops, I really need to go to bed.  Of course, I meant you *cannot*...

Sorry.

-- Gaby

Re: [Corelinux-develop] YAROGT Part II

[Gabriel D. R. <Gab...@cm...>]

"Frank V. Castellucci" <fr...@co...> writes:

[...]

| > * other incomplete friend declaration (without the class token)
| 
| Well, with my style of class fowarding. 

You can say "friend foo" without a class-key.

-- Gaby

Re: [Corelinux-develop] fix for cpp warning

[Gabriel D. R. <Gab...@cm...>]

"Christophe Prud'homme" <pru...@MI...> writes:

| with g++ 2.95 and 2.96 the following works fine and gives no warning
| 
| #define A( tag ) a::tag
| 
| whereas 
| 
| #define Ap( tag ) a::##tag
| 
| gives a warning message for 2.96
| 
| a is a namespace of course
| 
| comments?

The former is right and the second invokes undefined behavior -- see
my previous message.

-- Gaby

Re: [Corelinux-develop] YAROGT part I

[Gabriel D. R. <Gab...@cm...>]

"Frank V. Castellucci" <fr...@co...> writes:

| Christophe Prud'homme wrote:
| > 
| > > > * class is missing in Friend declaraion in Synchronized.hpp
| > >
| > > don't need it because it is foward declared in
| > > DECLARE_CLASS(Synchronized) as per C++ standard.
| > > Are you getting an error?
| > Yes !
| 
| Ok, interesting, I'll re-review the C++ standard 1998(E)

The interesting part is clause 2 about lexical conventions -- take a
look at the paragraphs about preprocessing tokens then go to 16.3.3
about "The ## operator".  It says:

16.3.3/3:
  For both object-like and function-like macro invocations, before the
  replacement list is reexamined for more macro names to replace,e ach
  instance of ## preprocessing token in the replacement list (not from
  an argument) is deleted and the preceding preprocessing token is
  concatenated with the following preprocessing token.  If the result
  is not a valid preprocessing token, the behavior is undefined. [...]

-- Gaby

Re: [Corelinux-develop] YAROGT part I

[Gabriel D. R. <Gab...@cm...>]

"Christophe Prud'homme" <pru...@MI...> writes:

| Hi
| it is Yet Another Round Of G++ Test !
| 
| I try to track some compilations problems :
| 
| * missing #include <IteratorBoundsException.hpp> in Iterator.hpp
|   might cause big trouble with exception since nothing is know about this     
|   class at compile time. This problem occur in other place
|   the compiler needs the class interface at compile time !!!

True.

| * class is missing in Friend declaraion in Synchronized.hpp

Yes, the compiler is now more stringent about elaborated-type-specifier.

| * warning with corelinux::##tag (common.hpp) don't know yet how to fix it

I think that is wrong since after replacemend, the result is not a
valid preprocessing-token.

-- Gaby

Re: [Corelinux-develop] g++ 2.96

[Gabriel D. R. <Gab...@cm...>]

[ Excuse me if I appear slow to answer, but I'm busy in fixing bugs I
introduced in current gcc cvs. ]

"Christophe Prud'homme" <pru...@MI...> writes:

| > Well, that mess was my fault -- I think the right figure is probably 4.
| > By now, most the testsuite failures should have gone.
| Well g++ 2.96 did a very good job at finding some issues in the code
| especially for the exceptions.

Hmm, now I'm confused, I'm unsure about the original topic...
Anyway...

| one quick question if you don't mind:
| - is a class forward declaration sufficient for exception
|   or is the class interface needed also?
|   
| class except;
| class A
| {
|  public:
| void f() throw(except);
| };
| 
| or
| 
| <full class definition for except via #include for example>
| class A
| {
|  public:
| void f() throw(except);
| };
| 
| it seems that g++ 2.96 likes the second one and rejects the first one

Yes, the first construct is ill-formed since

15.4/1:
  [...] A type denoted in an exception-specification shall not be an
  incomplte type.  A type denoted in an exception-specification shall
  not denote a pointer or reference to an incomplte type, other than
  void*, const void*, volatile void*, or const volatile const*.
  
-- Gaby

Re: [Corelinux-develop] g++ 2.96

[Christophe Prud'h. <pru...@MI...>]

> Well, that mess was my fault -- I think the right figure is probably 4.
> By now, most the testsuite failures should have gone.
Well g++ 2.96 did a very good job at finding some issues in the code
especially for the exceptions.

one quick question if you don't mind:
- is a class forward declaration sufficient for exception
  or is the class interface needed also?
  
class except;
class A
{
 public:
void f() throw(except);
};

or

<full class definition for except via #include for example>
class A
{
 public:
void f() throw(except);
};

it seems that g++ 2.96 likes the second one and rejects the first one


It seems that 2.96 now is very good at checking signature correctness !
bravo !



a Note for those who want to use g++ 2.96:

don't forget to add the gcc/g++ libraries path to the /etc/ld.so.conf if you 
relocate the gcc tree to an unknow location to the linker (which is 
/usr/local by default). Otherwise you will have undefined symbols.

regards
C.
-- 
  Christophe Prud'homme                  |
  MIT, 77, Mass Ave, Rm 3-243            |   In theory, theory and practice
  Cambridge MA 02139                     |   are the same. In practice they
  Tel (Office) : (00 1) (617) 253 0229   |   are different.
  Fax (Office) : (00 1) (617) 258 8559   |
  http://augustine.mit.edu/~prudhomm     |
                          Following the hacker spirit

Re: [Corelinux-develop] exception and inheritance

[Christophe Prud'h. <pru...@MI...>]

> Great! We want to add the correct signatures now. I get lazy, and now
> the compiler forces me to do it right. I love it.
I did that 
the port to 2.96 is complete and working

>
> Are you entering defects for these? That way you aren't saddled with all
> the work. The other thing is that any changes made can NOT cause errors
> with 2.95.2
I'll do that
I check that everything( the examples) is working with 2.96 but not 2.95
a priori there should be no problems since the code is c++ correct now
but I'll verify that also before commiting 
first step create defects
- port to 2.96 ?
- ensure C++ correctness ?

-- 
   Christophe Prud'homme                  |
   MIT, 77, Mass Ave, Rm 3-243            |   I respect faith, but doubt is
   Cambridge MA 02139                     |   what gives you an education.
   Tel (Office) : (00 1) (617) 253 0229   |   -- Wilson Mizner
   Fax (Office) : (00 1) (617) 258 8559   |
   http://augustine.mit.edu/~prudhomm     |
                          Following the hacker spirit

Re: [Corelinux-develop] g++ 2.96

[Gabriel D. R. <Gab...@cm...>]

"Christophe Prud'homme" <pru...@MI...> writes:

| with g++ 2.96 lots of bugs and warning can be found 
| you can have the RPM at http://www.codesourcery.com/gcc-snapshots/
| 
| don't forget to check the Testsuite results for g++ and gcc
| and look at the number of unexpected failures !!
| in the 23/08 snapshot there are 895 unexpected failures
| and in the 22/08 only 4 !!

Well, that mess was my fault -- I think the right figure is probably 4.
By now, most the testsuite failures should have gone.

-- Gaby

Re: [Corelinux-develop] fix for cpp warning

[Christophe Prud'h. <pru...@MI...>]

>
> We drop the ##
done

-- 
  Christophe Prud'homme                  |
  MIT, 77, Mass Ave, Rm 3-243            |   As flies to wanton boys are we
  Cambridge MA 02139                     |   to the gods; they kill us for
  Tel (Office) : (00 1) (617) 253 0229   |   their sport.
  Fax (Office) : (00 1) (617) 258 8559   |   -- Shakespeare, "King Lear"
  http://augustine.mit.edu/~prudhomm     |
                          Following the hacker spirit

Re: [Corelinux-develop] fix for cpp warning

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

Christophe Prud'homme wrote:
> 
> with g++ 2.95 and 2.96 the following works fine and gives no warning
> 
> #define A( tag ) a::tag
> 
> whereas
> 
> #define Ap( tag ) a::##tag
> 
> gives a warning message for 2.96
> 
> a is a namespace of course
> 
> comments?

We drop the ## 

-- 
Frank V. Castellucci