Standard C++ design tools

[Grizlyk]

Somebody have offered std colors to C++ in the msg here:
http://groups.google.com/group/comp...3d36ece543b/1acf6cd7e3ebdbcd#1acf6cd7e3ebdbcd


The main objection to the including "colors markup" is useless of the
marks, the marks is unneccessary extra information. The most used way
to make colored view of C++ programs is usage of classes of C++
language words (already included in C++): reserved words, user
identificators, operators, and so on.

Do you wish to have special color for each letter of program? Why?

It is evidently, C++ has another trouble.

1.

I think, the cause of the trouble, that when we have very many classes,
the interfaces of the classes and the links between the classes already
looks as _raw_ and _plain_ as, for example, implementation of all
functions in structured C program.

It is hardly possible to write C++ programs only with the help of
"free-standing" classes.

C++ is really weak for OO design, not for colors. C++ has no one design
tool or std features to help to build the tools.

OO design includes consideration of any task on conceptual level and on
"level of logical interfaces/behaviour" (specifications? - do not know
english term).

I think C++ must declare interface between design tools (UML for
example) and tools for compiling (ordinary files for example).

Look at the screenshot here: http://educh.chat.ru/pre/cpp/smtr.gif

This is smalltalk simplest design tool. You can see interface of
desired
class, tree of inheritance, description and implementation for any
desired
method of the selectted class. It can be implemented even on PC/XT.

I think, C++ must offer _standard_ way to convert ordinary class
declaration to standard "class items" - items of interface of design
(placed in each subwindow on the picture) and to convert back.

That is why C++ must
1. define std "class items" (items of interface of design)
2. and declare rules how to inlude them to ordinary C++ class
declaration.

It is easy to see, that building of any C++ module (ordinary C++ source
file)
is similar to preprocessing from "class items".

The "class items" marks (design information) is not extra information
(as colors do),
the information no need for compiling so is absent in C++ now.

It seems to me, the Stroustrup does not hurry to be going to be keen on
the idea of std design information.

 

[Grizlyk]

Look at the screenshot here: http://educh.chat.ru/pre/cpp/smtr.gif

Link updated.

 

[Grizlyk]

Maybe wrong group?

 

[=?iso-8859-1?q?Erik_Wikstr=F6m?=]

Maybe wrong group?

One problem might be that few of us understand Russian(?) so that
screen-shot does not mean much to us. As for the rest I'm afraid that I
don't quite understand what you mean. Do you want a tool to convert
UML-diagrams to code or do you want to add some kind of new modelling?

 

[Grizlyk]

One problem might be that few of us understand Russian(?) so that
screen-shot does not mean much to us.

Sorry, boys and girls, I have no another smalltalk, but it is easy
understand:
1. big blue window in center of screen is workshop for work with
classes
2. left up coner of the window is tree of classes soeted by inheritance
3. right up coner of the window is _inferface_ of selected class
4. center below is implementation of selected method of _inferface_ of
selected class or class description

As for the rest I'm afraid that I
don't quite understand what you mean. Do you want a tool to convert
UML-diagrams to code or do you want to add some kind of new modelling?

No, not exactly.

1.
It is intresting to me - how do you work with classes when you are
starting implementation of new job?


2.
I wrote:
I think, that when we have very many classes (befor new job), the
interfaces of the classes and the links between the already existing
classes looks as _raw_ and _plain_ as, for example, implementation of
all functions in structured C program.

Are you agree?

3.
The ordinary C++ class description hardly can be used _for design_,
when you are working with logic of interfaces of classes.

Are you agree?

4.
The picture is simplest kind of tool (implemented for MSDOS/AT-286),
that allows not only work with logic of interfaces of existing classes
on design stage, but allows quick switching between class interface and
inplementation of each method.

It is very useful. Are you agree?

5.
Why C++ can not allow standard "design with C++" or at least standard
inferface for external tools for "design with C++"? What is not enough
in C++, what kind of information must be added?

What do you think?

 

[=?iso-8859-1?q?Erik_Wikstr=F6m?=]

understand:
1. big blue window in center of screen is workshop for work with
classes
2. left up coner of the window is tree of classes soeted by inheritance
3. right up coner of the window is _inferface_ of selected class
4. center below is implementation of selected method of _inferface_ of
selected class or class description


1.
It is intresting to me - how do you work with classes when you are
starting implementation of new job?

