Give me some advice about book and how to master vc and mfc!

Discussion in 'C++' started by yuyazhang, Apr 27, 2006.

  1. yuyazhang

    yuyazhang Guest

    Hi ,

    I am a graduate , I have had some basic knowlege about C++ ï¼ but
    I find that I can't master it , I am disappoint for that . who give me
    some advice about ways which master it and some good books 。I will
    be pleasure.


    Thank you in advance!


    Zhang
    yuyazhang, Apr 27, 2006
    #1
    1. Advertising

  2. yuyazhang

    benben Guest

    yuyazhang wrote:
    > Hi ,
    >
    > I am a graduate , I have had some basic knowlege about C++ ï¼ but
    > I find that I can't master it , I am disappoint for that . who give me
    > some advice about ways which master it and some good books 。I will
    > be pleasure.
    >
    >
    > Thank you in advance!
    >
    >
    > Zhang
    >


    Well, grab a good book and read it down:)

    Regards,
    Ben
    benben, Apr 27, 2006
    #2
    1. Advertising

  3. yuyazhang

    osmium Guest

    "yuyazhang" writes:

    I am a graduate , I have had some basic knowlege about C++ ! but
    I find that I can't master it , I am disappoint for that . who give me
    some advice about ways which master it and some good books ?I will
    be pleasure.

    I'm not sure anyone has ever mastered C++, the language is huge, not pure,
    and not really designed to my way of thinking. This leads to quirky
    effects. By not pure, I mean object orientation is tacked on to the C
    language and the result is a forced fit. Obviously has been and is very
    successful despite these problems.

    The best way to proceed that I know of is to work with _The C++ Programming
    Language_ by Stroustrup, at least the third edition. Write lots of code,
    and don't keep beating the same problem over and over which I think a lot of
    people do. Writing you own string class is a good exercise if you haven't
    already done so.
    osmium, Apr 27, 2006
    #3
  4. yuyazhang

    Phlip Guest

    osmium wrote:

    > The best way to proceed that I know of is to work with _The C++
    > Programming Language_ by Stroustrup, at least the third edition.


    The absolute worst way to learn C++ has got to be MFC.

    ;-)

    --
    Phlip
    http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!
    Phlip, Apr 27, 2006
    #4
  5. yuyazhang

    benben Guest

    > By not pure, I mean object orientation is tacked on to the C
    > language and the result is a forced fit.


    Can you be more specific about why C++'s object-oriented support is a
    "forced fit"?

    I am under the impression that you came to this conclusion because C++
    does support non-OOP paradigms. Please prove me wrong.

    Regards,
    Ben
    benben, Apr 28, 2006
    #5
  6. yuyazhang

    Phlip Guest

    benben wrote:

    >> By not pure, I mean object orientation is tacked on to the C
    >> language and the result is a forced fit.

    >
    > Can you be more specific about why C++'s object-oriented support is a
    > "forced fit"?


    I can. Some languages permit this (in pseudo-C++ syntax):

    void foo(class & bar)
    {
    bar * frob = new bar;
    ...
    }

    I passed a class as an object into foo().

    Because C++ must follow C's legacy compiler and linker technology, classes
    are not objects. So we have two (mildly conflicting) syntaxes to do related
    OO things. To pass an interface to a function, we can use inheritance. To
    pass a class to a function, we must use template syntax. This is redundant -
    two different systems to pass things to functions! Redundancy is a very
    clear indicator of poor design.

    Tip: Part of becoming fluent in programming is to let go of defensiveness
    over languages. And about OO!

    --
    Phlip
    http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!
    Phlip, Apr 28, 2006
    #6
  7. yuyazhang

    Noah Roberts Guest

    Phlip wrote:
    > benben wrote:
    >
    > >> By not pure, I mean object orientation is tacked on to the C
    > >> language and the result is a forced fit.

    > >
    > > Can you be more specific about why C++'s object-oriented support is a
    > > "forced fit"?

    >
    > I can. Some languages permit this (in pseudo-C++ syntax):
    >
    > void foo(class & bar)
    > {
    > bar * frob = new bar;
    > ...
    > }
    >
    > I passed a class as an object into foo().
    >
    > Because C++ must follow C's legacy compiler and linker technology, classes
    > are not objects. So we have two (mildly conflicting) syntaxes to do related
    > OO things. To pass an interface to a function, we can use inheritance. To
    > pass a class to a function, we must use template syntax. This is redundant -
    > two different systems to pass things to functions! Redundancy is a very
    > clear indicator of poor design.


    That ability in other languages comes with several expenses including
    type safety and runtime efficiency.

    That is a fact...which is better is an opinion.
    Noah Roberts, Apr 28, 2006
    #7
  8. yuyazhang

    benben Guest

    > I can. Some languages permit this (in pseudo-C++ syntax):
    >
    > void foo(class & bar)
    > {
    > bar * frob = new bar;
    > ...
    > }


    Let's say we do something with frob other than the dot dot dot:


    void foo(class& bar)
    {
    bar* frob = new bar;
    frob->do_trick();

    delete frob;
    }


    Well, the problem is, what if class bar doesn't have a do_trick member
    function? You are moving compile-time error to runtime error, which is
    equivalent to letting the end users to deal with the error instead of
    you dealing it. Not a wise move.

    A type-safe alternative can be achieved in C++:

    template <typename bar>
    void foo(void)
    {
    bar* frob = new bar;
    frob->do_trick();
    delete frob;
    }

    Were bar not supporting the do_trick member, the compile will tell you.

    Regards,
    Ben
    benben, Apr 29, 2006
    #8
  9. yuyazhang

    Phlip Guest

    benben wrote:

    > Let's say we do something with frob other than the dot dot dot:
    >
    > void foo(class& bar)
    > {
    > bar* frob = new bar;
    > frob->do_trick();
    >
    > delete frob;
    > }
    >
    > Well, the problem is, what if class bar doesn't have a do_trick member
    > function? You are moving compile-time error to runtime error, which is
    > equivalent to letting the end users to deal with the error instead of you
    > dealing it. Not a wise move.


    Why can't the compiler just detect the use of class& and morph it into the
    template expansion system currently used for template<class>?

    (Because something could call the function that the compiler can't see yet,
    unlike templates which have a fixed instantiation point, etc...)

    The outer problem here is simply flexibility. I think having two redundant
    systems to pass things into functions (either types or objects) is _less_
    flexible than one unified system. Such unifications tend to force us to
    invent the _weakest_ possible primitives, which then can be assembled in
    new, emergent ways that language designers never thought of.

    The inner problem is your unit tests should catch the error. ;-)

    > A type-safe alternative can be achieved in C++:
    >
    > template <typename bar>
    > void foo(void)
    > {
    > bar* frob = new bar;
    > frob->do_trick();
    > delete frob;
    > }
    >
    > Were bar not supporting the do_trick member, the compile will tell you.


    Can you do the Prototype Pattern with templates? The general point here is
    that letting classes be objects makes many design patterns get shorter and
    more trivial.

    --
    Phlip
    http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!
    Phlip, Apr 29, 2006
    #9
  10. yuyazhang

    benben Guest

    Phlip wrote:
    > benben wrote:
    >
    >> Let's say we do something with frob other than the dot dot dot:
    >>
    >> void foo(class& bar)
    >> {
    >> bar* frob = new bar;
    >> frob->do_trick();
    >>
    >> delete frob;
    >> }
    >>
    >> Well, the problem is, what if class bar doesn't have a do_trick member
    >> function? You are moving compile-time error to runtime error, which is
    >> equivalent to letting the end users to deal with the error instead of you
    >> dealing it. Not a wise move.

    >
    > Why can't the compiler just detect the use of class& and morph it into the
    > template expansion system currently used for template<class>?
    >
    > (Because something could call the function that the compiler can't see yet,
    > unlike templates which have a fixed instantiation point, etc...)
    >
    > The outer problem here is simply flexibility. I think having two redundant
    > systems to pass things into functions (either types or objects) is _less_
    > flexible than one unified system. Such unifications tend to force us to
    > invent the _weakest_ possible primitives, which then can be assembled in
    > new, emergent ways that language designers never thought of.


    While whether flexibility can be improved by making classes objects is
    largely a subject of debate, I would point out that flexibility give way
    to program correctness when they conflict.

    >
    > The inner problem is your unit tests should catch the error. ;-)


    Why put an error to unit test while you could have eliminate it in the
    first place?

    And how are you so confident that your tests could catch all the errors?
    I am not. And aren't you frustrated every time your browser pops up a
    warning telling you some object doesn't support certain method? I am!

    >
    >> A type-safe alternative can be achieved in C++:
    >>
    >> template <typename bar>
    >> void foo(void)
    >> {
    >> bar* frob = new bar;
    >> frob->do_trick();
    >> delete frob;
    >> }
    >>
    >> Were bar not supporting the do_trick member, the compile will tell you.

    >
    > Can you do the Prototype Pattern with templates? The general point here is
    > that letting classes be objects makes many design patterns get shorter and
    > more trivial.


    What does prototype pattern have to do with template? It can, of course,
    be done in C++ with or without templates.

    Type safety is a C++ feature. It is designed to restrict you from doing
    something silly or inconsiderate in the first place. If you want to by
    pass the type system you have to be explicit (so that you know what you
    are doing)

    As I said, flexibility gives way to correctness.

    Regards,
    Ben
    benben, Apr 29, 2006
    #10
  11. yuyazhang

    yuyazhang Guest

    Thank you very much!
    yuyazhang, Apr 29, 2006
    #11
  12. yuyazhang

    Guest

    >I am a graduate , I have had some basic knowlege about C++ ï¼ but
    >I find that I can't master it , I am disappoint for that . who give me
    >some advice about ways which master it and some good books 。I will
    >be pleasure.


    Master vc or mfc?
    Do some software yourself.
    I have never used VC until I joined the present company six months ago.
    , Apr 30, 2006
    #12
  13. yuyazhang

    Phlip Guest

    benben wrote:

    > While whether flexibility can be improved by making classes objects is
    > largely a subject of debate, I would point out that flexibility give way
    > to program correctness when they conflict.


    Making classes objects is orthogonal to the problem: Two different syntaxes
    to passing things into functions. Redundancy is always a design smell.

    >> The inner problem is your unit tests should catch the error. ;-)

    >
    > Why put an error to unit test while you could have eliminate it in the
    > first place?


    Both arguments use the fallacy of the excluded middle. Let's do both.

    --
    Phlip
    http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!
    Phlip, Apr 30, 2006
    #13
    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. yuyazhang
    Replies:
    14
    Views:
    706
    yuyazhang
    Apr 29, 2006
  2. Scott McPhillips
    Replies:
    0
    Views:
    371
    Scott McPhillips
    Jul 5, 2003
  3. ringos75
    Replies:
    0
    Views:
    943
    ringos75
    Apr 14, 2005
  4. yuyazhang
    Replies:
    0
    Views:
    236
    yuyazhang
    Apr 27, 2006
  5. yuyazhang
    Replies:
    0
    Views:
    321
    yuyazhang
    Apr 27, 2006
Loading...

Share This Page