|
We can't make it too easy for ourselves.. Why do we want all these new stuff? What happened with the days that developers were real developers and did what they were paid for/liked : developing software on a high level.
With all new stuff we can expect in the next months/years, every moron can write applications. Only these ones will be more buggy and unstable than the one we write. Applications will crash more often, giving us a bad name. 50% of the users will blame Windows (Yeah, it crashed.. damn Windows), the other 50% will blame every developer on this globe (Your colleague can't write solid code, so neither can you).
Or maybe I just need some sleep and think it over...
--
Alex Marbus
www.marbus.net
But then again, I could be wrong.
|
|
|
|
|
I agree with you totally - the problem with these -easy- frameworks is they will make developing *seem* easier, but will not teach good design, etc. The result will be more buggy code out there, you only need to look at some of the VB code people try to sell as shareware on the web to see that.
Christian
#include "std_disclaimer.h"
The careful application of terror is also a form of communication.
Eagles may soar, but weasels don't get sucked into jet engines.
|
|
|
|
|
I'm probably just being an idiot, but I'm not familiar with this particular TLA. 
(I'm sure I'm not the only one who needs this explained, but I'm just brave enough to ask...)
Jason
|
|
|
|
|
|
Although I love speed in C++ but for most cases and as per the project needs I go for "Control over object lifetime" because I beleive that a good "Control over object lifetime" will bring you the "Fastest code execution" as a very welcomed by-product.
   
Farhan Noor Qureshi
|
|
|
|
|
What is it that you need when you want control over the object's lifetime - is it control over the resources that the object uses, control when memory for the object is allocated/deallocated, or do you need to know exactly when objects are destroyed?
cheers,
Chris Maunder (CodeProject)
|
|
|
|
|
Let's see, the choices are:
A. Control over the resources that the object uses.
B. Control of when memory for the object is allocated/deallocated.
C. Knowing exactly when objects are destroyed.
I can tell you now, from a long-time-C++-developer-turned-Java-weenie, that option A is what I miss the most. The fact that you can write a C++ class to wrap a resource allocated/freed via object construction/destruction is just awesome -- no try/finally clauses all over the place.
The other two options I haven't found important since I've been using Java to write business apps. Still, I could see them being critical in speed/memory intensive apps.
Regards,
Alvaro
|
|
|
|
|
From all posibilities, I think A is the least important (At least, in my opinion).
I believe that the developer _always_ should have control when he/she decides to allocate the object, and de-allocate it. It's my freakin' object, I decide when to kill it! (both B and C)
--
Alex Marbus
www.marbus.net
But then again, I could be wrong.
|
|
|
|
|
Hmmm, having control is nice but I've found it only necessary in speed/memory critical apps. In business apps it's not critical; you basically create your object, use it, and forget about it. In C++ you typically allocate such objects on the stack and let the compiler clean up when they go out of scope; in Java/C# you let the GC do it for you. I guess my point is, if you compare the times when you really care about when something is destroyed vs. the times when you don't you'll probably find that in most cases you don't.
|
|
|
|
|
I don't agree. In the applications I wrote, whether they're for business use or any other (e.g. personal) use' control of an object's lifetime is always important.
Can't name specific examples (It's 2 am here in the Netherlands ), but I'm sure you can think of something.
Keeping track of when an object is created, and when it's safe to delete is definately the job of the developer.. Otherwise, things would be too easy and we would all end up developing VB
--
Alex Marbus
www.marbus.net
But then again, I could be wrong.
|
|
|
|
|
Alex,
When I say business apps I mean apps that work with a database server to allow the user to view, add, edit, or delete business-related information. They basically show forms for data entry/retrieval -- nothing scientific about it. Such apps are typically written in VB, ASP, Java, JSP, etc. because they're not memory or speed intensive and because those languages/technologies make building such apps quick and easy.
Now, as far as keeping track of your objects lifetime; I still say that most of the time you don't need to. The best example to prove it is the "string" object. I'm sure you use some sort of string class in your code, right? Think about how you use it. You basically instanciate it, use it, and forget about it. You don't worry about when or how it gets destroyed... why? Because it's not important most of the time.
Regards,
Alvaro
|
|
|
|
|
1. control over the resources that the object uses,
2. control when memory for the object is allocated/deallocated,
3. when objects are destroyed
If you can control *all* three of the above (thats what a C++ programmer does!!!) then you produce a very high level code that,
1. easiest to maintain/debug
2. has a small memory foot print
3. is one of the fastest in finishing the task
If do not have any/all of them then your program,
1. starts with *megabytes* of memory
2. keeps on eating memory and other resources
3. and slows down as the time passes (mainly b/c of memory fragmentation, and inefficient use of resources)
So the bottom line is I want *ALL*.
Farhan Noor Qureshi
|
|
|
|
|
Do you feel that writing managed C++ doesn't give you control over 1, 2 and 3?
I've been thinking about your answer and a few questions have bubbled up in response.
How does having control over all 3 make for code that is easier to maintain? How does that ensure that you have a small memory footprint? How does not having those 3 mean a large starting footprint, that resources leak, and that memory is fragmented?
My thinking is this: if you write managed C++ and accept the use of the garbage collector, then you
1) still have full control over the (non-memory) resources an object uses
2) you still decide *when* an object will use memory resources (you just can't decide when that memory is free'd, unless you call for a global garbage collection)
3) You have no idea when an object is destroyed - but is this important (a serious question, not a rhetorical one)
Using the GC to handle memory means that you code is simpler and you won't have memory leaks, so it's easier to maintain and debug. The footprint size may be bigger because memory will hang around longer. This doesn't mean (necessarily) it will slow down over time (as compared with a comparable non-managed app). The slowdown will be at GC time. The time spent in garbage collecting will be the interesting factor here - but MS are aiming for it to take the same time as a page fault. Who knows.
Also, using a GC means that you still only allocate what you need, when you need (point 3.1). You still have to be careful with resources (which you allocate and release normally), and freeing references to memory so the GC can reclaim them - which means resource and memory leaks will (should!) not occur (point 3.2), and allocating memory on the managed heap actually means that fragmentation is vastly reduced, so page faults will be less and caching higher (and memory allocation much faster) (point 3.3).
[Note to MS: Please make out my 'covert salesman' paycheck to Chris c/- CodeProject]
cheers,
Chris Maunder (CodeProject)
|
|
|
|
|
>> Note to MS: Please make out my 'covert salesman' paycheck to Chris c/- CodeProject] cheers, Chris Maunder (CodeProject)
Now we all know what MS did to you during your frequent trips to Redmond -- 'a complete brainwash'.
_________________________________
Get RadVC today. Play RAD in VC++
http://www.capitolsoft.com
|
|
|
|
|
|
Chirs,
View my last reply in the light that I have done programming in C++ and it is my experience as a C++ developer than if you are making the best use of C++, encapsulating the functionality in small, maintainable classes *IS* very important. And this will bring you results like small memory foot print, better resource management and speed. I have seen tons of very good C++ code that helps the developer in all aspects from debugging to extending.
These days I am working in java which deprives me of the control that I used to enjoy in C++. Therefore my programs need memory in order of magnitudes, they run slow and I dont know when my objects are freed and resources de-allocated. Also note that I have not done any managed C++ yet. May be managed C++ or C# is not yet another java and gc by MS is not similar to gc by Sun
BTW: your points 3.1, 3.2, 3.3 sound interesting, I'll try to get the taste of managed C++ as soon as I get time.
Farhan Noor Qureshi
|
|
|
|
|
So are you saying that even beyond notions of memory management, caching, fragmentation etc, simply having well designed and well encapsulated functionality will bring about speed and efficiency as a by-product of prior planning?
I think I would agree.
If only I would practice what I preach
cheers,
Chris Maunder (CodeProject)
|
|
|
|
|
Wouldn't the 'Complete ISO C++ Implementation' cover 'Control over object lifetime'?
|
|
|
|
|
Given that they are behind on giving us this for C++ WITHOUT the CLR, why would using the CLR make them MORE likely to conform ?
By control over object lifetime I think they are talking specifically about operator new/delete, and maybe being able to put things into a scope. ISO I presume to mean fixing all the template stuff etc. that is broken.
Christian
#include "std_disclaimer.h"
The careful application of terror is also a form of communication.
Eagles may soar, but weasels don't get sucked into jet engines.
|
|
|
|
|
When writing managed C++ you can let the garbage collector control your object's lifetime.
cheers,
Chris Maunder (CodeProject)
|
|
|
|
|
Or rather when writing managed C++ you can loose control over your object's lifetime...
|
|
|
|
|
So how does the thing work in C++ - I understand it for C#? Say if you had the following:
CObject *pObject = new CObject;
pObject = NULL; that this work no longer be a memory leak because the now NULL pointer would be picked up by the CLR and the memory garbage-collected on the next cycle?
> Andrew.
|
|
|
|
|
Yep - it's as easy as that.
cheers,
Chris Maunder (CodeProject)
|
|
|
|
|
I hate this kind of Java-style programming practices. It force the programmer to pay less attention on what he does, and as a result the application will run slow, the memory footprint will be huge, etc, all because of this "admired" garbage collector. Remember that the garbage collector is consuming resources also. And generally speaking , this .Net stuff transform the programmer in a kind of fancy power user, and personally I am very disappointed to see how the robustness of an application ( speed & size) is traded for speed of development. Viva VB !  .
|
|
|
|
|
I don't think that writing managed C++ is a good idea. Keep C++ for the native code apps, and for CLR use C#.
I vote pro drink 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
