opencxx-users

RE: [Opencxx-users] C++ design patterns

[SF M. E. <el...@us...>]

> types.h is hell --- too much conditional compilation, lumps different
> things together (e.g. dynamic loading and gc). I recently broke it into
> several separate input files. Please review the code in
> 'sandbox_jakacki_frontend1' branch and let me know if this issue is still
> there.

http://cvs.sourceforge.net/viewcvs.py/*checkout*/opencxx/opencxx/src/types.h?rev=1.7.4.1
Yes - it contains this line:
#include <string.h> // For size_t


> If you see any places that 'const' may be injected in relatively painless
> way, let's inject it.

Please look at the methods that start with "bool Is..." like in the files "member.h" and "token.h".


> I am not aware of any such efforts. Before going into these areas I would
> however first try to determine if people really need it, because it looks
> like a huge work.

Are there any code parts that use (blocking) input or output functions?
Would your file operations benefit from multithreading?
Can any steps in the procecssing be separated into cooperating and asynchronous tasks? The "huge" work can be split into smaller exercises.


> I was not satisfied with defines either, so I wrote simple script that
> generates all these declarations at configuration time. Please review it
> (it is in sandbox_jakacki_frontend1 branch) and let me know what you
> think about this solution.

This script can generate objects or variable definitions that will use templates if the support for this technique will be stable.


> I am under impression that each 'Ptree...::What()' returns something else
> (discriminator), similarily each 'Ptree...::Translate()' calls different
> method from Walker iface. Can you point out what classes have the same
> What() methods?

There are so many. Can your class browser of the development environment show the occurences?


> Is this one item or two? As far as I understand "fat interface" means that
> it handles lots of different functionalities. I don't see any connections
> of "obesity" to ordering of public, protected and private parts of iface,
> please correct me if I am wrong.

4.1.1 Which is the number of methods or attributes when you begin to think about a "diet" for the classes?   ;-)

4.1.2 The ordering can be perhaps performed by code beautifiers.
      But the logic grouping might show dependencies that should be expresses by a specific class.


> OpenC++ is not perfect, but is fairly modular and unlike many other projects
> it seems fairly easy to improve it in small steps. Please let me know what
> you think about this strategy.

It is fine. The evolution will be harder for the fat classes. Who does dare to split the rocks into handy and manageable bricks?


> > inline std::ostream& operator << (std::ostream& s, const Ptree& p)
> >  {
> >   p.Write(s);
> >   return s;
> >  }
> Why do you think it is better?

You do not need to care about null pointers.


> Perhaps they were not available when the code was created. I would not touch
> this are, unless we need to do some other work in token.h . It works as it
> is, it does not show any bugs, rewritting this part would have only
> educational purpose and this is not the aim of this project. Do you think it
> is reasonable?

Are international character sets (UTF-8, Unicode) supported by the current interface?
How do you think about the limit for single byte characters?


> Also I encourage you to get yourself your sandbox, since many of your
> proposals are worth implementing immediately. If you decide to contribute,
> please send me your SourceForge ID, so that I can add you to the project.

My service can be code review at the moment. I assume that the "coding" should be done after a common agreement or a decision by the project leaders.



Would anybody like to publish which software uses the OpenC++ tools?
Are any related links useful?

RE: [Opencxx-users] C++ design patterns

[Grzegorz J. <ja...@he...>]

On Thu, 11 Mar 2004, SF Markus Elfring wrote:

> > > Most interfaces appear to me as if they are C functions.
> > > My goal is a check if more data structures can be encapsulated in a real C++ style.
> > > Was a class API refactoring considered?
> > Yes.
>
> Hello,
>
> I looked at the source files. Now I suggest some changes to the code
> in detail. I dare to present several refactorings to see if you can
> possibly agree with them. The next generation class library would be
> developed. The current (old) implementation would call the new one to
> achieve backward compatibility. It may happen that others prefer to
> use the new interface from the beginning.

That makes sense.

>
> 1. types.h:
> Why is not the direct and smaller header <stddef.h> used?

types.h is hell --- too much conditional compilation, lumps different
things together (e.g. dynamic loading and gc). I recently broke it into
several separate input files. Please review the code in
'sandbox_jakacki_frontend1' branch and let me know if this issue is still
there.

> 2. all files:
> 2.1 Should the type name "uint" be replaced by "size_t"?

Perhaps yes. There is another reason why I would like to see uint killed---a
typedef like this one IMO does not bring sufficient value (see [1]).

> 2.2 Several virtual destructors are missing. They are needed to derive useful classes.
> Does that mean that several structures are "concrete classes" that would be specified as "final" in Java?

That may be the case. Some classes are designed to be derived from, some
are "final". In particular classes that have value semantics (= define
operator() and copy ctor and generally behaves as values) IMO almost
always should be "final". But there may also be omissions. Please bring
the names of these classes and I will comment on each of them
particularily.

> 2.3 Inline code documentation would be necessary to better understand
> the relationships between the data structures. How do you think about
> tools like "DocBook" or "Doxygen"?

I think "YES!". That's a perfect point. IMHO it is much easier to keep docs
in sync, also it is clearly visible what is documented, what's not. Some
time ago (1.5 years?...) we were talking about using Synopsis or Doxygen for
this purpose. There is an outstanding "TODO" item about moving the existing
docs into sources and implementing Makefiles to extract them. I am still
looking for somebody to do it. Once infrastructure is in place I pledge to
fill in the gaps in developers docs.

> 2.4 Can the methods "Translate..." be moved into "Translators"?

I am not sure if I understand. Currently "Translate..." methods are in
"Walkers", together with "Typeof..." methods. If you mean separating
"Translate..." from "Typeof..." then I think this is a good idea. Please
also see list archives on SF for the discussion about extracting an
"AbstractWalker" base class from existing wakers (let me know if you
cannot find it, I should be able to dig it up from my mailboxes).

