Menu
▾
▴
opencxx-users
|
From: SF M. E. <el...@us...> - 2004-02-28 19:02:31
|
> 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. |
|
From: SF M. E. <el...@us...> - 2004-03-02 16:54:49
|
> (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 |
|
From: Grzegorz J. <ja...@he...> - 2004-03-03 02:07:25
|
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. # ################################################################## |
|
From: SF M. E. <el...@us...> - 2004-03-03 16:25:56
|
> 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. |
|
From: Grzegorz J. <ja...@he...> - 2004-03-04 01:30:58
|
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. # ################################################################## |
|
From: SF M. E. <el...@us...> - 2004-03-04 16:33:26
|
> 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 |
|
From: Grzegorz J. <ja...@he...> - 2004-03-05 01:40:34
|
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. #
##################################################################
|
|
From: SF M. E. <el...@us...> - 2004-03-05 15:30:29
|
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 |
|
From: Grzegorz J. <ja...@he...> - 2004-03-08 02:21:56
|
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. # ################################################################## |
|
From: SF M. E. <el...@us...> - 2004-03-08 17:15:40
|
> > Was a class API refactoring considered? > Yes. What will come next? |
|
From: Grzegorz J. <ja...@he...> - 2004-03-09 01:03:32
|
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. # ################################################################## |
|
From: SF M. E. <el...@us...> - 2004-03-11 21:05:10
|
> > 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
|
|
From: Grzegorz J. <ja...@he...> - 2004-03-12 03:57:32
|
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. #
##################################################################
|
|
From: SF M. E. <el...@us...> - 2004-03-12 22:22:10
|
> 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? |
|
From: Grzegorz J. <ja...@he...> - 2004-03-15 03:09:40
|
On Fri, 12 Mar 2004, SF Markus Elfring wrote: > > 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 This is not the latest revision. The whole 'opencxx/src' does not exist in this branch. The code was moved to 'opencxx/opencxx/gc-related-gc-{yes,no}/new.h', which now includes 'cstdlib' 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". This is still a lot of work. Take e.g. Member::IsConstructor(). When you qualify it with const, you also have to fix GetEncodedName(). After fixing it perhaps will return const char*, not char*. If so, then you have to fix Encoding::GetBaseName() and also Ptree::Eq(), because now they take non-const argument (AFAIK, sorry I do not have time to dig in it now). Moreover, you need to fix Class::GetEnvironment() also. I am not looking further now, so I don't know how many other functions you would have to fix. This is what I call snow-ball effect. If you want to do this --- please do, but be warned that the snow-ball may get huge. > > 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? All IO is blocking now. > Would your file operations benefit from multithreading? I don't see any benefits at the moment. IMO there are really two reasons to use MT: (a) when your processing needs a lot of power and you want to use multi-cpu architecture, (b) when you want lessen response time of interactive application. None of them applies. > Can any steps in the procecssing be separated into cooperating and > asynchronous tasks? The "huge" work can be split into smaller > exercises. I honestly don't think so. We have a lot of more rudimentary problems in OpenC++ (gcc-3.x STL headers for instance). Also I am afraid that synchronization of asynchronous tasks involves a lot of overhead in code and in execution time and this will not pay off in foreseable future. > > 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. Perhaps yes. > > 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? Perhaps so, but I did not have time to look into it. Please point to them if you want to help, that will spare me duplicating the job you have already done. > > 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? ;-) I don't think that number of methods tells much. Look at Walker or just any other implementation of Visitor pattern. If the visited hierarchy is numerous, then number of 'Visitor::visit()' (or Walker::Translate...()) member functions will be large, but that does not mean that the class is fat. On the other hand, the class class Driver { public: void RunCompilation(const string&); static Time GetCurrentTime(); ... }; already looks fatty, since GetCurrentTime most likely does not belong in it. > 4.1.2 The ordering can be perhaps performed by code beautifiers. Sure, but I found beautifiers not so usefull in practice. They confuse 'cvs annotate' and they usually loose some informal information present in code. It is like running ancient scriptures through OCR---you get the same text but certainly something is lost. > But the logic grouping might show dependencies that should be > expresses by a specific class. I guess we mean the same. > > 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? I don't see a problem if you do it one at a time. > > > 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. On all compilers I have seen, you will not get any problems calling 'os << (Ptree*)0'. See Ptree::Write() implementation for details (this trick is undefined behaviour according to the Standard, but it works; it can be made completely legal by moving the test into operator<<(); I guess nobody has done it so far, because nobody had problems). > > 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? Is UTF-8 or Unicode legal as input encoding for C++ preprocessor per ISO C++ Standard? Even if it is, I do not think this is cruicial to OpenC++. > > 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. That's a pity. Your input is very valuable, but we need people to do the real job. I am looking forward to see you contributing the code. > I assume that the "coding" should be done after a common agreement or > a decision by the project leaders. Sure. There are two project admins, Chiba and myself. Chiba is busy with more serious things and currently opts out from involvement in coding, so if you have "OK" from me and no objections from Chiba, then it counts as "decision by the project leaders". We have some democracy here also, if you post implementation idea on the list and nobody objects withing several days (the more revolutionary your idea, the more days you should wait), then you are safe to assume "common agreement". Apart of that we work in sandboxes, so there is no fear of breaking anything if you don't merge to MAIN. > Would anybody like to publish which software uses the OpenC++ tools? It would be useful to compile a list. Could you do this? I would love to post it on the website. > Are any related links useful? You mean you have related links or you are looking for related links? If the former, please post. If the latter, see Chiba's webpage. 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. # ################################################################## |
|
From: Shigeru C. <ch...@is...> - 2004-03-15 07:52:14
|
Dear all,
> My service can be code review at the moment.
That's a pity. Your input is very valuable, but we need people to do the
real job. I am looking forward to see you contributing the code.
I would like to suggest stopping this discussion. I think the review
by Markus is quite right but unfortunately it is not valuable to the
project unless we have human resources for implementing his ideas.
Without the human resources for implementation, I am afraid that the
review by Markus will only make other project members feel
uncomfortable. I think any experienced C++ programmer will be unhappy
if (s)he is treated as a C++ beginner and forced to hear basic C++
programming lessons.
Markus, I really thank you for your contributions to the project.
However, it might be just a time waste for you to further review the
code. I think it is much better for the open-source community that your
talent is used for other projects that have implementors but no
consultant.
Best regards,
Chiba
|
|
From: Grzegorz J. <ja...@he...> - 2004-03-16 00:52:40
|
On Mon, 15 Mar 2004, Shigeru Chiba wrote: > > Dear all, > > > My service can be code review at the moment. > > That's a pity. Your input is very valuable, but we need people to do the > real job. I am looking forward to see you contributing the code. > > I would like to suggest stopping this discussion. I think the review > by Markus is quite right but unfortunately it is not valuable to the > project unless we have human resources for implementing his ideas. I suggest moving this discussion off the list. I will discuss with Marcus the issues he brought and post a wrap-up here once we reach conclusions that are substantial to the project. [...] > I think any experienced C++ programmer will be unhappy > if (s)he is treated as a C++ beginner and forced to hear basic C++ > programming lessons. True. Best regards Grzegorz > > Markus, I really thank you for your contributions to the project. > However, it might be just a time waste for you to further review the > code. I think it is much better for the open-source community that your > talent is used for other projects that have implementors but no > consultant. > > Best regards, > > Chiba > > > > ------------------------------------------------------- > 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.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&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) 2004 Grzegorz Jakacki, HED. All Rights Reserved. # ################################################################## |
|
From: SF M. E. <el...@us...> - 2004-03-13 18:15:40
|
> 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 Will abstract base classes be available for them like it was discussed for "AbstractWalker"? > 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 derive such classes from an interface class like "http://boost.org/libs/utility/utility.htm#Class_noncopyable". I have not got detailed knowledge about your class library so far to decide where objects should not be copied. I hope that other developers are in a better position to do that. > 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. Value objects should not have any virtual methods. I suggest to look for missing virtual destructors in all classes that contain virtual methods. > 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. Would you like to use the methodology "http://en.wikipedia.org/wiki/Extreme_Programming" that is supported by the tool "http://www.xplanner.org/"? I suggest to use multiple inheritance in more cases. |
|
From: Grzegorz J. <ja...@he...> - 2004-03-15 03:10:27
|
On Sat, 13 Mar 2004, SF Markus Elfring wrote: > > 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 > > Will abstract base classes be available for them like it was discussed for "AbstractWalker"? Yes, if somebody finds time to implement it. > > 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 derive such classes from an interface class like > "http://boost.org/libs/utility/utility.htm#Class_noncopyable". That's a good idea, however somebody needs to do it. > I have not got detailed knowledge about your class library so far to > decide where objects should not be copied. I hope that other > developers are in a better position to do that. IMO this is wrong approach to collaborative open-source development. If you see something can be done better, go and make it better. Don't count on other people implementing your vision. Pointing out problems is not enough. We need action, talking alone is not going to move this project any further. > > 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 ^^^^^^^^^^ should be 'operator=()' > > 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. > > Value objects should not have any virtual methods. Agreed. > I suggest to look for missing virtual destructors in all classes that > contain virtual methods. I think this advice is not new to people on this list ("Effective C++" has it). If you want to help please post the exact locations. > > 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. > > Would you like to use the methodology > "http://en.wikipedia.org/wiki/Extreme_Programming" Some bits of it. In fact some bits we already use, e.g. automated regression testing. What I am trying to get working now is unit testing for parser. > that is supported > by the tool "http://www.xplanner.org/"? I don't know Xplanner (and I do not have time to learn it at the moment, sorry). > I suggest to use multiple inheritance in more cases. Where (I mean class names) and why? Thanks 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. # ################################################################## |
|
From: SF M. E. <el...@us...> - 2004-03-15 20:49:52
|
> > > My service can be code review at the moment. > > That's a pity. Your input is very valuable, but we need people to do the > > real job. I am looking forward to see you contributing the code. > [...] > However, it might be just a time waste for you to further review the > code. I think it is much better for the open-source community that your > talent is used for other projects that have implementors but no > consultant. I find slowly places where I would move from conceptional to practical contributions. I just ask several questions before I dig into an existing infrastructure. I hope that our discussion can help others to spot possibilities for participation, too. |
|
From: SF M. E. <el...@us...> - 2004-03-15 22:08:19
|
> > Please derive such classes from an interface class like > > "http://boost.org/libs/utility/utility.htm#Class_noncopyable". > > That's a good idea, however somebody needs to do it. I think that it would be easy to add this kind of derivation into header files. Is there an agreement which classes are good candidates and which class should be left untouched? |
|
From: SF M. E. <el...@us...> - 2004-03-16 17:23:48
|
> > 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"?
>
> These methods are not the same. Each of them has different implementation.
> How can you move them to a base class?
>
> Perhaps you mean moving the interface to separate base class, e.g.:
>
> class [whatever]
> {
> virtual int What() = 0;
> };
>
> is this what you mean?
Yes. Also: virtual int Translate() = 0;
Is this refacoring okay for you? Those classes can not be seen with "value semantics" after it.
|
|
From: Grzegorz J. <ja...@he...> - 2004-03-17 03:27:21
|
Let's move it off the list to private discussion.
BR
Grzegorz
On Tue, 16 Mar 2004, SF Markus Elfring wrote:
> > > 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"?
> >
> > These methods are not the same. Each of them has different implementation.
> > How can you move them to a base class?
> >
> > Perhaps you mean moving the interface to separate base class, e.g.:
> >
> > class [whatever]
> > {
> > virtual int What() = 0;
> > };
> >
> > is this what you mean?
>
> Yes. Also: virtual int Translate() = 0;
> Is this refacoring okay for you? Those classes can not be seen with "value semantics" after it.
>
>
>
> -------------------------------------------------------
> 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.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&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) 2004 Grzegorz Jakacki, HED. All Rights Reserved. #
##################################################################
|
|
From: Grzegorz J. <ja...@he...> - 2004-03-02 08:08:23
|
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. #
##################################################################
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X