Exception Misconceptions

[tanix]

[...]

---I'd guess that correctness would be the most important one
(but even there---correctness is only important for the
features you use).

Well, correctness is a vague concept overall.
Correctness of what?

Of the compiler, since that's the tool we're talking about.

Well, I thought you are talking about correctness of code,
or formal correctness of your program. To me, I could care
less if compiler exists. It should just compile. That is ALL
I care about, and if we start talking about correctness of
COMPILERS, it tells me there are issues with language itself.
Long subject.

If
the code generated by the compiler doesn't do what the language
says it should, then you have a very big program. It's a low
level correctness, but it's still an essential one.

I do not argue this point.
It is very unfortunate the issues like these even arise,
even though they forever do in a "real world" situations.

(I won't bother replying to the rest. The problems of the
poster should be obvious to any reasonably mature person who
reads it.)

:--}

To tell you the truth, you were one of my personal favorite
experts on C++ related collection. I always enjoyed reading your
posts because they were not simply dumb. But had depth, some
freshness and insight to them. In other words, a pretty pleasing
favor.

But...

The love affair forever comes to an end. So is the nature of things.
When I met you eye to eye, it was a totally different person.

You bother to reply or you don't "bother" to reply,
it is a matter of intellectual and scientific honesty
and the depth of your insight and a few other things.

It does not matter to me one iota.

It is YOUR choice wethere like to investigate deeper into issues
or remain as a coward, carrying a "holier than thou" mask on your
face. I could care less.

MY choise is to investigate ANY issues I am dealing with, until
no stone is left unturned.

So, I can talk to you until your nose goes blue, unless you lock
up as you just did, which simply means to me my original post
was right on the money, if you flipped out so bad.

So, be thankful to people like me giving you a chance to see
some things about yourself that you suppressed all your life,
carrying that "holier than though" phony mask on your face.
Cause we'll take that mask down in no time and we will see the
raw nature of who you are within the first steps, and that is:

1) Intellectual dishonesty.
2) Scientific dishonesty.
3) Arrogance of "holier than though".
4) Theoretical crap that has very little to do with reality,
as reality, in this particular case, is the issue of C++
basically dying and being replaced in more and more areas
and appications with languages that do not have these kinds
of problems, and some of you "experts" simply refuse to
look into it and realize your house is on fire.

Things like that.
If you do not appreciate all this, not a problem at all.

--
Programmer's Goldmine collections:

http://preciseinfo.org

Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.

 

[Balog Pal]

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.

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.

 

[tanix]

On Dec 17, 8:11 pm, Brian <[email protected]> wrote:

[...]
The machinery isn't that complicated. After all, you
need to be able to walk back the stack in other cases as
well (e.g. in a debugger---and what compiler doesn't
come with a debugger). The alternatives are relatively
expensive, and some people do choose their compiler
based on benchmark results (and those benchmarks rarely
test the performance when an exception is thrown). For
better or worse, performance is an issue for compiler
vendors---lower performance means less sales.
When buying a car I care about how fast it goes from 0 to
60. There's flexibility about the range for that with me,
but if a car is two to three times slower than others in
that regard, it's a big red flag
So you won't consider cars like the VW Golf, since a Ferrari
does accelerate two or three times fasters.
Actually, I'm sure you didn't think that statement out.
Performance is only one of many issues---I'd guess that
correctness would be the most important one (but even
there---correctness is only important for the features you
use). Or even availability: early implementations of
exceptions used the slower mechanism because they could get
the implementation out the door quicker that way. And so
on.

I'm not arguing with that, just saying that with the software
in question, both are free. If price/cost isn't a factor, I'd
definitely take a Ferrari.

You don't have three children. I wouldn't mind having a
Ferrari, either, but for day to day use, there are more
practical cars. Regardless of price. With three children and
two dogs, a van beats a Ferrari hands down. If you really live
out in the wilderness, with only dirt roads, you'll probably
prefer a Jeep. And if you have to drive and park a lot in
Paris or London, you'll want something small. As with software,
there's no silver bullet.

With regards to exception handling and C++ (to get back on
subject), if some of the early implementations of exceptions
used slower mechanisms than is considered necessary today, it's
generally because it was a question of supporting exceptions now
with the slower mechanism, or supporting them in two years time
with an optimal mechanism.

I am not going to comment on exceptions.
This issue is done to me. I know EXACTLY how to architect
and strucuture my code so that it works like a tank,
no matter what happens. It is a subtle mix of return codes
and exception mechanism, but there IS a solution, and it
is all implemented in one of my Java programs, the main
program I use.

Similarly, with regards to optimizing application code: you've
only got so much time to write it in, so it's often a question
of making it take 5 milliseconds less time (over an hour), or
adding a feature.

Well, to me, optimization is indeed one of the major criteria,
except I view optimization from the stand point of architecture.

There are different ways to structure your code,
or architect the system.

The major criteria for me are:

1) Minimization of the size of executable,
which indirectly translates into correctness of your code
and flexibility of your structure and program architecture.

2) System architecture.
Structuring the program is more important to me than
tweaking some routines to get the most bang for a buck.

3) Expandability and extensibility.
No matter what you write, you will have to forever expand it,
add more features and bells and whistles.
If your architecure is not "correct",
it is going to be a royal pain on your rear end to add
something QUICKLY.

I can add totally new functionality to my code within minutes,
no matter what i want. Typically, a MAJOR restructuring
takes several hours. At most a day or two.

So, I can expand my code as fast as I get some new idea
or feature.

4) Portability.
A tough one. Forget about it in the C++ world.
Such a major headache, that it is realistically undoable
unless you maintain several code bases.

With Java - a pice o cake. Non issue.

5) Robustness.
And THAT is where these nasty exceptions come in handy.
You'll never be able to write a stable code, and I mean
TRULY stable, if you do not use exceptions.

Otherwise, your code is going to be such a huge file of
conditional spagetti, that only God, omniscient, will be
able to see the net result.

Exceptions are a MUST.

But...

No need to get wild on it.
Exceptions should not be a part of your logic.
After all, what guides your program in 99.999% of all cases
is those nasty ifs and buts and not "something does not work".

So, exceptions should not be a part of your underlying logic.
They are your defense system against ANY kinds of problems.
You can NEVER assume that ANY operation is going to complete
without problems. In the middle of some routine, you may
loose power, just for the sake of argument.

That means, that once you restart your program, and it was
in the middle of doing some heavy duty processing, you should
be able to recover and continue on, if at all possible,
even in principle.

6) Never, under ANY condition, ignore ANY errors, even if
it looks like it will never happen and your code works fine
as it is.

Unless you handle the most inconceivable thing,
such as seemingly utterly meaningless return code,
your program eventually and inevitably will crash
one of these days.

7) Always complete your code.
Once something is written, it should be written to the state
of completeness. Meaning. You should be able to rely on that
code no matter what happens and no matter what kind of crazy
thing you may invent in the future with your system.

The complete code is easy to extend and restructure.

8) Program is a system.

This is probably the #1 item on the list.

Any more or less useful program is a SYSTEM.
It is not just a pile of code.

a) The most important system parameter is what?
Well, stability.
If system can EVER crash, you are dead and your program
isn't work a dime more or less.

b) The system is not a dissasociated set of ideas,
methods and routines.

It is an organism, alive, just like anything else on this
physical plain.

Any system has subsystems, performing diferent sub-tasks
to accomodate the living whole.

Subsystems, in their turn are also systems.

There needs to be a well thought out architecure
to minimize the number of subsystems and maximize the
bang for a buck.

Subsystems need to communicate with each other
and provide "sockets" for relating with other subsystems
or the master system. The best way to assure that is to
do all the communications via master system, which
is the main module of your program.

Every subsystem is guaranteed to know one thing
and one thing only: there IS a master system it serves.
It can rely on existance of it.

All interfaces should be constructed via master system.

No subsystem should attempt to communicate with the other
subsystem, or even know of its existence, if at all possible.

This way, your program architecture and structuring
of your code will be automatically optimized in most
cases and situations.

Do not worry about performance first. But keep it in mind
no matter what you write.

The original ideas need to be fundamental enough to
provide a significan enough benefit to even bother about
implementing it. From that standpoing, the modelling is
the most critical thing at this junction.

Once you implement your model and test it to sufficient
degree, then you will be able to see the weak points
and those things you did not think about initially.
At that point, you can start thinking about optimization.
But not before it.
Never start writing the most optimized code from the
fist take. Becaue it is not even clear it will become
a bottleneck in the final system.
Just tweaking things for the sake of "performance",
is the same thing as blind leading the blind.
The end result is the abyss.

I think all really competent computer scientists are purists,

Good. Keep them in museums then.
If someone has time to look at that stuff before the
end of times, and we have about 2 generations to go
before REAL hell will rage on the planet Earth,
abused to the hilt.

Get the hint, mr. "expert"?

and would like for every line to be
"optimal" (foremostly in elegance and readability, but also in
terms of performance).

Fine and dandy.
In THEORY.

In reality there is such a thing as "bang for the buck".
The "economics" of anything created.

The "purity" of code is more or less a mental masturbation
excersize, and I am not trying to be insultive.

I also keep in mind the code purity.

What I can tell is is this.
The 3-5 meg programs I wrote do pretty much the same thing,
if not better, than a typica half a gig sized bloatware,
written by "top guns".

That is ALL I need to say about "optimization"
or "purity of code", or "correctness", no matter what you
imply by it, and what scope you are referring to.

I also think that all really competent
software engineers know how and when to make engineering trade
offs.

I have to agree on this one.

Enjoy the ride.
:--}

--
Programmer's Goldmine collections:

http://preciseinfo.org

Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.

 

[tanix]

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.

Cool. You are the kind of person I like to talk to then.

The only issue is I could describe you the situation,
but it is going to be a long post. But let me try and see
if you can suggest something "better".

Ok, the situation is this:

