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

[yuyazhang]

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

[benben]

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

[osmium]

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

[Phlip]

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

[benben]

> 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

[Phlip]

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

[Noah Roberts]

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.

[benben]

> 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

[Phlip]

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

[benben]

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

[yuyazhang]

Thank you very much!

[zw111_2001]

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

[Phlip]

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