|
IMO the reason most old-hand programmers dont like GC is because it took a good deal of time to learn to manage memory manually. What oh What will these skills be used for after it is no longer an issue? I know I will miss deleting an heap-allocated object pointer from a FIFO buffer. This style is still possible with c# of course (picking large objects off a queue), but you dont have to clear the memory after the fact. but the "dont forget to delete" voice will sound for a long time to come.
But if your app is still just as fast, why bother with the general-use lower-level languages? "You dont, except when you need it" would be the reasonable response.
only a true scottsman uses pointers....
// Rock
|
|
|
|
|
CLaW wrote:
IMO the reason most old-hand programmers dont like GC is because it took a good deal of time to learn to manage memory manually.
IMO your opinion doesn't have any basis. Actually there is a lot of GC implementations, all done by "old-hand programmers". The reasons that is not widelly used is because most of the time it's not really useful. Let the BS speak for himself thought:
Why doesn't C++ have garbage collection
However GC have been around for ages and if you think you are discovering something new here then you have a lot to learn.
|
|
|
|
|
Your link doesnt seem to be working, but I think I've read that particular one already.
garbage collection is definately useful in a new language, since it guarentees a certain behavior (memory will be cleaned up). The error rate is reduced, which definately can not be argued against, except for the performance implications, which is marginal for most applications.
C++ uses pointers to the core, so I would agree completely that a garbage collector would be to unpredictable (how do you know a pointer is still valid?). It introduces more problems than it solves.
I'll be the first to admit I dont know all I could about this topic, but perhaps because of this I dont see why GC is automatically evil (or at least completely useless) in the eyes of so many.
It removes a source of error at virtually no cost, so why do people not like it so much?
// Rock
|
|
|
|
|
CLaW wrote:
C++ uses pointers to the core, so I would agree completely that a garbage collector would be to unpredictable (how do you know a pointer is still valid?). It introduces more problems than it solves.
Why ? A GC must simply reset a pointer to NULL.
CLaW wrote:
It removes a source of error at virtually no cost, so why do people not like it so much?
Virtually no cost is still a cost, and I doubt it's 'virtually' nothing.
Christian
I have come to clean zee pooollll. - Michael Martin Dec 30, 2001
Sonork ID 100.10002:MeanManOzI live in Bob's HungOut now
|
|
|
|
|
CLaW wrote:
Your link doesnt seem to be working (...)
You must be on the BS black list
CLaW wrote:
garbage collection is definately useful in a new language
Yep, and guess what: C++ can have it any time! (You can use it to track the memory leaks etc, then remove to have efiicient and fast appliciation) Flexibility, power and control - that's what the C++ is all about...
CLaW wrote:
C++ uses pointers to the core, so I would agree completely that a garbage collector would be to unpredictable
It's predictable, you can sleep well.
|
|
|
|
|
CLaW wrote:
But if your app is still just as fast, why bother with the general-use lower-level languages? "You dont, except when you need it" would be the reasonable response.
And when you need it, what do you do when the language is hiding it from you ? As has been pointed out, implimentations of GC are available for C++, but Stroustrup did not build it in for performance concerns. I believe those concerns are as valid today, even if most of us have machines so fast that it's the difference between using 15 % and using 25 % of the processor speed available.
I don't believe there is ever justification to make a program slower or bigger if it can be avoided at minimal cost.
Christian
I have come to clean zee pooollll. - Michael Martin Dec 30, 2001
Sonork ID 100.10002:MeanManOzI live in Bob's HungOut now
|
|
|
|
|
HTML and simple scripting is a fine example of what happens when you make "programming" and programming tools simple. Almost anyone can create a web page. However, just because someone created a website doesn't mean *anyone* would ever want to visit it.
I think C# and .net will be similar. At some point, almost anyone will be able to develop a simple Windows program. It doesn't mean, everyone will want to use it
|
|
|
|
|
Chad Slater wrote:
HTML and simple scripting is a fine example of what happens when you make "programming" and programming tools simple.
While that may be a side affect that was not the intent of the original HTML and scripting designers. They had a unique challenge and created languages which fitted the restrictions quite well.
I can right now open C++ in Visual Studio and create a rubbish app in under ten minutes using wizards etc. So does that make C++ a bad idea? Please. I can do the same in VB, C# and VBScript.
It is how you use something that really counts.
Chad Slater wrote:
It doesn't mean, everyone will want to use it
Nobody HAS to use anything. If something is rubbish, people won't use it. What is the problem here?
regards,
Paul Watson
Bluegrass
Cape Town, South Africa
"The greatest thing you will ever learn is to love, and be loved in return" - Moulin Rouge
Martin Marvinski wrote:
Unfortunatly Deep Throat isn't my cup of tea
Do you Sonork? I do! 100.9903 Stormfront
|
|
|
|
|
Paul Watson wrote:
While that may be a side affect that was not the intent of the original HTML and scripting designers. They had a unique challenge and created languages which fitted the restrictions quite well.
I wasn't implying the intent of the HTML script designers (not sure you how you assumed that from my comments).
Paul Watson wrote:
I can right now open C++ in Visual Studio and create a rubbish app in under ten minutes using wizards etc. So does that make C++ a bad idea? Please. I can do the same in VB, C# and VBScript.
WOW! I'm happy that you can, that's quite impressive
I know that people who created a website using Front Page, Word or other WYSIWYG editor would get stuck on the wizard when it asks if you want an EXE, DLL, static lib, ActiveX DLL etc. etc... You're comparison is quite a leap
|
|
|
|
|
Chad Slater wrote:
I know that people who created a website using Front Page, Word or other WYSIWYG editor would get stuck on the wizard when it asks if you want an EXE, DLL, static lib, ActiveX DLL etc. etc... You're comparison is quite a leap
God you are arrogant. I will bet most C++ coders would not have a clue as to how to put together a proper website. I am not talking about a 2 page personal affair made in FrontPage.
Web development is a skill just as is C+ coding. So back off and stick to your job.
regards,
Paul Watson
Bluegrass
Cape Town, South Africa
"The greatest thing you will ever learn is to love, and be loved in return" - Moulin Rouge
Martin Marvinski wrote:
Unfortunatly Deep Throat isn't my cup of tea
Do you Sonork? I do! 100.9903 Stormfront
|
|
|
|
|
Paul Watson wrote:
I will bet most C++ coders would not have a clue as to how to put together a proper website.
Before I take a bet would you mind to supply one or two examples of what you call a proper website?
Paul Watson wrote:
Web development is a skill just as is C+ coding.
C+? Funny you would make such a typo in that particular statement. It gives me the whole new understanding of the web development... (sorry, couldn't resist )
|
|
|
|
|
Paul Watson wrote:
God you are arrogant. I will bet most C++ coders would not have a clue as to how to put together a proper website. I am not talking about a 2 page personal affair made in FrontPage.
Web development is a skill just as is C+ coding. So back off and stick to your job.
Someone has issues
Code rage maybe?
|
|
|
|
|
Hi,
In subject i read, "For writing faster and ..." !
Is it right ?!
My month article: Game programming by DirectX by Lan Mader.
Please visit in: www.geocities.com/hadi_rezaie/index.html
Hadi Rezaie
|
|
|
|
|
Sure, it can be.
If what you want to do falls within the scope of what .NET is designed to make easier, then yes, you should be able to write your code faster.
Tim Smith
Descartes Systems Sciences, Inc.
|
|
|
|
|
The line is "making programming simpler, faster and less bug ridden"
Which means: "you can program faster", not "your programs will run faster" (although ASP .NET apps run faster than ASP apps, so it does work both ways)
cheers,
Chris Maunder
|
|
|
|
|
Chris Maunder wrote:
The line is "making programming simpler, faster and less bug ridden"
How does .NET make your code less bug ridden ? Do they mean using C#, or in general ?
Christian
I have come to clean zee pooollll. - Michael Martin Dec 30, 2001
Sonork ID 100.10002:MeanManOzI live in Bob's HungOut now
|
|
|
|
|
Christian Graus wrote:
How does .NET make your code less bug ridden
Through things like the use of strongly typed code (C#, VB .NET), garbage collection (to help alleviate memory leaks), array bounds checking (stop buffer overruns) and versioning (DLL problems)
Yes, all these things can be done without .NET, especially if you do things properly like check the return status of EVERY API call, and wrap every piece of code that can throw an exception in try blocks, and release every bit of memory you consume. But that's kind of the definition of a bug: something that breaks because we didn't do something we meant to do.
cheers,
Chris Maunder
|
|
|
|
|
Chris Maunder wrote:
Through things like the use of strongly typed code (C#, VB .NET),
How do you mean 'strongly typed' ? Are you saying that you can't cast implicitly or explicitly in C# or VB.NET ?
Chris Maunder wrote:
garbage collection (to help alleviate memory leaks), array bounds checking (stop buffer overruns) and versioning (DLL problems)
You mean it automatically checks when I put a[52] if the array is that size or not ? A bit like the vector .at function ?
Chris Maunder wrote:
Yes, all these things can be done without .NET, especially if you do things properly like check the return status of EVERY API call, and wrap every piece of code that can throw an exception in try blocks, and release every bit of memory you consume. But that's kind of the definition of a bug: something that breaks because we didn't do something we meant to do.
That's reasonable, and obviously those things make it easier to control such things, but the degree to which time is saved is obviously proportional to the lack of ability in the programmer in the first place.
I asked mainly because I was curious if the percieved saving applied to Microsoft proprietary languages only. I remain concerned about how much they cost, and the dumbing down of programmers who use these languages exclusively, but obviously for the sort of apps .NET is aimed at, speed is not enough of an issue to make the overhead prohibitive.
Christian
I have come to clean zee pooollll. - Michael Martin Dec 30, 2001
Sonork ID 100.10002:MeanManOzI live in Bob's HungOut now
|
|
|
|
|
Christian Graus wrote:
How do you mean 'strongly typed'
eg. things like if (x=1) { ... will no longer be a source of error, since the if statement in C# requires a bool (an int won't be implicitely converted). Explicit conversions are definitely allowed, and the new as keyword in C# makes this easy (and intuitive).
Other type issues such as VB's so called Evil Type Conversion are gone.
Christian Graus wrote:
You mean it automatically checks when I put a[52] if the array is that size or not
Yup. In .NET all arrays are derived from System.Array . If you try to access OOB then the CLR throws a System.IndexOutOfRangeException exception.
Christian Graus wrote:
but the degree to which time is saved is obviously proportional to the lack of ability in the programmer in the first place.
I disagree. In many situtations there are two types of programming battles: that which is spent mainly solving a platform implementation problem (ie fighting with the underlying platform/SDK/language) and that which is spent implementing an algorithm.
Once you clear the hurdle of understanding the CLR and the base class library you can concentrate more on getting results and less with the fiddly crap.
I don't see .NET as somthing that dumbs down programmers, but rather something that says 'OK - we've all had fun writing our own memory management, or writing our own wrappers for system objects, or ensuring we don't stomp over a program's instruction set - so how about we now start concentrating on the application itself, and not OS implementation issues'.
cheers,
Chris Maunder
|
|
|
|
|
Chris Maunder wrote:
eg. things like if (x=1) { ... will no longer be a source of error, since the if statement in C# requires a bool (an int won't be implicitely converted). Explicit conversions are definitely allowed, and the new as keyword in C# makes this easy (and intuitive).
This is indeed a problem, and one that bit me hard a few times until I got into the habit of putting if(1==x) instead. Does this mean I cannot do bool b = (x=1) ?
Chris Maunder wrote:
Christian Graus wrote:
You mean it automatically checks when I put a[52] if the array is that size or not
Yup. In .NET all arrays are derived from System.Array. If you try to access OOB then the CLR throws a System.IndexOutOfRangeException exception.
This has a cost in STL that is quite prohibitive if iterating through large arrays in tight loops, is this not the case in C# ?
Chris Maunder wrote:
Christian Graus wrote:
but the degree to which time is saved is obviously proportional to the lack of ability in the programmer in the first place.
I disagree. In many situtations there are two types of programming battles: that which is spent mainly solving a platform implementation problem (ie fighting with the underlying platform/SDK/language) and that which is spent implementing an algorithm.
What I mean is, I don't leak memory very often, and when I do it's usually a leak that VC detects but actually occurs during shutdown, so having garbage collection won't stop me making errors, as I don't make them that often now. So the more likely someone in C++ is to leak memory, the more that garbage collection will help them.
Chris Maunder wrote:
I don't see .NET as somthing that dumbs down programmers, but rather something that says 'OK - we've all had fun writing our own memory management, or writing our own wrappers for system objects, or ensuring we don't stomp over a program's instruction set - so how about we now start concentrating on the application itself, and not OS implementation issues'.
I agree totally that it's stupid to rewrite the same things over & over instead of using standard building blocks ( like the STL ). Does C# offer container classes and algorithms like the STL ? To me, that is a bigger time saving than memory management.
Christian
I have come to clean zee pooollll. - Michael Martin Dec 30, 2001
Sonork ID 100.10002:MeanManOzI live in Bob's HungOut now
|
|
|
|
|
Christian Graus wrote:
using standard building blocks
Yea, there is a nice selection of building blocks in the System.* Namespace.
Its quite amazing browsing that namespace. Cryptography, strings (conversions, formatting, etc), math, drawing, IO, web, threading. All the basics and quite a few higher level things are in there. Cant wait to turn some of this stuff to web development.
With the beta, I have made some aspx scripts that output JPEGs, generated from GDI calls. Code reuse is though the roof.
// Rock
|
|
|
|
|
Christian Graus wrote:
bool b = (x=1)
x=1 is an int. No conversion between bool and int types is possible. bool b = (x==1) is fine though.
Christian Graus wrote:
Does C# offer container classes and algorithms like the STL
C# per se doesn't, but the .NET Base Class Library (BCL) does (which C#, being a .NET language, can use natively). The BCL is wicked.
cheers,
Chris Maunder
|
|
|
|
|
Chris Maunder wrote:
C# per se doesn't, but the .NET Base Class Library (BCL) does (which C#, being a .NET language, can use natively). The BCL is wicked.
From what ClaW said, it sounds like it could well be. As I keep saying, I would like very much to find the time to play with C#, but I don't see it happening any time soon.
Christian
I have come to clean zee pooollll. - Michael Martin Dec 30, 2001
Sonork ID 100.10002:MeanManOzI live in Bob's HungOut now
|
|
|
|
|
"As you protect people from simple dangers, they get themselves into new and less obvious problems. Someone who avoids the simple problems may simply be heading for a not-so-simple one. "
http://www.research.att.com/~bs/bs_faq.html#invention
-c
Smaller Animals Software, Inc.
|
|
|
|
|
Programming tools are not getting "easier" at all. They are simply taking care of some of the low-level tasks that have become needless. The reason that more modern languages have added features like automatic memory cleanup is that memory is not as critical as it used to be. Most apps running on today's boxes don't have to worry that taking up another big chunk of memory is going to kill a system.
Losing the minutiae of memory management and sandbox restrictions allows programmers to spend more time concentrating on the finer points of UI and application design.
Sef Tarbell
|
|
|
|
|