I have a monitoring firewwall app, that is the number one program
for me, no matter what. That is the first thing I install once
I install a new operating system.

What it does is this:
There is a monitor window, that shows all the network packets
that are not a normal and safe traffic.

There are several rule sets: stealth, trusted, policy and per adapter.
The program supports as many network adapters as you wish.

When normal traffic occurs, you don't see anything. It just all works.
When you are attacked, or there is some fishy traffic,
the unknown packet dialog box pops up, if you click on "prompt"
checkbox in the main program window.

When some packet arrives, the driver checks all appropriate rule sets,
and if it does not have a rule for that packet, it places it on its
NDIS intermediate driver queue and sends the packet and all relevant
info to the user app.

Once the user app gets a funky traffic indication, what can it
possibly do? Well, if no "prompt for unknown traffic" checbox
is checked, it simply quietly drops that traffic.

But if it IS checked, then what can you possibly do?
First of all, all such traffic is automatically displayed in the
listbox in the monitor view. So, what you have is a buffer
allocated for the entire packet and for other service information,
so that the app can do all sorts of things and make all sorts of
decisions.

If, hours later, you decide to look at the actual packet data
for any packet int he monitor window, all you have to do is to
click on some packet in the monitor window and the click on
"show packet" button in the main window.
Two mouse clicks in toto to see ANYTHING that is fishy going on,
going back in time as long as you want.

Now. Since the listbox has a pointer to a buffer, allocated to
that packet, it is reponsible for releasing that buffer once the
monitor window reaches the max number of monitor entires you
are interested in seeing in the future. That may be seconds,
minutes or even days into the future.

But what if you have "prompt for unknow" checkbox enabled?

Well, a lil tough one. In order for you to inform the driver
about one of funky packets on its pending queue, you need
to create a rule for such packets: either allow or deny them,
or do nothing, meaning if such a packet happens in the future,
you'll start from the top.

So, do you need to know abut that packet if user goes to his
kichen to get a cup of tea?
Sure you do.

It is all pending until user finally clicks of some checkbox
in the unknow packet.

The processing of unknown packets is thus asyncronous.
Furthermore, you may have a NUMBER of those packets on a queue,
in case you are being attacked.

Zo...

How do you design such a thing?
ANY clue?

Gimmme your rough model and we'll see whose code is designed
"better".

I never had problems with memory leaks in C++.

I bow down to you, or immortal!

Except my lips are smiling.
What a fool they say in combination with my brain.

(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.)

Well, may be. If I ever find time to look at the design again,
who knows, I may even consider your "smart pointer" suggestion.

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.

:--}

You must be trully great. What a pleasure.
Let me see if you are on an expert filter list.
Uuups. You are not. Well, now you are.
Welcome to programmer's golmine world.
Now your articles are guaraneed to be seen by the cream of the
crop around the world, the biggest names in industry and ANY
industry for that matter, including the leaging universities,
libraries, the biggest names in sw industry and you name it.

From now on, whatever you write is going to be presented in
a highly fitlered expert section on all major issues with C++
language, tools, mechanisms, methods, programming techniques
and you name it.

Btw, since I am spending a few days around on this group,
if any of you, experts (those, that know what they are talking
about) have any idesa, proposals, new chapter requests,
filter specifications, be my guest. You can email your feedback
to preciseinfo at mail dot ru.

From now on, you are a part of global information system,
providing the top quality, to the point information on C++
for generations to come.

Once you write something, we don't have to deal with that issue
any longer, if your writing is up to snuff.
From then on, there is no need to suffer in the buffer for days,
trying to see what is wrong and where or how do you do this and
that.

Dig?

To my, and probably a big bunch of people this issue is considered as soled
and non-issue for extremely long.

I am glad to hear that.
Unfortunately, I don't know you enough to see how much
what is you say is worth. ALL I know is it is solved for what
I am doing in Java, which is my preferred language for several
years, and I am happy to hear that you think it is solved in C++
also, even though I have my doubts.

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.

Cool. I did not know that. Not that I much care about it now.
Again, I am working in Java lately. Do not have much hope for
C++ and would not invest a penny into writing any new code in C++,
unless it is absolutely necessary, which I do not see so far.

LOL. Nice proof.

:--}

I am glad to hear that!!!

Is there such a thing?

Yep. Ther IS. Believe it or not.
It is called AWT or modern version is called swing.
Gives you 100% portable GUI code.

Sure, the fine details of the LOOk of some visual components
are going to be rendered slightly differently, especially in
light of Microsofts pattent issues. But the overall functionality
of your GUI is going to work 100% on any platform wher you can
install the JVM. Simple as that.

Beyond that, it is a non issue in Java.

Because of that JVM idea, which is the equivalent of MVM,
except of totally sick limitations placed by Microsoft on
making it as simple and as straightforward to implement
and deliver as a single app.

The nice thing about Microsoft MVM is that is has about twice
better performance than Suns JVM, which is what I really
appreciate. Because when I do my processing, archive updates
and site generation, jobs run into hours, if not days.

Quite so. And in any other if you actually mean portability.

Yes, I actually DO mean portability.
And it is a non issue with Java.
Sorry to tell you that.
And I mean BINARY compatibility.
Meaning you can run your executable code without even recompiling
on ANY O/S where you can install a JVM, which is free, no string
attached virtual layer on the top of O/S, which shields you from
memory leaks, GUI, threading issues, and ALL sorts of things,
including the language syntax, which is FAR superior to C++
in my opinion.

It is like a hand in glove for me now.
When I had to fix some bugs in my monitoring firewall, written
i C++, it was like a headache in comparison to anything I wrote
in Java. It was like visiting some ancient fortress, filled
with spider webs all over.

Sorry to tell you that.

Even stoopid and clumsy PHP looks more exciting to me,
with ALL its limitations and weirness.
Yes, it is because of things I am doing lately.
But during the last several years, I had not a single urge
to write some code in C++.

Sure, lots of water has flown down the river and I did see
some stuff you guys write here, except it is too late.
The train has left the station for me.

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.



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.

Well don't know where you get it from.
But it is bright enough for what I am interested in.
In fact, I'd say it is far superior to all the Microsoft ugly
hacks in GUI design, that cause nothing more than goose bumps
when I even think of it. I can implement a much better functionality
of GUI in Java in about 2 to 10 times less of a time,
doing ANYTHING I can imagine as far as GUI goes.

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.

Too bad. I don't happen to share your opinion.
But again, I am interested in thing I am doing,
and not just some abstract theory of perfection.
So, who knows, you might have some point here,
except lil do I care. I am fine as is right now.

"non issue" is an easy claim that is prevalent in hype and forums, but
that's it.

Sorry. I stand by what I say.
When I say non issue that is what it means literally.
There is no issue that I see.
And I am not peddling Java here. Too bad everyone seems to be
abandoning it in a hurry. The traffic on Java collections of mine
are about 10 times as small as for MFC.

And, interestingly enough, C++ traffic is no more than
a half of MFC/VC/ATL/STL collection, which tells ME something.
Not sure if it tells YOU something though.

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?

Do you mind?
:--}

To tell you the truth, I do not know.
I just came here a couple of days ago for some small things.
One thing leads to another.
I saw some posts on programming issues.
So...

I think the issue of exceptions is significant enough,
and when someone asks for an opinion, do you mind if I have an
opinion? Or you have nothing better to do in your life besides
poking your nose into affairs of others and questioning their
integrity?

:-}

Why should C++ do anything when you already found your silver environment?
Why turn C++ to clone an existing and established thing?

Ok, enough for this one.
Looks like a hopeless case indeed.
I don't deal with people, biased out of their head.
Cya.

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.


My measure is 0 in simple situations, and "not worth mentioning" where the
design is complex.

--
Programmer's Goldmine collections:

http://preciseinfo.org

Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.

 

[Balog Pal]

Ok, the situation is this:

[whole story can be replaced with "you have to keep info on arbitrary number
of incoming network packets for arbitrary long time"]

That much was clear from previous posts. And it has little to do with memory
leaks or their prevention.

I see no problem to create your thing without leaks, as for every packet
there is a clear set of conditions when to keep and when to let go.

OTOH your requirements provide no upper limit resource usage, so if the
program just does keep the stuff around, it will fill the memory, or the
disk, or anything, just keep that checkbox checked and walk away.

If you actually want help with leaks, better describe what you do and how
you got them. (Though you said you already got rid of them, it is hardly
your aim, probably you just test how much posts people here read before
plonk or something... )

How do you design such a thing?
ANY clue?

Gimmme your rough model and we'll see whose code is designed
"better".

Better explain why java turns out to manage infinite amount of resources
better. ;-)
Is it like Chuck Norris, who did count to infinity? Twice! ?

I bow down to you, or immortal!

(***) > Except my lips are smiling.

What a fool they say in combination with my brain.

Guess if you saved up the trolling time to study well-known methods, you'd
be out of the swamp long ago. For sure, whining and blaming is easier.

Well, may be. If I ever find time to look at the design again,
who knows, I may even consider your "smart pointer" suggestion.

Just curious, you DID hear about existance of std::string, std::vector,
std::tr1:shared_ptr?

Dig?

next thing on my stack is

http://programmer.97things.oreilly.com/wiki/index.php/Edited_Contributions

and CERT's C++ section...

I am glad to hear that.
Unfortunately, I don't know you enough to see how much
what is you say is worth.

I'm sure. Your recent post suggest you hardly consirer anyone worth
listening to, including Sutter, Abrahams, so I'm not eager to fight for your
approval.

ALL I know is it is solved for what
I am doing in Java, which is my preferred language for several
years, and I am happy to hear that you think it is solved in C++
also, even though I have my doubts.

Java can collect only memory, with other resources you're almost as hosed as
in C. Well, you have finally to replace goto shutdown, still far from nice
and safe.

Cool. I did not know that. Not that I much care about it now.
Again, I am working in Java lately. Do not have much hope for
C++ and would not invest a penny into writing any new code in C++,
unless it is absolutely necessary, which I do not see so far.

