[Corelinux-public] Feedback

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

I received this yesterday. There are some points that merit close
evaluation. I have followed this post with my return statement to the
author. Hopefully, he will be joining this mailing list. 

------------- Orignal Post
----------------------------------------------

Hi,

I've been having a look at the CoreLinux++ homepage, have read the docs
you have so far created and looked at the source (via anon CVS).

This looks like an interesting project !

A while ago I noticed a group of developers starting a similar project,
called LCL. Unfortunately, they didn't seem to understand some basic
concepts, and had gone down the all-too-common route of coding first,
thinking second.

One thing I couldn't get across to the LCL people was that a 'tree'
class
structure is entirely inappropriate for the design. They didn't even
understand what I meant when I mentioned shared data.

It looks like you've already had a good think about coding standards,
code layout, etc. and also laid down some sensible guidelines for
design.

My background is that I completed a BSc in Comp. Sci. a few years back.
Since then I've worked as an UNIX admin, and then started learning C++
'properly' - i.e. not in an academic setting. It's taken about a year,
but I'm now well used to writing software for the real world. Recently
I started working as a contractor, writing Qt software from home, for
cash :)

I have some knowledge of Rational Rose and the Booch method, from my
days at uni. I'm afraid I haven't got around to reading the much-vaunted
book 'Design Patterns' which seems very trendy these days. My knowledge
is mostly self-taught and helped along by working with the Qt library
for the last year.

You will find I'm very keen on the design of Qt. If you look at recent
versions (2.0 onwards), you'll see that it provides a kind of template
library of its own, often dubbed the 'QTL'. This subset of Qt is best
described as STL, without the least-used classes, and with extra, more
useful features added.

QTL is obviously not as fast as STL, as it's designed to work
cross-platform,
on most Unices and on MS Windows; however, despite its incompleteness
(it doesn't have classes like 'set') and the slight speed disadvantage,
its design and usability is IMO second to none.

Perhaps the greatest advantages of QTL are QString, a 16-bit Unicode
string class, the value-based collections and the widespread use of
both explicit- and implicit- shared data.

I'm not entirely sure what the aim of your project is.

Are you looking to replace libg++ with a better library ?

Or are you attempting to provide a C++ version of libc, with socket and
thread wrappers, etc ?

Or... ?

I'm quite interested in getting involved.

While I'm currently very busy finishing off a contract and working
on some code for the upcoming KDE release (on the 15th), I'll have
plenty
of free time over the new year period.

Cheers,
Rik

p.s. Some topics I'd like to throw on the table for discussion.

---------------------------------------------------------------------------

You have specified that inspector methods should use the 'get' prefix.
While I'm a big fan of Java, I find that this prefix is generally
redundant and makes code more cluttered and less clear.

For example,

list.count();
list.getCount();

Which is more appropriate ?

---------------------------------------------------------------------------

In the coding standards doc, you seem to suggest that const references
may be returned. Considering that the const can be cast away, would it
not be wiser to return by value (assuming the return type is
copy-on-write
or has a trivial ctor), or to return via a reference parameter ?

This was suggested to me by someone else some time ago. He said that
it is possible that while it is expected that the returned reference
is safe, it may still be messed with, so unless you have complete
control
over your code (something you don't when writing a library) it's
dangerous.

I haven't had any problems with this myself, but I understand the
reasoning
and can see that if the scenario was to appear, debugging the references
would be a nightmare.

---------------------------------------------------------------------------

Have you considered the use of copy-on-write semantics ? Am I just being
premature, and this simply hasn't been written into the standards/code
yet ?

In my experience, copy-on-write coupled with value-based semantics
provide
for clean, safe user code. Pointers can be avoided more easily and
memory
leaks can be made practically extinct.

This also allows the use of value-based collections...

---------------------------------------------------------------------------

Value-based collections are useful for classes that implement a fast
copy ctor.

Example:

ValueList<int> intList;
intList << 1 << 2 << 3 << 4 << 5;

ValueList<int>::ConstIterator it;

for (it = intList.begin(); it != intList.end(); ++it)
  cout << *it << endl;

No pointers, no [a|de]llocation, no mess :)

If the list is implicit shared, then copy is done in O(1) - quite handy
:)

---------------------------------------------------------------------------

I can see that you're keen to take full advantage of Linux' capabilities
-
well, the name gives that away ;)

How far do you propose to take this ? I have written some code in the
past that takes advantages of the extra capabilities of gcc, i.e. C and
C++ extensions. There is, of course, the possibility that people will
use a different compiler on Linux in the future - are you going to
take this into consideration and write code without gcc extensions ?

Personally I think that it will be a long time before anyone wants to
replace gcc, and that corelinux++ could still take advantage of
gcc features without requiring gcc.

For example, constructs such as this:

  MyString
MyClass::myMethod() return str;
{
  str = "hello";
}

Using the above in .cpp files is ok if you are compiling the library
with gcc. The declaration is as normal - no 'return something' added,
so other compilers won't have a problem compiling code written in
this way.

