C++ syntax without C++ - Page 6

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: C++ syntax without C++
Hi Tom,

On 11/7/2013 3:06 AM, Tom Gardner wrote:
Quoted text here. Click to load it

(sorry, I don;t do Java)

Quoted text here. Click to load it

Yes.  It's more "documentation".  OTOH, it *exposes* more which
some folks find bad.

E.g., look at folks who get spooked seeing a "seconds" value of :60
in a timestamp:   "WTF?!  That can't happen!"  *Sure* it can!  :>
Now, consider how your code may break when now+60 isn't really
now+60!

Quoted text here. Click to load it

I think this is true of many scenarios.  I.e., why don't
people check malloc()'s return value?  And:  because they
haven't a clue as to how to deal with that possibility
and don't want to think about it!

(Or, because the execution environment doesn't give them
convenient hooks to "do something smart" in this case!
E.g., *block* inside the allocator until the request
*is* satisfied!  Of course, this just *changes* the problem!)

Quoted text here. Click to load it

Is this because so many "write code" that interacts with
"people"?  And, they rationalize that the peson can just
"try again"?

Re: C++ syntax without C++
On 07/11/13 21:45, Don Y wrote:

Quoted text here. Click to load it

If you try to ignore a checked exception, your code
simply won't compile.

You must either explicitly catch the exception in your
method, or explicitly define that your method can throw
the exception. (Inserting either requires one keystroke
in a modern IDE :) )

That's the best kind of documentation - something you
cannot ignore!

Re: C++ syntax without C++
Hi Tom,

On 11/7/2013 3:34 PM, Tom Gardner wrote:
Quoted text here. Click to load it

But it doesn't force you to "handle" it effectively.
I.e., you're still dependant on developers being
"responsible" (and not just propagating all exceptions
up the food chain, etc.).

I suspect it's much like folks adding extra casts to
silence compiler warnings -- instead of thinking about
why they were "needed" (a sign of something WRONG
elsewhere)?

Language designers really have a tough time.  Every time
they put something in place to "improve" the code, they
risk it being seen as an "irritation", instead.  So,
instead of its intended goals, it just fosters workarounds
that render it useless.  Or, *worse* than useless?

:<

Must be sort of what raising kids is like!  ;-)

Re: C++ syntax without C++
On 08/11/13 01:34, Don Y wrote:
Quoted text here. Click to load it

Of course. But nothing forces you to write "a+b"
when "a-b" is correct.

Quoted text here. Click to load it

That is often (but not always) the most appropriate
course of action - if your code can't take appropriate
recovery action,  then it has to be the higher
level's responsibility.


Quoted text here. Click to load it

Oh, anybody with any sensibility /knows/ they
are going to cock up their children in one way
or another! Deal with it!

Re: C++ syntax without C++
Hi Tom,

On 11/8/2013 9:43 AM, Tom Gardner wrote:

Quoted text here. Click to load it

But that's my point:  if the person writing the code
doesn't know what to do with the exception (lack
of imagination/specification), then the fact that he
now knows about it doesn't buy you anything!

Quoted text here. Click to load it

The advantage of exceptions is they *can* percolate more
information upwards -- instead of DISCARDING the detail
in some lower level and just propagating "FAIL" back
up through the call stack.

(Though no guarantee that anyone upstream will be
able to figure out *which* operation caused the
"ENOMEM")

Quoted text here. Click to load it

We have -- by not having any!  :>  Far easier (and less
risky) to be "honorary uncle" to others (seems they
also are more appreciative of your time than they
are of parents'!)

Re: C++ syntax without C++
}The biggest advantage I see to (this sort of) exceptions is that it
}makes it much easier to be more *descriptive* of the root cause of
}the "error".  Instead of just return(FAIL) because the topmost
}level has no idea what the *reason* for the failure propagated up to it  
}may have been!

Could you point me at any openly-accessible code which uses exceptions like
this? I have been looking for a good example for quite a while now.

Re: C++ syntax without C++
On 10/11/13 03:08, Charles Bryant wrote:
Quoted text here. Click to load it

In Java frameworks and libraries there are many examples of that;
it is rule rather than the exception (ho ho). It is one of the
reasons it is possible for competent /mortal/ developers to construct
complex systems relatively easily.

In C++ I couldn't comment.


Re: C++ syntax without C++
Hi Tom,

On 11/10/2013 4:11 AM, Tom Gardner wrote:
Quoted text here. Click to load it

Exceptions are just confined to languages that formally support them.
It's a *concept* so you can choose to adopt/implement wherever you
want (often in kludgey ways).

E.g., I use them in C with preprocessor support to give me a more
palatable "syntax" (though the compiler can't tell me if I've
screwed up!)

Like many "tricks" (bad choice of word), this requires a bit more of
an understanding of your execution environment.

Just like dealing with errno in a multithreaded/multitasking
environment!

Re: C++ syntax without C++
On 11/10/2013 2:21 PM, Don Y wrote:

Quoted text here. Click to load it