So you admit that your presence here and the lengthy posts are just
trolling.

Yep. Ther IS. Believe it or not.
It is called AWT or modern version is called swing.
Gives you 100% portable GUI code.

Sure, the fine details of the LOOk of some visual components
are going to be rendered slightly differently, especially in
light of Microsofts pattent issues. But the overall functionality
of your GUI is going to work 100% on any platform wher you can
install the JVM. Simple as that.

"generally portable" and "where JVM exists" is quite a diference.

The nice thing about Microsoft MVM is that is has about twice
better performance than Suns JVM, which is what I really
appreciate. Because when I do my processing, archive updates
and site generation, jobs run into hours, if not days.



Yes, I actually DO mean portability.

You just admitted you do not a few lines ago.

And it is a non issue with Java.

Sure. All you need is an already ported Java, and a big deal of resources.
I know java is preferred by many programmers -- I also know that the result
is so often hated by users. Even those having resources in abundance.

Sorry to tell you that.

You actually think I'm unaware what java can and can't do?

Well don't know where you get it from.
But it is bright enough for what I am interested in.
In fact, I'd say it is far superior to all the Microsoft ugly
hacks in GUI design, that cause nothing more than goose bumps
when I even think of it. I can implement a much better functionality
of GUI in Java in about 2 to 10 times less of a time,
doing ANYTHING I can imagine as far as GUI goes.

Just for a sanity check, you know what common cotrold are in Windows, and
what the listview control is?

Too bad. I don't happen to share your opinion.

If all you have is a hammer everything looks like a nail. ;-)

And I am not peddling Java here. Too bad everyone seems to be
abandoning it in a hurry. The traffic on Java collections of mine
are about 10 times as small as for MFC.

And, interestingly enough, C++ traffic is no more than
a half of MFC/VC/ATL/STL collection, which tells ME something.
Not sure if it tells YOU something though.

What traffic?

Do you mind?
:--}

Not really, just never understood the approach. I don't like java, but
express that by simply staying away. Not by going to java forums and start
flames. Either on made-up issues the real practicioners there know better
to be a non-issue, or real pains, that they also know ways better.

When I'm confident, I don;t need to prove it to anyone.

To tell you the truth, I do not know.
I just came here a couple of days ago for some small things.
One thing leads to another.
I saw some posts on programming issues.
So...

I think the issue of exceptions is significant enough,
and when someone asks for an opinion, do you mind if I have an
opinion?

Me? Absolutely not. Opinions are like assholes, everyone has one, and
not very interested in others'...

Or you have nothing better to do in your life besides
poking your nose into affairs of others and questioning their
integrity?

see (***) ?

Ok, enough for this one.
Looks like a hopeless case indeed.
I don't deal with people, biased out of their head.
Cya.

LOL.

 

[tanix]

Ok, the situation is this:

[whole story can be replaced with "you have to keep info on arbitrary number
of incoming network packets for arbitrary long time"]

I know, I know. I had to deal with one liner mentality for quite a while.

But you see, if you write these one liners, you are basically dealing
with bio robots.

There is no fun of a story in one liners.

That is why I suggested on other thread that before you get into
programming, first learn about beauty. Then learn about music.
And ONLY THEN we are going to have any luck talking to people like you.

I do not happen to communicate in one liners of a type
"coca cola is good. drink coca cola".
Because I perceive it as programming instructions for zombies
and biorobots.

Do you mind?

That much was clear from previous posts. And it has little to do with memory
leaks or their prevention.

Uhu. I am glad to see another smart guy on my way in life.
What DOES have it to do with?
Who knows, I might even think of changing some things in that
app if I see some revolutionary breakthroughs and some deep
you know what insights from the guys like you.

I see no problem to create your thing without leaks, as for every packet
there is a clear set of conditions when to keep and when to let go.

Nope, sire. I don't think you even BEGIN to comprehend the set of issues.
I guess I have to write an article twice as big as the original one.
But sorry, I am not in the mood right now. Plus there are other things
in my life.

OTOH your requirements provide no upper limit resource usage, so if the
program just does keep the stuff around, it will fill the memory, or the
disk, or anything, just keep that checkbox checked and walk away.

Nope. Not even in the picture.
There is no such a problem.

You just did not read the original post carefully enough.
There IS an upper limit on resource useage and it is determined
by the max size of the monitor entry list. Typically, you don't need
to keep > 1000 entries in the monitor list cause that will keep enough
history for you to go back several days, if not months.

And it is a configurable parameter from the control panel.
I typically run with 200 entries upper limit.
Once this limit is exceeded, the memory is deallocated in the
monitor view list control.

As far as pending "unknown packet" queues, there are limits also.
As far as intermediate NDIS driver goes, there are limits on
pending queues also. Plus there are time outs.

Zo...

We are in a good shape. This is a non issue.

Sorry not to be able to write it all out in one liner
to please people like you, lil do I care if you even exist though
in the scheme of things...

:--}

If you actually want help with leaks, better describe what you do and how
you got them.

Sorry. I have no more time to spend on it.
I'd have to waste several hours to describe things in sufficient
details and things like that.

If you have an idea from what I already wrote, fine.
Be my guest. You don't? Fine. Not a problem at all. Just enjoy
the trip of life.

(Though you said you already got rid of them, it is hardly
your aim, probably you just test how much posts people here read before
plonk or something... )

You are really a royal waste of time, Jack.
Cya.

Better explain why java turns out to manage infinite amount of resources
better. ;-)
Is it like Chuck Norris, who did count to infinity? Twice! ?

(***) > Except my lips are smiling.

Guess if you saved up the trolling time to study well-known methods, you'd
be out of the swamp long ago. For sure, whining and blaming is easier.


Just curious, you DID hear about existance of std::string, std::vector,
std::tr1:shared_ptr?


next thing on my stack is

http://programmer.97things.oreilly.com/wiki/index.php/Edited_Contributions

and CERT's C++ section...


I'm sure. Your recent post suggest you hardly consirer anyone worth
listening to, including Sutter, Abrahams, so I'm not eager to fight for your
approval.


Java can collect only memory, with other resources you're almost as hosed as
in C. Well, you have finally to replace goto shutdown, still far from nice
and safe.


So you admit that your presence here and the lengthy posts are just
trolling.



"generally portable" and "where JVM exists" is quite a diference.


You just admitted you do not a few lines ago.


Sure. All you need is an already ported Java, and a big deal of resources.
I know java is preferred by many programmers -- I also know that the result
is so often hated by users. Even those having resources in abundance.


You actually think I'm unaware what java can and can't do?


Just for a sanity check, you know what common cotrold are in Windows, and
what the listview control is?


If all you have is a hammer everything looks like a nail. ;-)


What traffic?


Not really, just never understood the approach. I don't like java, but
express that by simply staying away. Not by going to java forums and start
flames. Either on made-up issues the real practicioners there know better
to be a non-issue, or real pains, that they also know ways better.

When I'm confident, I don;t need to prove it to anyone.



Me? Absolutely not. Opinions are like assholes, everyone has one, and
not very interested in others'...


see (***) ?


LOL.

--
Programmer's Goldmine collections:

http://preciseinfo.org

Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.

 

[James Kanze]

"tanix" <[email protected]>

[concerning memory leaks...]

I never had problems with memory leaks in C++. (not like with
C).

Interesting. I can't remember ever having had any problems with
memory leaks in C. I do remember one in C++, recently. Due to
a compiler error resulting in the compiler not calling a
destructor. (But it wasn't in code I'd written. Had the code
been slightly cleaner, it wouldn't have triggered the compiler
error. But VC++ has problems with getting the destructor calls
right if you return in the middle of a loop.) But most of the
leaks I've seen have been in Java. Not because of the language,
but because of people trying to get the code out the door too
quickly, making the classic error of skipping on the design,
because "that's not what we're delivering".

The secret, of course, is good up front design. It's true that
it requires more work to avoid all leaks in C than it does in
C++, and (slightly) more work in C++ than in Java, but if you're
organization doesn't do good up front design (and design and
code reviews, and unit tests, and all the rest), you will have
problems (and Java won't solve them), and if it does, then you
won't have memory leaks. The advantage of things like garbage
collection isn't that they solve problems you wouldn't solve
otherwise---they don't. The only advantage is that they reduce
the total amount of work necessary in the solution.

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 that's the kind of comment which gives C++ a bad name.
There are no silver bullets, and in well designed code, you
typically don't have that many smart pointers. (Although I'm
pretty sure it depends on the application domain---there are
probably domains where boost::shared_ptr solves 90% of your
memory management problems. I've certainly not worked in such a
domain, however.)

(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.)

The classical case of a leak is when you "register" a session in
a map, mapping it's id to the session object, and forget to
deregister when the session ends. At least, something along
those lines accounts for most of the leaks I've seen.

Note that this is very application dependent. Actual allocation
with a copying collector is about the same as alloca in terms of
performance, and if you can arrange for all of the runs of the
garbage collector to be in otherwise dead time, you'll likely
significantly outperform a system using manual allocation. But
there are a couple of if's in there---for most applications I've
seen, the performance difference between garbage collection and
manual allocation won't be significant, and there are
applications where garbage collection is significantly slower,
or simply can't be used.

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.

I'll repeat: there's no silver bullet. And I've yet to see a
smart pointer which solved all of the memory management issues
without significant additional work.

[...]

Is there such a thing?

For any reasonable definition of "portable". (No GUI code can
be made to work on an embedded system without a terminal, for
example.) One of the advantages of Java is that Swing is
actually fairly well designed. From what little I've seen of
the C++ GUI libraries (where unlike Java, you do have a choice),
they weren't as well designed. But they're likely sufficient
for a lot of applications---I know that I use GUI applications
(e.g. Firefox) which are written in C or C++, and they more or
less work.

 

[James Kanze]

"tanix" <[email protected]>

Ok, the situation is this:

[whole story can be replaced with "you have to keep info on
arbitrary number of incoming network packets for arbitrary
long time"]

I know, I know. I had to deal with one liner mentality for
quite a while.

But you see, if you write these one liners, you are basically
dealing with bio robots.

There is no fun of a story in one liners.

That is why I suggested on other thread that before you get
into programming, first learn about beauty. Then learn about
music. And ONLY THEN we are going to have any luck talking to
people like you.

Well, I find his version more beautiful than yours. It's
obviously not complete, but it does sum up the issues for one
part of the application in a very clear and concise manner.
(And as my high school English teacher used to say: "Good
writing is clear and concise.")

I do not happen to communicate in one liners of a type "coca
cola is good. drink coca cola". Because I perceive it as
programming instructions for zombies and biorobots.

Do you mind?

Yes. You seem to prefer long, drawn out descriptions which jump
back and forth between issues. That's not what I'd consider
good writing.

Note that I'm not saying that such things shouldn't occur. But
you're description sounded like a first brainstorming session,
when you really don't know yet what the application should do.
Balog's is, of course, too simple, in that it only addresses one
aspect of the problem. But he has gotten over the first design
issue: breaking the problem up into simpler problems, which can
each be addressed by a simple statement.

My first reaction to your description is that you obviously need
two processes: one doing the filtering, and another to manage
the GUI. With a queue between them. In this case, from
experience, I'd say that two processes are a must, because you
want the filtering to maintain as small a footprint and use as
few resources as possible. Which means, BTW, that I would do it
in C++, and that I wouldn't use garbage collection, since
garbage collection does have a significant memory overhead (and
in such filtering applications, unlike a lot of other
applications, doesn't really buy you that much). For the GUI,
I'd use Java, because I know Swing, and I don't know any of the
C++ GUI libraries.

For the queue itself, I'd try to use something provided by the
system, because writing robust and rapid queue management in
Java is a pain. (You need to access system services to do it
efficiently.) Lacking something in the system, I'd write the
queue management in C++, and use JNI to interface with it on the
Java side.

 

[James Kanze]

James Kanze <[email protected]> wrote:

[...]

Well, to me, optimization is indeed one of the major criteria,
except I view optimization from the stand point of
architecture.

There are different ways to structure your code, or architect
the system.

The major criteria for me are:

1) Minimization of the size of executable,
which indirectly translates into correctness of your code and
flexibility of your structure and program architecture.

That's interesting, because memory use is one of the big costs
for garbage collection. I've actually used garbage collection
in C++ at times, and I know how to write C++ code which uses the
Boehm collector, but for the application you described
else-thread, I wouldn't do it, because the memory overhead of
garbage collection is just too high (and because for that
particular problem, garbage collection just doesn't buy you that
much anyway).

4) Portability.
A tough one. Forget about it in the C++ world.
Such a major headache, that it is realistically undoable
unless you maintain several code bases.

With Java - a pice o cake. Non issue.

My experience is exactly the opposite. Java's portability is
limited to machines which have a good JVM. Which isn't many.
C++ works on pretty much everything.

5) Robustness.
And THAT is where these nasty exceptions come in handy.
You'll never be able to write a stable code, and I mean TRULY
stable, if you do not use exceptions.

Explain how applications have been running for years, without
interruption, and without using exceptions. (The application in
question was written before C++ supported exceptions.)
Exceptions are a useful tool, for certain things, but like all
tools, you can do without (at some development cost) if you have
to.

[...]

So, exceptions should not be a part of your underlying logic.
They are your defense system against ANY kinds of problems.
You can NEVER assume that ANY operation is going to complete
without problems. In the middle of some routine, you may
loose power, just for the sake of argument.

In which case, you won't be able to process an exception.

That means, that once you restart your program, and it was in
the middle of doing some heavy duty processing, you should be
able to recover and continue on, if at all possible, even in
principle.

So you need persistent transactions. You're not the first
person to need them, and a lot of applications use them,
including applications written long before anyone had ever heard
of exceptions.

[...]

Good. Keep them in museums then.

Nothing like taking a quote out of context, is there?

 

[Balog Pal]

And that's the kind of comment which gives C++ a bad name.

I don;t see much difference between my comment and yours -- we do similar
things (proper design and match it in code) and have the same result (no
leaks).

There are no silver bullets, and in well designed code, you
typically don't have that many smart pointers.

I said "manager" that is *like* a smart pointer. string, vector, list is a
manager, and is not a smart pointer. I certainly agree that stts on a
regular program would find ust a few smart pointers compared to anything
else.

But safe coding have consistent manager usage, replacing "raw" stuff. Just
like you wrote before, that dynamic allocation is not left in a raw pointer,
but put in a smart one, and .release() it at return or transferuing to
another manager.
Even if it looks like done "immediately" with just one line between. ;-)

(Although I'm
pretty sure it depends on the application domain---there are
probably domains where boost::shared_ptr solves 90% of your
memory management problems. I've certainly not worked in such a
domain, however.)

Me neither. Still I think it is a good forum reference.

The classical case of a leak is when you "register" a session in
a map, mapping it's id to the session object, and forget to
deregister when the session ends. At least, something along
those lines accounts for most of the leaks I've seen.

Yeah, we discussed it a few weeks ago. This has nothing to do with coding
or any language -- a flaw in design/reqs that will hit in any possible
implementation.

Note that this is very application dependent. Actual allocation
with a copying collector is about the same as alloca in terms of
performance, and if you can arrange for all of the runs of the
garbage collector to be in otherwise dead time, you'll likely
significantly outperform a system using manual allocation. But
there are a couple of if's in there---for most applications I've
seen, the performance difference between garbage collection and
manual allocation won't be significant, and there are
applications where garbage collection is significantly slower,
or simply can't be used.

To start with the memory footprint starts as 2-3x as big. Actually did
anyone heard a reporting firewall implemented in java?

I'll repeat: there's no silver bullet. And I've yet to see a
smart pointer which solved all of the memory management issues
without significant additional work.

Well, my mistake, I planned to write a summary of the last discussion to sum
up the point where misunderstanding remains -- then decided they must be
evident.

Trivial approach here applies to transfering design to code, not solution in
general. The hard part is to have an abstract design that matches/solves
the problem. That includes the flow of information, and makes clear which
pieces are needed at which point.

My experience that the work to code it in a leak-free way is piece of cake
in comparision, when the flow is complicated. And when it is
straightforward you can do it with eyes closed.

[...]

Is there such a thing?

For any reasonable definition of "portable". (No GUI code can
be made to work on an embedded system without a terminal, for
example.) One of the advantages of Java is that Swing is
actually fairly well designed.

Can't comment on that.

One of my current project picked java UI with Swing because it has
auto-layout. What sounds like a cool idea when you must issue the app in a
dozen languages. And you can just have a ranslation table for the UI
strings, the rest will work.

Well, in practice it wasn't all that bright, and the auto property turned to
create a big deal of issues when translated stuff had a different size...