If I start from scratch I think it's a good idea to model the program
using a couple of class diagrams and perhaps some interaction diagrams
(unless the program is small, trivial or some such).

2.
I wrote:I think, that when we have very many classes (befor new job), the
interfaces of the classes and the links between the already existing
classes looks as _raw_ and _plain_ as, for example, implementation of
all functions in structured C program.

Are you agree?

No, I can usually use programs like doxygen to generate documentation
about which classes exists, what interfaces they have and how they
interact. I suppose you can find similar tools for C (generating
call-graphs) but I don't know of any.

3.
The ordinary C++ class description hardly can be used _for design_,
when you are working with logic of interfaces of classes.

Are you agree?

What do you mean by description? I think of the declaration of classes
as the description, this is usually put in the header-file. What do you
mean by design, from a class-diagram it's possible to generate all
header-files for an application. And last, what do you mean by logic of
interfaces and classes?

4.
The picture is simplest kind of tool (implemented for MSDOS/AT-286),
that allows not only work with logic of interfaces of existing classes
on design stage, but allows quick switching between class interface and
inplementation of each method.

It is very useful. Are you agree?

Again, I'm not sure what you mean by logic of interfaces, do you mean
the process of determining how the interfaces of the classes should
look like (which methods exists, what they return/take as parameters,
what their visibility are (private/public))? These kind of things there
are often wizards or such that can do, or applications that can
generate code from UML-diagrams.

5.
Why C++ can not allow standard "design with C++" or at least standard
inferface for external tools for "design with C++"? What is not enough
in C++, what kind of information must be added?

What is 'design withC++'? I don't personally think that there is
something missing from C++ (at least not the kind of things that you
are referring to), either the information is expressed explicit in the
code or it can be added in comments. As many have said, good code is
self documenting so with a good design the needs for comments are less.
Are you perhaps referring to the XML-tags in C#?

I'm not sure I understand what it is you are after, sorry about that.

 

[Grizlyk]

If I start from scratch I think it's a good idea to model the program
using a couple of class diagrams and perhaps some interaction diagrams
(unless the program is small, trivial or some such).

(do not answer befor read all message)
In which places (tools) are you working with the models and diagrams?
What are the goals of using of them - what is result?
How translate them into C++ classes?
How many projects you started and compelted with the tools?
Was the help of the tools noticable?

No, I can usually use programs like doxygen to generate documentation
about which classes exists, what interfaces they have and how they
interact. I suppose you can find similar tools for C (generating
call-graphs) but I don't know of any.

I do not understand. There are set of already defined and debugged
classes with complex interfaces and complex behaviour. Does "doxygen"
generate from them classes of you concrete job? of course no.

Your job at the point - to understand all interfaces of the alredy
existed classes, in order to use them in your concrete program.

What do you mean by description? I think of the declaration of classes
as the description, this is usually put in the header-file. What do you
mean by design, from a class-diagram it's possible to generate all
header-files for an application. And last, what do you mean by logic of
interfaces and classes?

