Is There Any Reason to Even Use VC++ Anymore?

[Greg]

Except for legacy or non-.NET applications, is there any reason to use VC++
anymore? It seems that for .NET applications, there would be no reason to
choose C++ over C# since C# is faster to develop with (i.e. no header files,
objects are easier to create and use, C# language is native to .NET)

I'm sure this question will stir some emotions :-)

--
Greg McPherran
www.McPherran.com

[Ted]

Here's some arguments pro-con:

http://blogs.msdn.com/texblog/archiv...21/495404.aspx

Ted.

"Greg" <[e-mail]> wrote in message
news:B6**********************************@microsof t.com...

Except for legacy or non-.NET applications, is there any reason to use
VC++
anymore? It seems that for .NET applications, there would be no reason to
choose C++ over C# since C# is faster to develop with (i.e. no header
files,
objects are easier to create and use, C# language is native to .NET)

I'm sure this question will stir some emotions :-)

--
Greg McPherran
www.McPherran.com

[Nishant Sivakumar]

See my article :

[A rational attempt to substantiate C++/CLI as a first class CLI language]
URL http://www.codeproject.com/managedcpp/whycppcli.asp

--
Regards,
Nish [VC++ MVP]
"Greg" <[e-mail]> wrote in message
news:B6**********************************@microsof t.com...

Except for legacy or non-.NET applications, is there any reason to use
VC++
anymore? It seems that for .NET applications, there would be no reason to
choose C++ over C# since C# is faster to develop with (i.e. no header
files,
objects are easier to create and use, C# language is native to .NET)

I'm sure this question will stir some emotions :-)

--
Greg McPherran
www.McPherran.com

[Greg]

Thank you both for your responses.

Here's my assessment:

For RAD GUI-intensive front ends that may also be published to web: C#

For Windows-only GUI-intensive apps:
C# unless delivery size is critical (e.g. download) and you don't want to
require cutomer to have .NET then C++ and native only.

For Windows-only apps where the GUI is not the major piece:
If performance and/or delivery size is critical then C++ native. Only use
..NET if it has critical features that are not available in MFC/ATL etc.
We have a spectrum:

-------------------------------------
Web
-------------------------------------
Windows GUI/DB apps
-------------------------------------
Windows number crunch apps
Windows direct graphics games
-------------------------------------
Fast ATL browser objects
-------------------------------------
Driver
-------------------------------------

Each area of the spectrum has languages/technologies that map to it. The
problem is that there are grey areas in between :-) C# is generally advisable
for web and GUI intensive Windows-only apps. C++ native is still generally
advisable for many Windows-only apps. I don't think that just because we have
..NET that MFC and ATL are antiquated. Each has its own place.

C# may begin to drill drown to areas now covered by C++ and C++ may begin to
"drill up" to the web and .NET (as it already has in VS 2005).

I think a smart way to manage all this is to isolate the GUI front end from
your core app crunching in your architecture. This way, the .NET vs native
decision can be made independently for these architectural areas. For
example, one could evolve an app's GUI to .NET and leave the app crunching in
native. Or the same app may even take two forms (no pun intended :-) ) one
with a .NET front end and one with an MFC front end. Both could be supported
with a proper architecture and each flavor could have it's own advantages.
We're not in Kansas anymore Toto :-) Pick your tool for what you're trying
to accomplish and what will get you there fastest. It's not either-or, it's
all of the above :-)

--
Greg McPherran
www.McPherran.com

[Tom Widmer [VC++ MVP]]

Greg wrote:

Except for legacy or non-.NET applications, is there any reason to use VC++
anymore? It seems that for .NET applications, there would be no reason to
choose C++ over C# since C# is faster to develop with (i.e. no header files,
objects are easier to create and use, C# language is native to .NET)

From this, it sounds like you haven't hear of C++/CLI, which is new in
the recently released VC2005.

C++/CLI is also native to .NET, doesn't need header files, and is
(arguably) faster to develop with than C# due to being more fully
featured while still supporting all the convenience of garbage
collection, etc. C++/CLI also produces faster code due to having a
compile-time optimizer (it can generate optimized byte code).

Tom

[David Wilkinson]

Tom Widmer [VC++ MVP] wrote:

Greg wrote:

Except for legacy or non-.NET applications, is there any reason to use
VC++ anymore? It seems that for .NET applications, there would be no
reason to choose C++ over C# since C# is faster to develop with (i.e.
no header files, objects are easier to create and use, C# language is
native to .NET)

From this, it sounds like you haven't hear of C++/CLI, which is new in
the recently released VC2005.

C++/CLI is also native to .NET, doesn't need header files, and is
(arguably) faster to develop with than C# due to being more fully
featured while still supporting all the convenience of garbage
collection, etc. C++/CLI also produces faster code due to having a
compile-time optimizer (it can generate optimized byte code).

Tom

Tom:

Even so, I am concerned about the future of C++ at Microsoft.

If you already know C++ well, the much improved C++/CLI is a natural
choice. But if you do not, then C# must look awful tempting. The
learning curve for C++ was always steep, and CLI certainly has not made
it any easier.

C++/CLI advantages:

1. Deterministic destruction. Nice, but can be done in C# using Dispose
(and maybe C# will get it right one day).

2. Interoperability with native code. Nice, but can also be done less
conveniently from C#. And this feature has a downside - non-verifiable code.

3. Improved optimization. Nice, but not a deal-breaker for most
applications.

4. STL.NET (if we ever see it). This could be a biggie if you want to
write verifiable code, and could constitute the only real advantage over
C# in this situation. But the learning curve of STL is extremely steep,
and many appliactions really do not need it.

5. Traditional C++ portability to other platforms. It remains to be seen
how portable it will remain in the presence of CLI extensions.

C# advantage(s):

A much simpler language, without historical baggage, designed
specifically for the CLR.

I guess I fear that the main function of C++/CLI will be to entice
existing C++ programmers into .NET. When we are all dead, perhaps few
people will be learning it any more. VB.NET, anyone?

David Wilkinson

[Arnaud Debaene]

David Wilkinson wrote:

Tom Widmer [VC++ MVP] wrote:

Greg wrote:

Except for legacy or non-.NET applications, is there any reason to
use VC++ anymore? It seems that for .NET applications, there would
be no reason to choose C++ over C# since C# is faster to develop
with (i.e. no header files, objects are easier to create and use, C#
language
is native to .NET)

From this, it sounds like you haven't hear of C++/CLI, which is new
in the recently released VC2005.

C++/CLI is also native to .NET, doesn't need header files, and is
(arguably) faster to develop with than C# due to being more fully
featured while still supporting all the convenience of garbage
collection, etc. C++/CLI also produces faster code due to having a
compile-time optimizer (it can generate optimized byte code).

Tom

Tom:

Even so, I am concerned about the future of C++ at Microsoft.

Just ask yourself one question : In what language do you think
1) Windows
2 The .NET CLR
are written, and how are they compiled?
If you already know C++ well, the much improved C++/CLI is a natural
choice. But if you do not, then C# must look awful tempting. The
learning curve for C++ was always steep, and CLI certainly has not
made it any easier.

C++/CLI advantages:

1. Deterministic destruction. Nice, but can be done in C# using
Dispose (and maybe C# will get it right one day). The Dispose pattern is far inferior to RAII because resource freeing is on
the responsibility of the client code.

2. Interoperability with native code. Nice, but can also be done less
conveniently from C#. And this feature has a downside -
non-verifiable code. C++ Interop is also much faster and efficient that COM Interop or P/Invoke.
Non-verifiable code is only a matter in low-trusts scenarios : in practice
when writting web code or plugins for some "hosting" apps such as SQL Server
2005.
C# advantage(s):

A much simpler language, without historical baggage, designed
specifically for the CLR.

Agreed, C# is much easier and simplier, but it also lacks some features of
C++ : templates come to mind first (and generics are no replacement for
templates because templates are a Turing-complete language, generics are
not).

Arnaud
MVP - VC

[David Anton]

The main reason to use C++ is that it's still the language you know (even
with the new 2005 syntax). Also, objects are not easier to create in C# and
there are 4 core Microsoft .NET languages: C++, C#, VB, and J#. C# has no
special place in the .NET world - it just happens to be the newest one.

C++ has many language features not available in any other .NET languages.
--
David Anton
www.tangiblesoftwaresolutions.com
Instant C#: VB.NET to C# Converter
Instant VB: C# to VB.NET Converter
Instant C++: C# to C++ Converter
Instant J#: VB.NET to J# Converter

"Greg" wrote:

Except for legacy or non-.NET applications, is there any reason to use VC++
anymore? It seems that for .NET applications, there would be no reason to
choose C++ over C# since C# is faster to develop with (i.e. no header files,
objects are easier to create and use, C# language is native to .NET)

I'm sure this question will stir some emotions :-)

--
Greg McPherran
www.McPherran.com

[Willy Denoyette [MVP]]

See inline

Willy.

"Arnaud Debaene" <ad******@club-internet.fr> wrote in message
news:OK**************@tk2msftngp13.phx.gbl...

David Wilkinson wrote:

Tom Widmer [VC++ MVP] wrote:

Greg wrote:

2. Interoperability with native code. Nice, but can also be done less
conveniently from C#. And this feature has a downside -
non-verifiable code.

C++ Interop is also much faster and efficient that COM Interop or
P/Invoke.
Non-verifiable code is only a matter in low-trusts scenarios : in practice
when writting web code or plugins for some "hosting" apps such as SQL
Server 2005.

C++ interop is not faster than PInvoke, whenever you cross the managed
unmanaged border you take a hit, be it using C++ interop or PInvoke. And
whenever you need to pass non blitables to or from managed memory, you take
a hit because of the marshaling that has to be done. Only advantage you have
with C++ interop is that you are in charge (control?) of the marshaling, so
you have a chace to optimize, while using PInvoke, the marshaling is
automatically done for you.

C# advantage(s):

A much simpler language, without historical baggage, designed
specifically for the CLR.

Agreed, C# is much easier and simplier, but it also lacks some features of
C++ : templates come to mind first (and generics are no replacement for
templates because templates are a Turing-complete language, generics are
not).

Arnaud
MVP - VC

[Herby]

We have chosen C++\CLI as our current source code base is in C++ and
provides a clear migration path.
Its also a benefit for us to be able to use mixed mode using both the
un-managed and managed heap in the same application/function.
You could almost think of the syntax extensions almost independent of
..NET. Just can now work with a garbage collector etc.

[Peter Oliphant]

I've heard VS C++.NET can run from 6-10 times FASTER than VS C#.NET. That's
a pretty good selling point right there... : )

[==P==]

"Herby" <pr********@gmail.com> wrote in message
news:11**********************@g49g2000cwa.googlegr oups.com...

We have chosen C++\CLI as our current source code base is in C++ and
provides a clear migration path.
Its also a benefit for us to be able to use mixed mode using both the
un-managed and managed heap in the same application/function.
You could almost think of the syntax extensions almost independent of
.NET. Just can now work with a garbage collector etc.

[Willy Denoyette [MVP]]

Sure, for those who believe this nonsense. Those who ran some benchmarks
know that there is almost no difference, for some specific cases C++/CLI is
a bit faster and in other cases C# is a bit faster. This is quite normal if
you know that both front-end compilers emit MSIL and the bulk of the
optimizations are done at JIT compile time. Sure the C++ compiler can spend
some extra time to optimize MSIL, while the C# compiler is more time
constrained, but in reality there is very little that can be done at the
MSIL level. Note also that a great deal of the code that gets executed in a
real world application comes from the FCL which is written in C#.
Believe me, performance is not C++/CLI's selling point.

Willy.

"Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
news:en**************@TK2MSFTNGP15.phx.gbl...

I've heard VS C++.NET can run from 6-10 times FASTER than VS C#.NET.
That's a pretty good selling point right there... : )

[==P==]

"Herby" <pr********@gmail.com> wrote in message
news:11**********************@g49g2000cwa.googlegr oups.com...

We have chosen C++\CLI as our current source code base is in C++ and
provides a clear migration path.
Its also a benefit for us to be able to use mixed mode using both the
un-managed and managed heap in the same application/function.
You could almost think of the syntax extensions almost independent of
.NET. Just can now work with a garbage collector etc.

[Peter Oliphant]

I never did any benchmarks, so I was basing my statement on other reports.
Thus I believe your findings more than what I've read (even though,
ironically, all I've done is read what you've said in saying this...lol). So
speed is not a selling point.

Still, I prefer to use C++ over C#, probably just because I prefer (am more
familiar with) the syntax. And, I'm afraid of seeing this pop up one day on
the MS website:

"MS has deprecated C++ in favor of C#". <shiver>

[==P==]

"Willy Denoyette [MVP]" <wi*************@telenet.be> wrote in message
news:%2******************@TK2MSFTNGP10.phx.gbl...

Sure, for those who believe this nonsense. Those who ran some benchmarks
know that there is almost no difference, for some specific cases C++/CLI
is a bit faster and in other cases C# is a bit faster. This is quite
normal if you know that both front-end compilers emit MSIL and the bulk of
the optimizations are done at JIT compile time. Sure the C++ compiler can
spend some extra time to optimize MSIL, while the C# compiler is more time
constrained, but in reality there is very little that can be done at the
MSIL level. Note also that a great deal of the code that gets executed in
a real world application comes from the FCL which is written in C#.
Believe me, performance is not C++/CLI's selling point.

Willy.

"Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
news:en**************@TK2MSFTNGP15.phx.gbl...

I've heard VS C++.NET can run from 6-10 times FASTER than VS C#.NET.
That's a pretty good selling point right there... : )

[==P==]

"Herby" <pr********@gmail.com> wrote in message
news:11**********************@g49g2000cwa.googlegr oups.com...

We have chosen C++\CLI as our current source code base is in C++ and
provides a clear migration path.
Its also a benefit for us to be able to use mixed mode using both the
un-managed and managed heap in the same application/function.
You could almost think of the syntax extensions almost independent of
.NET. Just can now work with a garbage collector etc.

[Willy Denoyette [MVP]]

"Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
news:ul***************@tk2msftngp13.phx.gbl...

I never did any benchmarks, so I was basing my statement on other reports.
Thus I believe your findings more than what I've read (even though,
ironically, all I've done is read what you've said in saying this...lol).
So speed is not a selling point.

Still, I prefer to use C++ over C#, probably just because I prefer (am
more familiar with) the syntax. And, I'm afraid of seeing this pop up one
day on the MS website:

"MS has deprecated C++ in favor of C#". <shiver>

