Board index » cppbuilder » Re: Languages for developing for .NET

Re: Languages for developing for .NET


2004-12-22 10:34:10 AM
cppbuilder104
A program can too easily be architected to be inherently slow. Then when you need to
optimize a huge rearchitecting becomes necessary. That can be expensive in schedule
time and money. I've seen this from other programmers and have been asked to go fix
it. Well, it would have been a lot easier to avoid the problem in the first place.
Look, if you have some array of records and the first time you write a sort on it you
use a bubble sort you can always swap in a quicksort or something else later. So some
kinds of initial use of unoptimal techniques will not hurt in terms of how hard it
will be to optimize later. But I've come across architectural errors that made
optimization extremely difficult.
mr_organic wrote:
Quote
Maybe it's just me, but I'd rather get a program that *works correctly*.
If it doesn't run fast enough, I'll spend a grand or two and buy a faster
box: it's cheaper than paying my programmers for hours of "optimization"
work that doesn't add to the robustness or feature-set of the program.

But hey, maybe that's just me.

mr_organic

 
 

Re:Re: Languages for developing for .NET

Kris Golko wrote:
Quote

>
>RAII ? You still have to call free in Delphi, or did i miss something ?

You do miss something, you don't have to call free in Delphi for .Net,
you can for backward compatibility.
But if you call free it is a deterministic destruction. If you let it go out of
scope and let the GC get it it is non deterministic.
Quote

Kris
--
Jeff Overcash (TeamB)
(Please do not email me directly unless asked. Thank You)
A human being should be able to change a diaper, plan an invasion, butcher
a hog, conn a ship, design a building, write a sonnet, balance accounts, build
a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act
alone, solve equations, analyze a new problem, pitch manure, program a computer,
cook a tasty meal, fight efficiently, die gallantly. Specialization is for
insects. (RAH)
 

Re:Re: Languages for developing for .NET

"Jeff Overcash (TeamB)" < XXXX@XXXXX.COM >writes:
Quote
>>RAII ? You still have to call free in Delphi, or did i miss something ?
>
>You do miss something, you don't have to call free in Delphi for .Net,
>you can for backward compatibility.

But if you call free it is a deterministic destruction. If you let it go out of
scope and let the GC get it it is non deterministic.
Destruction != memory deallocation
The interesting thing about C++ destructors is that its calling is
implicit and guaranteed (for non-dynamically allocated objects). This
frees the programmer from a lot of worries about intra-procedure and
application resource *cleanup* (not just memory).
--
Oscar
 

{smallsort}

Re:Re: Languages for developing for .NET

Randall Parker < XXXX@XXXXX.COM >writes:
Quote
Here is something I've noticed with customers: Most of them do _not_
complain. They are passive. They can be hitting some bug every day and
never report it. So if your customers are not complaining about
performance that doesn't mean anything.
corollary: unless they work in the same building as you do, in which
case they never leave you alone, especially about performance
problems. :)
--
Chris (TeamB);
 

Re:Re: Languages for developing for .NET

Randall Parker < XXXX@XXXXX.COM >wrote in
Quote
Here is something I've noticed with customers: Most of them do _not_
complain. They are passive. They can be hitting some bug every day and
never report it. So if your customers are not complaining about
performance that doesn't mean anything.

You must live on a completely different planet than the one I do: my users
never *stop* complaining about slowdowns, bugs, lack of features, and so
on. They are very vocal about what they want, and I've found this to be
true of users in general. I'd say your experiences are the exception, not
the rule.
mr_organic
 

Re:Re: Languages for developing for .NET

