.NET book recommendations ??

  • Thread starter Thread starter Rubio
  • Start date Start date
R

Rubio

What books would you recommend to a seasoned C/C++ programmer wanting
to venture into the .NET domain? And yes, I do want to stick to C++.

-- Rubio
 
What books would you recommend to a seasoned C/C++ programmer wanting
to venture into the .NET domain? And yes, I do want to stick to C++.

This one is pretty good to learn .net w/out having to learn the baggage that
came before it (mfc, atl, com, win32):

Managed C++ and .NET Development: Visual Studio .NET 2003 Edition
by Stephen R. G. Fraser

But it doesn't cover interop with unmanaged code, which is one of vc.net's
strength. This one, though I have not read it, seems to bee a good book to
cover that:

Programming with Managed Extensions for Microsoft Visual C++ .NET
by Richard Grimes

Only problem I see with learning managed c++ this way, is that with the new
CLI binding proposed, managed c++ will be quite different and may render
these books obsolete.

Nevertheless, these are the best two books from what I can tell so far.

-Don
 
Don said:
This one is pretty good to learn .net w/out having to learn the
baggage that came before it (mfc, atl, com, win32):

Managed C++ and .NET Development: Visual Studio .NET 2003 Edition
by Stephen R. G. Fraser

But it doesn't cover interop with unmanaged code, which is one of
vc.net's strength. This one, though I have not read it, seems to bee
a good book to cover that:

Programming with Managed Extensions for Microsoft Visual C++ .NET
by Richard Grimes

Only problem I see with learning managed c++ this way, is that with
the new CLI binding proposed, managed c++ will be quite different and
may render these books obsolete.

Where is an official document abouit the new CLI binding ? Is there word
about when the new CLI binding will be implemented by MS for VS .Net ?
 
Ronald said:

In the C++ CLI binding, what was the reasoning for adding '^' and '%' as
pointers and references/addressing to the GC heap rather than just keeping
C++'s '*' and '&' ?

While it separates accessing the GC heap from normal standard C++, it
creates syntax additions which really seems unnecessary. C++ programmers are
a pretty advanced programmers generally and they don't need such babying in
a language addition.
 
Edward said:
http://download.microsoft.com/downl...0e14cd1670cd/C++ CLI Candidate Base Draft.pdf

In the C++ CLI binding, what was the reasoning for adding '^' and '%'
as
pointers and references/addressing to the GC heap rather than just
keeping
C++'s '*' and '&' ?

For one thing, it allows overloading based on the GC-ness of an object -
something that the current Managed Extensions for C++ are sorely lacking.
While it separates accessing the GC heap from normal standard C++, it
creates syntax additions which really seems unnecessary. C++
programmers are
a pretty advanced programmers generally and they don't need such
babying in
a language addition.

A problem in MC++ now is that T* means (at least) 3 different things, and
what you can do with a T* requires that you know exactly what kind of T* you
have. It's proven to be very confusing in practice.

-cd
 
Where is an official document abouit the new CLI binding ? Is there word
about when the new CLI binding will be implemented by MS for VS .Net ?

Here's an announcement made by Herb Sutter from
http://www.gotw.ca/microsoft/ in October:

For the past year, I've been working on something that has now become
public, and I hope that it's an important statement about the future
relevance of C++ on modern platforms. In particular, I think it
demonstrates that C++ is alive and well in the industry in general,
and in particular that it's alive and well (and the subject of heavy
and continued investment) at Microsoft.

Increasingly, we are writing programs targeted to modern environments
characterized by a virtual machine with garbage collection. Leading
examples include the JVM and the .NET CLR (ISO CLI, or Common
Language Infrastructure, is the standardized subset of the .NET
runtime environment and frameworks class library). But Standard C++
has no notion of now-fundamental concepts like garbage collection.
Is C++ simply obsolescent? No; it can be cleanly extended to
directly support these modern environments. Further, C++ actually
offers compelling advantages that can make it the language of choice
for your application, even on the "home turf" of newer languages
specifically designed for these new environments.

The Managed Extensions for C++ (aka "Managed C++") were only partly
successful. They achieved an important goal well: The ability to take
existing C++ code and just recompile it with /clr and have it running
on the virtual machine, and then to start adding .NET features and
types. Unfortunately, they achieved other goals less well: As soon as
you tried to add .NET types and features to your system, the syntax
was uneven and sometimes just weird (e.g., T* meant three different
and incompatible things depending on the type of T), the extensions
looked ugly (e.g., __keywords), and they lacked first-class support
for some fundamental CLR features (e.g., __property decorations on
individual member functions that the compiler would cobble together
for you, instead of a property abstraction). More importantly, MC++
followed what I call the "two worlds" hypothesis -- it did expose the
important CLR features, but only for CLR types, not native types; and
it did not expose native C++ features also for CLR types. The two
worlds were grafted together, not integrated. This has been a
constant source of surprises to programmers who always have to
remember the list of things that don't work, or work differently,
when using CLR types.