Apart of that there is some additional cruft in Walker public iface
which does not belong there (e.g. static TranslateArgDeclList2()).

> 2.5 Copyright notice: express -> expressed

I am not a lawyer and English is not my first language, but I think you
are wrong here (see [2]).

> 2.6 Where are the copy constructors and assignment operators? Are
> compiler generated implementations used for them?

Again, this very much depends on the class semantics. Sometimes compiler
generated implementations are OK. Please note, that due to GC even when
class has value semantics and it contains (garbage collected) pointers,
default copy ctor and assignment operator are ok. On the other hand,
I suspect that in several places those functions should be blocked
(by privation), but are not.

Please point out the places where you think something is wrong and I will
comment on them. It may be that in some places this is messed up.

> 2.7 Please consider constant methods like it is in the waiting queue
> for the class "Member".

Present code does not employ 'const' in many places where it should,
perhaps because const did not have reasonable support in compilers when
Chiba was designing OpenC++. I would love to see const-correctness
improved, but:

  * it is easy to break backward compatibility (on the other hand
    it can be worked around by using e.g. const_<T>::type and
    giving client an option to define const_<T>::type == T)

  * it is not easy to retrofit const into existing code. I tried to
    do this several times on different products and almost always
    you end up with a snow-ball effect: one const here requires
    two consts there, and they require further eight const there
    and you have to paddle a lot before you reach the closure.

If you see any places that 'const' may be injected in relatively painless
way, let's inject it.

> 2.8 Was thread safety and concurrent access considered?

I am not aware of any such efforts. Before going into these areas I would
however first try to determine if people really need it, because it looks
like a huge work. I would expect that not many compilation tools use threads
in parsing or DOM manipulation, but I might be wrong (the examples that
spring to my mind are syntax-higlighting editors or some huge and
sophisticates IDEs that run many independent agents to modify ASTs; but this
requires much more caution than just thread safety).

> 3. ptree.h:
> 3.1 I would prefer class templates instead of the macros
> "ResearvedWordDecl", "PtreeStatementDecl" and "PtreeExprDecl".

I was thinking along the same lines, however I decided not to go for
templates for very pragmatic reason: ptree.h has to be compilable by occ
itself (ptree.h is included by mop.h), so I was afraid that unresolved issues
with templates parsing will surface here.

I was not satisfied with defines either, so I wrote simple script that
generates all these declarations at configuration time. Please review it
(it is in sandbox_jakacki_frontend1 branch) and let me know what you
think about this solution.

> 3.2 There are several classes with the same methods "What" and
> "Translate". Why were they not moved into another base class like
> "Translatable" or "Typeof" that would be used for multiple inheritance
> together with the class "NonLeaf"?

I am under impression that each 'Ptree...::What()' returns something else
(discriminator), similarily each 'Ptree...::Translate()' calls different
method from Walker iface. Can you point out what classes have the same
What() methods?

>
> 4. walker.h, mop.h, parse.h:

> 4.1 The classes "Parser", "Walker" and "Class" contain "fat"
> interfaces. The sections "public", "protected" and "private" should be
> ordered.

Is this one item or two? As far as I understand "fat interface" means that
it handles lots of different functionalities. I don't see any connections
of "obesity" to ordering of public, protected and private parts of iface,
please correct me if I am wrong.

However, if you mean two distinct items, then:

(a) "fat interface". To some extent I agree. As for "Walker": I think that
    only "Translate..." functions fit there, and "Typeof..." functions
    should be moved out, to something like another "Walker" (TypingWalker?).
    Also functions like "NewScope()" hardly fit there at first glance.

    "Class": it lumps together at least three responsibilities: representation
    of C++ class (Members(), Name()), being a MOP metaclass (Translate...()),
    and serving as access point for different functionalities of OpenC++
    (e.g. RegisterNewModifier(), ErrorMessage()). It may be argued that the
    idea of OpenC++ is that first two should be lumped together, but
    I do not agree, as this disables the independent reuse of parser and
    static analyzer without MOP.

    "Parser": I don't think this interface is very "fat". The public
    interface is in fact too lean as for my taste, because being an outsider
    you cannot use Parser just to parse, say, an expression. There are some
    functions that IMO do not fit in protected iface (e.g. SyntaxError()),
    but I think these are minor problems.