C++ != C++/CLI remember!
What's possible is that you may see "MS has deprecated C++/CLI in favor of
C#", but they would never deprecate the language (native C++) they use to
build >95% of their products.
Willy.

[Peter Oliphant]

Here's what I'm getting at. I use to program in C++ before managed stuff
came into play (gc). So, when managed stuff did come into play, I had to
convert my stuff to it. Then CLI came into play. Now I'm converting my stuff
to CLI since gc has been deprecated.

Short of only using 'vanilla' C++, can I ever write code I'm sure will still
be valid 'forever'? That is, code that can be re-used in future projects,
say, 2+ years from now? How can one build a library of tools if the syntax
keeps changing? Hence, I'm even worried about:

"MS has deprecated C++/CLI in favor of C#". <shiver>

Has CLI been made to be 'here to stay", or can we expect some VS.NET 2007
upgrade to possibly deprecate CLI and expect us to learn yet another new
syntax? Like I've mentioned before, one of the purposes of languages like
C++ is the concept it will be re-usable in the future. This constantly
changing the syntax violates that contract.

IMHO, a new version of a product should always be 100% backwards comaptible
IF it's going to be called an UPGRADE. CLI is not backwards comaptible with
'gc', thus requiring conversion time that shouldn't be necessary for an
upgrade, but in this case is absolutely required. Hence, VS 2005 is not an
upgrade to 2003, IMHO, but a 'new' language.

That being said, I really enjoy this new syntax, but wish I hadn't learned
and programmed using "gc" syntax so much. And having done that, I'm worried
a bit about investing time in CLI, since it could be deprecated in a few
years too.

Do we have ANY guarantee along these lines, even in terms of limited-time
(i.e., MS warrants that CLI will NOT be deprecated for X number of years)?

[==P==]
"Willy Denoyette [MVP]" <wi*************@telenet.be> wrote in message
news:Os****************@TK2MSFTNGP11.phx.gbl...

"Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
news:ul***************@tk2msftngp13.phx.gbl...

I never did any benchmarks, so I was basing my statement on other reports.
Thus I believe your findings more than what I've read (even though,
ironically, all I've done is read what you've said in saying this...lol).
So speed is not a selling point.

Still, I prefer to use C++ over C#, probably just because I prefer (am
more familiar with) the syntax. And, I'm afraid of seeing this pop up one
day on the MS website:

"MS has deprecated C++ in favor of C#". <shiver>

C++ != C++/CLI remember!
What's possible is that you may see "MS has deprecated C++/CLI in favor of
C#", but they would never deprecate the language (native C++) they use to
build >95% of their products.
Willy.

[Bo Persson]

"Peter Oliphant" <po*******@RoundTripInc.com> skrev i meddelandet
news:ui****************@TK2MSFTNGP11.phx.gbl...

Here's what I'm getting at. I use to program in C++ before managed
stuff came into play (gc). So, when managed stuff did come into
play, I had to convert my stuff to it. Then CLI came into play. Now
I'm converting my stuff to CLI since gc has been deprecated.

Short of only using 'vanilla' C++, can I ever write code I'm sure
will still be valid 'forever'? That is, code that can be re-used in
future projects, say, 2+ years from now? How can one build a library
of tools if the syntax keeps changing? Hence, I'm even worried
about:

"MS has deprecated C++/CLI in favor of C#". <shiver>

Has CLI been made to be 'here to stay", or can we expect some VS.NET
2007 upgrade to possibly deprecate CLI and expect us to learn yet
another new syntax? Like I've mentioned before, one of the purposes
of languages like C++ is the concept it will be re-usable in the
future. This constantly changing the syntax violates that contract.

IMHO, a new version of a product should always be 100% backwards
comaptible IF it's going to be called an UPGRADE. CLI is not
backwards comaptible with 'gc', thus requiring conversion time that
shouldn't be necessary for an upgrade, but in this case is
absolutely required. Hence, VS 2005 is not an upgrade to 2003, IMHO,
but a 'new' language.

That being said, I really enjoy this new syntax, but wish I hadn't
learned and programmed using "gc" syntax so much. And having done
that, I'm worried a bit about investing time in CLI, since it could
be deprecated in a few years too.

Do we have ANY guarantee along these lines, even in terms of
limited-time (i.e., MS warrants that CLI will NOT be deprecated for
X number of years)?

Noooo!

You will never, ever get any guarantees at all.

I was around when MS introduced Windows 1.0. Several years ago... :-)

At the time, the promise was "learn this new Windows API, and you will
never have to learn another interface again".

Yeah, right!
Bo Persson

[Brian Muth]

"Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
news:ui****************@TK2MSFTNGP11.phx.gbl...

Here's what I'm getting at. I use to program in C++ before managed stuff
came into play (gc). So, when managed stuff did come into play, I had to
convert my stuff to it.
Why? Is someone holding a gun to your head?

In our development environment, we start from the premise that "what isn't
broken shouldn't be fixed". Perhaps there was a compelling reason on your
case, but I wouldn't be seduced into "upgrading" your source code simply
because the features become available.
Then CLI came into play. Now I'm converting my stuff to CLI since gc has
been deprecated.

Short of only using 'vanilla' C++, can I ever write code I'm sure will
still be valid 'forever'? That is, code that can be re-used in future
projects, say, 2+ years from now? How can one build a library of tools if
the syntax keeps changing? Hence, I'm even worried about:

"MS has deprecated C++/CLI in favor of C#". <shiver>

C++/CLI offers capabilities and a blending of the managed and native worlds
that cannot be duplicated with C#. I can assure you it is here for the long
term.
Has CLI been made to be 'here to stay", or can we expect some VS.NET 2007
upgrade to possibly deprecate CLI and expect us to learn yet another new
syntax? Like I've mentioned before, one of the purposes of languages like
C++ is the concept it will be re-usable in the future. This constantly
changing the syntax violates that contract.
I disagree. Language extensions are never a contract, and that is exactly
what the old syntax represented. The old syntax is still supported, so you
have lots of time to adapt to the new "language extensions". Obviously, it
is not in the vendor's interest to keep modifying the language extensions
with each new version. But in this case, the syntax has been cleaned up, and
there is a clearer distinction between native pointers and reference
pointers.

IMHO, a new version of a product should always be 100% backwards
comaptible
Egad.... then I daresay you haven't had much experience putting out a
product that is widely used. There is a natural conflict between maintaining
backwards-compatibility and jettisoning out-dated and dangerous features and
coding styles. The former doesn't always win.

Indeed, even your favourite language C doesn't support the early versions of
the language when it was first developed by Bell Labs. Remember when int's
and pointers could be used pretty much interchangeably? Do you really want
to continue to support that?
IF it's going to be called an UPGRADE. CLI is not backwards comaptible
with 'gc', thus requiring conversion time that shouldn't be necessary for
an upgrade, but in this case is absolutely required. Hence, VS 2005 is not
an upgrade to 2003, IMHO, but a 'new' language.

That being said, I really enjoy this new syntax, but wish I hadn't learned
and programmed using "gc" syntax so much.
I think that is the real burn you are feeling. I managed to skip the "gc"
syntax... it was ugly, and Microsoft indicated this was going to be
revamped.
And having done that, I'm worried a bit about investing time in CLI, since
it could be deprecated in a few years too.
Again, don't worry. This is going to be around for the long term. Expect
improvements, bug fixes, and so on, but nothing as drastic as the recent
"upgrade".