Class description is ordinary C++ class declaration, like this:
[q]
/**
* @brief Part of std::numeric_limits.
*
* The @c static @c const members are usable as integral constant
* expressions.
*
* @note This is a seperate class for purposes of efficiency; you
* should only access these members as part of an
instantiation
* of the std::numeric_limits class.
*/
struct __numeric_limits_base
{
/** This will be true for all fundamental types (which have
specializations), and false for everything else. */
static const bool is_specialized = false;

/** The number of @c radix digits that be represented without
change: for
integer types, the number of non-sign bits in the mantissa; for
floating types, the number of @c radix digits in the mantissa.
*/
static const int digits = 0;
/** The number of base 10 digits that can be represented without
change. */
static const int digits10 = 0;
/** True if the type is signed. */
static const bool is_signed = false;
/** True if the type is integer.
* @if maint
* Is this supposed to be "if the type is integral"?
* @endif
*/
static const bool is_integer = false;
/** True if the type uses an exact representation. "All integer
types are
exact, but not all exact types are integer. For example,
rational and
fixed-exponent representations are exact but not integer."
[18.2.1.2]/15 */
static const bool is_exact = false;
/** For integer types, specifies the base of the representation.
For
floating types, specifies the base of the exponent
representation. */
static const int radix = 0;

/** The minimum negative integer such that @c radix raised to the
power of
(one less than that integer) is a normalized floating point
number. */
static const int min_exponent = 0;
/** The minimum negative integer such that 10 raised to that power
is in
the range of normalized floating point numbers. */
static const int min_exponent10 = 0;
/** The maximum positive integer such that @c radix raised to the
power of
(one less than that integer) is a representable finite floating
point
number. */
static const int max_exponent = 0;
/** The maximum positive integer such that 10 raised to that power
is in
the range of representable finite floating point numbers. */
static const int max_exponent10 = 0;

/** True if the type has a representation for positive infinity.
*/
static const bool has_infinity = false;
/** True if the type has a representation for a quiet
(non-signaling)
"Not a Number." */
static const bool has_quiet_NaN = false;
/** True if the type has a representation for a signaling
"Not a Number." */
static const bool has_signaling_NaN = false;
/** See std::float_denorm_style for more information. */
static const float_denorm_style has_denorm = denorm_absent;
/** "True if loss of accuracy is detected as a denormalization
loss,
rather than as an inexact result." [18.2.1.2]/42 */
static const bool has_denorm_loss = false;

/** True if-and-only-if the type adheres to the IEC 559 standard,
also
known as IEEE 754. (Only makes sense for floating point
types.) */
static const bool is_iec559 = false;
/** "True if the set of values representable by the type is finite.
All
built-in types are bounded, this member would be false for
arbitrary
precision types." [18.2.1.2]/54 */
static const bool is_bounded = false;
/** True if the type is @e modulo, that is, if it is possible to
add two
positive numbers and have a result that wraps around to a third
number
that is less. Typically false for floating types, true for
unsigned
integers, and true for signed integers. */
static const bool is_modulo = false;

/** True if trapping is implemented for this type. */
static const bool traps = false;
/** True if tinyness is detected before rounding. (see IEC 559)
*/
static const bool tinyness_before = false;
/** See std::float_round_style for more information. This is only
meaningful for floating types; integer types will all be
round_toward_zero. */
static const float_round_style round_style = round_toward_zero;
};
[/q]

"design, from a class-diagram"
who will create class diagram from the example of class declaration?

Again, I'm not sure what you mean by logic of interfaces, do you mean
the process of determining how the interfaces of the classes should
look like (which methods exists, what they return/take as parameters,
what their visibility are (private/public))? These kind of things there
are often wizards or such that can do, or applications that can
generate code from UML-diagrams.

Yes. "Process of determining how the interfaces of the classes should
look like"

applications that can generate code from UML-diagrams.

Excelent.
But C++ do not have std applications, even to generate code from UML
diagram, and can not generate back to diagram. UML diagram has no
primitive as "item of C++ class".

In real life, all UML tools I have seen, is something abstracted from
C++ and your, instead of "abstracted from problem of the project". You
can not work with interfaces, after diagram have generated, but you can
not define the diagrams, befor working with generated code, in other
words, work with interfaces is iterated process, you need quickly
switch from UML diagram to code and back, but you no need compile at
the point.

Abstracted tools working with abstracted UML diagram can be useful, but
often looks like "hot and clean professional sand for your desert".

What is 'design withC++'? I don't personally think that there is
something missing from C++ (at least not the kind of things that you
are referring to), either the information is expressed explicit in the
code or it can be added in comments. As many have said, good code is
self documenting so with a good design the needs for comments are less.
Are you perhaps referring to the XML-tags in C#?

"What is 'design withC++'?"
The design with C++ is ordinary object-oriented design, close related
to C++, working with pieces of C++ specipfic OO items and integrating
all stages of desing and coding, exclude compiling, running and
debugging output.

 

[red floyd]

(do not answer befor read all message)
In which places (tools) are you working with the models and diagrams?

Who says he's using electronic tools? I often use pencil and paper, or
a whiteboard.

What are the goals of using of them - what is result?

The goals are a better understanding of *what* I'm trying to do, and how
I'm going to do it. Ideally this is also the result.

How translate them into C++ classes?

Manually, for pencil&paper/whiteboard. Tool specific if electronic.

 

[Grizlyk]

Manually, for pencil&paper/whiteboard. Tool specific if electronic.

Very interesting, shure, my grandfather could be happy, if he was alive.

 

[Ian Collins]

red floyd wrote:




Very interesting, shure, my grandfather could be happy, if he was alive.

I've yet to see any 'tool' that that makes a decent job of generating
code from diagrams. I'm sure that level of abstraction will be along soon.

Even if I did, I wouldn't use it for the simple reason that I code test
first and generated unit tests are worse than useless.