On windows I still keep stumbling into programs that spoil the interface
just because I have "big font" setting. (using 1280x1024 res was far from
common back in '98 but I thought today lowes should be strange...)
The point is, I see examples that GUI gets spoiled even on the same
platform, using its natural features -- either having the items fixed or
auto-moving.

That keeps me generally sceptic wrt GUI portability. Without a big deal of
manual work at the QA dept and coding too...

From what little I've seen of
the C++ GUI libraries (where unlike Java, you do have a choice),
they weren't as well designed.

Well, at elast the libraries for windows do use the Windows UI the natural
way, and give you access to common controls. So at least can solve the
situation where the req says to work on Windows, but there correctly,
intuitively and user-friendly.

Portability to other platforn is not something everyone seeks, and if so do
not want to sacrifice anything for unused generality.

 

[tanix]

"tanix" <[email protected]>

[concerning memory leaks...]

I never had problems with memory leaks in C++. (not like with
C).

Interesting. I can't remember ever having had any problems with
memory leaks in C.

Ok, I am going to take this one up just one more time.
Beyond it, sorry, could care less.

I do remember one in C++, recently. Due to
a compiler error resulting in the compiler not calling a
destructor.

I bow down to you, oh, holey ghost.

(But it wasn't in code I'd written.

Sure. Understood. How COULD it be, considering how great
you are?

Had the code
been slightly cleaner, it wouldn't have triggered the compiler
error. But VC++ has problems with getting the destructor calls
right if you return in the middle of a loop.)

There are problems up to your gazoo in a more or less complex
app, at least from what I know, not you.

But most of the
leaks I've seen have been in Java.

WHAT?

Is it some kind of insult?
Are you going to fall THAT low?

Not because of the language,
but because of people trying to get the code out the door too
quickly, making the classic error of skipping on the design,
because "that's not what we're delivering".

Does not matter in Java more or less within the reasonable
set of limitations.

In Java memory leaks ARE possible. But THEORETICALLY.
Not practically. If you understand how gc works, you would
NEVER make such a statement.

Could you give me an example of the situation that will cause
a memory leak in Java? I'd be curious to see that one.

And I can give you an example of memory leaks in C++,
that will crack your scull trying to avoid them,
especially in async environment.

The secret, of course, is good up front design.

Blah, blah, blah.

That is NOT how real world works.

Do you think you waste half a year on your great "design"
in real life?

Nope. You have a functionality requirements in most situations
I had to deal with. The "design" is driven by the sales and
marketing department.

"We want this and this and that".

And we want it NOW.
Actually, we want it YESTERDAY.

You have about 2 weeks to do a job that should normally
take at least 2 months to a competent programmer.

And THAT is how it works in the silicon valley at least.

I have NEVER EVER seen a SINGLE company that does
"good design". I am not even sure they know what it means
to begin with.

Because it is so expensive that most of them can not even
BEGIN thinking in those terms.

It's true that
it requires more work to avoid all leaks in C than it does in
C++, and (slightly) more work in C++ than in Java,

WHAT?

Is this some kind of insult?

SLIGHTLY more than in Java?

I would defietely like to see some substantiation of this
argument, even though I already know the end of the story.

but if you're
organization doesn't do good up front design

And WHICH organization does that kind of thing?

You mean Intel?
- nah.

You mean HP?
- nah

You mean SGI?
- nah

You mean Fujitsu?
- nah.

You man Amdahl, for god's sake, the competitors of no one
less than IBM?
- nah.

WHO then?

Well, no one I know of. Sorry to tell you.
"Good design" is the kind of crap they brainwash you wit
at computer school.

It does not exist, unless you do your own project at home
and could care less how much is it going to "cost" you
or hoe much time is it going to take.

But, putting aside the fun part of it,
it is actually a FUNDAMENTAL issue.

What is "good design" by definition?

Well, it is something that does not exist!

Why?

Well, becaue how do you create something?

Well, initially you have some idea to create a product that
does this and that.

At THAT stage, you only have a pin sized view on ALL sorts
of issues that may or may not arise as you start implementing
some of this stuff and start seeing the situations you did
not even expect to have when you had your initial idea.

Yes, no question about it. If you are "smart" and have enough
of experience and are not simply hacking away at it, you DO
know how to walk the mine field and how to avoid the most of
pitfalls. But that is the ART part of programming. Not science,
necessarily.

If you do appreciate beauty and to appreciate the music,
as it is about the most abstract and most fundamental aspect
of comprehending what the structures are, then yes, you will
be able to design and code your stuff much better than if you
don't.

But...

At the end, what is FOREVER happening is that you never know
what is going to happen tomorrow. You may be just called into
a salesman's office and he will tell you something that will
make your hairs raise.

You may never know how exactly do you want to make some of
your GUI panels look like and what kind of program parameters
do you want to expose to user, or what kind of logging system
you are going to implement.

Are you going to waste some heavy duty time to write some
"general purpose, omnipotent logging system" in ANY project?
Why?
How much is it going to cost you?
How portable is it going to be if in one environment you might
have log4j and in another evnironment there is no such a thing?

And what about robustness?
Do you know all the exceptions in your future project?

Oh, you mean you are going to take a two year sabbatical
and lay back on some beach on one of the virgin islands
and do your great design there?

Do you even begin to comprehend what good design is worth?

Well, first of all, it has to be done by the systems architect
level guys, just to make sure.

How much do you pay those guys?
Well, at LEAST $150/hr. and that is a CHEAP one.

Can you multiply some numbers?

Well, I can tell you witout calculator, for any more or less
complex program that is even worth mentioning, you are talking
high end 5 or 6 figure numbers.

Simple as that.
And that is for a SINGLE person.

And on and on and on.

(and design and code reviews,

Screw those. About the sickest idea I had to deal with.

WHO is going to "review" YOUR code?

They are upto hilt with THEIR code?

WHAT kind of thing they are going to do on YOUR code?
Well, they are going to find some trick and some totally
meainingless lil piece of crap they can find, just to
discredit you and make you feel guilty. So everyone on
a "code review panel" could see how "great" THEY are,
not you.

Do you understand?

If you call me on a code review to see someone elses code,
how much of a chance do I have to see some of the most
subtle tricks in HIS code by simply looking at it for a half
an hour, which is what you have most of the time?

How much time do you think I have to review YOUR code
and then someone elses code, and then someone elses?

You want me to spend half of my time doing YOUR "code review"?

Are you a lunatic?

Do you live in a world of pipe dreams?

and unit tests,

Yes, AND unit tests,
AND system tets,
and ANY tests you can imagine.
The more, the better.

and all the rest), you will have
problems (and Java won't solve them),

Are you a pervert by ANY chance?

What I see is this sadistic pleasure on your end.

You see, if you said such a thing on a java group,
they'd tare you to pieces, if they even cared to bother
about it. At best, they'd make you look like fool,
and laugh their arses off you.

You must be some "moron" to them if you even conceive
saying things like that. Becaues this is about the highest
order insult to Java as a concept.

Because these things are some of the CENTRAL concepts
in the whole Java world.

and if it does, then you won't have memory leaks.

Who does what?
Java won't solve them?
And if it does, you won't have memory leaks?

What kind of logic is this, sire?
Never heard of anything like this?
Too much work without sleep?

The advantage of things like garbage
collection isn't that they solve problems you wouldn't solve
otherwise---

Bullshit.
That is EXACTLY what they are meant to do.
Otherwise, just hack away, trying to waste upto 10-30% of your
time forever worrying about memory deallocation issues.

Oh, you mean that "smart pointer" paradise?
Well, sorry to tell you, I haven't looked at that thing yet,
and unfortunately have no plans to ever do.

But... I do have my reservations about it.
Not that I do not trust what you are saying outright.

they don't.

Oh yes they do.
I have have as hard of an evidence as it gets
and I process such immense amounts of data and so many different
allocations of so many different object types, that I am not sure
it is going to be easy for you something even more stretching,
unless you are a major world bank or a government, doing billions
of records processing.

The only advantage is that they reduce
the total amount of work necessary in the solution.

Not only reduce. They simply eliminate it.
Yes, I do prefer to explicitly deallocate most of objects
by resetting the "pointers" to null so that gc kicks in as
soon as it can.

Because, first of all, I have such amounts of allocated memory,
that even after I stop some major operation, there may be tens
if not hundreds of megs still sitting idle and not being
deallocaed by gc because i am holding those pointers.
And the reason I am holding those pointers is that if you are
interested in looking at some of your results in various program
dialogs, you still have ALL of the most important information
available, even AFTER the operation is totally completed
and success status has been reported, shown to you in your active
dialog and logged into a perpetual rotating log file, down to
quite a minute details of your entire operation or a job,
within the reasonable granularity.

The same as what?

Well, again. Sorry to tell you. But I have not looked at an
issue of "smart pointers". I can not argue this one.
ALL I can say: great.
If I ever have time, I'll look at it and may be, you never
know, may be, will find some time to convert my code to use the
"smart pointer". Even though I doubt very much I'll be able
to find some time to waste on this. Because by now it is
quite acceptable as is and I am about the only one, who is
even aware of this issue. Because it does not matter at all.
You can run this program for years and as long as you don't
restart it, you won't have the memory leaks. Well, I AM a
bit stretching it, just for the sake of arugument.
Just to show the relative significance of it.

And, if you are going to tell me that there is no memory
leaks problems with C++, or they are not much more difficult
to handle than in Jave, sorry, I do have my reservations.

And that's the kind of comment which gives C++ a bad name.
There are no silver bullets, and in well designed code, you
typically don't have that many smart pointers.

Well, I am quite happy with my design. But there are intricacies.

(Although I'm
pretty sure it depends on the application domain---there are
probably domains where boost::shared_ptr solves 90% of your
memory management problems.

Sorry, I don't want to hear the word boost, unless it is
totally compatible with Visual Studio compiler without me
moving a finger more or less.

What I DO want to hear is the trick you are going to show
me that will make the memory leaks go away by using a
standard, off the shelf environment under windows,
and the name of that envirionment is Visual Studio.
That is ALL I want to hear, no matter how great anybody's
compiler or development environment is.

Sorry to tell you this.

I've certainly not worked in such a
domain, however.)

Too bad. Try to deal with driver related issues.
That helps.

I did not say infinite.
But, I DO have an option of keeping some information
for a more or less infinite time, considering the scope
of practical events. After all, what was the oldest packet
are you interested in seeing trying to check when was the
last time your box was attacked or you saw some funky packet
just now and are interested in seeing when was the last time
you might see it before?

Well, not more than 24 hrs. more or less.
And that is "infinite" in the scheme of things.

Now, I DO have that packet held for you and you CAN look at
it in the packet display window and you can take all the time
you want to do that kind of thing. And I will hold that and
ANY other fishy packet for you at least for hours.

And THAT is the kind of design I like.
I mean TOTAL flexibility. As much as total can be applied
to anything on the physical domain.

The classical case of a leak is when you "register" a session in
a map, mapping it's id to the session object, and forget to
deregister when the session ends. At least, something along
those lines accounts for most of the leaks I've seen.


Note that this is very application dependent.

Yes, no argument on that one.

Actual allocation
with a copying collector is about the same as alloca in terms of
performance, and if you can arrange for all of the runs of the
garbage collector to be in otherwise dead time, you'll likely
significantly outperform a system using manual allocation.

You don't "arrange" ANYTHING as far as garbage collector goes.
It does its thing and you can not even force to garbage collect
even though there is a call to gc(). But that call is not
guaranteed to garbage collect. It is hist a hint to gc that
it MAY collect this stuff.

GC is a pretty sophisticated algorithm.
I have not looked at the source, but from what I heard about
it from the top level experts, it IS definetely an impressive
piece of code and I am glad it is there.
I did watch the memory deallocation issue quite carefully.
Becaues I am dealing with terabytes of data allocation/deallocation
in millions of allocations. So, if ANYTHING just sneases,
this whole thing is going to get screwed up beyond belief
and I may loose so much time, that I am not even interested
in tell you how much this is. It may turn out to be days,
if not weeks if something fishy happens.

But
there are a couple of if's in there---for most applications I've
seen, the performance difference between garbage collection and
manual allocation won't be significant, and there are
applications where garbage collection is significantly slower,
or simply can't be used.

I do not agree on that one.
From what I saw and tested and verified and a pretty memory
intensive situations is that I can hardly even notice gc exists.

First of all, what do you think happens if you deallocate memory
manually? Well, what happens on the O/S level, this buffer has
to be returned to a memory pool. If this buffer happens to be
an ajacent to some other memory region, it has to be merged
so the allocator can find the best fit existing buffer.
Which means? Well, which means that no matter wether you have
gc or not, the underlying mechanisms are pretty much similar
to what gc does and the net effect as far as overall system
performance is not that significant. Probably in the range
of 5% of your performance, even though I am pulling this
number out of the hat.

I'll repeat: there's no silver bullet. And I've yet to see a
smart pointer which solved all of the memory management issues
without significant additional work.

Oh, I see. So those "smart pointers" are not exactly the
kind of magic you guys are selling it to be?

Well, that is exactly what I suspected before I even looked at it.
In fact, I do not believe in this magic to the least.

[...]

Is there such a thing?

Why did you stip my response?

One more time: YES, there IS such a thing!

For any reasonable definition of "portable". (No GUI code can
be made to work on an embedded system without a terminal,

Huh?
Ok. good enough for now?

for
example.) One of the advantages of Java is that Swing is
actually fairly well designed. From what little I've seen of
the C++ GUI libraries (where unlike Java, you do have a choice),
they weren't as well designed. But they're likely sufficient
for a lot of applications---I know that I use GUI applications
(e.g. Firefox) which are written in C or C++, and they more or
less work.

--
Programmer's Goldmine collections:

http://preciseinfo.org

Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.

 

[tanix]

"tanix" <[email protected]>
Ok, the situation is this:
[whole story can be replaced with "you have to keep info on
arbitrary number of incoming network packets for arbitrary
long time"]

I know, I know. I had to deal with one liner mentality for
quite a while.

But you see, if you write these one liners, you are basically
dealing with bio robots.

There is no fun of a story in one liners.

That is why I suggested on other thread that before you get
into programming, first learn about beauty. Then learn about
music. And ONLY THEN we are going to have any luck talking to
people like you.

Well, I find his version more beautiful than yours. It's
obviously not complete, but it does sum up the issues for one
part of the application in a very clear and concise manner.
(And as my high school English teacher used to say: "Good
writing is clear and concise.")

I do not happen to communicate in one liners of a type "coca
cola is good. drink coca cola". Because I perceive it as
programming instructions for zombies and biorobots.

Do you mind?

Yes. You seem to prefer long, drawn out descriptions which jump
back and forth between issues. That's not what I'd consider
good writing.

Too bad.

Not interested.

Cya.

Note that I'm not saying that such things shouldn't occur. But
you're description sounded like a first brainstorming session,
when you really don't know yet what the application should do.
Balog's is, of course, too simple, in that it only addresses one
aspect of the problem. But he has gotten over the first design
issue: breaking the problem up into simpler problems, which can
each be addressed by a simple statement.

My first reaction to your description is that you obviously need
two processes: one doing the filtering, and another to manage
the GUI. With a queue between them. In this case, from
experience, I'd say that two processes are a must, because you
want the filtering to maintain as small a footprint and use as
few resources as possible. Which means, BTW, that I would do it
in C++, and that I wouldn't use garbage collection, since
garbage collection does have a significant memory overhead (and
in such filtering applications, unlike a lot of other
applications, doesn't really buy you that much). For the GUI,
I'd use Java, because I know Swing, and I don't know any of the
C++ GUI libraries.

For the queue itself, I'd try to use something provided by the
system, because writing robust and rapid queue management in
Java is a pain. (You need to access system services to do it
efficiently.) Lacking something in the system, I'd write the
queue management in C++, and use JNI to interface with it on the
Java side.

--
Programmer's Goldmine collections:

http://preciseinfo.org

Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.

 

[tanix]

[...]

Similarly, with regards to optimizing application code:
you've only got so much time to write it in, so it's often a
question of making it take 5 milliseconds less time (over an
hour), or adding a feature.

Well, to me, optimization is indeed one of the major criteria,
except I view optimization from the stand point of
architecture.

There are different ways to structure your code, or architect
the system.

The major criteria for me are:

1) Minimization of the size of executable,
which indirectly translates into correctness of your code and
flexibility of your structure and program architecture.

That's interesting, because memory use is one of the big costs
for garbage collection.

Forget about garbage collection on this thread I suggest.
I don't have that problem at the moment.
I have a different problem now. And that is win 7 related
problem of a perfectly good app with perfectly good, well
written NDIS device driver not working as advertized under
win 7. For one thing, it reports 2 more network adapters
than the XP reports. The names of those adapters are totally
diffetent than what XP reports. A major pain on the butt.
So, win 7 is no go for me. Because THAT app is the only
app I care about if I ever run windows of any kind.
Screw win 7. Does not worth it. Just becasue Microsoft want
to make another trillion bux and wasted at least 5 years on
developing this totally dead end win 7, does not mean I
have to buy into their trip.

I've actually used garbage collection
in C++ at times,
Wut?

and I know how to write C++ code which uses the
Boehm collector,

Good for you. I am impressed.
Cause I don't!
:--}

but for the application you described
else-thread, I wouldn't do it, because the memory overhead of
garbage collection is just too high (and because for that
particular problem, garbage collection just doesn't buy you that
much anyway).

I am not sure about this. But I trust your word on it.
I'd have to take half of the day to even think about it.
Sorry, can not afford it at this time.

My experience is exactly the opposite.

WHAT?

Why are you trying to continuously insult my intelligence?
Not nice!

:--}

Java's portability is
limited to machines which have a good JVM.
Correct.

Which isn't many.

Well, about 90% of total market from what I know.

Good enough for a poor guy like me.

C++ works on pretty much everything.

True. No argument on that one.
Except of some REALLY nasty details.

Explain how applications have been running for years, without
interruption, and without using exceptions.

Well, THEORETICALLY, it can happen even without using exceptions.
In reality, it is just a joke.
For one thing, without exceptions your code becomes a huge pile
of spegetti code and I know what I am talking about.
So, it simply becomes more difficult to even see the subtle points
in your code because there is so much informational noise if you
do not use the exception mechanism.

You see, with exceptions, you have a rougher granularity of your
logic. For the applications I have to deal with right now it
translates into things like you have several levels deep in your
execution. If ANY kind of error happens on ANY of those levels,
you have a chance to hangle it on a local bulk level, vs.
checking every single call return result, which is really not
necessary.

Say, for example, you are establishing the network connection.
It does not much matter what kind of error you are going to get
even if you have to execute several methods to do that,
such as authentication or what have you.

All that matters is that you could have not established a
connection. Yes, you DO want to know why, but that can be
handled with a single exception. This is just an overall idea.

The same thing if you are downloading something from the
network. Even if you unplug the network wire in the middle
of no matter which level deep on the stack, you get at most
2 levels of exceptions. One is the lowest level network,
and the 2nd one is logical level of doing some operation.

Now, if you look at how many calls had to be made and how
many return codes you'd have to examine, it may be tens
if not hundreds, depending on what exactly you are doing

So, with exceptions you have only two things that trigger,
and if you user return codes, your code size and your
program logic becames twices as big and trice as complicated
with all those conditional spagetti code.

I do not know what kind of argument I can possibly provide
if you are so biased AGAINST exceptions. Sorry.

It is a psychology trip. Not a programing issue to me.

(The application in
question was written before C++ supported exceptions.)
Exceptions are a useful tool, for certain things, but like all
tools, you can do without (at some development cost) if you have
to.

Sorry. I can not agree with you on this one.
I think you are somehow predisposed AGAINST exceptions.
If that is the case, we will be arguing here untill our noses
go blue with no benefit that I can see.

[...]

So, exceptions should not be a part of your underlying logic.
They are your defense system against ANY kinds of problems.
You can NEVER assume that ANY operation is going to complete
without problems. In the middle of some routine, you may
loose power, just for the sake of argument.

In which case, you won't be able to process an exception.

True. But...

The trick is the program state logging.

You see. I can just turn off the power switch on my UPS off,
and after I reboot and restart the program, I am GUARANTEED
to continue on from the same exact point.

Why?

Well, because the very last successful logical operation
that resulted in the file update was logged and all the IDs
of relevant elements were saved. Yes, it IS a lil overhead.
About 1-2% I estimated. But the benefit can not be underestimated,
at least in MY situation.

Sure, if a nuclear war starts out, forget about those stinky
computers!

So you need persistent transactions.
Correct.

You're not the first
person to need them, and a lot of applications use them,
including applications written long before anyone had ever heard
of exceptions.

So what?

I know for fact that what I do works MUCH better with exceptions.
You know why?

Well, because I originall had this code without exceptions.
But when I fully implemented the exception mechanism, I was able
to get read of probably 30% of my code, if not more,
and reliability probably went up a number of times.
I do not even know how to estimate it.
At this point, it is like a tank.
Unless you loose your entire hard disk, it is going to work
not matter what and not matter who says what for or against it.
I am just as pretty sitting with it as it gets.

[...]

Good. Keep them in museums then.

Nothing like taking a quote out of context, is there?

Well, there are ALL sorts of things in life.
Depends on what turns you on.

But to hear such a thing from YOU?

:--}

--
Programmer's Goldmine collections:

http://preciseinfo.org

Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.

 

[tanix]

I don;t see much difference between my comment and yours -- we do similar
things (proper design and match it in code) and have the same result (no
leaks).


I said "manager" that is *like* a smart pointer. string, vector, list is a
manager, and is not a smart pointer. I certainly agree that stts on a
regular program would find ust a few smart pointers compared to anything
else.

But safe coding have consistent manager usage, replacing "raw" stuff. Just
like you wrote before, that dynamic allocation is not left in a raw pointer,
but put in a smart one, and .release() it at return or transferuing to
another manager.
Even if it looks like done "immediately" with just one line between. ;-)


