Class design issue

Discussion in 'C++' started by crea, Mar 3, 2011.

  1. crea

    crea Guest

    Lets say we are programming a wheather data analysing and display program
    (of course using VC!).

    We have already classes:
    - CChart, which draws wheather data
    - CWheather, which contains wheather data and all the functions regarding
    analysing data. So this data (it contains the data) can be passed to CChart
    to draw it.

    Now we want combine these two to draw a chart with data in it. Is it better
    to create a new class which inherits from them like this:

    1)
    class CWheatherChart : public CChart, public CWheather
    {
    ....
    };

    or create a class which inludes them as members like this:

    2)
    class CWheatherChart
    {
    CChart m_Chart;
    CWheather m_Wheather;
    ....
    };

    (The point is, that later on we can create specific classes for example to
    moon-wheather , earth wheather, summer wheather... etc. which are inherited
    from CWheatherChart:

    class CMoonWheatherChart : public CWheatherChart)

    These two classes must communicate with eatch others sometimes as doing
    steps, like when the chart draws a certain data value (x,y) it might ask
    something from CWheather class in the middle of its drawing. So using the
    design 1) we could use virtual functions to handle this (having virtual
    function for data draw in CChart and then have also it on CWheatherChart ).

    Which way is better? I guess 1) makes things a bit easier to program (can
    use virtual functions to communicate between CChart and CWheather ), but on
    the other hand 2) gives possibility to change easily chart or data on the
    fly.
     
    crea, Mar 3, 2011
    #1
    1. Advertising

  2. On 3/3/2011 7:43 AM, crea wrote:
    > Lets say we are programming a wheather data analysing and display program
    > (of course using VC!).
    >
    > We have already classes:
    > - CChart, which draws wheather data
    > - CWheather, which contains wheather data and all the functions regarding
    > analysing data. So this data (it contains the data) can be passed to CChart
    > to draw it.


    BTW, the English word 'weather' does not have the 'h' following 'w'...

    >
    > Now we want combine these two to draw a chart with data in it. Is it better
    > to create a new class which inherits from them like this:
    >
    > 1)
    > class CWheatherChart : public CChart, public CWheather
    > {
    > ...
    > };
    >
    > or create a class which inludes them as members like this:
    >
    > 2)
    > class CWheatherChart
    > {
    > CChart m_Chart;
    > CWheather m_Wheather;
    > ...
    > };
    >
    > (The point is, that later on we can create specific classes for example to
    > moon-wheather , earth wheather, summer wheather... etc. which are inherited
    > from CWheatherChart:
    >
    > class CMoonWheatherChart : public CWheatherChart)
    >
    > These two classes must communicate with eatch others sometimes as doing
    > steps, like when the chart draws a certain data value (x,y) it might ask
    > something from CWheather class in the middle of its drawing. So using the
    > design 1) we could use virtual functions to handle this (having virtual
    > function for data draw in CChart and then have also it on CWheatherChart ).
    >
    > Which way is better? I guess 1) makes things a bit easier to program (can
    > use virtual functions to communicate between CChart and CWheather ), but on
    > the other hand 2) gives possibility to change easily chart or data on the
    > fly.


    First off, both 1) and 2) provide the changeability of 'CChart' and
    'CWheather' part, since, technically speaking, they are contained within
    your 'CWheatherChart' in either case.

    Public inheritance has the additional perk - the possibility to use your
    derived class where the base class is expected - LSP (look it up). The
    containment does not have that.

    You have not provided any detailed explanation on how your classes are
    going to be used, and *only that* should drive the design.

    Also, post to 'comp.object' to learn more about OOD.

    V
    --
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Mar 3, 2011
    #2
    1. Advertising

  3. crea

    crea Guest

    Victor Bazarov wrote:
    > Also, post to 'comp.object' to learn more about OOD.
    >
    > V


    I continue there..
     
    crea, Mar 3, 2011
    #3
  4. * crea, on 03.03.2011 13:43:
    > Lets say we are programming a wheather data analysing and display program
    > (of course using VC!).
    >
    > We have already classes:
    > - CChart, which draws wheather data
    > - CWheather, which contains wheather data and all the functions regarding
    > analysing data. So this data (it contains the data) can be passed to CChart
    > to draw it.


    Presumably[1] the "C" signifies "Constant"?


    > Now we want combine these two to draw a chart with data in it. Is it better
    > to create a new class which inherits from them like this:
    >
    > 1)
    > class CWheatherChart : public CChart, public CWheather
    > {
    > ...
    > };
    >
    > or create a class which inludes them as members like this:
    >
    > 2)
    > class CWheatherChart
    > {
    > CChart m_Chart;
    > CWheather m_Wheather;
    > ...
    > };


    No.

    In the first case you are saying that a constant weather chart is a constant
    weather. That doesn't make sense to me. In the second case you are copy a
    constant weather to each constant weather chart, and that doesn't make much
    sense (although it might, if your weathers are really small weathers).

    Anyway, define your notion of "better".


    > (The point is, that later on we can create specific classes for example to
    > moon-wheather , earth wheather, summer wheather... etc. which are inherited
    > from CWheatherChart:
    >
    > class CMoonWheatherChart : public CWheatherChart)
    >
    > These two classes must communicate with eatch others


    Well, tehcnically classes don't communicate: instances of them may communicate.


    > sometimes as doing
    > steps, like when the chart draws a certain data value (x,y) it might ask
    > something from CWheather class in the middle of its drawing. So using the
    > design 1) we could use virtual functions to handle this (having virtual
    > function for data draw in CChart and then have also it on CWheatherChart ).




    > Which way is better? I guess 1) makes things a bit easier to program (can
    > use virtual functions to communicate between CChart and CWheather ), but on
    > the other hand 2) gives possibility to change easily chart or data on the
    > fly.


    Define resposibilities, put knowledge where it's needed, remember that
    indirection is the solution to any computer science problem.

    Cheers & hth.,

    - Alf


    Notes:
    [1] I'm discounting the low-probability possibility that you're mindlessly
    copying the meaningless and counter-productive Microsoft convention of appending
    a misleading and meaningless prefix to every name.

    --
    blog at <url: http://alfps.wordpress.com>
     
    Alf P. Steinbach /Usenet, Mar 3, 2011
    #4
  5. crea

    crea Guest

    Alf P. Steinbach /Usenet wrote:
    > * crea, on 03.03.2011 13:43:
    >> Lets say we are programming a wheather data analysing and display
    >> program (of course using VC!).
    >>
    >> We have already classes:
    >> - CChart, which draws wheather data
    >> - CWheather, which contains wheather data and all the functions
    >> regarding analysing data. So this data (it contains the data) can be
    >> passed to CChart to draw it.

    >
    > Presumably[1] the "C" signifies "Constant"?
    >


    No, it means "class" (CWheather = "class Wheather"). They are 2 normal
    classes...
     
    crea, Mar 3, 2011
    #5
  6. On 3/3/2011 9:27 AM, crea wrote:
    > Alf P. Steinbach /Usenet wrote:
    >> * crea, on 03.03.2011 13:43:
    >>> Lets say we are programming a wheather data analysing and display
    >>> program (of course using VC!).
    >>>
    >>> We have already classes:
    >>> - CChart, which draws wheather data
    >>> - CWheather, which contains wheather data and all the functions
    >>> regarding analysing data. So this data (it contains the data) can be
    >>> passed to CChart to draw it.

    >>
    >> Presumably[1] the "C" signifies "Constant"?
    >>

    >
    > No, it means "class" (CWheather = "class Wheather"). They are 2 normal
    > classes...


    Alf was teasing you (see his footnote). Microsoft's habit of putting
    'C' in front of all their classes is surely contagious, isn't it?

    V
    --
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Mar 3, 2011
    #6
  7. crea

    crea Guest

    Victor Bazarov wrote:
    > On 3/3/2011 9:27 AM, crea wrote:
    >> Alf P. Steinbach /Usenet wrote:
    >>> * crea, on 03.03.2011 13:43:
    >>>> Lets say we are programming a wheather data analysing and display
    >>>> program (of course using VC!).
    >>>>
    >>>> We have already classes:
    >>>> - CChart, which draws wheather data
    >>>> - CWheather, which contains wheather data and all the functions
    >>>> regarding analysing data. So this data (it contains the data) can
    >>>> be passed to CChart to draw it.
    >>>
    >>> Presumably[1] the "C" signifies "Constant"?
    >>>

    >>
    >> No, it means "class" (CWheather = "class Wheather"). They are 2
    >> normal classes...

    >
    > Alf was teasing you (see his footnote). Microsoft's habit of putting
    > 'C' in front of all their classes is surely contagious, isn't it?
    >
    > V


    yes, They use C. But I think its quite logical... C like class... This was
    you know its a class type.
     
    crea, Mar 3, 2011
    #7
  8. On 3/3/2011 10:26 AM, crea wrote:
    > Victor Bazarov wrote:
    >> On 3/3/2011 9:27 AM, crea wrote:
    >>> Alf P. Steinbach /Usenet wrote:
    >>>> * crea, on 03.03.2011 13:43:
    >>>>> Lets say we are programming a wheather data analysing and display
    >>>>> program (of course using VC!).
    >>>>>
    >>>>> We have already classes:
    >>>>> - CChart, which draws wheather data
    >>>>> - CWheather, which contains wheather data and all the functions
    >>>>> regarding analysing data. So this data (it contains the data) can
    >>>>> be passed to CChart to draw it.
    >>>>
    >>>> Presumably[1] the "C" signifies "Constant"?
    >>>>
    >>>
    >>> No, it means "class" (CWheather = "class Wheather"). They are 2
    >>> normal classes...

    >>
    >> Alf was teasing you (see his footnote). Microsoft's habit of putting
    >> 'C' in front of all their classes is surely contagious, isn't it?
    >>
    >> V

    >
    > yes, They use C. But I think its quite logical... C like class... This was
    > you know its a class type.


    There is nothing logical in that. It's called "monkey see, monkey do".
    Do you use other "Hungarian notation" elements as well? Do you have
    all your int variables' names start with 'i'? All doubles start with
    'd'? Or some other similar nonsense? What if the type changes from
    double to float or from int to unsigned long? Do you go renaming all
    your affected variables?

    V
    --
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Mar 3, 2011
    #8
  9. crea

    crea Guest

    Victor Bazarov wrote:
    > On 3/3/2011 10:26 AM, crea wrote:
    >> Victor Bazarov wrote:
    >>> On 3/3/2011 9:27 AM, crea wrote:
    >>>> Alf P. Steinbach /Usenet wrote:
    >>>>> * crea, on 03.03.2011 13:43:
    >>>>>> Lets say we are programming a wheather data analysing and display
    >>>>>> program (of course using VC!).
    >>>>>>
    >>>>>> We have already classes:
    >>>>>> - CChart, which draws wheather data
    >>>>>> - CWheather, which contains wheather data and all the functions
    >>>>>> regarding analysing data. So this data (it contains the data) can
    >>>>>> be passed to CChart to draw it.
    >>>>>
    >>>>> Presumably[1] the "C" signifies "Constant"?
    >>>>>
    >>>>
    >>>> No, it means "class" (CWheather = "class Wheather"). They are 2
    >>>> normal classes...
    >>>
    >>> Alf was teasing you (see his footnote). Microsoft's habit of
    >>> putting 'C' in front of all their classes is surely contagious,
    >>> isn't it? V

    >>
    >> yes, They use C. But I think its quite logical... C like class...
    >> This was you know its a class type.

    >
    > There is nothing logical in that. It's called "monkey see, monkey
    > do". Do you use other "Hungarian notation" elements as well? Do you


    yes, its good to know what type it is. I think many professionals use this.

    > have all your int variables' names start with 'i'? All doubles start


    with integers its "n".

    > with 'd'? Or some other similar nonsense? What if the type changes
    > from double to float or from int to unsigned long? Do you go


    this happens very rarely in practical applications. Dont remember when
    happened to me.

    > renaming all your affected variables?


    from double to float its not that big issue bce both are decimal numbers
     
    crea, Mar 3, 2011
    #9
  10. On 3/3/2011 12:14 PM, crea wrote:
    > Victor Bazarov wrote:
    >> On 3/3/2011 10:26 AM, crea wrote:
    >>> Victor Bazarov wrote:
    >>>> On 3/3/2011 9:27 AM, crea wrote:
    >>>>> Alf P. Steinbach /Usenet wrote:
    >>>>>> * crea, on 03.03.2011 13:43:
    >>>>>>> Lets say we are programming a wheather data analysing and display
    >>>>>>> program (of course using VC!).
    >>>>>>>
    >>>>>>> We have already classes:
    >>>>>>> - CChart, which draws wheather data
    >>>>>>> - CWheather, which contains wheather data and all the functions
    >>>>>>> regarding analysing data. So this data (it contains the data) can
    >>>>>>> be passed to CChart to draw it.
    >>>>>>
    >>>>>> Presumably[1] the "C" signifies "Constant"?
    >>>>>>
    >>>>>
    >>>>> No, it means "class" (CWheather = "class Wheather"). They are 2
    >>>>> normal classes...
    >>>>
    >>>> Alf was teasing you (see his footnote). Microsoft's habit of
    >>>> putting 'C' in front of all their classes is surely contagious,
    >>>> isn't it? V
    >>>
    >>> yes, They use C. But I think its quite logical... C like class...
    >>> This was you know its a class type.

    >>
    >> There is nothing logical in that. It's called "monkey see, monkey
    >> do". Do you use other "Hungarian notation" elements as well? Do you

    >
    > yes, its good to know what type it is. I think many professionals use this.
    > [..]


    "Many" as in hundreds/thousands? Or "many" as in seventy-five percent?
    *All* professionals *I know* discourage use of type prefix. BTW, do
    you use 'T' or 'CT' for class templates? What about functions? Do you
    use prefix to indicate what type it returns or what type it has
    (including the arguments)?

    V
    --
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Mar 3, 2011
    #10
  11. crea

    crea Guest

    Victor Bazarov wrote:
    > On 3/3/2011 12:14 PM, crea wrote:
    >> Victor Bazarov wrote:

    > "Many" as in hundreds/thousands? Or "many" as in seventy-five
    > percent? *All* professionals *I know* discourage use of type prefix.
    > BTW, do you use 'T' or 'CT' for class templates? What about
    > functions? Do you use prefix to indicate what type it returns or
    > what type it has (including the arguments)?


    With functions you see it automatically because the parameters are using
    prefixs. Like this:

    int nCount;
    string strName;

    Foo(nCount, strName);

    Now, we dont need to put it to Foo, because we can see that what types they
    are according to variables. So we know that the first Foo parameter is int
    because of nCount.
     
    crea, Mar 3, 2011
    #11
  12. crea

    crea Guest

    Victor Bazarov wrote:
    > On 3/3/2011 12:14 PM, crea wrote:
    > "Many" as in hundreds/thousands? Or "many" as in seventy-five
    > percent? *All* professionals *I know* discourage use of type prefix.
    > BTW, do you use 'T' or 'CT' for class templates? What about
    > functions? Do you use prefix to indicate what type it returns or
    > what type it has (including the arguments)?


    For example with global integer you could use:

    int g_nCounter;

    Just looking the name you know its global AND its an integer. Handy ... :).

    If you put m_, that would mean a class memeber
     
    crea, Mar 3, 2011
    #12
  13. crea

    James Kanze Guest

    On Mar 3, 3:26 pm, "crea" <> wrote:
    > Victor Bazarov wrote:
    > > On 3/3/2011 9:27 AM, crea wrote:
    > >> Alf P. Steinbach /Usenet wrote:
    > >>> * crea, on 03.03.2011 13:43:
    > >>>> Lets say we are programming a wheather data analysing and display
    > >>>> program (of course using VC!).


    > >>>> We have already classes:
    > >>>> - CChart, which draws wheather data
    > >>>> - CWheather, which contains wheather data and all the functions
    > >>>> regarding analysing data. So this data (it contains the data) can
    > >>>> be passed to CChart to draw it.


    > >>> Presumably[1] the "C" signifies "Constant"?


    > >> No, it means "class" (CWheather = "class Wheather"). They are 2
    > >> normal classes...


    > > Alf was teasing you (see his footnote). Microsoft's habit of putting
    > > 'C' in front of all their classes is surely contagious, isn't it?


    > yes, They use C. But I think its quite logical... C like class... This was
    > you know its a class type.


    And what types with e.g. member functions and private data
    aren't class types?

    In fact, the Microsoft convention is used for functions in MFC,
    it's a private prefix (MFC predates namespaces), used to avoid
    the risk of name collisions with user classes (which, of course,
    should never be prefixed with a C.) It's not a good
    convention---it's too short---but it was common practice back
    then to use some sort of convention when providing librarys to
    a large community of users.

    --
    James Kanze
     
    James Kanze, Mar 3, 2011
    #13
  14. crea

    James Kanze Guest

    On Mar 3, 5:14 pm, "crea" <> wrote:
    > Victor Bazarov wrote:
    > > On 3/3/2011 10:26 AM, crea wrote:
    > >> Victor Bazarov wrote:
    > >>> On 3/3/2011 9:27 AM, crea wrote:
    > >>>> Alf P. Steinbach /Usenet wrote:
    > >>>>> * crea, on 03.03.2011 13:43:
    > >>>>>> Lets say we are programming a wheather data analysing and display
    > >>>>>> program (of course using VC!).


    > >>>>>> We have already classes:
    > >>>>>> - CChart, which draws wheather data
    > >>>>>> - CWheather, which contains wheather data and all the functions
    > >>>>>> regarding analysing data. So this data (it contains the data) can
    > >>>>>> be passed to CChart to draw it.


    > >>>>> Presumably[1] the "C" signifies "Constant"?


    > >>>> No, it means "class" (CWheather = "class Wheather"). They are 2
    > >>>> normal classes...


    > >>> Alf was teasing you (see his footnote). Microsoft's habit of
    > >>> putting 'C' in front of all their classes is surely contagious,
    > >>> isn't it? V


    > >> yes, They use C. But I think its quite logical... C like class...
    > >> This was you know its a class type.


    > > There is nothing logical in that. It's called "monkey see, monkey
    > > do". Do you use other "Hungarian notation" elements as well? Do you


    > yes, its good to know what type it is. I think many professionals use this.


    Actually, it's an almost certain indicator of an amateur. The
    type is Chart, or Weather, or whatever.

    > > have all your int variables' names start with 'i'? All doubles start


    > with integers its "n".


    > > with 'd'? Or some other similar nonsense? What if the type changes
    > > from double to float or from int to unsigned long? Do you go


    > this happens very rarely in practical applications. Dont remember when
    > happened to me.


    I don't think I've ever worked on an application where it didn't
    happen. Applications live.

    > > renaming all your affected variables?


    > from double to float its not that big issue bce both are decimal numbers


    Neither is decimal, at least not on any platform I know. (Most
    platforms today, except mainframes, use binary. IBM mainframes
    use hexadecimal, and Unisys mainframes octal. The IBM 1401 did
    use decimal, but I don't think that there was ever a C++
    compiler for it.)

    --
    James Kanze
     
    James Kanze, Mar 3, 2011
    #14
  15. crea

    Jorgen Grahn Guest

    On Thu, 2011-03-03, crea wrote:
    > Victor Bazarov wrote:


    [Hungarian-like notation]

    >> with 'd'? Or some other similar nonsense? What if the type changes
    >> from double to float or from int to unsigned long? Do you go

    >
    > this happens very rarely in practical applications. Dont remember when
    > happened to me.


    Perhaps you change types seldom /because/ your naming convention makes
    it hard?

    Although to be honest, I don't seem to do a lot of type changes
    myself, even though I'm not locked down by prefixes.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
     
    Jorgen Grahn, Mar 3, 2011
    #15
  16. crea

    Öö Tiib Guest

    On Mar 3, 8:35 pm, "crea" <> wrote:
    > Victor Bazarov wrote:
    > > On 3/3/2011 12:14 PM, crea wrote:
    > > "Many" as in hundreds/thousands?  Or "many" as in seventy-five
    > >  percent? *All* professionals *I know* discourage use of type prefix.
    > > BTW, do you use 'T' or 'CT' for class templates?  What about
    > > functions?  Do you use prefix to indicate what type it returns or
    > > what type it has (including the arguments)?

    >
    > For example with global integer you could use:
    >
    > int g_nCounter;


    He did ask about your policy with class prefixes that global integer
    is totally different entity.

    > Just looking the name you know its global AND its an integer. Handy ... :).


    Yes. When you have several threads then you can just search your code-
    base for "g_n" to find out all broken places that use mutable global
    integer for something dim in multithreaded program.

    >
    > If you put m_, that would mean a class memeber


    I have seen code-base where several local variables were prefixed with
    m_ and even one typedef'd type. So obviously not everybody taken into
    team did understand wtf that m_ is about ... they put it here or there
    just for a case. Without set coding policy that outright demands such
    things and reviews that check if the policy has been followed it is
    bloat of two characters.
     
    Öö Tiib, Mar 3, 2011
    #16
  17. crea

    James Kanze Guest

    On Mar 3, 7:20 pm, Leigh Johnston <> wrote:
    > On 03/03/2011 19:05, James Kanze wrote:
    > > On Mar 3, 3:26 pm, "crea"<> wrote:
    > >> Victor Bazarov wrote:
    > >>> On 3/3/2011 9:27 AM, crea wrote:
    > >>>> Alf P. Steinbach /Usenet wrote:
    > >>>>> * crea, on 03.03.2011 13:43:
    > >>>>>> Lets say we are programming a wheather data analysing and display
    > >>>>>> program (of course using VC!).


    > >>>>>> We have already classes:
    > >>>>>> - CChart, which draws wheather data
    > >>>>>> - CWheather, which contains wheather data and all the functions
    > >>>>>> regarding analysing data. So this data (it contains the data) can
    > >>>>>> be passed to CChart to draw it.


    > >>>>> Presumably[1] the "C" signifies "Constant"?


    > >>>> No, it means "class" (CWheather = "class Wheather"). They are 2
    > >>>> normal classes...


    > >>> Alf was teasing you (see his footnote). Microsoft's habit of putting
    > >>> 'C' in front of all their classes is surely contagious, isn't it?


    > >> yes, They use C. But I think its quite logical... C like class... This was
    > >> you know its a class type.


    > > And what types with e.g. member functions and private data
    > > aren't class types?


    > > In fact, the Microsoft convention is used for functions in MFC,
    > > it's a private prefix (MFC predates namespaces), used to avoid
    > > the risk of name collisions with user classes (which, of course,
    > > should never be prefixed with a C.) It's not a good


    > There was never a Microsoft prohibition on prefixing user classes with a
    > C


    Microsoft never prohibited anything, as long as you were
    spending money on their product. (Microsoft isn't alone in
    this, of course.)

    > in fact the exact opposite is true: if you create a new project called
    > "foo" the application wizard will create such classes as CfooApp,
    > CfooDoc, CfooView and CMainFrame.


    That's horrible. You mean that the Wizard encourages really bad
    code.

    --
    James Kanze
     
    James Kanze, Mar 4, 2011
    #17
  18. crea

    crea Guest

    James Kanze wrote:
    >> in fact the exact opposite is true: if you create a new project
    >> called "foo" the application wizard will create such classes as
    >> CfooApp, CfooDoc, CfooView and CMainFrame.

    >
    > That's horrible. You mean that the Wizard encourages really bad
    > code.


    So you guys dont use "C" in front of class names? I am totally used to it...
    been using since 1996 ... we are speaking about VC++5 ...

    It would be "wierd" not to use it...
     
    crea, Mar 4, 2011
    #18
  19. On 3/4/2011 6:22 AM, crea wrote:
    > James Kanze wrote:
    >>> in fact the exact opposite is true: if you create a new project
    >>> called "foo" the application wizard will create such classes as
    >>> CfooApp, CfooDoc, CfooView and CMainFrame.

    >>
    >> That's horrible. You mean that the Wizard encourages really bad
    >> code.

    >
    > So you guys dont use "C" in front of class names?


    Not if it's superfluous. For instance, if I have a class modeling a
    group of lights, I call it LightGroup, not CLightGroup. OTOH if I have
    a class modeling a list of arguments the system passes to a program, I
    call it CommandLine. The latter sports the "C" as its first letter ("in
    front"), but it's definitely not superfluous. I can swear I do not omit
    'C' just for the sake of omitting it. *That* would be weird. Imagine
    my class for arguments would be called 'ommandLine'... 8-O

    > I am totally used to it...
    > been using since 1996 ... we are speaking about VC++5 ...
    >
    > It would be "wierd" not to use it...


    Some folks are so used to wearing a hat, they wear one even when they
    are in bed sleeping. To them it would be weird not to wear it...

    V
    --
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Mar 4, 2011
    #19
  20. crea

    Paul Guest

    "Leigh Johnston" <> wrote in message
    news:...
    > On 04/03/2011 11:22, crea wrote:
    >> James Kanze wrote:
    >>>> in fact the exact opposite is true: if you create a new project
    >>>> called "foo" the application wizard will create such classes as
    >>>> CfooApp, CfooDoc, CfooView and CMainFrame.
    >>>
    >>> That's horrible. You mean that the Wizard encourages really bad
    >>> code.

    >>
    >> So you guys dont use "C" in front of class names? I am totally used to
    >> it...
    >> been using since 1996 ... we are speaking about VC++5 ...
    >>
    >> It would be "wierd" not to use it...
    >>
    >>

    >
    > I tend to use the Microsoft C class prefix convention for any classes that
    > derive from an MFC class; this means that most of my GUI (e.g. view) class
    > names are CCamelCase whilst all other (e.g. model/controller) class names
    > are lowercase_like_this.
    >


    Why don't you use both: class C_case{}?

    I usually just capitalise first letter like this : class Case{}. I like the
    capital first letter to easily see the difference in code between types and
    names e.g:

    Case case1; /*clear code*/
    Case(); /*Obviously not a function call*/
    do_something(); /*obvioulsy is a function call*/

    I guess I can see why people are happy to stick with the CCase syntax
    because its makes the code very readable. I think the extra C is a bit
    overkill though , simply capitalising the first letter is fine for me.
     
    Paul, Mar 4, 2011
    #20
    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. E11
    Replies:
    1
    Views:
    4,844
    Thomas Weidenfeller
    Oct 12, 2005
  2. Jacek Dziedzic
    Replies:
    2
    Views:
    331
    Jakob Bieling
    Oct 17, 2003
  3. John_Woo

    class design vs. db design

    John_Woo, Dec 19, 2006, in forum: Java
    Replies:
    2
    Views:
    339
    John_Woo
    Dec 19, 2006
  4. Bartholomew Simpson

    class design/ design pattern question

    Bartholomew Simpson, Jun 12, 2007, in forum: C++
    Replies:
    2
    Views:
    456
    Daniel T.
    Jun 12, 2007
  5. Nilone

    Re: Class design issue

    Nilone, Mar 3, 2011, in forum: C++
    Replies:
    8
    Views:
    262
Loading...

Share This Page