(b) ordering of public, protected, private: I do not see much value in
    ordering those sections apart from aestethics (there are some technical
    merits to it, but only if you depend on data layout in memory; we
    don't). There is some logic to the existing ordering, I don't think we
    should reorder. Also different people have different views on
    aesthetisc, so it is difficult to defend the point that one layout is
    better than another.  I am aware of at least two major styles (Lakos and
    Stroustrup/Sutter) and variations (e.g. if you say "private:" again
    for separating private data from private functions), for me both are OK
    if used consequently. Please let me know if I miss your point.

> 4.2 The replacement of pointers with C++ references would lead to a complete redesign.

That's for sure and I have one advice here. I have been programming for 14
years, using C++ for 10 years and for more than 5 years I do C++ every day.
That's to make the subsequent statement heavier :-)

Complete redesign is very costly (in open source project that means it takes
*lots* of time) and after you build the thing anew you initially get lower
quality than the original and you need to put another lot of work in it to
make it equally good. From this point it begins to be nice, since you have
better structure. However reaching this point is far more difficult than it
originally seems. Ask Chiba how many manmonths has he put into OpenC++,
estimate contributions from different people (see README, AUTHORS and 'cvs
history' output), divide by number of hours you can spend on it every week
and I bet you arrive at years.

The way that I would strongly recommend is to redesign components one by one
and go from the old design to the new design in evolutionary steps. The
smaller the components you replace, the easier it is to manage. Sometimes it
pays off to refactor the old code to insulate some part of it before
rewritting them. That way you have the running thing all the time. Also if
you get bored or occupied with something else on the way, your work up to
date is not lost.

OpenC++ is not perfect, but is fairly modular and unlike many other projects
it seems fairly easy to improve it in small steps. Please let me know what
you think about this strategy.

> 4.3 Limits like "MaxOptions" can be avoided if STL collections would be used.

True (applies also to other limits).

> 5. hash.h:
> How do see the future of the class "HashTable" in comparison to "std::hash_map"?

First, hash_map is not standard yet, so I would be reluctant to use it.

Second, IMO map would be enough for a while, at least until somebody
complains about efficiency (and that should be trivial to upgrade to
hash_map).

Third, YES, it would be fantastic if somebody simplifies HashTable with STL.
That would get one bug off my head (I happen to hit premature garbage
collection somewhere in HashTable).

>
> 6. ptree-core.h:
> 6.1 Please correct...
> inline std::ostream& operator << (std::ostream& s, Ptree* p)
>  {
>   p->Write(s);
>   return s;
>  }
> to
> inline std::ostream& operator << (std::ostream& s, const Ptree& p)
>  {
>   p.Write(s);
>   return s;
>  }

Why do you think it is better?

> 6.2 Can the class "PtreeIter" benefit from the STL iterator rules?

I don't think so. PtreeIter just was designed with another protocol in mind
and it should stay this way. However, that may be useful to have another
PtreeArray iterator that models STL iterator concept. Do you think it would
be possible to implement it as PtreeIter wrapper?

>
> 7. token.h:
> Why are the functions from the file <ctype.h> not reused?

Perhaps they were not available when the code was created. I would not touch
this are, unless we need to do some other work in token.h . It works as it
is, it does not show any bugs, rewritting this part would have only
educational purpose and this is not the aim of this project. Do you think it
is reasonable?

>
> I am curious how you will react on these ideas. I hope that I do not bother and annoy you.

Not this time :-)

> Is this a useful contribution?

Sure.

I would also very much appreciate if you could review
'sandbox_jakacki_frontend1' branch and let me know your comments. Perhaps
you could also have a look at file TODO, as it somewhat shows a direction in
which I would like to head.

Also I encourage you to get yourself your sandbox, since many of your
proposals are worth implementing immediately. If you decide to contribute,
please send me your SourceForge ID, so that I can add you to the project.

Best regards
Grzegorz

Footnotes:

[1] "A typedef declaration creates an alias for an existing type, not a
    new type. A typedef, therefore, gives only ilusion of type safety."
    J. Lakos "Large Scale C++ Software Design", p. 30

[2] I just found it with Google: "The law divides warranties into 'express'
    and 'implied' warranties.  Express warranties are any promises to back
    up the product that the seller expresses either in writing or orally."
    http://cobrands.public.findlaw.com/newcontent/consumerlaw/chp8_a.html



##################################################################
# Grzegorz Jakacki                       Huada Electronic Design #
# Senior Engineer, CAD Dept.              1 Gaojiayuan, Chaoyang #
# tel. +86-10-64365577 x2074               Beijing 100015, China #
# Copyright (C) 2004 Grzegorz Jakacki, HED. All Rights Reserved. #
##################################################################

RE: [Opencxx-users] C++ design patterns

[SF M. E. <el...@us...>]

> > Most interfaces appear to me as if they are C functions.
> > My goal is a check if more data structures can be encapsulated in a real C++ style.
> > Was a class API refactoring considered?
> Yes.

Hello,

I looked at the source files. Now I suggest some changes to the code in detail. I dare to present several refactorings to see if you can possibly agree with them.
The next generation class library would be developed. The current (old) implementation would call the new one to achieve backward compatibility. It may happen that others prefer to use the new interface from the beginning.

1. types.h:
Why is not the direct and smaller header <stddef.h> used?

2. all files:
2.1 Should the type name "uint" be replaced by "size_t"?
2.2 Several virtual destructors are missing. They are needed to derive useful classes.
Does that mean that several structures are "concrete classes" that would be specified as "final" in Java?
2.3 Inline code documentation would be necessary to better understand the relationships between the data structures. How do you think about tools like "DocBook" or "Doxygen"?
2.4 Can the methods "Translate..." be moved into "Translators"?
2.5 Copyright notice: express -> expressed
2.6 Where are the copy constructors and assignment operators? Are compiler generated implementations used for them?
2.7 Please consider constant methods like it is in the waiting queue for the class "Member".
2.8 Was thread safety and concurrent access considered?

3. ptree.h:
3.1 I would prefer class templates instead of the macros "ResearvedWordDecl", "PtreeStatementDecl" and "PtreeExprDecl".
3.2 There are several classes with the same methods "What" and "Translate". Why were they not moved into another base class like "Translatable" or "Typeof" that would be used for multiple inheritance together with the class "NonLeaf"?

4. walker.h, mop.h, parse.h:
4.1 The classes "Parser", "Walker" and "Class" contain "fat" interfaces. The sections "public", "protected" and "private" should be ordered.
4.2 The replacement of pointers with C++ references would lead to a complete redesign.
4.3 Limits like "MaxOptions" can be avoided if STL collections would be used.

5. hash.h:
How do see the future of the class "HashTable" in comparison to "std::hash_map"?

6. ptree-core.h:
6.1 Please correct...
inline std::ostream& operator << (std::ostream& s, Ptree* p)
 {
  p->Write(s);
  return s;
 }
to
inline std::ostream& operator << (std::ostream& s, const Ptree& p)
 {
  p.Write(s);
  return s;
 }
6.2 Can the class "PtreeIter" benefit from the STL iterator rules?

7. token.h:
Why are the functions from the file <ctype.h> not reused?

I am curious how you will react on these ideas. I hope that I do not bother and annoy you.
Is this a useful contribution?

Sincerely,
Markus Elfring

RE: [Opencxx-users] C++ design patterns

[Grzegorz J. <ja...@he...>]

On Mon, 8 Mar 2004, SF Markus Elfring wrote:

> > > Was a class API refactoring considered?
> > Yes.
>
> What will come next?

I am afraid next we have to start ignoring your posts unless you start
asking precise questions and giving precise answers.

Best regards
Grzegorz

##################################################################
# Grzegorz Jakacki                       Huada Electronic Design #
# Senior Engineer, CAD Dept.              1 Gaojiayuan, Chaoyang #
# tel. +86-10-64365577 x2074               Beijing 100015, China #
# Copyright (C) 2004 Grzegorz Jakacki, HED. All Rights Reserved. #
##################################################################

RE: [Opencxx-users] C++ design patterns

[SF M. E. <el...@us...>]

> > Was a class API refactoring considered?
> Yes.

What will come next?

RE: [Opencxx-users] C++ design patterns

[Grzegorz J. <ja...@he...>]

On Fri, 5 Mar 2004, SF Markus Elfring wrote:

> Miko=B3aj_Dawidowski <da...@te...> schrieb am 05.03.04 11:02:12:
> > Whats your point in that whole discussion. All your tips deal with
> > non-functional area, so it is not interesting for the users. You don't =
seem
> > willing to contribute, so it is not interesting for developers of this
> > project.
> >
> > So what is your goal??
> > I hope only it is not to show us how good you know C++ and STL.
>
> I started this discussion because I saw some details in the class
> design that would need an update in my opinion. I got informed about
> the current state of the library and its maintenance.
>
> Most interfaces appear to me as if they are C functions.
> My goal is a check if more data structures can be encapsulated in a real =
C++ style.
> Was a class API refactoring considered?

Yes.

Best regards
Grzegorz

>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.
> _______________________________________________
> Opencxx-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opencxx-users
>
>

##################################################################
# Grzegorz Jakacki                       Huada Electronic Design #
# Senior Engineer, CAD Dept.              1 Gaojiayuan, Chaoyang #
# tel. +86-10-64365577 x2074               Beijing 100015, China #
# Copyright (C) 2004 Grzegorz Jakacki, HED. All Rights Reserved. #
##################################################################

RE: [Opencxx-users] C++ design patterns

[SF M. E. <el...@us...>]

Miko=B3aj=5FDawidowski <da...@te...> schrieb am 05.03.04 11:02:12:
> Whats your point in that whole discussion. All your tips deal with
> non-functional area, so it is not interesting for the users. You don't s=
eem
> willing to contribute, so it is not interesting for developers of this
> project.
>=20
> So what is your goal=3F=3F
> I hope only it is not to show us how good you know C++ and STL.

I started this discussion because I saw some details in the class design t=
hat would need an update in my opinion. I got informed about the current s=
tate of the library and its maintenance.

Most interfaces appear to me as if they are C functions.
My goal is a check if more data structures can be encapsulated in a real C=
++ style.
Was a class API refactoring considered=3F

Re: [Opencxx-users] C++ design patterns

[Grzegorz J. <ja...@he...>]

On Thu, 4 Mar 2004, SF Markus Elfring wrote:

> > Do you think that in general it is better to return an object rather
> > then NULL pointer? If so, why?
>
> The traditional or C style handling of linked list uses the NULL
> pointer as a special marker.

Agreed.

> It can be used in encapsulated C++
> methods, too.

Agreed.

> Another design might be to connect the pointers to a
> ring.

Agreed.

> The STL consistently uses iterators.

Agreed, but I see no connection to previous sentences.

> There is no need to deal
> with pointers directly.

I could agree (dependes on what "to deal with pointers directly" means),
but this does not answer the question. The question was:

    Do you think that in general it is better to return an object rather
    than NULL pointer? If so, why?

> Please look at the section "Invariants", for
> example. http://www.zib.de/benger/STL/Container.html

I fail to see how this answers my question.

Markus,

I is very nice talking to you, but we arrive nowhere. Discussion means
asking questions and ANSWERING them. You asked some questions. I answered
all your questions I understood.

In order to get better understanding of your point, I asked you some
questions (e.g. the question at the top of this e-mail). You did not
answer them (e.g. it is still unclear to me if you think it is better to
return an object or a NULL pointer).

I would appreciate if you could go back to previous postings in our
discussion to address the questions I asked. That would let us move
forward with substantial discussion.

Best regards
Grzegorz


##################################################################
# Grzegorz Jakacki                       Huada Electronic Design #
# Senior Engineer, CAD Dept.              1 Gaojiayuan, Chaoyang #
# tel. +86-10-64365577 x2074               Beijing 100015, China #
# Copyright (C) 2003 Grzegorz Jakacki, HED. All Rights Reserved. #
##################################################################

Re: [Opencxx-users] C++ design patterns

[SF M. E. <el...@us...>]

> Do you think that in general it is better to return an object rather
> then NULL pointer? If so, why?

The traditional or C style handling of linked list uses the NULL pointer as a special marker. It can be used in encapsulated C++ methods, too. Another design might be to connect the pointers to a ring.
The STL consistently uses iterators. There is no need to deal with pointers directly. Please look at the section "Invariants", for example.
http://www.zib.de/benger/STL/Container.html

Re: [Opencxx-users] C++ design patterns

[Grzegorz J. <ja...@he...>]

Hi Markus,

On Wed, 3 Mar 2004, SF Markus Elfring wrote:

> > First, please read my post again. I am not saying that you *need* pointers
> > to express "special value".
>
> How do you think about to return an object for your "special value"
> like it is done with the methods "begin" and "end" in a list class?
> http://www.igpm.rwth-aachen.de/C++/STL_doc/List.html

Why do you think STL list<>::end() returns an object?

Do you think that in general it is better to return an object rather
then NULL pointer? If so, why?

> > Third, I am not sure I fully understand your iterators example. The source
> > of my confusion may be the fact that raw poiters are also valid STL
> > iterators. Could you elaborate on what exactly you want to point out?
>
> The STL encapsulates this behaviour with template classes.

What do you mean by "this behaviour" ? Could you restate?

> So you are used to that kind of "magic".
>
> > I am sorry, I do not understand the question. What copy semantics do I use
> > where?
>
> This topic deals with object identity and object equality.

Yes, there are connections. But what is your question?

Regards
Grzegorz

##################################################################
# Grzegorz Jakacki                       Huada Electronic Design #
# Senior Engineer, CAD Dept.              1 Gaojiayuan, Chaoyang #
# tel. +86-10-64365577 x2074               Beijing 100015, China #
# Copyright (C) 2003 Grzegorz Jakacki, HED. All Rights Reserved. #
##################################################################

Re: [Opencxx-users] C++ design patterns

[SF M. E. <el...@us...>]

> First, please read my post again. I am not saying that you *need* pointers
> to express "special value".

How do you think about to return an object for your "special value" like it is done with the methods "begin" and "end" in a list class?
http://www.igpm.rwth-aachen.de/C++/STL_doc/List.html


> Third, I am not sure I fully understand your iterators example. The source
> of my confusion may be the fact that raw poiters are also valid STL
> iterators. Could you elaborate on what exactly you want to point out?

The STL encapsulates this behaviour with template classes.
So you are used to that kind of "magic".


> I am sorry, I do not understand the question. What copy semantics do I use
> where?

This topic deals with object identity and object equality.

Re: [Opencxx-users] C++ design patterns

[Grzegorz J. <ja...@he...>]

On Tue, 2 Mar 2004, SF Markus Elfring wrote:

> > (1) Sometimes you need a special value to mark "error", "not supplied",
> >     "the end" etc., so it is convenient to use null pointer for this
> >     purpose.
>
> Please look at a design or an implementation of the standard template
> library.
> Example: I think that the iterators do not need pointers in their
> public interfaces to mark special positions.
> - http://boost.org/libs/iterator/doc/index.html
> - http://dtemplatelib.sourceforge.net/index.htm
> - http://www.melikyan.com/ptypes/

First, please read my post again. I am not saying that you *need* pointers
to express "special value".

Second, I agree with your statement about iterators, however I don't think
it contradicts what I wrote. Please correct me if I am missing anything.

Third, I am not sure I fully understand your iterators example. The source
of my confusion may be the fact that raw poiters are also valid STL
iterators. Could you elaborate on what exactly you want to point out?

Four, just an observation: iterators really employ "special values"
(singular value, past-the-end value).

> > (2) References have different assignment semantics than pointers.
> >     Changing pointer class data members into references will most likely
> >     change the assignment semantics of the class.
>
> Which copy semantics do you use at the moment?

I am sorry, I do not understand the question. What copy semantics do I use
where?

What I meant is that you cannot assign to a reference the way you can
assign to a pointer. For example try to write cyclic double-link list on
references not pointers. Or consider boost::shared_ptr<>. Assume you want
to modify it, so that ctors throw when you try to pass NULL pointer. The
raw pointer stored internally (in 1.30.0 it is called 'px', file
shared_ptr.hpp:302) is now guaranteed to be non-NULL. Can you change it to
a reference?

>
> > (3) As I already mentioned, references can potentially confuse
> >     garbage collector.
>
> How do Java references fit into this picture?

By "garbage collector" I meant "Hans Boehm's garbage collector", currently
used in OpenC++.

Java references are more like C++ pointers than C++ references, because:

  * they can be null,
  * you can assign to them (in C++ you cannot).

Java bytecode is run on virtual machine which knows which pieces of memory
are pointers (references). On the contrary, compiled C++ runs directly on
CPU and HB's GC uses miscellaneous heuristics to figure out which bits of
memory are pointers. If GC misses a live pointer, it is likely to free an
object, which is still referenced.  HB's GC assumes that pointers are
implemented as memory addresses. As long as references are implemented in
the same fashion, it should be safe to use references.  My gut feeling is
that some compiler optimizations are more likely to confuse HB's GC when
GC-managed object is refenced by references only.

> Can "smart pointers" help?
> http://boost.org/libs/smart_ptr/smart_ptr.htm

Yes, they would definitely help to make OpenC++ independent of GC.
Sometimes people have problems getting GC to work on their platforms, so
it would be a plus. I have heard of people just switching GC off at all,
which still lets you run OpenC++ on reasonably sized sources.

However, changing all garbage collected pointers to boost::shared_ptr<>
would change all the interfaces, consequently totally break the backward
compatibility. One solution I had in mind was to define OpenCxx::ptr<> and
have three build options:

    (A) OpenCxx::ptr<T>::type is T* and GC is used
    (B) OpenCxx::ptr<T>::type is T* and GC is not used
    (C) OpenCxx::ptr<T>::type is boost::smart_ptr<T> and GC is not used

This is nontrivial to do, however. If you would like to help with this you
have a "go ahead".

BR
Grzegorz

##################################################################
# Grzegorz Jakacki                       Huada Electronic Design #
# Senior Engineer, CAD Dept.              1 Gaojiayuan, Chaoyang #
# tel. +86-10-64365577 x2074               Beijing 100015, China #
# Copyright (C) 2003 Grzegorz Jakacki, HED. All Rights Reserved. #
##################################################################

Re: [Opencxx-users] C++ design patterns

[SF M. E. <el...@us...>]

> (1) Sometimes you need a special value to mark "error", "not supplied",
>     "the end" etc., so it is convenient to use null pointer for this
>     purpose.

Please look at a design or an implementation of the standard template library.
Example: I think that the iterators do not need pointers in their public interfaces to mark special positions.
- http://boost.org/libs/iterator/doc/index.html
- http://dtemplatelib.sourceforge.net/index.htm
- http://www.melikyan.com/ptypes/


> (2) References have different assignment semantics than pointers.
>     Changing pointer class data members into references will most likely
>     change the assignment semantics of the class.

Which copy semantics do you use at the moment?


> (3) As I already mentioned, references can potentially confuse
>     garbage collector.

How do Java references fit into this picture?
Can "smart pointers" help?
http://boost.org/libs/smart_ptr/smart_ptr.htm

Re: [Opencxx-users] C++ design patterns

[Grzegorz J. <ja...@he...>]

On Sat, 28 Feb 2004, SF Markus Elfring wrote:

> > Third, observe that OpenC++ uses garbage collection. The popular idiom
> > that reference is a non-owning pointer is not useful in this context.
> > Moreover, it can be deadly if function stores the reference passed in.
> > AFAIK the original idea was then to stick to the pointers.
>
> One thing that I like with references is: You do not need to check for
> null pointers. They must be initialized.

I like it too, but:

(1) Sometimes you need a special value to mark "error", "not supplied",
    "the end" etc., so it is convenient to use null pointer for this
    purpose.

(2) References have different assignment semantics than pointers.
    Changing pointer class data members into references will most likely
    change the assignment semantics of the class.

(3) As I already mentioned, references can potentially confuse
    garbage collector.

So references are not just better pointers. References are references and
pointers are pointers. In particular C++ is lacking native compound type
that would behave as a pointer, but guarantee non-nullness.

Best regards
Grzegorz

##################################################################
# Grzegorz Jakacki                       Huada Electronic Design #
# Senior Engineer, CAD Dept.              1 Gaojiayuan, Chaoyang #
# tel. +86-10-64365577 x2074               Beijing 100015, China #
# Copyright (C) 2003 Grzegorz Jakacki, HED. All Rights Reserved. #
##################################################################

Re: [Opencxx-users] C++ design patterns

[SF M. E. <el...@us...>]

> Third, observe that OpenC++ uses garbage collection. The popular idiom
> that reference is a non-owning pointer is not useful in this context.
> Moreover, it can be deadly if function stores the reference passed in.
> AFAIK the original idea was then to stick to the pointers.

One thing that I like with references is: You do not need to check for null pointers. They must be initialized.

[Opencxx-users] RAM-SE04: ECOOP Workshop on Reflection, AOP and Meta-Data for Software Evolution (CFP)

[Walter C. <ca...@di...>]

(Apologies, if you receive more than one copy)

% ---
                                   RAM-SE'04 
     ECOOP Workshop on Reflection, AOP and Meta-Data for Software Evolution
                    Oslo, Norway, 14th or 15th of June 2004
                     http://homes.dico.unimi.it/RAM-SE04.html
                             Call for Contributions

*Workshop Description*
Software evolution and adaptation is a research area in continuous evolution,
and offering stimulating challenges for both academic and industrial
researchers.

The evolution of software systems, to face unexpected situations or just for
improving their features, relies on software engineering techniques and
methodologies. Nowadays a similar approach is not applicable in all situations
e.g., for evolving nonstopping systems or systems whose code is not available.
 
Features of reflection such as transparency, separation of concerns, and
extensibility seem to be perfect tools to aid the dynamic evolution of running
systems.  Aspect-oriented programming can simplify code instrumentation whereas
techniques that rely on meta-data can be used to inspect the system and to
extract the necessary data for designing the heuristic that the reflective and
aspect-oriented mechanism use for managing the evolution. 

We feel the necessity to investigate the benefits brought by the use of these
techniques on the evolution of object-oriented software systems. In particular
we would determine how these techniques can be integrated together with more
traditional approaches to evolve a system and the benefits we get from their
use.

This workshop can be a good meeting-point for people working in the software
evolution area, and an occasion to present reflective, aspect-oriented, and
meta-data based solutions to evolutionary problems, and new ideas straddling
these areas.
    
*Workshop Topics*
Every contribution that exploits reflective techniques, aspect-oriented
programming and/or meta-data to evolve software systems is welcome. Specific
topics of interest for the workshop include, but are not limited to:

 - reflective middleware and environments for software evolution;
 - adaptative software components;
 - feature-oriented adaptation;
 - aspect interference and composition for software evolution;
 - evolution and adaptability;
 - MOF, code annotations and other meta-data facilities for software evolution;
 - intercession and introspection;
 - software evolution tangling concerns.

To ensure lively discussion at the workshop, the organizing committee will
choose the contributions on the basis of topic similarity that will permit the
beginning of new collaborations. To grant an easy dissemination of the proposed
ideas and to favorite an ideas interchange among the participants, accepted
contributions will be made available in advance over the Web and an hardcopy of
the contributions will be distributed to participants at the workshop.  

*Workshop Format*

The workshop is a full day meeting. Part of the workshop will be devoted to
contribution of papers, and part will be devoted to panels and (we hope) to
interchange of ideas between participants.  The workshop has to provide a
discussion forum about the evolution of the sector and has to permit new
cooperations to established with other researchers. The workshop will be
particularly useful for young researchers who will be able to compare their
ideas with other people working on the topic.

*Submissions*

Position papers (max 5-pages long) must be sent electronically (Postscript or
PDF file) to 

                             ra...@di...

Extended version of most interesting contributions, that have benefited from
the workshop discussions, will be collected as a book or as a special issue of
a journal that will be published after the workshop (to be defined).

*Organizing Committee*

Walter Cazzola DICo University of Milano
Shigeru Chiba  Tokyo Institute of Technology
Gunter Saake   University of Magdeburg

*Important Dates*

Submission deadline:    5th April 2004
Notification date:     26th April 2004 
Workshop date:         14th or 15th June 2004

[Opencxx-users] Info (fwd)

[Grzegorz J. <ja...@he...>]

---------- Forwarded message ----------
Date: Mon, 16 Feb 2004 11:14:53 +0100 (CET)
From: ocean0 <lorenzet at interfree.it>
To: opencxx-commits at lists.sourceforge.net
Subject: Info
Resent-Date: Tue, 24 Feb 2004 15:16:35 +0800 (CST)

I ' m a student of information engineering (Padova-Italy) and
i' m interesting of object serialization and RMI,ARMI in C / C++.
The basic problem that I would solve is send function code from source
host X to destination host Y and only destination host runs the received
function.
A first solutions that i have thought is send to host Y a binary code and
then use a emulator for execute a function received but the current
implementations with similar targets make to run the  functions (in
bytecode)  received by virtual machine such as in java and in opencxx, why?
Perhaps why is the execution time of second type of implementation better?
or  why is too complex and difficult emulate binary code of different
machine?

And Then also C# allows to use object serialization ... why
opencxx realize ?

Re: [Opencxx-users] static code analysis

[Grzegorz J. <ja...@he...>]

Markus,

I had a quick look at these tools, this is what I found:

  * AntiC/Jlint: webpage [http://www.ispras.ru/~knizhnik/jlint/ReadMe.htm],
    a kind of lint for C++ and Java.

  * BLAST: cannot find it, Wikipedia has a link to a package in
    computational biology called BLAST, but apparently this is not this
    BLAST.

  * BOON: "BOON is a tool for automatically finding buffer overrun
    vulnerabilities in C source code. (...) BOON has many serious
    limitations and defects, and it is not for the faint of heart."
    [http://www.cs.berkeley.edu/~daw/boon/]

  * Broadway: Looks like it handles C only. It seems non-free.
    [http://www.cs.utexas.edu/users/emery/]

  * CQual: "A tool for adding type qualifiers to C."
    [http://sourceforge.net/projects/cqual/]

  * DAEDALUS: I am not sure how we can use this software, also I don't see a
    link to source code.
    [http://www.di.ens.fr/~cousot/projects/DAEDALUS/synthetic_summary/index.shtml]

  * ESC/Java: for Java. [http://research.compaq.com/SRC/esc/]

  * Flawfinder: "(...) program that examines source code and reports
    possible security weaknesses." [http://www.dwheeler.com/flawfinder/]
    Looks like it handles C only.

  * MOPS: commercial. [http://www.mops.fu-berlin.de/Products.htm]

  * SLAM: "This tool uses model checking to verify predicates of a boolean
    program generated from a C program" [from the summary at VFiasco project
    site]

  * Smatch: "Smatch is C source checker but mainly focused [on] checking the
    Linux kernel code." [http://smatch.sourceforge.net/]

  * Splint: "Splint is a tool for statically checking C programs for
    security vulnerabilities and coding mistakes." [http://www.splint.org/]


On Mon, 23 Feb 2004, SF Markus Elfring wrote:

> 1. sharing and reusing ideas (=> code)

I am not aware of idea diffusion between these projects and OpenC++. If
you think there are good ideas there that are applicable to OpenC++ now,
please discuss them here. If you think OpenC++ ideas can be reused by
these projects, please advertise OpenC++ to them and let me know if they
decide to use/reuse OpenC++.

> 2. Was your code ever checked by such tools?

It looks like only AntiC is applicable. I am not aware of anybody running
OpenC++ source through it. Usually linting sources is much more work that
just running the program --- you get lots of spurious messages and you have
to read through them and work around them. Moreover, running a lint tool
once has only limited impact, as with time the code picks up new dirt. So to
get the real value out of linting you need to include it in the development
process, i.e. add to makefiles, install lint tool on CompileFarm, convince
people to run it on a regular basis (e.g. before release) and keep pinging
them if they don't. This is a lot of work and I don't think that it brings
as much value at the moment. The work invested in linting could be spent
much better, e.g. on templates support. However, as always I am open to
discussion: if you still think that OpenC++ project needs linting, please do
some more advertising/convincing on this list (and volunteer to implement
the process and be a lint guardian :-).

Thanks for your input
Grzegorz

>
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Opencxx-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opencxx-users
>
>

##################################################################
# Grzegorz Jakacki                       Huada Electronic Design #
# Senior Engineer, CAD Dept.              1 Gaojiayuan, Chaoyang #
# tel. +86-10-64365577 x2074               Beijing 100015, China #
# Copyright (C) 2003 Grzegorz Jakacki, HED. All Rights Reserved. #
##################################################################

Re: [Opencxx-users] static code analysis

[SF M. E. <el...@us...>]

> What do you mean exactly? Interoperability or sharing/reusing source code?

1. sharing and reusing ideas (=> code)
2. Was your code ever checked by such tools?

Re: [Opencxx-users] static code analysis

[Grzegorz J. <ja...@he...>]

On Sat, 21 Feb 2004, SF Markus Elfring wrote:

> Are there any relationships to the tools that are listed on the page
> "http://en.wikipedia.org/wiki/Static_code_analysis"? How do you think
> about a cooperation?

What do you mean exactly? Interoperability or sharing/reusing source code?

BR
Grzegorz

##################################################################
# Grzegorz Jakacki                       Huada Electronic Design #
# Senior Engineer, CAD Dept.              1 Gaojiayuan, Chaoyang #
# tel. +86-10-64365577 x2074               Beijing 100015, China #
# Copyright (C) 2003 Grzegorz Jakacki, HED. All Rights Reserved. #
##################################################################

Re: [Opencxx-users] C++ design patterns

[Grzegorz J. <ja...@he...>]

On Sat, 21 Feb 2004, SF Markus Elfring wrote:

> I am suprised about some details in the documentation.
> The use of pointers seems not to be "state of the art".
>
> Examples:
> - Ptree* FullTypeName()
> - InsertDeclaration(Environment* e, Ptree* d, Ptree* key, void* client_data)
> - InstancesOf(char* metaclas_name, ClassArray& result)
>
> I would expect references to C++ objects and the use of a standard string class.

First, I don't think that always aiming at "start of the art" solution is
a good engineering practice. E.g. very often "state of the art solution",
say Loki::SmartPtr<> or visitable classes, is an overkill. It requires
codding and attention and sometimes does not pay off.

Second, software development always has to face the legacy and backward
compatibility issues. Certain decisions about interfaces (in particular
how pointers are used) once made are costly to change later (in terms of
coding or loosing users).

Third, observe that OpenC++ uses garbage collection. The popular idiom
that reference is a non-owning pointer is not useful in this context.
Moreover, it can be deadly if function stores the reference passed in.
AFAIK the original idea was then to stick to the pointers.

Fourth, strings have been standardized in 1998, OpenC++ was created in
in 1995.

Fifth, OpenC++ really includes many state of the art programming
techniques from the time of its inception. Just have a look when the GoF
book was first published.

Sixth, personally I feel that your judgement is unfair to Chiba and other
contributors, who put effort into making and keeping OpenC++ operational.
IMHO it would be more enabling to ask about the rationales than to throw
judgements.

Seventh, I agree that OpenC++ has many shortcommings. As Chiba mentions in
his reply, we do not have enough manpower now. I am in the process of
building a team of reliable volunteers ready to tackle the outstanding
issues. If you would like to join this effort and put some time into
making OpenC++ better, you are more than welcome. Please contact me
directly for more details on volunteering.

Best regards
Grzegorz

##################################################################
# Grzegorz Jakacki                       Huada Electronic Design #
# Senior Engineer, CAD Dept.              1 Gaojiayuan, Chaoyang #
# tel. +86-10-64365577 x2074               Beijing 100015, China #
# Copyright (C) 2003 Grzegorz Jakacki, HED. All Rights Reserved. #
##################################################################

Re: [Opencxx-users] C++ design patterns

[Shigeru C. <ch...@ac...>]

    From: "SF Markus Elfring" <el...@us...>
    Date: Sat, 21 Feb 2004 21:50:10 +0100

    > I am suprised about some details in the documentation.
    > The use of pointers seems not to be "state of the art".

Well, it *was* the state of the art when most of the code was written
around 10 years ago for Sparc 10 with about 50MHz SPARC chip and
32-64MB memory. :-p

I agree that the code should be written to be today's state of the art
but unfortunately the project does not have resource enough to do so.

Best regards,

Chiba

[Opencxx-users] static code analysis

[SF M. E. <el...@us...>]

Are there any relationships to the tools that are listed on the page "http://en.wikipedia.org/wiki/Static_code_analysis"?
How do you think about a cooperation?

[Opencxx-users] C++ design patterns

[SF M. E. <el...@us...>]

I am suprised about some details in the documentation.
The use of pointers seems not to be "state of the art".

Examples:
- Ptree* FullTypeName()
- InsertDeclaration(Environment* e, Ptree* d, Ptree* key, void* client_data)
- InstancesOf(char* metaclas_name, ClassArray& result)

I would expect references to C++ objects and the use of a standard string class.

Re: [Opencxx-users] Help for compiling opencxx source

[Grzegorz J. <ja...@he...>]

On 19 Feb 2004, =D6=A3=BD=A8=CF=C9 wrote:

> Dear Sir:

Ni hao,

> =09I am having a trouble to compile some file downloaded from
>
> http://cvs.sourceforge.net/viewcvs.py/opencxx/opencxx/sample/?only_with_t=
ag=3Dre
> l_2_7.
>
> I have opencxx-2.7 got from the same website above. I type "./configure" =
to
>
> configure the package for OS which is RedHat linux x9.2 with kernel 2.4
>
> , and then I type "make install" to install the programs.But when I type
>
> "occ -m -- -g VerboseClass.mc" for compiling the downloaded file
> "VerboseClass.mc" I get an error whichlike following:
>
> *****************************************************************
>
> /usr/include/c++/3.2.2/i386-redhat-linux/bits/c++locale.h:48: parse error
> before `; }'
>
> MOP warning: The hash table is full.  Expanded...
>
> 1 Error(s).  OpenC++ stops.
>
> *****************************************************************
>
[snip]
>
>     I am wondering if I install an older version of gcc compiler,which ju=
st
> for older C++ library.so that I would not see this sort of problem.
>
>     I really appreciate if you could any suggestions on this.Thank you,an=
d
> hava a good day.

Yes. OpenC++ has a known problem with parsing gcc-3.x header files. It
should work OK with headers from gcc-2.95.x.

Fixing OpenC++ wrt. gcc-3.x headers is not trivial. I am now in a process
of building a team of voluteers who would like to contribute work into it.
If you have time and would like to help with it, please send me an e-mail.

> Yours Zheng(From China)

Cheers
Grzegorz
(also from China)

##################################################################
# Grzegorz Jakacki                       Huada Electronic Design #
# Senior Engineer, CAD Dept.              1 Gaojiayuan, Chaoyang #
# tel. +86-10-64365577 x2074               Beijing 100015, China #
# Copyright (C) 2003 Grzegorz Jakacki, HED. All Rights Reserved. #
##################################################################