Do we have ANY guarantee along these lines, even in terms of limited-time
(i.e., MS warrants that CLI will NOT be deprecated for X number of years)?

I wouldn't expect a guarantee from Microsoft. But they do listen to their
developers, and they do read this newsgroup, so your posting will be noted.

Brian (and I don't represent Microsoft :-)

[Peter Oliphant]

>>Why? Is someone holding a gun to your head?

This is how it went. I was using 2003 just fine. 2005 comes out, so our
company upgrades. We want the newest stuff because UPGRADES typically fix
any old problems and bugs.

I then took the 'old' source and decided to now use 2005. What's this? It
wants to convert my 2003 source to 2005 format, and tells me there is no way
to reverse? Ok, that's fine, no problem. Then, guess what? It doesn't
compile because its not backwards compatible...

Yes, I still have backups of the 2003 version, and I could use them. BUT -
MS has announced that 'gc' has been deprecated. So, if I continue to use
2003 MS has aggresively announced they won't support my code in the near
future...

So, YES, there IS a gun being held to my head in this matter... : )

The old syntax is still supported...
.... but has been deprecated by MS, and 'deprecated' mean 'will not be
supported in the near future'. So if I choose not to learn the syntax of
2005 MS says I'm on my own...
Egad.... then I daresay you haven't had much experience putting out a
product that is widely used. There is a natural conflict between
maintaining
Yeah, only 20+ published computer games, some of which have sold
platinum...lol I've been designing and programming now for 36 years. One
of my computer game projects took 5 years (that should have taken 2 years)
because CPU's kept upgrading:

286 -> 386 -> 486 -> Pentium

Now this can happen becuase languages change. That's not good...

Again, don't worry. This is going to be around for the long term.

Didn't MS say this about 'gc' syntax too? : )

[==P==]