I'm not entirely sure, but I think that if libcorelinux++ is compiled
with gcc and another compiler is used to write software, linking
won't work due to different name mangling. If extensions such as the
above are used in the implementation, then another compiler may be
unable to compile libcorelinux++, so a user couldn't even create their
own libcorelinux++ to use with their own compiler.

So, is this something you have considered ? Will you be writing in
ANSI C++ only ? Forgive me if I missed this in your docs. I noticed
in the changelog 'Changed all code to conform to the update C++
Standards
and Guidelines Revision 1.2 document.' but I haven't seen anything about
using gcc extensions.

-------------- Partial Original with my response -------------------


> [snip]
> 
> I have some knowledge of Rational Rose and the Booch method, from my
> days at uni. I'm afraid I haven't got around to reading the much-vaunted
> book 'Design Patterns' which seems very trendy these days. My knowledge
> is mostly self-taught and helped along by working with the Qt library
> for the last year.

We are pushing for UML as the standard notation for analysis and design,
shouldn't be to hard to pick up unless you meant recent Rose, in which
case I will assume you are familiar (tell me otherwise and we can get
into the differences between Booch notation).

> You will find I'm very keen on the design of Qt. If you look at recent
> versions (2.0 onwards), you'll see that it provides a kind of template
> library of its own, often dubbed the 'QTL'. This subset of Qt is best
> described as STL, without the least-used classes, and with extra, more
> useful features added.

I must admit, I haven't taken a long enough look to consider myself
familiar. I have 1.44 and 2.? installed. I will familiarize myself with
it.

> QTL is obviously not as fast as STL, as it's designed to work cross-platform,
> on most Unices and on MS Windows; however, despite its incompleteness
> (it doesn't have classes like 'set') and the slight speed disadvantage,
> its design and usability is IMO second to none.

Whereas STL is cross-platform and has the speed. Could you elaborate on
the QT advantage?

> Perhaps the greatest advantages of QTL are QString, a 16-bit Unicode
> string class, the value-based collections and the widespread use of
> both explicit- and implicit- shared data.

That I did notice. Did you also look at the IBM Unicode implementation?

> I'm not entirely sure what the aim of your project is.
> 
> Are you looking to replace libg++ with a better library ?

Well, err...

> Or are you attempting to provide a C++ version of libc, with socket and
> thread wrappers, etc ?

Hang in there it's coming...

> 
> Or... ?


Part I
------
The overall objective here is to provide common classes abstractions,
and at least the Gang Of Four (Gamma et.al) patterns, if at a minimal
abstraction for later building blocks.

To do this we SHOULD and WILL:

A. Gather requirements. There is a Requirements forum on the CoreLinux
project page and I just started a mailing list which I will detail at
the end of this message.

B. Perform the proper analysis which brings out all those thing the
requirements did not specify, re-iterate.

C. Design the above, re-iterating to Analysis and Requirements as
needed.

D. Prioritize the implementation of the design. 

E. Implement

F. Go to A 

Part II
-------
The overall objective here is to begin construction of frameworks
(again, those recognized as common) to work with the objects implemented
in libcorelinux++ and extending where appropriate. We will follow the
same process detailed in Part I.

As you well know (or are picking up as your experience with C++
continues) there is very little real Object Oriented class libraries for
Linux. Hear me out if I raised a few hackles. What is available now
specifically for Linux are either quick ports of the traditional C work,
almost a "see I can do this" attempt, class libraries that are
encumbered by the desire to be portable to Windows, OS/2, etc. etc. etc.
(which by definition are NOT specific to Linux). 

But, what is even more important is the LACK of Open Source class
libraries that reflect both real world abstractions and the ability to
be useful. I refer strongly to Patterns and Frameworks as there is no
cohesivness<sp> between development efforts. Now I will admit that I
haven't perused every available library or framework that IS available,
but I have seen enough. Help me here if I am missing something.

> ---------------------------------------------------------------------------
> 
> You have specified that inspector methods should use the 'get' prefix.
> While I'm a big fan of Java, I find that this prefix is generally
> redundant and makes code more cluttered and less clear.
> 
> For example,
> 
> list.count();
> list.getCount();
> 
> Which is more appropriate ?

This is a loaded gun. I need to tell you about my background:

1982 - MVS using BAL (assembler for the mainframe)
1983 - PL1 (kinda Fortran and COBOL mix)
1985 - x86 assembler
1987 - C with some C with classes
1989 - C++ 

At which point I became a consultant on large scale system
implementations on primarily x86 and OS/2 systems. Part time I wrote a
performance analysis and capacity planning system for OS/2 (Osrm2).

Projects ranging from Speech recognition systems to Databases, Fuzzy
logic to Knowledge Representation and Constraint Logic.

Enough of which to know that with a development group larger than 1
there are communication problems. The last place that any effort can
afford to have communication problems are in the CODE!!! Now granted,
these projects move on and the hired guns to maintain them are usually
of less experience than the architects and original teams that
implemented them. The costs of maintenance grows exponentially if there
is a complete education required to bring them up to speed on ambiguous
terminology, I wouldn't want to foot the bill. I have bore witness and
even recommended that entire systems be re-written because the grammar
wasn't even CLOSE to the problem domain.

And I think that is what part of the effort is about: Recognize the
problem domain through the clutter is half the battle. Making it so that
others that follow have the same clarity is the other half.

I would opt for the latter (list.getCount()). BTW: It had really nothing
to do with Java (although I think it is useful there as well) but with
my understanding of the methodologies I weaned on (Rumbaugh, Booch,
Coad).

Still, I am willing to state that even though I feel strongly about this
I also believe in more minds than mine arriving at a sensible path or
direction. The standards I put up were in part straw-man to that effect.
I think you should bring this up in the mailing list, if you are still
even reading this...

> ---------------------------------------------------------------------------
> 
> In the coding standards doc, you seem to suggest that const references
> may be returned. Considering that the const can be cast away, would it
> not be wiser to return by value (assuming the return type is copy-on-write
> or has a trivial ctor), or to return via a reference parameter ?
> 
> This was suggested to me by someone else some time ago. He said that
> it is possible that while it is expected that the returned reference
> is safe, it may still be messed with, so unless you have complete control
> over your code (something you don't when writing a library) it's dangerous.
> 
> I haven't had any problems with this myself, but I understand the reasoning
> and can see that if the scenario was to appear, debugging the references
> would be a nightmare.

I agree that const can be casted away. But I also know there is some
protection in invarient state management and enforcement. I have used
it, it has worked to some degree but it is not a silver bullet. You only
need to change the header file to the class library you are linking with
and remove the const from the grammar!
 
> ---------------------------------------------------------------------------
> 
> Have you considered the use of copy-on-write semantics ? Am I just being
> premature, and this simply hasn't been written into the standards/code
> yet ?

Copy on write is a good thing. I believe the analysis and design will
bring out where it is appropriate.

> In my experience, copy-on-write coupled with value-based semantics provide
> for clean, safe user code. Pointers can be avoided more easily and memory
> leaks can be made practically extinct.
> 
> This also allows the use of value-based collections...
> 
> ---------------------------------------------------------------------------
> 
> Value-based collections are useful for classes that implement a fast
> copy ctor.
> 
> Example:
> 
> ValueList<int> intList;
> intList << 1 << 2 << 3 << 4 << 5;
> 
> ValueList<int>::ConstIterator it;
> 
> for (it = intList.begin(); it != intList.end(); ++it)
>   cout << *it << endl;
> 
> No pointers, no [a|de]llocation, no mess :)
> 
> If the list is implicit shared, then copy is done in O(1) - quite handy :)

