C++ syntax without C++

Grrrrr.... this is why I don't "work" mornings!!! Apologies to anyone caught by this screwup in the past hour (time for me to repair, rerun test suite and document the screwup)

(OBVIOUSLY) should have been:

t6 := (test) (test6, "Preinitialized Global objects plus sprint"); t5 := (test) (test5, "Global objects plus sprint"); t4 := (test) (test4, "Create, init and destroy objects plus sprint"); t3 := (test) (test3, "Create and destroy objects"); t2 := (test) (test2, "Create, init and destroy objects"); t1 := (test) (test1, "Create, init and destroy objects plus operations"); t0 := (test) (test0, "Subroutine invocation overhead");

Reply to
Don Y
Loading thread data ...

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

Reply to
Don Y

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 :)

Reply to
Tom Gardner

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)

Reply to
Don Y

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!

Reply to
Tom Gardner

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...
Reply to
Don Y

On Sun, 10 Nov 2013 12:43:26 -0700 in comp.arch.embedded, Don Y wrote,

I don't believe you. My guess is that he told you that your interpretation was consistently wrong, and you refused to believe that there was any problem with your interpretation and therefore that the problem must be his.

>
Reply to
David Harmon

ROTFLMFAO!

You can, of course, believe what you choose. But, that won't change reality! :->

You could also go purchase copies of each edition/release of each of his titles and hunt for bugs, yourself -- if you are interested in The Truth. (Hmm, why a new edition if nothing wrong with the old?)

I've also got a text here from some folks at Mayo that has some glaring errors in it.

Expecting things to be "correct" solely because they are "in print" is overly naive!

Reply to
Don Y

And the reality is that you told some made-up self-aggrandizing bunkum story at the expense of a better man than you, and when Charles asked for specifics you have Zilch.

>
Reply to
David Harmon

Gee, would be awfully foolish of me to make a claim when the books are out there for folks to consult! You can feel free to do the legwork to PROVE ME WRONG! *I*, OTOH, have no incentive to lift a finger to prove (to myself) that my memories are correct.

Believe what you want. No skin off *my* back, either way! :>

Hey, great COMPROMISE approach! As you are probably just lots of hot air and NOT inclined to investigate for yourself, why not *hire* someone to do this work for you! That way, you will be able to KNOW FOR CERTAIN (despite your opinions/delusions on the subject).

Figure out how long it would take *you* to do all the research. Then, decide on a reasonable hourly rate for your time. Then, find someone who is willing to undertake the task on your behalf FOR THAT FEE.

What's a reasonable cost for such a task? $1,000? $10,000?

Hell, let's make it interesting -- put $100K in an escrow account and I'll give you contact information for my attorney. Once he has verified the CASH in the account and has your signature on an agreement, *I* will do the research *for* you. And, if I'm

*wrong*, I won't cash your check. YOU HAVE NOTHING TO LOSE! YOU ARE *SURE*, right??

This is going to be the easiest $100K I've ever made!!

Put up or shut up. Remember, all of this is a matter of PUBLIC RECORD :> I've not retracted any of my claims!

C'mon... call my "bluff". I'd LOVE to have a photo to publish of me cashing YOUR check!! Make it WORTH my while to prove YOU wrong (not *me* right!) :>

Reply to
Don Y

He's not infallible, look at the reviews for the latest (4th) edition of the "bible", "The C++ programming language".

While very positive, a lot of the reviews complain about the number of syntax errors in the example code.

--

John Devereux
Reply to
John Devereux

Indeed - most books contain some errors. It is not uncommon for computing books to have their example code available online as well, so corrections can be made easily after printing. And sometimes it happens that an author will make a major mistake, or miss a much easier way to handle a problem - authors are mere humans like the rest of us.

I don't think Don claimed that he was the /only/ person to have spotted this mistake, or was claiming to know more C++ than Stroustrup - just that he spotted this particular sizeable error, and that the author agreed with him. Sounds believable enough to me.

It might help if Don could remember at least /something/ about the case in point, but I'll assume his anecdote is true unless proved otherwise.

Reply to
David Brown

Just look at the errata page, published on Stroustrup's web site. Actually, print out a copy to keep with the book before even trying to read it and don't bother bitching about errors that have already been corrected. How many authors give you that?