Grrrrrrrrrrr... s/are/aren't/

Re: C++ syntax without C++
On 10/11/13 21:21, Don Y wrote:
Quoted text here. Click to load it

One of the least appealing characteristics of C++ and the C++
community was the continual unwitting poor kludgy re-invention
of features that worked tolerably well in preceding languages.

It is probably unfair to say "unwitting", but they never
bothered to reference the concepts from other languages.

In contra-distinction, the Java whitepaper in 1996 made
repeated statements of the form "feature X was first
demonstrated in Y, and works well with Java features A,B,C
because...".

Much more impressive.


Quoted text here. Click to load it

The troubles with anything like that is integrating it with
decent tool support and having other people (e.g. maintainers
or co-workers) understand it.


Re: C++ syntax without C++
Hi Tom,

On 11/10/2013 2:29 PM, Tom Gardner wrote:

Quoted text here. Click to load it

Look at whence C++ came -- the same folks who thought big,
formally defined systems were too constraining (MULTICS -> UNIX).
Do you think folks with a "Wild West" mindset would want to
*force* a particular coding style/technique on others?

Look, e.g., at Limbo/Inferno -- the "most modern" creation by
the same sorts of minds and ask how much is elegance vs. kludge.

Quoted text here. Click to load it

Exactly -- there's the rub.  You can build something that is
self-consistent, works well, robust, etc.  But, if the first (or second)
person who touches it *after* you bodges the whole thing, then what's
the point/value?

OTOH, it *does* get you thinking along different lines and,
hopefully, inching towards better style and technique -- despite
how your development environment shackles you!



Re: C++ syntax without C++
On 10/11/13 21:48, Don Y wrote:
Quoted text here. Click to load it

True, but that's a different point. In effect the kludges are
/preventing/ an elegant coding style.

Re: C++ syntax without C++
Hi Tom,

On 11/10/2013 2:59 PM, Tom Gardner wrote:

Quoted text here. Click to load it

But that was my point!  MULTICS really tried to approach
"computing" with the same level of robustness as a public
utility (!!)  I.e., INSANE uptimes.

UNIX took the opposite extreme -- "let's just get something
up and running and if we have to reboot DAILY... <shrug>"

There (appears to have been) a lot more forethought put into
how MULTICS was "assembled" ("put together") than UNIX.  Its
structure as well as the methodologies applied.  You get
the *feel* that UNIX was a "garage shop" operation.

[I am not meaning to malign UNIX.  Rather, comment on the
different mindsets behind them, their makers, their tools, etc.]

As tends to be true in many cases in our society, "quick" often
wins out over "good".  Which would be fine -- if you could backfill
"good" AFTER "quick" (this seldom seems to be the case).

And, folks looking at existing codebases are REALLY hesitant to
even consider NOT using them: "imagine all the manhours that
are represented in this stuff!!!".  So, the kludges perpetuate
with little incentive to ever go back and "fix" things (or
reimplement, etc.)

E.g., the current "(death)spiral" approach of incremental
design:  you don't know what you really *want*... but, you will
know what you DON'T want -- after you've coded it!  (then, just
tweek it and repeat)

[Of course, this also means you are essentially locked into the
initial assumptions you have made -- yet "con" yourself into thinking
they can be "revised" on the next loop around!  With the waterfall
approach, this was incredibly evident BEFORE YOU GOT STARTED!]

Re: C++ syntax without C++


Quoted text here. Click to load it

BLISS supported exception handling on VAX/VMS in the 1970's :-).  

Installing exception handlers, resignal exceptions, unwind stack and
continuing from an exception were all supported from the start (see
VAX/VMS architecture handbook).
  

Re: C++ syntax without C++
}On 10/11/13 03:08, Charles Bryant wrote:
}> }The biggest advantage I see to (this sort of) exceptions is that it
}> }makes it much easier to be more *descriptive* of the root cause of
}> }the "error".  Instead of just return(FAIL) because the topmost
}> }level has no idea what the *reason* for the failure propagated up to it
}> }may have been!
}>
}> Could you point me at any openly-accessible code which uses exceptions like
}> this? I have been looking for a good example for quite a while now.
}
}In Java frameworks and libraries there are many examples of that;
}it is rule rather than the exception (ho ho). It is one of the
}reasons it is possible for competent /mortal/ developers to construct
}complex systems relatively easily.
}
}In C++ I couldn't comment.

I should have been more explicit. I'm sure they are written with that in
mind, but I expect libraries may only have lots of examples of throwing
exceptions. I'm interested in seeing how they are caught and handled
as well.

Re: C++ syntax without C++
Hi Charles,

On 11/11/2013 4:58 PM, Charles Bryant wrote:
Quoted text here. Click to load it

The problem is that this is highly application (domain) specific.
And, within that, largely influenced by developer philosophy.

E.g., (pseudo-code)
     if (time_spent <= 0)
        speed = 0;   // does anything else make ANY sense??
     else
        speed = (miles) distance_traveled / (hours) time_spent;