This works for atomics but what about aggregates? What about objects
that the semantics require uniqueness in the domain? Again, this is one
area I am playing devils advocate from experience. In addition, we have
a requirement for SmartPointers, which I have alot of experience with.

> ---------------------------------------------------------------------------
> 
> I can see that you're keen to take full advantage of Linux' capabilities -
> well, the name gives that away ;)
> 
> How far do you propose to take this ? I have written some code in the
> past that takes advantages of the extra capabilities of gcc, i.e. C and
> C++ extensions. There is, of course, the possibility that people will
> use a different compiler on Linux in the future - are you going to
> take this into consideration and write code without gcc extensions ?

> Personally I think that it will be a long time before anyone wants to
> replace gcc, and that corelinux++ could still take advantage of
> gcc features without requiring gcc.
> 

The portability goals of CoreLinux would be across Linux implementations
and compilers that work under Linux. It presents a distribution issue
that we will have to face, but needless to say I suggest we stay well
clear of any specific compiler tricks or extensions. I don't think we
need them, but we haven't advanced far enough along to say either way.

> I'm not entirely sure, but I think that if libcorelinux++ is compiled
> with gcc and another compiler is used to write software, linking
> won't work due to different name mangling. If extensions such as the
> above are used in the implementation, then another compiler may be
> unable to compile libcorelinux++, so a user couldn't even create their
> own libcorelinux++ to use with their own compiler.

I would rather they can compile with the compiler of their choice. If we
want to have a single binary distribution we would have no choice but to
look to CORBA and remain independant. This is more overhead than is
desired.
 
> So, is this something you have considered ? Will you be writing in
> ANSI C++ only ? Forgive me if I missed this in your docs. I noticed
> in the changelog 'Changed all code to conform to the update C++ Standards
> and Guidelines Revision 1.2 document.' but I haven't seen anything about
> using gcc extensions.

Yes, I am checking everything we have gone near (which isn't much yet)
against the ISO C++ 14882 (1998E) standard. That is the conformance we
SHOULD aim for. The Revision 1.2 refered to the CoreLinux++ C++
document, not the ISO.

-------- End of response -------------------------------------