Oscar Fuentes wrote:
Quote
Destruction != memory deallocation
Agreed, which is why calling Free in Delphi calls the destructor, just
like a delete in C++ <g>
Delphi has real destructors, not just finalizers, but you have to call
them explicitly, just as you would for any heap-allocated object in C++
(through delete) Of course, nice libraries will take care of this for
you, which is where the Owner property comes into the VCL.
Quote
The interesting thing about C++ destructors is that its calling is
implicit and guaranteed (for non-dynamically allocated objects). This
frees the programmer from a lot of worries about intra-procedure and
application resource cleanup (not just memory).
This is the feature I believe Delphi for .NET lacks. I am assured the
Interface syntax supports this kind of behaviour in 'native' Delphi.
However, this is not a common idiom as the syntax is not as clean as
C++. Well, you can't beat 'no syntax' for cleanliness and simplicity
<g>
AlisdairM(TeamB)
 

Re:Re: Languages for developing for .NET

"Alisdair Meredith [TeamB]" < XXXX@XXXXX.COM >writes:
Quote
Oscar Fuentes wrote:

>Destruction != memory deallocation

Agreed, which is why calling Free in Delphi calls the destructor, just
like a delete in C++ <g>
Delphi has real destructors, not just finalizers, but you have to call
them explicitly, just as you would for any heap-allocated object in C++
(through delete)
[snip]
I know. I was a Delphi programmer for about 5 years. However, Jeff
mentioned Free and GC on the same context (see his post).
[snip]
--
Oscar
 

Re:Re: Languages for developing for .NET

mr_organic wrote:
Quote
Randall Parker wrote:

>Here is something I've noticed with customers: Most of them do
>not complain. They are passive. They can be hitting some bug
>every day and never report it. So if your customers are not
>complaining about performance that doesn't mean anything.
>

You must live on a completely different planet than the one I do:
my users never stop complaining about slowdowns, bugs, lack of
features, and so on. They are very vocal about what they want,
and I've found this to be true of users in general. I'd say your
experiences are the exception, not the rule.
In both private and government programming, my experience is 90% of
the users - the ones whose boss paid for the program, don't
complain. They may whine and moan about it to co-workers, but they
can't be bothered to call the help desk and report it.
The 10% who do complain are usually total pains in the rear, but
thank goodness they actually bother to report stuff.
-Brion
 

Re:Re: Languages for developing for .NET

mr_organic wrote:
Quote

You must live on a completely different planet than the one I do: my users
never *stop* complaining about slowdowns, bugs, lack of features, and so
on. They are very vocal about what they want, and I've found this to be
true of users in general. I'd say your experiences are the exception, not
the rule.

We have the same issue - people don't actually tell you about problems.
We develop scientific instruments and the software to control them and
process the data. When a developer finally notices something odd in
front of one of the scientists, they just say "Oh yes, its always done
that" but they haven't actually bothered to tell you about it.
Whilst we work for the same company, they are focused on the performance
of the machine and any problem with the software, unless major, they
just work around and ignore and forget to tell anyone about. It is
similar with customers.
A lot of scientists aren't actually that computer literate and asuume
that the problem is with them not knowing about the software, not a
problem with the software itself, so if they can find a way to work
around it, they just do, and don't bother reporting it.
Cheers
Russell
 

Re:Re: Languages for developing for .NET

Oscar Fuentes < XXXX@XXXXX.COM >wrote:
Quote
[...]

The interesting thing about C++ destructors is that its calling is
implicit and guaranteed [...]
...and deterministic.
Schobi
--
XXXX@XXXXX.COM is never read
I'm Schobi at suespammers dot org
"The presence of those seeking the truth is infinitely
to be prefered to those thinking they've found it."
Terry Pratchett
 

Re:Re: Languages for developing for .NET

"Hendrik Schober" < XXXX@XXXXX.COM >writes:
Quote
Oscar Fuentes < XXXX@XXXXX.COM >wrote:
>[...]
>
>The interesting thing about C++ destructors is that its calling is
>implicit and guaranteed [...]

...and deterministic.
Yea. I forgot to add "independently of the execution path followed
after the object was created" which is not really true (an exception
on a constructor breaks this) but it is the feature that makes
__finally unneeded.
--
Oscar
 

Re:Re: Languages for developing for .NET