Well, we've been working on it. My current job is that I'm the lead
architect for the language design team, and together with bright
people both inside and outside of Microsoft (and names you would
recognize), we have come up with a design for the .NET extensions
that meets all of the following goals:

- provides an elegant (and uniform!) syntax and semantics that give
a natural feel for C++ programmers

- provides first-class support for all current and upcoming .NET
features (e.g., properties, events, garbage collection, generics)
for all types including existing C++ classes

- provides first-class support for C++ features (e.g.,
deterministic destruction, templates) for all types
including .NET classes

- preserves ISO C++ standards conformance (by adding pure
extensions, but also in a way that we don't need to use "__"
keywords)

(See also http://www.gotw.ca/microsoft .)

Further, we're not keeping it to ourselves: On October 6, 2003, a new
ECMA standards committee was formed to create an open international
standard for "C++/CLI," this set of extensions to C++. Formally,
C++/CLI is a binding between ISO C++ and ISO CLI; the announcement is
at www.ecma-international.org/news/ecma-TG5-PR.htm . This is
important because it specifically enables other compiler vendors to
implement the same extensions _and_ guarantee that they can fully
interoperate.

For those who are interested in seeing the shape of the project, we
will be making the proposed standard's base document (the "starting
point" document) publicly available on November 15, and I'll post a
link to it in a future issue of this newsletter. Then, starting in
December 2003, the new ECMA committee will take over the base
document and craft it into a consensus standard, which Microsoft will
track (i.e., we will incorporate changes the committee makes into our
product). The participants are tentatively planning to complete the
technical work by September 2004, which would let the ECMA General
Assembly vote on issuing the standard in December 2004.

I'll post more news bits and links as they become available. I'll
also be giving more talks about this language extensions design over
the coming months; for more details as events get scheduled, see my
"Talks & Appearances" page at http://www.gotw.ca/presentations.htm ,
and you can also watch the "News" page, http://www.gotw.ca/news.htm .

----------------------------------------------------

There was also a hugh thread about it on comp.lang.c++.moderated which you
can referrence here:

http://groups.google.com/[email protected]

-Don
 
Carl said:
http://download.microsoft.com/downl...0e14cd1670cd/C++ CLI Candidate Base Draft.pdf

For one thing, it allows overloading based on the GC-ness of an
object - something that the current Managed Extensions for C++ are
sorely lacking.

Overloading works on the actual types being used. I don't see how that
affects whether a type is a GC reference or not. Can you give a practical
example of what you mean here ?
A problem in MC++ now is that T* means (at least) 3 different things,
and what you can do with a T* requires that you know exactly what
kind of T* you have. It's proven to be very confusing in practice.

I think it is worse to invent different syntax to make it less confusing.
C++ programmers are used to 'T*' to refer to a pointer to a type and 'T&" to
refer to a reference to a type. Now creating 'T^' to refer to a pointer to a
ref type and 'T%' to refer to a reference to a ref type, seems just plain
silly and far more confusing than the 3 different things mentioned above.
Again MS is trying to baby programmers who don't need it. I am surprised Mr.
Sutter fell for this. The compiler always knows what is a ref type and what
is a C++ type. Any programmer should know this by the normal documentation
about what they are doing. Creating new syntax just to make a programmer
feel better, unless it significantly makes a language easier and more
elegant to use, seems really wrong to me. I favor consistency more.

I feel the same way about 'gcnew'. It is a redundancy of 'new' unless one
can create a C++ object on the GC dynamic heap or a ref object on the C++
dynamic heap, but neither of these possibilities make sense. Is there a good
practical reason for 'gcnew' which I have missed ?

For other added keywords, I also see nothing wrong with the __ designation.
With the proposed CLI binding, it is much more likely that there will be a
conflict between a programmer using 'delegate' or 'property' or 'event' as
identifiers in his code than if the __ designation was there, as C++
programmers are smart enough to know not to use identifiers starting with __
..
 
Edward said:
Overloading works on the actual types being used. I don't see how that
affects whether a type is a GC reference or not. Can you give a
practical example of what you mean here ?

Rather than give poor (and probably incorrect) answers, I'll refer you to
Herb Sutter's blog, where he's gone into all of these questions in some
depth:

http://blogs.gotdotnet.com/hsutter/

-cd
 
Back
Top