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

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

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