Re: Exception Misconceptions
"tanix" <tanix@mongo.net>
Finally, when I stamped the buffers with the allocator ID tag,
i was able to get read of those memory leaks.
But the whole point is that it wooks months to even decide to
go after this issue and it took days to rewrite the code,
including the NDIS driver before the solution was finally there.
You see the issue?
Not really. You must use some pretty weird design in coding, that
contradicts all suggestions made for some 10-15 years. Then no wonder you
have such issues.
And I NEVER EVER saw the issue of this kind with Java.
I never had problems with memory leaks in C++. (not like with C). Many
people here have the same experience. Yes, writing programs including
smilar to that you described. Just use a manager, like a smaprt pointer
consistently with every allocation. No leaks possible. (And if you need
to keep blocks unreleased an indefinite time waiting user interaction --
that is not a leak issue, but consequence of a general design decision.)
One heavy duty program I wrote in Java works like a champ
for years without a SINGLE issue with memory leak and gc is
so efficient that it is not far from automatic stack deallocation.
Cool. And *all* I signed off for deployment work the same, and wrt not only
memory but files, locks, and any other stuff that requires cleanup. In C++.
Using the same, quite trivial approach.
And to me, personally, the memory leak issues are some of the
top priority items and it is very unfortunate that this issue
is not resolved to this day in C++.
To my, and probably a big bunch of people this issue is considered as soled
and non-issue for extremely long. If it still hits you there must be some
other issue in the background. And beyond RAII, garbage collection is
also an option to be plugged in, if one really think it is needed or is the
solution for a particular problem.
Sure, you don't have the JVM or MVM to rely upon and the whole
thing becomes quite a trip. But these kinds of things eventually
kill the language for all practical purposes.
LOL. Nice proof.
Take for example the issue with writing a portable GUI code.
Is there such a thing?
It is a nightmare in C++ environment.
Quite so. And in any other if you actually mean portability. Then if you
limit it sufficiently, you may reach down to a solution. If you define the
limitation in a special way, sure, that may get similar to a some stock
solution tied with some language too.
Microsoft does it their
way, Linux/Unix does it their way, all sorts of graphit toolkits
do it their way. It is a literal nightmare.
With Java, it is a non issue.
I saw a couple of projects that switched to java for that property (or
switched the interface, calling out for "work" written in whatever else),
experience shows the picture is far from that bright.
And the "success" stories I saw have a really simple, and uncool
interface -- that looks pretty alien on at least one platform, if not on all
of them.
"non issue" is an easy claim that is prevalent in hype and forums, but
that's it.
And I am not even using the swing version of GUI.
AWT is just fine for what I am doing and the user interface
is probably the best you can imagine in the wildest dreams.
I could care less about swing. Everything is just fine.
Great. So the next question is what on earth you do in this forum then?
Instead on living the happy life with java and AWT?
And it is a pitty that C++ can not satisfy either of these morst
critical elements for me.
Why should C++ do anything when you already found your silver environment?
Why turn C++ to clone an existing and established thing?
And I saw plenty of posts by different people and their opinions
on it, and it basically lead nowhere. No progress so far that
I know of in none of the most critical areas of modern programming
languages. Even stinky Javascript does not have as many portability
prblems as C++. What a pitty!
Another mega-LOL. Can't imagine why half of the code fights to determine
what browser it runs on.
And again portabili=ty in your view looks meaning like 2 system sets and
that is it.
While in fact C++ reaches to a massively wider set. With some requirements
on the user, and with attached cost. While other languages made the choice
up fronmt to limit where they work. TANSTAAFL.
so memory leak can not be one problem if one use these special "malloc"
functions (like i use always with all bell that sound)
Not do worry, I did all of that.
The point is how much time and energy you have to waste to bother
with stoopid things like memory leaks?
My measure is 0 in simple situations, and "not worth mentioning" where the
design is complex.