I'll stick with my guess that Don's story is grossly distorted and overblown, based on a shred of a fragment of underlying fact, unless he comes up with at least some minimal hint of evidence otherwise. His hysterical bluster about how *I* should search everything Stroustrup has ever published, looking for something that he can't even remember to match *his* inflated claims, doesn't help.

Reply to
David Harmon

Thanks, I will do that.

Actually code in the programming books I have read is generally machine-checked. Even going back to K&R IIRC.

I was not denigrating Stroustrup here. I found the edition I bought in

2000 an excellent book, and I have just bought the 4th edition (includes c++11).

But he can make a mistake just like anyone else.

I agree that was a bit silly.

--

John Devereux
Reply to
John Devereux

Consider this:

If you are knowledgeable about the code (language), why have syntax errors at all? Can't you *run* the code through a compiler to at least

*check* the syntax? Even if you don't TEST THE CODE?

The first manual that I wrote had lots of examples in it. KNOWING that typos creep into examples (and, that many folks reading a manual may not be intimately familiar with the product and, thus, RELY on the manual as The Authoritative Reference), I made a point of running the examples, verifying results and then copy/pasting the examples directly into the manual. Ditto screen shots, etc.

I.e., "*this* code yields *these* results". Not "some piece of code SIMILAR to this" yields "some results that are more-or-less like this" (typos can creep into the "output" as well!).

*This* is a "typo" (actually, three): # build "tests" t6 := (test) (test4, "Preinitialized Global objects plus sprint"); t5 := (test) (test4, "Global objects plus sprint"); t4 := (test) (test4, "Create, init and destroy objects plus sprint"); t3 := (test) (test2, "Create and destroy objects"); t2 := (test) (test2, "Create, init and destroy objects"); t1 := (test) (test1, "Create, init and destroy objects plus operations"); t0 := (test) (test0, "Subroutine invocation overhead"); (cf. test4 & test2 unintended duplicates)

It's often easy to catch a typo because it is glaringly obvious (as was the case when I noticed the anomalies in the results I posted for each test -- and fixed half an hour later). Someone "new" to the language would be able to spot the TYPO (as above, or below).

for (i = 0; i < NUMBER; i--) { something() };

This *isn't* a typo: int result; result = malloc(...); if (result == 0) exit(); *result = 4; result = 3 * result + 2; Someone new to the language reading this -- AND HAVING THE SYNOPSIS FOR MALLOC HANDY -- would be puzzled by the "incongruity" here. "What am I missing? What am I failing to perceive in this example because it clearly looks *wrong*. And, not 'in a SMALL way'!"

WHEN YOU ARE THE AUTHORITATIVE FIGURE for a topic, you earn a much bigger "benefit of the doubt" among your audience. "Surely HE can't be wrong -- he's *The* Expert!"

If you're writing an editorial, sending a one-off email, etc. the stakes aren't high. A bit of egg on face and that's about it. OTOH, when you are writing DEFINITIVE REFERENCES, I think you have an obligation to get things right.

Reply to
Don Y

And some of these errors are deliberate :-).

By injecting some random errors in various editions, it is easy to detect from which edition and possibly from which print some illegal copies have been generated.

Reply to
upsidedown

I claimed that the error wasn't as trivial as a "typo" -- which even someone new to the language would be able to recognize as such (see my example elsewhere this thread).

I claimed that his reply (to me) suggested that he was unaware of the error before I brought it tot his attention.

I claimed that it wasn't something in the dark corners of the language that would be particularly tricky for EVEN HIM to get right (i.e., *I*, as a neophyte, was able to spot the error).

My recollection of my email was a *tiny* "book fragment" reproduced to show the error (though the error was repeated multiple times -- hence negating the "simple typo" idea) accompanied by the page number from which it was extracted, the title of the book and the edition (printing date).

My accompanying message *apologized*, in advance, for BOTHERING HIM with something that must UNDOUBTEDLY be a shortcoming on MY PART. Yet, complaining that I couldn't make sense of his text: "What am I missing?"

*His* reply was something to the effect of, "You're absolutely right (*I* am wrong). That whole page is BACKWARDS."

Note that I am not equivocating, here. I'm not misunderstanding his explanation. He *clearly* stated he was in error. And, that the error was not just a "typo" in the small example I had reproduced in my message to him. "That whole page is backwards".

