Standard C++ design tools

Discussion in 'C++' started by Grizlyk, Jan 12, 2007.

  1. Grizlyk

    Grizlyk Guest

    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, Jan 12, 2007
    #1
    1. Advertising

  2. Grizlyk

    Grizlyk Guest

    Grizlyk, Jan 12, 2007
    #2
    1. Advertising

  3. Grizlyk

    Grizlyk Guest

    Maybe wrong group?
     
    Grizlyk, Jan 16, 2007
    #3
  4. On Jan 16, 9:38 am, "Grizlyk" <> wrote:
    > 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?

    --
    Erik Wikström
     
    =?iso-8859-1?q?Erik_Wikstr=F6m?=, Jan 16, 2007
    #4
  5. Grizlyk

    Grizlyk Guest

    Erik Wikström wrote:

    > 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?
     
    Grizlyk, Jan 16, 2007
    #5
  6. On Jan 16, 5:11 pm, "Grizlyk" <> wrote:
    > Erik Wikström wrote:
    > > 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?


    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.

    --
    Erik Wikström
     
    =?iso-8859-1?q?Erik_Wikstr=F6m?=, Jan 17, 2007
    #6
  7. Grizlyk

    Grizlyk Guest

    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_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?

    > > 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.
     
    Grizlyk, Jan 17, 2007
    #7
  8. Grizlyk

    red floyd Guest

    Grizlyk wrote:
    >
    > (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.
     
    red floyd, Jan 17, 2007
    #8
  9. Grizlyk

    Grizlyk Guest

    red floyd wrote:

    > > How translate them into C++ classes?

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


    Very interesting, shure, my grandfather could be happy, if he was alive.
     
    Grizlyk, Jan 19, 2007
    #9
  10. Grizlyk

    Ian Collins Guest

    Grizlyk wrote:
    > red floyd wrote:
    >
    >
    >>>How translate them into C++ classes?

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

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

    --
    Ian Collins.
     
    Ian Collins, Jan 19, 2007
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Namratha Shah \(Nasha\)
    Replies:
    0
    Views:
    613
    Namratha Shah \(Nasha\)
    Nov 23, 2004
  2. Namratha Shah \(Nasha\)

    Article : Security Tools Part -- 2 (.Net FrameWork Tools Series)

    Namratha Shah \(Nasha\), Nov 23, 2004, in forum: ASP .Net Datagrid Control
    Replies:
    0
    Views:
    207
    Namratha Shah \(Nasha\)
    Nov 23, 2004
  3. Namratha Shah \(Nasha\)

    Article : Security Tools Part -- 2 (.Net FrameWork Tools Series)

    Namratha Shah \(Nasha\), Nov 23, 2004, in forum: ASP .Net Mobile
    Replies:
    0
    Views:
    200
    Namratha Shah \(Nasha\)
    Nov 23, 2004
  4. Namratha Shah \(Nasha\)

    Article : Security Tools Part -- 2 (.Net FrameWork Tools Series)

    Namratha Shah \(Nasha\), Nov 23, 2004, in forum: ASP .Net Security
    Replies:
    0
    Views:
    219
    Namratha Shah \(Nasha\)
    Nov 23, 2004
  5. martinig
    Replies:
    0
    Views:
    190
    martinig
    Jul 2, 2007
Loading...

Share This Page