Me neither. Still I think it is a good forum reference.


Yeah, we discussed it a few weeks ago. This has nothing to do with coding
or any language -- a flaw in design/reqs that will hit in any possible
implementation.


To start with the memory footprint starts as 2-3x as big. Actually did
anyone heard a reporting firewall implemented in java?

Oh. Now that you mentioned it, just for the kicks of it,
I might conside rewriting the code in Java so it can run under
Linux/Unix cause linux firewall suck so bad, I can not even
begin to tell you.

The only problem I have is low level driver.
Under windows, I have a NDIS inermediate driver,
which simply translates into fact that my drier sits as close
to the wire as it gets. Just above the minipor, which is your
netowork card driver. This means that I can intercept ANY
traffic, even traffic from other firewalls, installed simultaneously
on the same box.

And my firewall is the only one I know of that does not conflict
with any other network related apps that use low level kernel
drivers. Because all others use totally ugly hacks of intercepting
the data structure in the kernel with all sorts of hooks.
You can not install 2 different firewalls on the same box.
You'll have a blue screen orgasm.

Why do you want to install > 1 firewall?
Well, because first of all, most of them are bluff.
They let any questionable traffic through and you don't get the
security out of it as you think you do. Secondly, all of them
have their strong points and weak points.

So, I run 2 firewalls on my box. The number one is my own,
which is a monitoring firewall. Meaning, I can see ANY funky
network traffic. NOTHING escapes me. There is no firewall
I know of that can do that kind of thing, even though I did
not look at the firewall market for a couple of years.

