D
dragan
James said:[....]James said:James Kanze wrote:
"dragan" ha scritto nelThat's the whole point of exceptions. They're for the sort of
problems where it doesn't matter where the problem occured; the
handling is the same. If you run out of memory processing a
request, for example, it doesn't matter where you were in the
processing when you ran out; you just abort the request (but not
the process) with an error message, and continue.
You seem to be big on aborting.
Attention about word use. There's aborting (in the sense of
calling abort()), and aborting (in the more general sense,
of immediately terminating some action that you were in the
process of doing). In this case, I'm using the other sense:
say you've received a request on your LDAP server, and you
run out of memory trying to service it (because it requires
interpreting some obscenely complicated filter expression,
for example). When you detect the lack of memory, you're
down in some really deap parsing function, executing
operator new. You (or rather the system) raises an
std::bad_alloc exception, which you catch at the top level,
and abort the request (not the program), returning an error
message of "insufficient resources", or the like.Ah. Bad choice of word then to describe that.
I didn't invent the language (English). I just use it.
Don't worry about. It's my "second language", but maybe that elicited me to
study it more. I have found no error in you use of English.
I don't
know of any other word for what I described; abort is the
standard word.
It sounds like an "unstudied appropriation". "Hurried". Inappropriate and
incorrect.
I think most people read more than just a word at a time,
Oh, you know I'm not gonna let you off that easy Mr. (Did you read where I
was spanking the other with such childish tactic? Did he maybe LEARN it from
you??!)
and
the expression "abort the request" is quite clear. "Abort the
request" is not "abort the process".
Noted: your vocabulary is terse so you requisition what you have at your
disposal, hoping that it will be understood (or hoping it will give you a
scapegoat!). I understand the way you think. You are unsure of what to do.
And so, unsure of yourself. But, you KNOW that you can be MORE or "the
bomb". Let's get it done. You're really Elvis, right? I mean really, you
can't hide forever right? Surely you are Elvis. The King!
:/ <-- parse this.
I'm not sure I follow. The server will certainly have some
resources preallocated, so that it can successfully log the
error, unwind the stack, and return an error message.
Pfft. Stop already. To cut the convo short: I think I can deploy without C++
exceptions. Any of this "large scale" bullshit, does not apply to me, so
curb it already. Stop being pedantic. (Or not, it's all good: it's my fault
if I get sucked into these USELESS tiradal "discussions").
But by
definition, it can't use those resources for parsing the
request, or they won't be available for the things they were
reserved for.
Answer: too abstract. I have a real application and don't need to be
thinking about "THE general solution" that will do this that AND cure cancer
as a side effect. Nuff said. If you don't grok that, I don't care, you're
not my problem.
Which one? Are you saying that if you get std::bad_alloc, you
should output a message to the terminal, asking the sysop to
insert additional memory chips, and only continue when he does?
I could call you facetious, but I think you trully are not following the
main points. Your scapegoat is that you follow too many threads. I said
"preallocate", but just like I said that error handling (not "management"
this time) is application-specific, so is that one specific error. I know
those answers. I don't want to entertain discussion or be the bouncing board
for those who only "read the books". No offense, but it's not my thing. And
no, I'm not being "high and mighty", nor am I about to be a whimp. (speaking
of whimps, I noticed you didn't have anything more to say about being WRONG
about "error reporting").
Preallocate what?
M-E-M-O-R-Y.
Parsing an LDAP request requires unbounded
You don't really expect me graft my discussion on your post-conceived
scenario, do you? That would be so "unsporting".
memory, since the request can be arbitrarily complicated: the
filter expression can contain any number of parenthesized
sub-expressions. It's just like a C or a C++ compiler: feed it
a file with a function which contains 2 billion nested
parentheses, and see what happens. You can't predict up front
how complex an expression will be, and how much memory you'll
need. Either you arbitrarily limit the complexity (for example,
to prevent stack overflow if you're using recursive descent), or
you handle insufficient memory. Or both: you might normally be
able to handle the expression, but not if a thousand or so
clients send it at the same time.
So, maybe "call me" when you have a PRODUCT like SmartHeap? Else maybe "shut
up"? You don't really think I'd consider hiring you before I'd buy a product
like that, do you? I do it differently, yes. Internally I DO "compete" with
the commercial memory allocator offerings. No offense meant.
Dragan
"English is my second language"