is how a "traditionalist" might approach the "speed" problem.

But, you could also
    try {
       speed = (miles) distance_traveled / (hours) time_spent;
    }
    catch (mine::exception& ex)
    {
       speed = 0;
    }

Which is "right"?   Better??

Similar problem:
    net_hourly_pay_rate = (dollars) net_pay / (hours) time_worked;

Is this the same problem as above?  Or different?

If the first is happening in a loop invoked every 60 seconds
(nominally -- even if time_spent is cumulative!), then you
don't EVER expect to see time_spent == 0!  Yet, it would be
foolish to not deal with that possibility -- because that
constraint is too loosely applied (in this example).  Someone
could easily change that behavior (perhaps in some other
part of the application!) and forget about this computation!

OTOH, the pay-rate example may occur in the normal processing
of a paycheck.  Some employees may NOT have worked at all
this pay period.  Nothing "exceptional" about that!

See what I mean?

*MY* (personal) philosophy is to not clutter the normal execution
path with things that aren't likely to occur.  Move them out of
the way (visually & conceptually) so you can "see" what the
nominal actions of the routine are expected to be.

OTOH, if "some condition" is expected to happen "often" -- so
much so that you actually think of it as *part* of the problem
that you are "solving", then it should be prominently exposed!

(Of course, a lot of this is easier of the language will unwind
the stack *for* you, etc.)

Re: C++ syntax without C++
On 12/11/13 20:45, Don Y wrote:
Quoted text here. Click to load it

So yours is based on the "occurrence" of a condition.
Mine tends to be based on the "response" to a condition.

If a condition can reasonably occur in normal operation,
then I should test for it and deal with it.

If the condition should never occur in normal operation
or I can't determine the appropriate response, then
I'll throw an exception.

But I reserve the right to do otherwise :)

Re: C++ syntax without C++
Hi Tom,

On 11/12/2013 2:07 PM, Tom Gardner wrote:
Quoted text here. Click to load it

Yes.  E.g., I tend to expect malloc *not* to fail so handling
a failure would tend to be "exceptional".  E.g., when allocating a
local heap off the global heap, I typically know that this
"can't fail" (because of the design analysis).

OTOH, there are cases where I *may* expect it to have a
reasonable likelihood of failing.  E.g., imagine a user
creating yet another email address (in an unbounded address
book structure).

I.e., I have to *plan* that this can fail as part of the
normal design of the algorithm as opposed to being "surprised"
that it failed!

(subtle differences that are very subjective)

Quoted text here. Click to load it


Re: C++ syntax without C++
On 12/11/13 21:25, Don Y wrote:
Quoted text here. Click to load it

That's still focusing on the "occurrence". What would
you do if /at that point in the code/ you didn't know
the appropriate response or couldn't locally make
an appropriate response?

For example, what would you do if malloc did fail,
despite your best efforts at analysing all the code
produced by other people that has been linked in?

If complete analysis of the system is possible then
you have been working on simpler and more contained
problems than me!

Re: C++ syntax without C++
On 11/12/2013 2:49 PM, Tom Gardner wrote:
Quoted text here. Click to load it

Every possible failure has to be handled.  I.e., if
a function *can* return an error code (or throw an
exception) then you have to do something about it.

I was trying to draw attention to the types of
"conceptualizations" that I use in deciding how to
approach "errors/exceptions".

Returning to my "heaps" example...

The system heap has a fixed, known size.   (whether this
size was determined first or as a consequence of the
consumers of that heap is immaterial).

When I bring the (this) system up, I have a fixed, KNOWN
set of processes that must be created.  Each of these
needs a heap (within that heap, I will allocate the
stack for each local process).  The sum of these heaps
*must* be less than the size of the system heap.
Otherwise, the system can't start!

[In practice, the system heap's size fits the needs of these
processes *exactly* -- as any extra memory is inaccessible
once the system is up!]

So, I can pick the CONSTANTS that I use or each of these
sizes such that they always sum to a total less than that
of the system heap's size.

This can be enforced with an invariant.  "CAN'T FAIL".

OTOH, I wouldn't elide away this test at run-time!   E.g.,
what happens if there is some other way for the code to
get back to this point?  Even if it was a *bug*?  So,
this code (or portions thereof) tries to get executed a
second time!  Or, some seldom used "debug" path is\
invoked that creates a "debugger" task that happens to
consume part of this system heap.

In that case, an allocation that "CAN'T FAIL" suddenly
(unexpectedly!!) fails.  Do you notice this?  Or, do you
let the condition propagate through your code in some
indeterminate manner?

If you can't "handle" the error, all you can do is
FAIL.  Hopefully, whoever invoked you can handle this
failure!

E.g., if a process (task) exhausts its stack allocation,
there is nothing that *it* can do about that!  But, the
*system* (or the task's parent or an exception handler
nominated to handle this sort of thing) can deal with
it.  Even if just to log an entry in syslog...

Quoted text here. Click to load it


Site Timeline