So, as far as rewriting this thing in Java, that is not
a big deal. I think it can be done in a couple of months.

But... There is a low level driver.
What do you do with it on Linux?
I did not investigate it, but looks like a lil problem there.

But, thanx for a hint. I WILL consider rewriting it in Java.
I see no problems whatsoever besites the low end of it, the
O/S interface.

Well, my mistake, I planned to write a summary of the last discussion to sum
up the point where misunderstanding remains -- then decided they must be
evident.

Trivial approach here applies to transfering design to code, not solution in
general. The hard part is to have an abstract design that matches/solves
the problem. That includes the flow of information, and makes clear which
pieces are needed at which point.

My experience that the work to code it in a leak-free way is piece of cake
in comparision,

I feel jealous!
:--}

when the flow is complicated. And when it is
straightforward you can do it with eyes closed.

Maaan. I wish I could afford to hire you as consultant.
But I am afraid to even ask for your rate...

[...]

Take for example the issue with writing a portable GUI code.

Is there such a thing?

For any reasonable definition of "portable". (No GUI code can
be made to work on an embedded system without a terminal, for
example.) One of the advantages of Java is that Swing is
actually fairly well designed.

Can't comment on that.

And I can. Because I wrote more GUI code than most of you combined
I bet.

Yes. You CAN write a portable GUI code.

One of my current project picked java UI with Swing because it has
auto-layout.

My favorite layout is Gridbag, as screwed up as it is
and with all inconsistency of its behavior,
it beats all others hands down.
I don't even care to get some non standard layout all sorts of
people sell. I like it standard. No hacks allowed, no matter
how pretty they might look on paper.

What sounds like a cool idea when you must issue the app in a
dozen languages. And you can just have a ranslation table for the UI
strings, the rest will work.

Well, in practice it wasn't all that bright, and the auto property turned to
create a big deal of issues when translated stuff had a different size...

Well, fonts are a different world alltogether.
Combined with localization issues, forget about it.

You can not even guarantee that using the same most basic
English verions, you are going to get it rendered the same on
a different platform.

I just give users an option to reconfigure ANYTHING they want.
Fonts, colors, buttons and you name it.

So, if they like some font, but it renders differently on their
platform, be my guest. Change it in a single config file.
I do not even care to give them a luxury to do it in a sexy, GUI way.
There is a text configuration file. Open it in your favorite text
editor and change those things till your nose goes blue.
It is all self explanatory. If you can not figure it out,
too bad. You need a lobotomy work done.
:--}

On windows I still keep stumbling into programs that spoil the interface
just because I have "big font" setting.

Agreed. The windows granularity of "small", "medium" and "big"
is just for the morons. Actually, I do not know what kind of
idiot could even conceive such an idea.

Big to someone who has poor eye sight is small to someone who has
a good one.

Fonts do not have "big" or "small" attributes.
They have font sizes and those are the only things that are
standartized.

I have the same problem with my new screen.
I'd like to make fonts about 20-30% bigger.
But when I switch to next bigger font size,
it jumps proably 50% in size.

Disgusting.

And you are talking about these purist ideas about
"good software design" when the biggest and baddest players
in the industry shit right into your face with screwups of
THIS level of dumbness?