PS - Like I said, I do love the new syntax, but I now have at least three
different syntax's running around in my head and like 50,000 lines of
library tool code that has seen all three versions. Had they just skipped
'gc' and gone directly to 'CLI' I'd have been mch happier. But hey, I like
product testing (and paying $1000's for the privilege for upgrades) so MS
can get it right... LOL

Seriously, I do think MS is doing a good job here with CLI and the way all
of the languages (VB, C++, J#, and C#) use a common basis. Just they could
have been more forthcoming about how 2003 won't compile under 2005 without
changes...

"Brian Muth" <bm***@mvps.org> wrote in message
news:eJ***************@tk2msftngp13.phx.gbl...
"Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
news:ui****************@TK2MSFTNGP11.phx.gbl...

Here's what I'm getting at. I use to program in C++ before managed stuff
came into play (gc). So, when managed stuff did come into play, I had to
convert my stuff to it.

Why? Is someone holding a gun to your head?

In our development environment, we start from the premise that "what isn't
broken shouldn't be fixed". Perhaps there was a compelling reason on your
case, but I wouldn't be seduced into "upgrading" your source code simply
because the features become available.

Then CLI came into play. Now I'm converting my stuff to CLI since gc has
been deprecated.

Short of only using 'vanilla' C++, can I ever write code I'm sure will
still be valid 'forever'? That is, code that can be re-used in future
projects, say, 2+ years from now? How can one build a library of tools if
the syntax keeps changing? Hence, I'm even worried about:

"MS has deprecated C++/CLI in favor of C#". <shiver>

C++/CLI offers capabilities and a blending of the managed and native
worlds that cannot be duplicated with C#. I can assure you it is here for
the long term.

Has CLI been made to be 'here to stay", or can we expect some VS.NET 2007
upgrade to possibly deprecate CLI and expect us to learn yet another new
syntax? Like I've mentioned before, one of the purposes of languages like
C++ is the concept it will be re-usable in the future. This constantly
changing the syntax violates that contract.

I disagree. Language extensions are never a contract, and that is exactly
what the old syntax represented. The old syntax is still supported, so you
have lots of time to adapt to the new "language extensions". Obviously, it
is not in the vendor's interest to keep modifying the language extensions
with each new version. But in this case, the syntax has been cleaned up,
and there is a clearer distinction between native pointers and reference
pointers.

IMHO, a new version of a product should always be 100% backwards
comaptible

Egad.... then I daresay you haven't had much experience putting out a
product that is widely used. There is a natural conflict between
maintaining backwards-compatibility and jettisoning out-dated and
dangerous features and coding styles. The former doesn't always win.

Indeed, even your favourite language C doesn't support the early versions
of the language when it was first developed by Bell Labs. Remember when
int's and pointers could be used pretty much interchangeably? Do you
really want to continue to support that?

IF it's going to be called an UPGRADE. CLI is not backwards comaptible
with 'gc', thus requiring conversion time that shouldn't be necessary for
an upgrade, but in this case is absolutely required. Hence, VS 2005 is
not an upgrade to 2003, IMHO, but a 'new' language.

That being said, I really enjoy this new syntax, but wish I hadn't
learned and programmed using "gc" syntax so much.

I think that is the real burn you are feeling. I managed to skip the "gc"
syntax... it was ugly, and Microsoft indicated this was going to be
revamped.

And having done that, I'm worried a bit about investing time in CLI,
since it could be deprecated in a few years too.

Again, don't worry. This is going to be around for the long term. Expect
improvements, bug fixes, and so on, but nothing as drastic as the recent
"upgrade".

Do we have ANY guarantee along these lines, even in terms of limited-time
(i.e., MS warrants that CLI will NOT be deprecated for X number of
years)?

I wouldn't expect a guarantee from Microsoft. But they do listen to their
developers, and they do read this newsgroup, so your posting will be
noted.

Brian (and I don't represent Microsoft :-)

[Brian Muth]

>

Yes, I still have backups of the 2003 version, and I could use them. BUT -
MS has announced that 'gc' has been deprecated. So, if I continue to use
2003 MS has aggresively announced they won't support my code in the near
future...
Can you support this statement with a link?

So, YES, there IS a gun being held to my head in this matter... : )

The old syntax is still supported...
... but has been deprecated by MS, and 'deprecated' mean 'will not be
supported in the near future'.

Nonsense.

RDS has been deprecated for 6 years. Yet it is still present in Microsoft
Windows 2003 Server and therefore it is still supported.

"Deprecated" does not mean "it will be not supported in the near future". It
does mean that there is no further R&D in this area. It is a strong hint
that new code should adopt the recommended replacement technology. But it
shouldn't make you panic and start tearing up your old code. In the case of
RDS, the software is sealed, so it means there will be no changes to the
software in future releases. But RDS is still around today. And I'll bet RDS
is going to appear in Windows Vista, identical to the code present in
Windows 2003 Server.

[==P==]

PS - Like I said, I do love the new syntax, but I now have at least three
different syntax's running around in my head and like 50,000 lines of
library tool code that has seen all three versions. Had they just skipped
'gc' and gone directly to 'CLI' I'd have been mch happier.
Agree whole-heartedly.

Seriously, I do think MS is doing a good job here with CLI and the way all
of the languages (VB, C++, J#, and C#) use a common basis. Just they could
have been more forthcoming about how 2003 won't compile under 2005 without
changes...

I have to admit I don't feel the same compulsion to recompile my code under
the latest compiler. I have lots of code that compiles just fine under VC
6.0, and I really don't care if MS stops supporting this version of the
compiler one day. My code will still compile without their support.

[Peter Oliphant]

>> MS has announced that 'gc' has been deprecated....

Can you support this statement with a link?

Sure:

http://msdn2.microsoft.com/en-us/lib...us,VS.80).aspx

Quote on this page ("This syntax" refers to C++/CLI syntax):

"This syntax replaces the previous syntax, known as Managed Extensions for
C++. Managed Extensions for C++ syntax is are still available, but as a
deprecated feature under /clr:oldSyntax compiler option."

[==P==]

"Brian Muth" <bm***@mvps.org> wrote in message
news:OR***************@TK2MSFTNGP14.phx.gbl...

Yes, I still have backups of the 2003 version, and I could use them.
BUT - MS has announced that 'gc' has been deprecated. So, if I continue
to use 2003 MS has aggresively announced they won't support my code in
the near future...

Can you support this statement with a link?

So, YES, there IS a gun being held to my head in this matter... : )

The old syntax is still supported...

... but has been deprecated by MS, and 'deprecated' mean 'will not be
supported in the near future'.

Nonsense.

RDS has been deprecated for 6 years. Yet it is still present in Microsoft
Windows 2003 Server and therefore it is still supported.

"Deprecated" does not mean "it will be not supported in the near future".
It does mean that there is no further R&D in this area. It is a strong
hint that new code should adopt the recommended replacement technology.
But it shouldn't make you panic and start tearing up your old code. In the
case of RDS, the software is sealed, so it means there will be no changes
to the software in future releases. But RDS is still around today. And
I'll bet RDS is going to appear in Windows Vista, identical to the code
present in Windows 2003 Server.

[==P==]

PS - Like I said, I do love the new syntax, but I now have at least three
different syntax's running around in my head and like 50,000 lines of
library tool code that has seen all three versions. Had they just skipped
'gc' and gone directly to 'CLI' I'd have been mch happier.

Agree whole-heartedly.

Seriously, I do think MS is doing a good job here with CLI and the way
all of the languages (VB, C++, J#, and C#) use a common basis. Just they
could have been more forthcoming about how 2003 won't compile under 2005
without changes...

I have to admit I don't feel the same compulsion to recompile my code
under the latest compiler. I have lots of code that compiles just fine
under VC 6.0, and I really don't care if MS stops supporting this version
of the compiler one day. My code will still compile without their support.

[Brian Muth]

"Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
news:eO****************@tk2msftngp13.phx.gbl...

MS has announced that 'gc' has been deprecated....

Can you support this statement with a link?

Sure:

http://msdn2.microsoft.com/en-us/lib...us,VS.80).aspx

Quote on this page ("This syntax" refers to C++/CLI syntax):

"This syntax replaces the previous syntax, known as Managed Extensions for
C++. Managed Extensions for C++ syntax is are still available, but as a
deprecated feature under /clr:oldSyntax compiler option."

You have cleverly edited out the statement you made: "MS has aggresively
announced they won't support my code in the near future..."

That was the statement I was wondering if you could back up with a link. I
assume not.

Brian

[Josh McFarlane]

Peter Oliphant wrote:

Yes, I still have backups of the 2003 version, and I could use them. BUT -
MS has announced that 'gc' has been deprecated. So, if I continue to use
2003 MS has aggresively announced they won't support my code in the near
future...

Honestly why use gc at all? Never got why people felt the need for a
garbage collector.

Sometimes you just have to update things for a number of reasons. All
of the sprintf and buffer copy functions were also declared depreciated
because MS introduced more secure versions (most of the time it just
involved adding _s to the call and letting the compiler handle the
rest)

[Peter Oliphant]

> You have cleverly edited out the statement you made: "MS has aggresively

announced they won't support my code in the near future..."

That was the statement I was wondering if you could back up with a link. I
assume not.
No, I didn't cleverly edit anything out. You ASKED for a link to support my
statement, I gave you a link to support my statement. If there was some
particular aspect of my statement that you want me to address, then you
should have made this clear (which obviously you didn't, and still haven't).
Anyway...

The link I gave has a quote by MS stating that Managed C++ (old syntax) is
deprecated. That was my point, that something that MS released just 2 years
ago is now deprecated. Do you deny this?

But, your right. MS didn't say they would just stop supporting MY CODE in
the future, they said they would stop supporting MANY PEOPLE'S CODE in the
future (i.e., those that bought into old syntax Managed C++).

[==P==]
"Brian Muth" <bm***@mvps.org> wrote in message
news:eX***************@tk2msftngp13.phx.gbl...
"Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
news:eO****************@tk2msftngp13.phx.gbl...

MS has announced that 'gc' has been deprecated....

Can you support this statement with a link?

Sure:

http://msdn2.microsoft.com/en-us/lib...us,VS.80).aspx

Quote on this page ("This syntax" refers to C++/CLI syntax):

"This syntax replaces the previous syntax, known as Managed Extensions
for C++. Managed Extensions for C++ syntax is are still available, but as
a deprecated feature under /clr:oldSyntax compiler option."

You have cleverly edited out the statement you made: "MS has aggresively
announced they won't support my code in the near future..."

That was the statement I was wondering if you could back up with a link. I
assume not.

Brian

[Peter Oliphant]

> Honestly why use gc at all? Never got why people felt the need for a

garbage collector.
I will assume you mean this in general, not specifically 'gc'. As such, I'll
answer you question in regards to why the concept of garbage-collected
classes is a good thing...

The basic problem has to do with ownership. A class is passed a pointer to
an instance of something created externally to it. Simple right? Not really!
Who is responsible for destroying this instance? Well, if the instance is
only to be used by the class, then the class can destroy it when its done
with it. But, if the instance still has usage outside the class, it should
not be destroyed by the class! But if the instance is not used outside the
class, then it should be destroyed by the class, or else you get a memory
leak (memory allocated which is never freed up).

Now, how can the class know whether the instance has further use externally?
Answer: in general, it can't! A class, is typically unaware of the
environment it is in, since many classes are designed for re-usability in
DIFFERENT environments.

An example. Say a class is responsible for displaying the color of an object
representing a toy ball. It does this by taking a pointer to a ball object
and displaying its color. Now, here's the problem. The caller could have
passed a pointer to the instance of the ball itself, or a COPY of this
instance. In the first case, the instance should not be destroyed. In the
second case, the instance passed MUST be destroyed. But the class has no
idea which case is true for any particular call!

Garbage collecting solves this problem since its aware of the ENTIRE
application. Thus, it keeps track of who is using objects, and destroys
those it discovers nowbody is using anymore. It does this by keeping track
of references to the object. A reference is (usually) generated every time a
pointer to the object is created. When the number of these references drops
to zero 'nobody' has any idea the object even exists anymore (since nobody
has a reference to it), and so the GC systen can safely destroy it.

[==P==]

"Josh McFarlane" <da*****@gmail.com> wrote in message
news:11*********************@f14g2000cwb.googlegro ups.com... Peter Oliphant wrote:

Yes, I still have backups of the 2003 version, and I could use them.
BUT -
MS has announced that 'gc' has been deprecated. So, if I continue to use
2003 MS has aggresively announced they won't support my code in the near
future...

Honestly why use gc at all? Never got why people felt the need for a
garbage collector.

Sometimes you just have to update things for a number of reasons. All
of the sprintf and buffer copy functions were also declared depreciated
because MS introduced more secure versions (most of the time it just
involved adding _s to the call and letting the compiler handle the
rest)

[Josh McFarlane]

Peter Oliphant wrote:

Honestly why use gc at all? Never got why people felt the need for a
garbage collector. Now, how can the class know whether the instance has further use externally?
Answer: in general, it can't! A class, is typically unaware of the
environment it is in, since many classes are designed for re-usability in
DIFFERENT environments.

Contracts between the calling function and the destination functions
work quite nicely for me.

If I require an object in a function, I use a reference.

If, for some reason, the object needs to be worried about the life of
the object (Such as a "message" being passed), I make that a condition
of the function if it is the end-point and destroy the object.

If, for another reason, the calling function needs to allocate memory,
call a 2nd function, and then is done with the memory, it is up to the
calling function to remove the memory from play.
An example. Say a class is responsible for displaying the color of an object
representing a toy ball. It does this by taking a pointer to a ball object
and displaying its color. Now, here's the problem. The caller could have
passed a pointer to the instance of the ball itself, or a COPY of this
instance. In the first case, the instance should not be destroyed. In the
second case, the instance passed MUST be destroyed. But the class has no
idea which case is true for any particular call!

If the function is responsible for drawing the ball, it should be up to
the caller function to determine whether or not the allocated object is
through. I mean granted it's around for another cycle or two until you
hit the delete function, but the cost is negligible.

I tend to shun away from using lists of pointers, and generally don't
have that big of a problem with it. I just go with the philosophy of
the allocator owns the pointer, unless it calls another function which
always assumes ownership of the allocated pointer, and that the owner
is responsible for freeing the memory.

Can you give an example where memory would have to be allocated prior
to the function, but the function would require both pass-through and
delete functionality that the calling function could not provide?

[Carl Daniel [VC++ MVP]]

"Josh McFarlane" <da*****@gmail.com> wrote in message
news:11*********************@f14g2000cwb.googlegro ups.com...

Peter Oliphant wrote:

Yes, I still have backups of the 2003 version, and I could use them.
BUT -
MS has announced that 'gc' has been deprecated. So, if I continue to use
2003 MS has aggresively announced they won't support my code in the near
future...

Honestly why use gc at all? Never got why people felt the need for a
garbage collector.

IME there's only one BIG advantage to a GC: it will automatically collect
cycles, while other lifetime management systems (like reference counting)
won't. A lesser advantage of GC is that gen-0 allocation and collection is
very efficient (orders of magnitude faster than a traditional malloc()-like
implementation). But if you don't keep most of your objects in gen-0, this
benefit can be completely overshadowed by the high cost of gen-1 and gen-2
collection.

I general, I agree with your sentiment: By making appropriate use of RAII
(using smart pointers, etc), it's possible (nee, easy) to write native C++
that has no memory leaks at all. I don't think I've had a memory leak in
any native C++ code I've written in the last 5 years or more.

-cd

[Peter Oliphant]

> Contracts between the calling function and the destination functions

work quite nicely for me.
I've used this method to, and it's pretty good. It works fine if I'm the
only one creating the code. However, getting a team to adhere to this
rigorously is prone to error. And this is complicated due to what I think is
a bug in the new VS C++.NET 2005 (Express). I reported it here:

http://lab.msdn.microsoft.com/produc...e-640a4de75f39

Turns out if you use a reference (or value) parameter in a method that only
accepts a pointer it will still compile! Thus, the convention of using a
pointer if you own it and a reference if owned externally is broken (not
your fault!) since both a pointer and a reference are accepted by a method
asking for a pointer! I hope this isn't considered a 'feature' by MS...
I tend to shun away from using lists of pointers, and generally don't
have that big of a problem with it.
How do you deal with variable length lists? Imagine a picture editor. Would
you set a limit as to how many pictures can be editted at a time, and keep
all instances of them around regardless of how many you will actually need?
It is probably better to keep a dynamic list of pointers to each of the
pictures being editted. This extends to many situations where the
application can't know ahead of time how many of something it will need,
especially if this number is only limited by available memory or dictated
by the end-user...
I just go with the philosophy of
the allocator owns the pointer, unless it calls another function which
always assumes ownership of the allocated pointer, and that the owner
is responsible for freeing the memory Can you give an example where memory would have to be allocated prior
to the function, but the function would require both pass-through and
delete functionality that the calling function could not provide?
I'll try. Consider this scenario. A is created. A creates X (allocation). B
is created. B shares X (not a duplicate). What should B do when it is
destroyed? It doesn't know if A still exists, so it can't destroy X. But if
A HAS already been destroyed, then when B is destroyed there is nothing left
to destroy X, so X becomes a memory leak.

Note that A is the allocator of X, but can't be the destroyer if A goes away
before B. And B can't be the destroyer, since it doesn't know if A is still
around when B is destroyed. And even if B somehow knows A has already been
destroyed, B doesn't know if A also shared X with C. If B destroys X and C
exists, C will complain. If B doesn't destroy X and C doesn't exist, X
becomes a memory leak. And what about the possiblity of the existence of
other sharer's of X such as D, E, F. G, H,...?

Only at the application level can it be determined that there is NOTHING in
the application still using X, and so the application is the only thing that
can safely destroy X. That, in a nutshell, is garbage collection! : )

[==P==]

"Josh McFarlane" <da*****@gmail.com> wrote in message
news:11**********************@g43g2000cwa.googlegr oups.com... Peter Oliphant wrote:

> Honestly why use gc at all? Never got why people felt the need for a
> garbage collector.

Now, how can the class know whether the instance has further use
externally?
Answer: in general, it can't! A class, is typically unaware of the
environment it is in, since many classes are designed for re-usability in
DIFFERENT environments.

Contracts between the calling function and the destination functions
work quite nicely for me.

If I require an object in a function, I use a reference.

If, for some reason, the object needs to be worried about the life of
the object (Such as a "message" being passed), I make that a condition
of the function if it is the end-point and destroy the object.

If, for another reason, the calling function needs to allocate memory,
call a 2nd function, and then is done with the memory, it is up to the
calling function to remove the memory from play.

An example. Say a class is responsible for displaying the color of an
object
representing a toy ball. It does this by taking a pointer to a ball
object
and displaying its color. Now, here's the problem. The caller could have
passed a pointer to the instance of the ball itself, or a COPY of this
instance. In the first case, the instance should not be destroyed. In the
second case, the instance passed MUST be destroyed. But the class has no
idea which case is true for any particular call!

If the function is responsible for drawing the ball, it should be up to
the caller function to determine whether or not the allocated object is
through. I mean granted it's around for another cycle or two until you
hit the delete function, but the cost is negligible.

I tend to shun away from using lists of pointers, and generally don't
have that big of a problem with it. I just go with the philosophy of
the allocator owns the pointer, unless it calls another function which
always assumes ownership of the allocated pointer, and that the owner
is responsible for freeing the memory.

Can you give an example where memory would have to be allocated prior
to the function, but the function would require both pass-through and
delete functionality that the calling function could not provide?

[Josh McFarlane]

Peter Oliphant wrote:

How do you deal with variable length lists? Imagine a picture editor. Would
you set a limit as to how many pictures can be editted at a time, and keep
all instances of them around regardless of how many you will actually need?
It is probably better to keep a dynamic list of pointers to each of the
pictures being editted. This extends to many situations where the
application can't know ahead of time how many of something it will need,
especially if this number is only limited by available memory or dictated
by the end-user...
Containers of objects. Granted, I have to sometimes have buffers that
are pointers to char arrays, can't get around that, but they're stored
in a vector of char*s for the program's document / similar class, and
maintained by the controler, rather than the called function / window
and delete'ed as the "closed" command is initiated from the window.
(Also tells the editor window depending on it to shut down and waits
for it to terminate before deleting the buffer pointer.

I just go with the philosophy of
the allocator owns the pointer, unless it calls another function which
always assumes ownership of the allocated pointer, and that the owner
is responsible for freeing the memory

Can you give an example where memory would have to be allocated prior
to the function, but the function would require both pass-through and
delete functionality that the calling function could not provide?

I'll try. Consider this scenario. A is created. A creates X (allocation). B
is created. B shares X (not a duplicate). What should B do when it is
destroyed? It doesn't know if A still exists, so it can't destroy X. But if
A HAS already been destroyed, then when B is destroyed there is nothing left
to destroy X, so X becomes a memory leak.

OK, the one thing I can think of is a shared memory space between two
processes. However, can the garbage collector know what another process
is not using said shared memory space?

Otherwise, you have two possible scenarios from this:

A is called in Thread Foo, allocates X and launches thread B.
If both access the allocated X you've got syncronization problems
already, but the safe side would be that under the assumption that B
was doing processing on X, you'd have to have some way to notify the
main application that processing was done, and that could be done by
posting a message, and that message handles management during results
Note that A is the allocator of X, but can't be the destroyer if A goes away
before B. And B can't be the destroyer, since it doesn't know if A is still
around when B is destroyed. And even if B somehow knows A has already been
destroyed, B doesn't know if A also shared X with C. If B destroys X and C
exists, C will complain. If B doesn't destroy X and C doesn't exist, X
becomes a memory leak. And what about the possiblity of the existence of
other sharer's of X such as D, E, F. G, H,...?
But then you have to ask yourself why do D, E, F, G, H need X data past
the point of when A returns?
Only at the application level can it be determined that there is NOTHING in
the application still using X, and so the application is the only thing that
can safely destroy X. That, in a nutshell, is garbage collection! : )

Avoiding the multi-threading issue of allowing the pointers, and
focusing on single threading for now (Feel free to let me know if you
want to discuss the multi-threading aspect of it), how do you have A be
destroyed before B - H are finished with their processing of the
pointer? If you're using the pointers for anything more than
read-conditions, you have a race issue if you're handling them with an
indeterminate order. If you are simply using them for constant reads,
why not simply make it linking to a const reference in an STL container
in the document or form?

I've just always had the view that the garbage collector is there to
allow developers to have to maintain less of a hold over their
variables. Don't worry about tracking that race condition down, it'll
all delete itself in the end.

Maybe I'm just used to all my variables having a very clear distinct
allocation time (smallest being inter-function, and longest being in
the constructor / destructor of the main window itself) who knows.

[Dave]

On Wed, 7 Dec 2005 13:53:14 -0800, "Carl Daniel [VC++ MVP]"
<cp*****************************@mvps.org.nospam > wrote:

I general, I agree with your sentiment: By making appropriate use of RAII
(using smart pointers, etc), it's possible (nee, easy) to write native C++
that has no memory leaks at all.

Carl, can you recommend any good docs on RAII as you're using it?

BTW, I think a major plus in garbage collection is the fact that it
cleans up code and makes it easier to maintain. Even if programmers
are fastidious in memory allocation, that takes some effort, and the
resulting code is often not transparent.

[David Wilkinson]

Dave wrote:

On Wed, 7 Dec 2005 13:53:14 -0800, "Carl Daniel [VC++ MVP]"
<cp*****************************@mvps.org.nospam > wrote:

I general, I agree with your sentiment: By making appropriate use of RAII
(using smart pointers, etc), it's possible (nee, easy) to write native C++
that has no memory leaks at all.

Carl, can you recommend any good docs on RAII as you're using it?

BTW, I think a major plus in garbage collection is the fact that it
cleans up code and makes it easier to maintain. Even if programmers
are fastidious in memory allocation, that takes some effort, and the
resulting code is often not transparent.

Dave:

If you use smart pointers and the standard library, then RAII just
happens. I don't think garbage collection makes things any easier. And
of course RAII is not just for memory management anyway.

To be fair, I think the primary goal of .NET is to produce verifiably
safe code, and C++ with RAII cannot provide that (unfortunately).

What bothers me, though, is that the CLI seems to have been modeled
after Java rather than C++. This IDisposable stuff rather than automatic
RAII is just absurd. The one good thing about the Managed C++ fiasco is
that it provided the opportunity to break with C# and implement the
destructor and the finalizer in C++/CLI the way they should always have
been.

Although C++/CLI is a big improvement, it still has to deal with the
muddled CLI object model, tacked on top of the very clean C++ one.

David Wilkinson

[Andre Kaufmann]

Josh McFarlane wrote:

[...]
Contracts between the calling function and the destination functions
work quite nicely for me.
But over DLL boundaries you can't pass objects and ownership directly.
And if you have to share code with different languages you have to use
DLLs.
[...]
have that big of a problem with it. I just go with the philosophy of
the allocator owns the pointer, unless it calls another function which
always assumes ownership of the allocated pointer, and that the owner
is responsible for freeing the memory.
[...]

And if there are multiple owners ? E.g. if the object is stored in
multiple lists ? How to keep track of ownership ?

I use reference counting in native C++, managed code does this
"automatically" ;-)

Andre

[Josh McFarlane]

Andre Kaufmann wrote:

But over DLL boundaries you can't pass objects and ownership directly.
And if you have to share code with different languages you have to use
DLLs.

So the GC can see past code that isn't in it's realm, such as native or
VB, or even a shared memory space, or am I confusing what you're trying
to say?

> [...]
have that big of a problem with it. I just go with the philosophy of
the allocator owns the pointer, unless it calls another function which
always assumes ownership of the allocated pointer, and that the owner
is responsible for freeing the memory.
[...]

And if there are multiple owners ? E.g. if the object is stored in
multiple lists ? How to keep track of ownership ?

Never had a reason to have multiple ownership. For items that have
program-lifetime, I handle initialization before spawning whatever else
needs it, still own it, and then deconstruct / destroy it at program
shutdown after the dependant objects are destroyed.

Can you give a concrete example of a variable lifetime for an object
dealt with by 2 different threads that doesn't have an inherant race
condition?

Josh McFarlane

[Peter Oliphant]

> Never had a reason to have multiple ownership.

That's quite possible, since what is required for any particualr application
varies greatly.

Consider, though, if you were a 3D game programmer who wanted to invent an
engine to rival DirectX (I know, blasphemy, I tell you, blasphemy! :) You
realize one of the tricks is to have some texture that can be repeated on
multiple walls in the world.

Does it make sense to have each wall object keep a separate copy of the
texture? Even today this would cause the computer and/or graphics to run out
of memory fast. It is better for each wall object to point to the same
bitmap representing the texture. However, you want to support the broadest
base of possibly machines, so you want to dump textures no longer being used
to reduce end-user memory requirements. Part of the scheme should then
include that if an object needs a texure not already in memory it loads it
in. Fair enough?

In this scenario, a wall could easily discover it needs to load in its
texture, and then future walls could make use of it. But the wall that
loaded it in could easily be destroyed while other walls are still making
use of it. So the allocator can't be the destructor.

Ok, then who does destroy the texture when everyone is done with it? Well,
one clever method might be for the allocator to designate to another wall
still using the texture that it be the 'torch carrier' for destroying the
texture. Then when a wall discovers there are no more walls using it, it
might destroy the texture. This is a bit cumbersome, but could be done using
'static' variables to comunicate amongst the walls. Quick note: Notice how
this method requires GLOBALIZING information amongst the walls...

So, when the 'torch carrier' wall can't find another wall to pass the torch
to, it destroys the texture. But wait!!!! We want this application to be
REALLY efficient, so we cleverly allow that same texture to be usable by
other objects in the world: like furniture, posters, helmets, flags, etc. So
now none of the walls in the wall class can destroy the texture, since it is
necessary to know when no object in the system is still using it. Now we
need to derive everything that could use the texture from one class. Gee,
this is getting even more cumbersome, and even more GLOBAL in scope.
Especially since we just used up all our 'inheritance cards' (multiple
inheitance is not universally supported, such as VS.NET CLI). For example,
now you can't have a derived custom Form class that uses the texture since
no class can derive from both our 'texture-aware' underlining class AND Form
at the same time. Bummer.

So, stepping outside the box, and realizing that the entity responsible for
destroying our texture benefits form being as global as it can be, we see
that the best candidate for keeping track of whether or not any object is
still using the texture is the application itself, since it has the largest
scope for the application (DUH!). And when the application takes care of
destroying things that are no longer being used, this is called 'garbage
collecting"! : )

Yes, of course there are ways around these techniques that don't require GC.
Just like there are ways of doing Windows programming in assembly, or
avoiding object-oriented techniques such as creating classes. One could wrap
the allocation/delete methods, keep track of everything allocated and how
many references to each, and destroy anything not already destroyed upon
exit. But that would be just writing your own GC! Why not instead just use
all the tools available to you if they make life easier?

[==P==]

PS - Josh - how would you do the above texture situation WITHOUT maving
multiple ownership of the texture bitmap in memory?

"Josh McFarlane" <da*****@gmail.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...

Andre Kaufmann wrote:

But over DLL boundaries you can't pass objects and ownership directly.
And if you have to share code with different languages you have to use
DLLs.

So the GC can see past code that isn't in it's realm, such as native or
VB, or even a shared memory space, or am I confusing what you're trying
to say?

> [...]
> have that big of a problem with it. I just go with the philosophy of
> the allocator owns the pointer, unless it calls another function which
> always assumes ownership of the allocated pointer, and that the owner
> is responsible for freeing the memory.
> [...]

And if there are multiple owners ? E.g. if the object is stored in
multiple lists ? How to keep track of ownership ?

Never had a reason to have multiple ownership. For items that have
program-lifetime, I handle initialization before spawning whatever else
needs it, still own it, and then deconstruct / destroy it at program
shutdown after the dependant objects are destroyed.

Can you give a concrete example of a variable lifetime for an object
dealt with by 2 different threads that doesn't have an inherant race
condition?

Josh McFarlane

[Andre Kaufmann]

Josh McFarlane wrote:

Andre Kaufmann wrote:
[...]
So the GC can see past code that isn't in it's realm, such as native or
VB, or even a shared memory space, or am I confusing what you're trying
to say?

I meant implementing a function returning an object in VB.NET and using
the object in C#. With native code you have to use handles or COM
interfaces wrapping the object. Using the object directly is IMHO easier
than dealing with handles.

> [...] And if there are multiple owners ? E.g. if the object is stored in
multiple lists ? How to keep track of ownership ?

Never had a reason to have multiple ownership. For items that have
program-lifetime, I handle initialization before spawning whatever else
needs it, still own it, and then deconstruct / destroy it at program
shutdown after the dependant objects are destroyed.

Josh has given a good example in the other thread, I'll try to give one too:

Example:

You have a thread with a list of objects, let's say objects handling
files. In another thread (mustn't be a thread by the way) you are
selecting some of these and copy the reference to another list, to do
some operations on the files.

After the operation has succeeded you remove them one by one from the
second list. If you have reference counted or managed objects you simply
can discard the object. If not you have to check the first list, if the
object is still inside and if you have to delete it or not.
Can you give a concrete example of a variable lifetime for an object
dealt with by 2 different threads that doesn't have an inherant race
condition?
I don't see one. You have to protect the reference pointer when copied,
to ensure that the object isn't deleted before the other thread has
taken the ownership. And for sure the methods and resources itself.
For managed objects that means you have to protect (eventually) the
dispose method to be called multiple times from different threads, but
that's the price you have to pay if you want / have to use multiple threads.

And as I wrote already, multiple ownership doesn't mean necessarily that
multiples threads must be involved. I find it quite handy to have
reference pointers to an object in multiples list and don't have to care
if it's still used but only have to remove the reference pointer from
the object list.

Doesn't mean that I use reference counting / GC for all of my objects. ;-)
Josh McFarlane

Andre

[Greg]

From a purely language feature perspective does C++ offer more than C#? For
example are templates more powerful than generics?

Basically, I am trying to determine if C# is to C++ as C++ was to C. I.e.
C++ basically replaced C except for specialized things such drivers/embedded
systems development. Has C# basically replaced C++ (except for such things as
native Windows development etc.) as the name C# (C++++) implies?

Should I switch to C# and basically just use C++ only when strictly needed?
With your answer could you please include an overall YES/NO to this question
so we can tally up the YESes vs. the NOs and see what the general consensus
is.

My vote is YES. C# has replaced C++ except for cases when C++ is 'required".



--
Greg McPherran
www.McPherran.com

[aa]

"Greg" <[e-mail]> wrote in message
news:65**********************************@microsof t.com...

From a purely language feature perspective does C++ offer more than C#?
For
example are templates more powerful than generics?

Basically, I am trying to determine if C# is to C++ as C++ was to C.

They're not even related, C#, a pale shadow of C++, is a Microsoft invention
primarily intended to support application development in the Windows
environment.

C++ offers templates, classes and is portable to most operating systems.
Write in C++; run in Windows. Write in C#; run it only in Windows.

[Bo Persson]

"Greg" <[e-mail]> skrev i meddelandet
news:65**********************************@microsof t.com...

From a purely language feature perspective does C++ offer more than
C#? For
example are templates more powerful than generics?
They are not related. :-)

Templates do their work at compile time. Generics is a run-time
concept. In that sense C++ offers something that C# doesn't have.

Basically, I am trying to determine if C# is to C++ as C++ was to C.
I.e.
C++ basically replaced C except for specialized things such
drivers/embedded
systems development. Has C# basically replaced C++ (except for such
things as
native Windows development etc.) as the name C# (C++++) implies?
To me, C# is to C++ as Java was to C++.

Should I switch to C# and basically just use C++ only when strictly
needed?
You should definitely use C++ when needed. :-)
With your answer could you please include an overall YES/NO to this
question
so we can tally up the YESes vs. the NOs and see what the general
consensus
is.
I bet the result will be "No concensus". :-)
My vote is YES. C# has replaced C++ except for cases when C++ is
'required".

It depends on how you determine when it is required.

You can count me as a NO.

Bo Persson

[Josh McFarlane]

Peter Oliphant wrote:

Never had a reason to have multiple ownership.

[Snipped Texture Memory Allocation Example]

Kudos on that example, never dealt with 3D Rendering so never had that
issue to deal with I'll have to get back to you once I let it rumble
around in my brain for a little bit. =)

Josh McFarlane