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