(using 1280x1024 res was far from
common back in '98 but I thought today lowes should be strange...)
The point is, I see examples that GUI gets spoiled even on the same
platform, using its natural features -- either having the items fixed or
auto-moving.

Correct. Even with Java, if you run a JMV vs. MVM, the rendering of
your GUI is totally different. Even scrollbars and buttons look
totally different. But you can not expect THIS level of granularity.
Not in foreceable future I bet.

That keeps me generally sceptic wrt GUI portability. Without a big deal of
manual work at the QA dept and coding too...

Well. I don't take that.

The issue of portability to me is the issue of being able to run
the same thing on a different platofrm. It is not the issue of how
GOOD it may look or how fast it may run.

Yes, the performance of MVM is better than JVM at least twice.
But you can still run it.

The rendering is not the same, even on the same O/S.
But you can still run it and it all works.

Well, at elast the libraries for windows do use the Windows UI the natural
way, and give you access to common controls. So at least can solve the
situation where the req says to work on Windows, but there correctly,
intuitively and user-friendly.

Portability to other platforn is not something everyone seeks, and if so do
not want to sacrifice anything for unused generality.

But I thought that is what portability means.
Never mind.

Have fun.


--
Programmer's Goldmine collections:

http://preciseinfo.org

Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.

 

[Brian]

"tanix" <[email protected]>
Ok, the situation is this:
[whole story can be replaced with "you have to keep info on
arbitrary number of incoming network packets for arbitrary
long time"]

I know, I know. I had to deal with one liner mentality for
quite a while.
But you see, if you write these one liners, you are basically
dealing with bio robots.
There is no fun of a story in one liners.
That is why I suggested on other thread that before you get
into programming, first learn about beauty. Then learn about
music.  And ONLY THEN we are going to have any luck talking to
people like you.

Well, I find his version more beautiful than yours.  It's
obviously not complete, but it does sum up the issues for one
part of the application in a very clear and concise manner.
(And as my high school English teacher used to say: "Good
writing is clear and concise.")

I do not happen to communicate in one liners of a type "coca
cola is good. drink coca cola".  Because I perceive it as
programming instructions for zombies and biorobots.
Do you mind?

Yes.  You seem to prefer long, drawn out descriptions which jump
back and forth between issues.  That's not what I'd consider
good writing.

Note that I'm not saying that such things shouldn't occur.  But
you're description sounded like a first brainstorming session,
when you really don't know yet what the application should do.
Balog's is, of course, too simple, in that it only addresses one
aspect of the problem.  But he has gotten over the first design
issue: breaking the problem up into simpler problems, which can
each be addressed by a simple statement.

My first reaction to your description is that you obviously need
two processes: one doing the filtering, and another to manage
the GUI.  With a queue between them.  In this case, from
experience, I'd say that two processes are a must, because you
want the filtering to maintain as small a footprint and use as
few resources as possible.  Which means, BTW, that I would do it
in C++, and that I wouldn't use garbage collection, since
garbage collection does have a significant memory overhead (and
in such filtering applications, unlike a lot of other
applications, doesn't really buy you that much).  For the GUI,
I'd use Java, because I know Swing, and I don't know any of the
C++ GUI libraries.

It might make sense to learn one of those C++ GUI libs since
then the filtering could be done in a thread.


Brian Wood
Ebenezer Enterprises
http://webEbenezer.net

 

[tanix]

"tanix" <[email protected]>
Ok, the situation is this:
[whole story can be replaced with "you have to keep info on
arbitrary number of incoming network packets for arbitrary
long time"]

I know, I know. I had to deal with one liner mentality for
quite a while.
But you see, if you write these one liners, you are basically
dealing with bio robots.
There is no fun of a story in one liners.
That is why I suggested on other thread that before you get
into programming, first learn about beauty. Then learn about
music. And ONLY THEN we are going to have any luck talking to
people like you.

Well, I find his version more beautiful than yours. It's
obviously not complete, but it does sum up the issues for one
part of the application in a very clear and concise manner.
(And as my high school English teacher used to say: "Good
writing is clear and concise.")

Here is a piece of writing for you.
See if you can beat it:

http://preciseinfo.org/Convert/We_are_here_to_change_the_world_01.html

And if I ever talk to you again, remember:
THAT is where we stand.

Cya.

Yes. You seem to prefer long, drawn out descriptions which jump
back and forth between issues. That's not what I'd consider
good writing.

Too bad.

Not interested.

Cya.

--
Programmer's Goldmine collections:

http://preciseinfo.org

Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.

 

[tanix]

i don't know for your difficult problem; my easy problem for leak was

"from one pointer address
print in the screen like leak
to find where in the code
was the problem"

That'd be cool if it was a realistic situation.
But things are much more involved. Long story.

if i remember well
i restart (run always in a debugger)
the program with the same input and trace
using the debugger who
reserve the memory of that pointer
when i know where is the code not free it,
all the rest was very easy

Yep. We know all that.
But thanx for the input.

--
Programmer's Goldmine collections:

http://preciseinfo.org

Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.

 

[tanix]

Well, flip some bits in Visual Studio IDE and you'll get
a dump of ALL your memory leaks when the program terminates.
Not exactly a nuclear science. But some things are not as simple
as it looks. Sure, if you are willing to waste days on it,
assuming those leaks are bad enough to make you worrry about it,
you can design some things to exactly identify the situation.
But there are times when you pass the same buffer around
to several methods and hold a reference to in on various queues
for efficiency reasons for example. In those cases, your buffer
may be releasable by several different routines and in the async
environment, you don't have a luxury of seeing a sequential
allocation and deallocation within more or less same scope of
events.

You may allocate it in one place. Then, depending on what kinds
of things happen, deallocate it DAYS later for that matter,
and from SEVERAL different places. Not just one, and I could
care less what anybody has to say on "good design" issue.

So, considering the fact there are several clients, which one has
a bug?

Yes, memory deallocations are non issues in trivial applications.
But if you do not have a gc equvalent mechanism, no matter how
you cut it, it is going to be a headache one way or another.

if there is "no way any tool can tell whether there is a leak or not"

Well, there ARE ALL sorts of tools and methods.
It is a matter of "bang for a buck", or "return on investment",
a matter of economics and priorities.

How long is it going to take you to even get into it?
Can you afford to spend DAYS?
Hours?

Well, depends on the size of the stack on your table
and relative priorities.

Yes, it is nice to hear there is such a thing as a "good design"
paradise. But that is like politicians telling you and
promising you ALL sorts of things you never seem to get at
the end.

There is this thing called reality.

that programming language has one all you call "designed error"
because can eat memory more than is sufficient
because all you can not have the controll on memory

so in the first statemt you say:
"there's no way any tool can tell whether there is a leak or not"
in the other you say
"I've worked on a
fairly large number of applications which didn't leak."

so do how you can be sure?

if pass some of your programs with some "leak print at end" program
possibily find some leak (or you OS-compiler allow to see if one program
has some leak (not free all memory) )

Unfortunately, if you do a raw malloc() type of calls and not
new(), what you get in the dump of your memory leaks at the end
of execution is something that does not tell you WHO did the
allocation, so you have no idea who MUST have done DE allocation.
And if you have all sorts of objects allocated on the heap,
the whole things becomes a nightmare.
So, I resorted to conditional compilation in some situations
and sacrifice some efficiency for the sake of debugging.

And there are tradeoffs in those "design decisions".
You do want the performance.
You do want the efficiency of resource useage.
You do want robustness.
You do want compacntess.
And you do want ALL sorts of other things.

The question is how do you have it all at once?
The answer: ONLY in paradise!
And not on the pysical domain on the planet Earth.

So...

for my little programs in my enviroment i'm sure for the memory
of the malloc wrapper (not for the memory released from "new" (i never use
it but should be used from the compiler or for static object if
i rember well))

Well, you can have an alloc wrapper.
What I did in my last version for one of the most critical
and massive allocation related methods is to ID stamp the
allocations. The buffers are allocated at a single place,
a driver interface. Once they are allocated, they are stamped
with ID of 0.

Once you start processing and pass those buffers around
and incorporate them into different objects, you increase the
processing ID.

Once you terminate the program and get your memory leak dump
from VC, the 1st byte of buffer is that ID. So you can see
exactly what routines had that buffer and could or should have
released it. That took care of some of the nastiest deallocation
issues I had that could potentially lead to MASSIVE leaks
under certain conditions.

possibily the leak is small and/or in some corner case

Even considering 5 YEARS?

:--}

I'll say it again: there's no silver bullet.

the silver bullet exist in all

In the end, good
software engineering is the only solution. Thus, for example, I
prefer using garbage collection

when I can, but it's a tool
which reduces my workload, not something which miraculously
elimninates all memory leaks (and some of the early Java
applications were noted for leaking, fast and furious).

are you sure is it good for think less?
are you sure is it good for not doing formal
correct memory allocation-deallocations?

--
Programmer's Goldmine collections:

http://preciseinfo.org

Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.

 

[Vladimir Jovic]

Why do you want to install > 1 firewall?
Well, because first of all, most of them are bluff.
They let any questionable traffic through and you don't get the
security out of it as you think you do. Secondly, all of them
have their strong points and weak points.

So, I run 2 firewalls on my box. The number one is my own,
which is a monitoring firewall. Meaning, I can see ANY funky
network traffic. NOTHING escapes me. There is no firewall
I know of that can do that kind of thing, even though I did
not look at the firewall market for a couple of years.

Have you tried peerguardian?

 

[tanix]

in the case i think, there is a place where the buffer born, and
a place where the buffer die

Yep, at least in theory AND in SYNCHRONOUS environment.

malloc/realloc has to do all the "efficiency work" (if possible)

Nope. Does not work. The buffer size varies with the packet size.
The buffer generation is pertty much a random event.
One buffer has no relations to any other buffer for related
classes. They all exist on their own and there is nothing common
between them except of the fact that they are of the same
class. But WHO will eventually be a client or "consumer"
depends on ALL sorts of things. Those buffers may become
a part of one class or another. There may be several different
complex objects that would hold those buffers for various reasons.

The only time the buffers are released is either when you
run over the limits to a number of monitor entries, or you
exit the program.

At all other times, these buffers may be temporarily held
until the user decides what he wants to do, in which cause
the references from some queues are released, but even there,
there may exist a copy of that buffer on a monitor view
list box.

The solution, finally adopted was to specifically make
a copy of the buffer so that there is no "competition"
for the same buffer.

The buffer deallocation in this situation is one of the
nastiest things you can imagine.

As far as logical design of the system, to this day,
I am not aware of a better way to design it as it is
probably the most efficient way to accomodate for ALL
sorts of different situations.

Unless this magic "smart pointer" works and is not a royal
pain on the neck to even bother about and it really does
its "automatic" whatever to make sure there is not
leaks possible, which I doubt, you have about the toughest
memory management situation you can imagine.

this can not exist, for what i write up, and double allocation
of the same pointer without free is not allow

It is not a DOUBLE allocation.
The allocation is single.
But the buffer may be temporarily owned by a different
subsystem. Those subsystems are independent and are not even
aware of each other.

Depending on logical operation, which ultimately is determined
by the user's choice, the buffer may be passed to a different
subsystem and, in some cases, may be released instantly,
in some cases it may be released at a predictable point,
and in other cases it may be held for "indefinetely" long
period of time within the scope of realistic events.

it is not one headache if all the functions to debug
has one place (at start) where all memory is created
and what place (at end) where all memory is free

Except when you have thousands if not millions of allocations
and deallocation does not happen in ALL cases more or less
immediately. Try to debug that one. Or even log it.
Would you like to look at 10 mile long logs?

then there would be something, that when the function end
and there is some leak for pointer allocated in that function,
for debug reason,
program stop and
print the line of the function and the pointer that is never free

That would be nice if it was THAT simple.
:--}

But you are talking about SYNCHRONOUS environment.
A different animal altogether.

You can not simply single step this issue in async environment.

Yes, you CAN log things into some log file.
But when you start analyzing it, you'll get a 3 mile long log.
How do you even LOOK for something in that log?
Well, DAYS of work.

in not a multithread environment, i could ask to some malloc function
the size of all the memory
allocated for the program in the start of the function
and check that in the end of that function the memory is the same
something like

Not a good idea. To do your own memory management is WAY
too ineficient and simply does not make sense.
The end result though looks nice.
Because you know you only have one buffer, which you can
easily deallocate at the end.

But then you have to worry about ALL sorts of side effects.
You see, there IS already a system for memory management
for you on the O/S level. Do you think you can manage memory
MORE efficiently than the O/S does?
Well, people spent YEARS on designing those mechanisms.
It may take you YEARS to make it finally work,
after you see those nasty special cases, hitting your like
a brick.

The problem could be solved by buffer duplication.
That is. You could make a copy of the buffer for a different
subsystem. So, each subsystem knows it is an owner of the
buffer and no matter what happens with other subsystem,
it is guaranteed to be able to deallocate the buffer
whenever it decides to do so.

But...

If the number of those allocations is huge,
you will be consuming at least double the amount of memory
by your program and will overload the O/S unnecessarily
with essentially idle things that do not have to exist
in vast majority of cases.

That is why this program is probably one of the leanest
programs you can see in your windows task manager.
It consumes about 10-20 megs. in toto, no matter what
happens. Compare it to hundreds of megs taken by just
about any modern program.

Sure, I COULD swallow a couple of hundreds megs just like
anybody else does and I COULD solve this problem in a
matter of hours if I decided to be sloppy, just like
everybody else. But hey, it is no fun that way.

I can pretty much guarantee you:
You won't find a more efficient program, more leaner
program and more robust program for ANY money, more or
less, within the reasonable limitations.

Just take ANY firewall out there, and most of them
simply create an ILLUSION that you are protected
while silently passing some of the nastiest and most
dangerous traffic without even knowing you do.

Because some of that traffic happens to be on remote
port 80, whichs your web browser. One of the most lethal
and potent rootkit versions operates a global network.
If your box is infected, it will send out a packet
on remote port 80 to their root host. No firewall
program will even notice it.

Now, once that packet is sent out, your box will be
essentially attacked by a number of hosts on their
network, and some of those boxes belong to people,
who do not even know their boxes are used in a global
most lethal network known to mankind.

So, some of those hosts may send you the ICMP type 4
packets to probe if your box is responsive.
Some other hosts may send you viruses and trojans
of the latest version.

All these things are done either in temp port range
that no firewall will even attempt to block, or in
high port range.

The bottom line is that when you use most of the firewalls
out there, you are like blindfolded.

One of the things I have in my firewall is the traffic
indication lights. As soon as I suspect something, I just
click on icon and simply look at the traffic light.
If I am not doing anything and see those lights flashing,
then something funky may be going on. At THAT point, I
may just push a single checkbox and it will display me
every single packet my box is dealing with. If I right
click on any of those packets and push a single button,
my firewall will perform a whois request from all the
major world's servers and will automatically filter
the server results and display it in the window.

That is another set of buffers. Also fully async.

There are also the DNS buffers. The forward/backward
DNS requests are performed automatically for ANY
funky pakcet, so when I look at the monitor listbox,
it shows me not only the remote IP, but remote host name.
The DNS requests are fully async and will automatically
update the monitor entries as soon as DNS server
sends me the data.

There are trace buffer, raw socket buffers, and you
name it.

When some jack says he has a magic solution for me,
I just say: go to hell.

Ok, Cya.

unsigned z;
z=All_malloc_memory();
f(a,b,c,c,s);
x=All_malloc_memory();
if(x!=z) {printf("Memory problem for f line=%u \n", 1111); exit(0); }

Cool.
:--}

I wish it would be THAT simple!

--
Programmer's Goldmine collections:

http://preciseinfo.org

Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.