Erik Wikström wrote:
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).
(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?
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.
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.
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?
Class description is ordinary C++ class declaration, like this:
[q]
/**
* @brief Part of std::numeric_li mits.
*
* 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_li mits class.
*/
struct __numeric_limit s_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_N aN = false;
/** See std::float_deno rm_style for more information. */
static const float_denorm_st yle 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_roun d_style for more information. This is only
meaningful for floating types; integer types will all be
round_toward_ze ro. */
static const float_round_sty le round_style = round_toward_ze ro;
};
[/q]
"design, from a class-diagram"
who will create class diagram from the example of class declaration?
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.
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".
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#?
"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.