Oscar Fuentes wrote:
Quote
Yea. I forgot to add "independently of the execution path followed
after the object was created" which is not really true (an exception
on a constructor breaks this) but it is the feature that makes
__finally unneeded.
However, 'finally' has been added to C++/CLI as people coming from
other languages find it convenient <g>
I think it is a mistake, as it seems to encourage a move away from RAII
(which requires a little more effort up front encapsulating the
resource handling into a class) but apparently is one of the more
popular features among those using C++/CLI today.
Looks like C++ ->CLI folks like finally, and C# ->C++/CLI go for
deterministic destructors. I think we can all agree there is a lot to
think about with object lifetimes that the garbage collector does not
touch <g>
AlisdairM(TeamB)
 

Re:Re: Languages for developing for .NET

Alisdair Meredith [TeamB] < XXXX@XXXXX.COM >wrote:
Quote
[...]

Looks like C++ ->CLI folks like finally, and C# ->C++/CLI go for
deterministic destructors. [...]
Um, I assume you meant it the other way
around? Or am I missing something?
Quote
AlisdairM(TeamB)
Schobi
--
XXXX@XXXXX.COM is never read
I'm Schobi at suespammers dot org
"The presence of those seeking the truth is infinitely
to be prefered to those thinking they've found it."
Terry Pratchett
 

Re:Re: Languages for developing for .NET

Hendrik Schober wrote:
Quote
Alisdair Meredith [TeamB]
< XXXX@XXXXX.COM >wrote:
>[...]
>
>Looks like C++ ->CLI folks like finally, and C# ->C++/CLI go for
>deterministic destructors. [...]

Um, I assume you meant it the other way
around? Or am I missing something?

>AlisdairM(TeamB)


Schobi
I assume he meant what he said. Those going from C++ to CLI (i.e. C#,
VB.NET or Delphi for .NET) like finally (otherwise, they wouldn't
switrch <g>) and those going from C# to C++/CLI like deterministic
destructors (since that is what C++/CLI offers).
--
Rudy Velthuis [TeamB] rvelthuis.bei.t-online.de
"The Stones, I love the Stones. I watch them whenever I can. Fred,
Barney..." -- Steven Wright.
 

Re:Re: Languages for developing for .NET

I disagree.... Inside MS, C++ is becoming the .NET language of choice.... I
don't know exactly why ( I've never coded in C# )... but that's what I hear
from some pretty good contacts inside MS.
Al
"mr_organic" < XXXX@XXXXX.COM >wrote in message
Quote
"Remy Lebeau \(TeamB\)" < XXXX@XXXXX.COM >wrote in
news:41c724cc$ XXXX@XXXXX.COM :

>
>From what was shown at BorCon regarding the new C++/CLI architecture,
>things like pointers and direct memory accessing are going to be
>preserved. C++ will be the only .NET language that supports that.
>I've heard it said that C++ is being primed to become the language of
>choice on .NET because of its strong features over C# and other .NET
>languages.
>
>
>Gambit
>

Eh - I doubt it. C# is (and has always been) the "standard" .NET
language, and I don't expect that to change. The only advantage that C++
brings to the table (now that C# supports generics) is its ability to
directly manipulate memory via pointers -- something that .NET explicitly
tries to keep you from doing. If you program for pure performance and/or
have to integrate a lot of legacy C++ code with new .NET stuff, then
C++/CLI makes sense. But for a lot of new projects, C++ makes no real
sense -- the learning curve is so shallow that it makes more sense to
just use C# at the get-go.

As an application developer, I like C# a lot more than C++ for almost
everything. The language is cleaner, the standard frameworks (ADO.NET
especially) give you most of the benefits of the VCL with little of the
pain, and execution speed is pretty good. I'm finding it more and more
difficult to find excuses to use C++ at all, but like I said, this is
from an application-developer standpoint. I'm not writing games or math-
intensive stuff or device drivers.

*Shrug* Whatever gets you down the road, I guess.

Regards,

mr_organic