Re: Exception Misconceptions
In article <hglc7c$20ub$1@news.ett.com.ua>, "Balog Pal" <pasa@lib.hu> wrote:
"James Kanze" <james.kanze@gmail.com>
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.
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.
(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.
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.
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.
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?
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.
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.
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.
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.
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.