I.e., when David Harmon agrees to put some money where his MALIGNING MOUTH is, I will go search my email archive (I used to keep all my email archived for business reasons, 20 years ago) for that phrase!

Until he's put some money on the line to pay for my time (and make his "crow" far less palatable), it's not in my interests to invest the time to prove my claim.

OTOH, I'd sure like to make it HIGHLY PROFITABLE to do so! "Sure things" are so few and far between! Especially when I have disinterested third parties to testify to my claims :>

When I think of "backwards" and "C++" the only thing that comes to mind is ++ vs. --. Yet, I am *sure* the error wasn't a CONSISTENT misuse of "++" where "--" was intended.

And, recall the point of my initial mention of this event: it was to illustrate how much stuff happens "in the whitespace" in C++ that EVEN ITS CREATOR can miss!

Years ago, I was reading one of Stroustrup's C++ books. I had to keep RE-reading a section (a few pages) as it seemed entirely WRONG to me. Yet, here's the guy who created the language... surely the problem must be one of comprehension (lack thereof) on my part!

No, it's not a "typo" -- he is taking a consistent position and repeating it. "What am I missing?"

I finally took the opportunity to write to him -- humbly citing chapter and verse and explaining my dismay at failing to understand (or agree with) his points: "What am I missing?"

His reply: everything he had written was WRONG. (WTF? Surely *you* with the most experience in YOUR creation...)

What does that say about those of us who are less experienced, less disciplined, less invested or less intelligent? People who imperfectly know something inevitably make mistakes. People who aren't "motivated" don't CARE about their mistakes. Presumably, Bjarne was neither -- yet still made a glaring mistake -- and printed tens of thousands? of copies thereof! (apparently coming as a surprise to him as he didn't indicate it was a "previously reported error")

(Hmm... where did I "malign a better man" in this? I wonder what term you would use when you publicly call someone a LIAR?? :> )

"And the reality is that you told some made-up self-aggrandizing bunkum story at the expense of a better man than you, and when Charles asked for specifics you have Zilch."

Ain't USENET wonderful? Makes a permanent record of all these claims!

Yet *I* (and Stroustrup) know The Truth -- while David Harmon will never know "for sure" -- whether he is safe in his delusion or not! :>

Priceless!

Reply to
Don Y

Ah, well, $100K is probably out of your league -- especially given that you're just working "on faith" --- your own, at that!

So, let's be more realistic. A day's pay? $1000? Surely it ahould be worth that for you to coerce *me* to invest *my* time TO PROVE YOU RIGHT (by failing to prove myself right)! Hey, if you're right, it doesn't cost you a penny! Of course, if you're *wrong*, it SHOULD cost you something! Surely you can live with a day's less pay for all your "bluster" and "maligning my reputation".

C'mon! I'll provide verifiable THIRD PARTY PROOF that you'll be able to verify from the comfort of your office! That EVERYONE READING ALONGSIDE can also verify!

*But*, you gota PAY to PLAY!

So, what's it gonna be, big man? Gonna sit and hide behind your words? Or, put your money where your mouth is?

NEVER say something in a public forum that you aren't willing to back up. It's too easy for people to hold your feet to the fire and you've no wiggle room to sneak out of your claims. A client could bring you to court. Another party could sue for libel, etc.

I suspect I've set the bar really LOW in this case. $1000 to learn a lesson... whaddya say??? :> How *sure* are you of your claims???

Reply to
Don Y

If your e-mail archive is reasonably well organized, it should be a trivial effort to start a search for Stroustrup as the sender address. Unless you had regular conversations, there should only be one or two hits.

It would take less time than writing a Usenet post about how much effort it is.

Reply to
Arlet Ottens

My email archive isn't "spinning" in one place (spindle). So, I have to go hunt for the appropriate medium (mount each, examine contents, repeat). Since *I* already KNOW the answer, the question is "How much is it worth to David Harmon to learn that answer in a VERY PUBLIC WAY!

I.e., What does he think his reputation is worth? How prepared is he to back his /ad hominem/ attacks on my character?? How willing is he to risk the humiliation of seeing his baseless, unfounded allegations proven wrong?

I have been BLATANTLY accused of lying. I figure I can extract a pound of flesh for that UNPROVOKED afront!

Reply to
Don Y

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.