Re: Exception Misconceptions
In article <4b2fb5f7$0$1120$4fafbaef@reader3.news.tin.it>, "io_x" <a@b.c.invalid> wrote:
"tanix" <tanix@mongo.net> ha scritto nel messaggio
news:hgno7a$7hu$1@news.eternal-september.org...
In article <4b2f4d16$0$1109$4fafbaef@reader4.news.tin.it>, "io_x"
<a@b.c.invalid> wrote:
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.
it seems to me it is eficient
Well, Ok. I CAN comprehend that.
The only thing is there are some NASTY memory management
details if you are going to manage your own pools of memory.
I happen to have deal with things like that in the past.
At the moment, my position on everything more or less is this:
use standard, off the shelf, components subsystems, etc.
Do not try to oversmart the O/S. It won't pay at the end.
In a fully multithreaded environment, ESPECIALLY in async mode,
be as careful as you can manage. There is no need to reinvent
the wheel. Some of that code, you may be trying to bypass,
took YEARS to perfect, and there are ALL sorts of reasons
it is as it is. Yes, one of those reasons is backward
compatibility and some things end up being not as efficient
if it was not the case. But overall, you are most shielded
from the revision issues in the O/S, your IDE, language
fashions and you name it.
Basically, your code should work not only today, but
for generations to come on any future version of O/S,
more or less, if at all possible.
Some of the programs I ran were written 15 years ago,
and they are STILL the best I know of. The most flexible,
the most powerful, etc. And YES, they do have bugs,
because they are THAT old, and some things may even
cause crashes of the whole program, just like it happened
a couple of minutes ago.
But...
After looking at PLENTY of other programs that do pretty
much the same kind of things, I still return to them,
and never regretted. It is like a hand in glove.
The porst "portable" way of doing it.
The most intitive way of doing it.
The simpliest way of doing it.
And the list goes on.
Even if I loose my box, I am still in a good shape.
Nothing has been lost. At most a few hours of work.
And that is good enough for a poor guy like me.
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?
don't know, but for my programs the speed is good
Could be. I can not possibly argue that.
We'd have to discuss your program, and I'd have to spend at least
a few hours on it. Sorry, can not afford that at the moment.
Well, people spent YEARS on designing those mechanisms.
It may take you YEARS to make it finally work,
i use the malloc found in the K&R book
with some modifications (the ones for find
bouds errors, memory leak, etc)
Well, the interesting thing about C is that it is STILL
the most active group on usenet. The traffic on C groups
is even higher than on C++ group.
And, from what I know, C is probably the REAL "revolution"
in the programming languages and it was the one, used
to create the most long standing operating system.
And, after GENERATIONS, it is still there. Full blast.
That is not only "good" design.
It is MONUMENTAL design.
And with ALL its limitations, you can still rely on it
like you can not rely on anything else in the sw world.
it seems i remember that i wrote something for allow
that malloc function to be fast on stack allocation
p1=malloc(1255);
p2=malloc(4555);
p3=malloc(2555);
.....
free(p3);
free(p2);
free(p1);
has few clock size for free; don't remember if for write
that i change all the malloc function and
structure type heavy
what was a little more hard was to write the realloc function
using what CBFalconer said, in assembly
[ if realloc(alloked+x)
alloked free
-------|__________________________ =>
alloked+ x free
---------------|__________________
]
i wrote all in asm because for these operation
assembly is my language of choice
Hey. I like that stuff. I reminded me Forth experience.
What a fun that was. Did not last that long, but it WAS fun!
:--}
after you see those nasty special cases, hitting your like
a brick.
the malloc function ask to the OS memory function some memory
so that memory is for my programme, i not see
nasty special cases if not count issues for aligned data
Well, OK. Let me see if I understand what you are trying
to say.
Are you saying that you want to make a huge memory request
and the try to have your own equivalent of .alloc() functions,
where you get a piece of memory from that original chuck
of memory you allocated?
If THAT is the case, then you are for some nasty surprises,
trying to manage memory by yourself. These things are not
that simple.
Say, for example, you have MANY allocations and deallocations.
Each allocation is not of a fixed size. It can be anything.
So, assume you requested a chunk of memory from your own
memory management system.
Then you requested an arbitrary number of other chunks.
Then, some of them can be released.
So what do you do?
How do you release it?
You have a memory fragmentation problem.
You'd have to keep the lists of free chunks or unallocated
holes in your memory region.
What if you have many free holes, but the block you are
trying to request is bigger than any single hole you have?
Well, you simply conc out, you simply die. Because there
is nothing you can do at that point, unless you keep
merging the ajacent memory regeions during the release phase
and do ALL sorts of nasty memory management things.
It is such a royal headache, I can not even begin to describe it.
The days first all this malloc function,
my little programs for bignums
written in C and assembly and in "C++"
not work at all, the program goes to segfalut one minute yes
the other minute too
after that, no problem, no seg fault, no write out of bound
or memory leak or too much memory used
but my experience is little,
the difficult error i fixed were of the kind
why the big num
(0,0, 0xf78f898f, 0x73893838, 0x893038333, 0x73893838)
* or /
(0xf78f898f, 0x73893838)
have a wrong result
or find who write "out of the array bounds" of
some bignum array of unsigned
for find that i used what i said above
for example
h fname(a,b,c)
{
writeToTheArray("fname");
// in the start of function
// it write its name in a 'rotating' array
// then allocate memory with malloc (in class too)
// for the "fname" function, at the end of that function
// free all array of malloc (checking if some
// out of bound error too); if some out of bound is find
// print the static array of all calls and exit(0);
// and eventually use some function for see
// where is the problem inside the function
// eg
if(!isInThisPlaceAllMemoryWithBoudsOk())
{printf("The error is above here\n"); exit(0);}
}
what it print was one array of the kind
f1||f2||f3+|f0+-fy+-etcetc
and i did know that in f3 there was one error
of some out of bound written array
but it seems now, not so useful because it seems
i do less error and few memory leak, and few wrong array
write
Maaaan. I feel jealous of you. It must be such a fun
to dig into this stuff at the point where you are!
Enjoy the trip.
--
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.