On Mon, Jun 18, 2012 at 1:46 AM, David Brown wrote:

> ...
> The great thing about Lisp coding is how happy programmers are when they
> reach the end of their code :-))))))))))))))))))))))))))
>
And your Monday quiz is: Why do the parentheses all pile up on the right in
Lisp, less so in Scheme? :-)

Mike

On 17/06/2012 23:00, Paul Curtis wrote:
>
> On 17 Jun 2012, at 21:09, Jon Kirwan wrote:
>
>> On Sun, 17 Jun 2012 18:10:26 +0200, David wrote:
>>
>>> On 17/06/12 02:00, Jon Kirwan wrote:
>>>> On Sat, 16 Jun 2012 23:11:29 +0200, you wrote:
>>>>
>>>>> I am not sure if noexcept will negate all the bad points
>>>>> about exceptions
>>>>
>>>> I never speak in absolutes -- except when saying that I
>>>> absolutely don't do so. :)
>>>>
>>>
>>> And I /always/ speak in absolutes - well, most of the time :-)
>>
>> Oh, cripes. I've been using iterator concepts and lazy evaluation
>> for decades with good results. These are subsets of lambda
>> calculus, as I'm learning more now.
>
> Are you late to lambda calculus? Surely not. :-) lambda
> expressions are bread and butter to a Lisp programmer.
>
> If you like thinking lambdas, you might like to get hold of a copy of
> this:
>
> This is quite old, but it does a good job and expands the mind.
> Might be a bit out of date these days, as the comment says Mine is
> pristine. :-)
>
>> But it is a VERY POWERFUL concept. One I've been using for almost
>> two decades already because they work so well and improve the
>> quality of the resulting code. If you are interested in seeing a
>> good example, I'd be happy to show you how why they helped me
>> recently and allow you to consider the alternative options to see
>> why this is the better way to handle what I faced.
>>
>> And they are NOT AT ALL hard to follow!! The C++11 syntax is the
>> ugliest, most vile way of specifying them I can imagine. It's
>> despicable. But that is syntax, not semantics. Semantically, they
>> are a thing of beauty and simplicity itself. Anyone can get the
>> idea. Anyone. I just spent a few days doing a code review to
>> programmers who'd never been so much as even exposed to the
>> concept, let alone the syntax. And they came away wondering out
>> loud why they'd never bothered to learn about it before.
>>
>> It took me 5 minutes to get the idea across so that they actually
>> understood it.
>>
>> They are not "hard to follow."
>

I am very familiar with these concepts - they were a major part of my
university degree (I studied maths and computation - not computing or
programming), although I am a little out of practice.

When working with Python, lambda functions, iterators (and lazy
evaluation), currying, mapping, list comprehension, etc., are all very
useful concepts that lead to neat and clear source code.

But in C or C++, it is ugly - as you say. Iterators are common in C++
for STL code - and they are absolutely hideous. The biggest improvement
of C++11 is the "auto" keyword that lets you get rid of half the
template type monstrosities in STL iterator code, but it is still ugly.

I agree entirely that the semantics of lambdas and other functional
programming concepts can be very nice (and the same principle applies to
other concepts, such as coroutines). But when the syntax is a mess, and
the implementation is often bigger and slower than "traditional"
programming, it's hard to see it as the right solution.

For a brief example, supposing you have a string "s" of characters, and
you want to print out the ascii codes in hex. In python, an obvious
solution is:

print ", ".join(["0x%02x" % ord(c) for c in s])

It is clear, neat and reasonably efficient in Python. But in C or C++,
it would be a terrible way to do the job involving two arbitrary lists
(meaning element nodes with links, and dynamic memory), string as class
objects with complex methods, general formatting routines (of "printf"
style), etc. A "traditional" algorithm using a loop would be much
smaller, faster and clearer in C or C++.
I am sure there /are/ times when lambdas give a clearer and better
program in C or C++. As I said, I haven't come across them in embedded
programming - but that does not mean that such situations don't exist.
And like you, if I come across such a situation I would look at the
balance between the benefits of making better code by using an unusual
(for this field) technique, and the disadvantages of using something
unfamiliar to other programmers.
> For someone straightjacketed by programming a regular algorithmic
> language for decades, escaping to lambdas may be quite disorienting.
> Just tell them they'll enjoy currying. :-)
>
> Of course, Lisp has the ultimate syntax when talking of lambda
> expressions. But then, as a language that can consume its own source
> text, it is highly elegant.
>

The great thing about Lisp coding is how happy programmers are when they
reach the end of their code :-))))))))))))))))))))))))))

On Sun, 17 Jun 2012 22:12:46 +0100, Paul wrote:

>On 17 Jun 2012, at 20:01, Jon Kirwan wrote:
>
>> On Sun, 17 Jun 2012 08:40:47 +0100, you wrote:
>>
>>> Exceptional programming, with Ada's exceptions, looked so
>>> good to a novice programmer. How bad it turned out to be.
>>> Your nice, readable code turned into a mess of exception
>>> handlers for things that would very rarely go wrong but
>>> would take an inordinate amount of time to code for.
>>
>> I'm not sure why you bring in a system that makes things a
>> "mess" applies to my responses, which were merely that I like
>> options I can use or not use. Perhaps this is just an
>> interesting side bar?
>> Exceptional programming is highly turdy IMHO; I just make an
> observation. You soon find your code littered with crap
> everywhere, and integrating a 3P library into your code that
> doesn't know about exceptions is a disaaaaastah daaahlink.
> try-catch-finally and throw specification tries to force you
> to deal with error handling--so you don't ignore a return
> code. The cure is worse than the disease in most cases.
>
> Just $0.02 of biased opinion.
>
>-- Paul.

Okay. I have used exceptions sparingly. One place I found
value that I remember right now is with a simple parser used
by a serial port command/query feature. The exception
handling made the code focus on the main thrust (simple,
easy, straightforward) and to handle invalid issues using
exceptions rather than the excessive use of status values for
function returns and all the associated garbage related to
surrounding conditional code -- it would be almost impossible
to see the main thrust through all the noise if I'd gone that
direction.

In any case, I don't have the problems you are talking about.
If I did, I wouldn't do it.

Jon

On 17 Jun 2012, at 20:01, Jon Kirwan wrote:

> On Sun, 17 Jun 2012 08:40:47 +0100, you wrote:
>
>> Exceptional programming, with Ada's exceptions, looked so
>> good to a novice programmer. How bad it turned out to be.
>> Your nice, readable code turned into a mess of exception
>> handlers for things that would very rarely go wrong but
>> would take an inordinate amount of time to code for.
>
> I'm not sure why you bring in a system that makes things a
> "mess" applies to my responses, which were merely that I like
> options I can use or not use. Perhaps this is just an
> interesting side bar?
>

Exceptional programming is highly turdy IMHO; I just make an observation. You soon find your code littered with crap everywhere, and integrating a 3P library into your code that doesn't know about exceptions is a disaaaaastah daaahlink. try-catch-finally and throw specification tries to force you to deal with error handling--so you don't ignore a return code. The cure is worse than the disease in most cases.

Just $0.02 of biased opinion.

-- Paul.

On 17 Jun 2012, at 21:09, Jon Kirwan wrote:

> On Sun, 17 Jun 2012 18:10:26 +0200, David wrote:
>
>> On 17/06/12 02:00, Jon Kirwan wrote:
>>> On Sat, 16 Jun 2012 23:11:29 +0200, you wrote:
>>>
>>>> I am not sure if noexcept will negate all the bad points about
>>>> exceptions
>>>
>>> I never speak in absolutes -- except when saying that I
>>> absolutely don't do so. :)
>>>
>>
>> And I /always/ speak in absolutes - well, most of the time :-)
>
> Oh, cripes. I've been using iterator concepts and lazy
> evaluation for decades with good results. These are subsets
> of lambda calculus, as I'm learning more now.

Are you late to lambda calculus? Surely not. :-) lambda expressions are bread and butter to a Lisp programmer.

If you like thinking lambdas, you might like to get hold of a copy of this:

This is quite old, but it does a good job and expands the mind. Might be a bit out of date these days, as the comment says Mine is pristine. :-)

> But it is a
> VERY POWERFUL concept. One I've been using for almost two
> decades already because they work so well and improve the
> quality of the resulting code. If you are interested in
> seeing a good example, I'd be happy to show you how why they
> helped me recently and allow you to consider the alternative
> options to see why this is the better way to handle what I
> faced.
>
> And they are NOT AT ALL hard to follow!! The C++11 syntax is
> the ugliest, most vile way of specifying them I can imagine.
> It's despicable. But that is syntax, not semantics.
> Semantically, they are a thing of beauty and simplicity
> itself. Anyone can get the idea. Anyone. I just spent a few
> days doing a code review to programmers who'd never been so
> much as even exposed to the concept, let alone the syntax.
> And they came away wondering out loud why they'd never
> bothered to learn about it before.
>
> It took me 5 minutes to get the idea across so that they
> actually understood it.
>
> They are not "hard to follow."

For someone straightjacketed by programming a regular algorithmic language for decades, escaping to lambdas may be quite disorienting. Just tell them they'll enjoy currying. :-)

Of course, Lisp has the ultimate syntax when talking of lambda expressions. But then, as a language that can consume its own source text, it is highly elegant.

-- Paul.

On 17 Jun 2012, at 21:17, Jon Kirwan wrote:

> On Sun, 17 Jun 2012 22:09:03 +0200, you wrote:
>
>> On 17/06/12 21:05, Jon Kirwan wrote:
>>> On Sun, 17 Jun 2012 08:40:47 +0100, you wrote:
>>>
>>>> Have to say, I really don't like references in C or C++ code
>>>> (or even XC code for that matter) but they are
>>>> matter-of-fact in Pascal-class languages (derived from
>>>> Algol's ref type).
>>>
>>> I would use references because they permit a compiler to do
>>> better optimizations. They simply do. Of course, that doesn't
>>> mean the compiler author will do anything useful with that
>>> fact. But they could.
>>>
>>> Others might use them because they allow a quick-hack way of
>>> suddenly turning a "by value" parameter into something they
>>> can reach through and modify, breaking to earlier contract.
>>> Maybe that is your problem. But it's not mine. I care about
>>> better optimizations. A hope that has been repeatedly dashed
>>> over and over again, by what I see as regression rather than
>>> progress in that area. Supported by a few recent comments
>>> lately here in this group by you, if I recall.
>>>
>>> Jon
>>> I don't think references give the compiler much more opportunity for
>> optimisations than pointers do. There are a few cases - it can be
>> better for alias analysis, the compiler can assume they are non-zero,
>> they can't change, etc. But for the most part, references are syntactic
>> sugar for pointers.
>>
>> However, I think they are often nicer than pointers because it allows
>> the benefits of pointers (such as avoiding copying large items by value)
>> without many of the risks (the compiler can check that the reference is
>> valid and non-zero at compile time), and with a cleaner and neater
>> syntax. Cleaner source code and better static error checking is the
>> winning point for me - better optimisations is a nice bonus.
>
> Stroustrup says he first considered the idea of references
> BECAUSE of the optimizations permitted when references are
> used as parameters instead of pointers.

This might be for an era where compilers were typically weak and would not do what they currently do when disambiguating.

> A reference cannot be
> changed during the function lifetime. It also cannot be 0. A
> pointer can be changed and it can be 0.

Indeed, but if you do not alter the pointer in a function then a reference and a pointer are equivalent. A compiler can know a pointer is never assigned to and can simply ignore (or cause the computer to blow up) when assigning through zero.

> Static optimization
> is much easier when you can know unambiguously what bit of
> memory a variable means. Pointers break this condition.

I would disagree with this. You (typically) don't know where a reference points, you only know that it points "somewhere"; this is no different from knowing that a pointer points "somewhere". Assignment through a reference may change *anything* and a compiler will kill everything that it knows about (based on type) when assigning through a reference. It has no choice in the matter. You would have to provide a concrete example of how a compiler can do a better job using references than using pointers. I just do not see it.

I see absolutely no difference (speaking of absolutes) in the disambiguation process between assignment through a pointer and assignment through a reference and what the compiler must invalidate. But I am open to be corrected.

-- Paul.

On Sun, 17 Jun 2012 22:09:03 +0200, you wrote:

>On 17/06/12 21:05, Jon Kirwan wrote:
>> On Sun, 17 Jun 2012 08:40:47 +0100, you wrote:
>>
>> > Have to say, I really don't like references in C or C++ code
>> > (or even XC code for that matter) but they are
>> > matter-of-fact in Pascal-class languages (derived from
>> > Algol's ref type).
>>
>> I would use references because they permit a compiler to do
>> better optimizations. They simply do. Of course, that doesn't
>> mean the compiler author will do anything useful with that
>> fact. But they could.
>>
>> Others might use them because they allow a quick-hack way of
>> suddenly turning a "by value" parameter into something they
>> can reach through and modify, breaking to earlier contract.
>> Maybe that is your problem. But it's not mine. I care about
>> better optimizations. A hope that has been repeatedly dashed
>> over and over again, by what I see as regression rather than
>> progress in that area. Supported by a few recent comments
>> lately here in this group by you, if I recall.
>>
>> Jon
>>I don't think references give the compiler much more opportunity for
>optimisations than pointers do. There are a few cases - it can be
>better for alias analysis, the compiler can assume they are non-zero,
>they can't change, etc. But for the most part, references are syntactic
>sugar for pointers.
>
>However, I think they are often nicer than pointers because it allows
>the benefits of pointers (such as avoiding copying large items by value)
>without many of the risks (the compiler can check that the reference is
>valid and non-zero at compile time), and with a cleaner and neater
>syntax. Cleaner source code and better static error checking is the
>winning point for me - better optimisations is a nice bonus.

Stroustrup says he first considered the idea of references
BECAUSE of the optimizations permitted when references are
used as parameters instead of pointers. A reference cannot be
changed during the function lifetime. It also cannot be 0. A
pointer can be changed and it can be 0. Static optimization
is much easier when you can know unambiguously what bit of
memory a variable means. Pointers break this condition.

That's part of what I remember.

Jon

On Sun, 17 Jun 2012 18:10:26 +0200, David wrote:

>On 17/06/12 02:00, Jon Kirwan wrote:
>> On Sat, 16 Jun 2012 23:11:29 +0200, you wrote:
>>
>> >I am not sure if noexcept will negate all the bad points about
>> >exceptions
>>
>> I never speak in absolutes -- except when saying that I
>> absolutely don't do so. :)
>>And I /always/ speak in absolutes - well, most of the time :-)

Hehe. I rule programming self with an iron fist. By this, I
mean that every single line I write (and it may surprise you
but by now I have a second "brain" that is always operating
and that forces me to do this quite literally with every line
I write, now) I am always thinking to myself, "Could I defend
this line here, by itself and in its context, to an angry
room full of expert programmers all of whom want to take me
from my job and still succeed in convincing them that it is
no worse than other alternatives and possibly better?" If I
can defend it, I will write it. If I feel it exposes me to
abuse, I find another way. That room is always present in my
mind. Always. I can't get rid of it.

So I have that. But I don't have "bright lines." Bright lines
are ignorant. They can't be debated. They cannot be
convinced. Novel situations cannot be explained to them. I
cannot defend myself to them, make arguments to them, etc.
They are simply ignorant walls, barriers. Some people need
them because that is the crutch their minds require. Mine
requires that "angry room of programmers." That is my crutch,
so to speak. Others want the bright lines, because they need
them. I prefer to actually _THINK_ all the time. Not follow
rules all the time.

That's how I see it, anyway. Rules set a floor beneath which
idiots cannot sink. The angry room sets a pinnacle that
encourages you to reach for the best within yourself.

I'm a "give me options" type who will then do his level best
to use those options only when they can be well defended.
Treat me like the professional I am. Don't treat my like a
child who needs restrictions.

>> I hope I didn't imply that noexcept would negate _all_ bad
>> points.
>
>No, you didn't imply that.

Thanks.

>> I just thought it was a potentially useful addition
>> for some circumstances. It seems attractive, in that I
>> believe it may inform the compiler that it does NOT need to
>> generate exception handlers in code that doesn't specify any,
>> just to handle destruction of an object that _might_ need
>> destruction if some call to a function might cause an
>> exception.
>>
>> Code that looks like:
>>
>> .
>> .
>> .
>> x();
>> string y;
>> x();
>> .
>> .
>> .
>>
>> Assume this resides in a module (file) where it looks exactly
>> like C (no exceptions, no try blocks, no use of exceptions,
>> etc.) and the only thing in all the code is that in ONE place
>> it specifies the construction of an object (y) that must be
>> destroyed if x(), which we will assume for now resides in a
>> different module where the source code is NOT visible to the
>> compiler, generates a throw. The first call to x() doesn't
>> need to trap anything, as there is nothing prior needing
>> destruction. The second call to x() does need such a hidden
>> mechanism because C++ is forced to deal with destroying y if
>> such an exception were to take place. And it doesn't know,
>> since it can't see the code for x(). I was hoping noexcept
>> would permit me to inform the compiler that it doesn't need
>> to worry so it can produce the same code for both calls to
>> x() (or, another way of saying it, it doesn't need to insert
>> exception handling to destroy y in the case of a throw but
>> only needs to destroy y in a non-exception context of the
>> current code.)
>>
>> That's not much of an improvement. But it is an improvement
>> that might open an option, which would otherwise be closed to
>> me.
>
>Yes, I think that's the aim of noexcept. Basically, the idea is to have
>something that does what people think "throw()" does (i.e., it says that
>the function will never throw an exception). Many C++ compilers already
>have extensions for this (such as gcc's "nothrow" attribute).

I was just glad to see some handwaving in this direction in
C++11 (or C++0x as Stroustrup has explicitly said it will
always be in his mind.)

>> >- you'd have to be consistent about using it everywhere, in
>> >which case it is easier just to disable exceptions entirely (I would be
>> >surprised if there were any embedded C++ compilers that don't have a
>> >flag for disabling exceptions).
>>
>> Here, I simply think you continue to speak in extremes. I am
>> speaking entirely in moderation. It is not the case that
>> either I want exceptions everywhere or else I want them
>> nowhere. That is extreme-minded mentality operating. Not
>> nuanced thinking.
>
>That's entirely true.
>
>Sometimes a happy medium is the best solution - one where you can use
>exceptions when you need them, and use "noexcept" to avoid the overhead
>when you don't need them.

Yes.

>But I stand by my point that if you are going to allow exceptions at all
>and in any way, then you have to be very careful about being consistent
>and accurate all the way.

David, that's MY JOB, damn it!! That's what they pay me to
do! Of course I will be careful.

I hate being treated as a child, David. I've been programming
actively since 1973, for gosh sake.

And I agree with you about consistency. If there is ANYTHING
that counts in helping other professionals (not children, but
professionals) to read your code it will NOT be the rules you
apply but the consistency with which you apply your own
rules. Any professional with any experience will soon figure
out what you are doing and "lock in" on it. Then the rest
becomes much easier going. It's just a "calibration period"
as they get a bead on it. But so long as you are consistent,
a professional can rapidly get on track with it and proceed.

>
>Will "noexcept" be useful? I think probably it will, for programs that
>use exceptions. Will it significantly help? I suspect not, unless you
>you work hard to do so (but unlike "throw()", it is unlikely to make
>things worse). Will I use it in embedded C++ code? Not a chance - I'll
>disable exceptions entirely. But that absolute rule is for /me/ -
>others can take it or leave it.

I've used C++ for embedded applications with exceptions
turned off, among other things I also disabled or avoided.
But like I said, if I could imagine successfully arguing a
case in front of that room of programmers, then I would use
it. I mainly focus on if the design I am considering is the
better design for the client. If it is, and if that better
design involves some use of noexcept and some places where
exceptions are permitted, then I want the chance to make that
argument in my mind and then with the client.

I don't know when that will happen, or if it will happen in
the rest of my life again. But I'd rather have the option to
consider, than not to have it. Even if I decide against it.

>(Note that I do use exceptions in other circumstances - I have found
>them useful in Python programming. But embedded programming an Python
>programming on a PC are not the same thing.)

:)

>> There are cases where it would be important to me in some
>> places in an application that I am absolutely certain that
>> the burden of exception handling isn't being generated but
>> where elsewhere in the application such handling would be
>> fine.
>
>If you need that, then "noexcept" is a good idea.

Yes.

A focus is writing maintainable and explainable code that
others will find easier to follow, modify for likely areas of
modification, and support in the longer term. This includes a
lot of factors to consider, of course. It's not likely that
I'd choose a course that includes exceptions on smaller
embedded applications. But one area where I like them because
they are cleaner than setjmp and longjmp is in some cases
where a customer wants a separate thread setup to handle
serial port command/query parsing. The code is much cleaner
and more easily read and maintained (in some cases here)
where the parser doesn't use status values everywhere (which
makes it very ugly) and instead uses exceptions to handle the
unusual cases of lexing and parsing errors. I would have to
show code to make the point clearer, but I suspect you've
done enough of it to mentally manufacture some examples on
your own. (If you can't come up with any, you haven't had
enough experience or else you know something I have never
been exposed to yet.)

>> In any case, more control is better in my mind. Gives me more
>> options, not fewer. The way you talk, you don't want options
>> but want only BLACK and WHITE thinking processes.
>
>I don't have anything against giving /you/ an option here - I /choose/
>not to give /myself/ the option. I will also recommend this opinion to
>others, but it is always up to others whether they follow it or not.

Each of us must do what works better for us.

>Rules and recommendations are different for different people, different
>tools, different program types, etc.

I suppose so.

>> I'm not like that.
>
>I know :-)
>
>However, I am also not as absolutist as you think, or as I often appear.
> There are times when rules get bent or broken. Think of my opinions
>more like the "shall" rules of Misra, rather than mathematical laws. If
>you really want to break them, you can beg permission and forgiveness
>from the project manager, and carefully document /why/ you want to break
>them - then its fair enough.
>
>I like to keep things simple where possible. Shades of grey are often
>unavoidable, but if you can stick to black and white, it's much easier
>to write code that is clear, readable, correct, and easily seen to be
>correct. Isn't that a good aim?

It's a good aim. I just don't agree that sticking to black
and white is the always-better way to achieve it. Sometimes
it is, sometimes not.

This recent example I just went through using lambdas is a
case in point where I actually made a choice to use something
NONE of my client's programmers had EVER experienced before
in their lives. That was a difficult choice for me and I
worried a lot about it. But after trying it without their
use, I knew it was wrong. So I made the decision to use the
lambdas and it not only greatly improved the quality of the
code, it also moved the code much closer to their own stated
goals, and when I set out to do a code walkthrough the
response I got wasn't concern or worry but was instead

"we need to start doing this ourselves, this is so easy
to understand and maintain, and it makes so much sense."

I had expected worse. They are sticklers for rules and I knew
that. These are long-term programmers who have stayed with
the same corporation, most of them, for more than 20 years
now. They know their product and have a very large amount of
software they support (and sell.) I was actually worried, but
I also KNEW that this was the RIGHT APPROACH in this
particular case.

And it appears I was able to convince them, too.

I want the options to make such choices. I won't always use
those options. But I want the options so that I may make that
choice if I feel it is the right time and place for them.

>> >The main problem with exceptions is the obvious one - it makes it very
>> >difficult to guess the control flow of the program. You can get
>> >unexpected jumps at odd times, and you have to be /extremely/ rigorous
>> >and structured in your programming to be sure you have full control.
>> >With half that discipline you can get the same benefits from passing
>> >error conditions and checking return values in the traditional C manner,
>> >and having it clearly and explicitly shown in the code.
>>
>> I could add pages to this discussion supporting your points
>> further. Been there, paid my dues.
>>
>> >The secondary issue, that is particularly relevant in embedded systems
>> >where code size and speed is often important, is that exceptions can
>> >cripple your optimiser, and generate larger and slower code. At
>> >multiple points in the generated code, the compiler has to add code to
>> >deal with exceptions - for every function call that might throw an
>> >exception (including every function whose definition is not known and is
>> >not declared with noexcept), the compiler has to assume that an
>> >exception will be thrown. That means stack unwinding, destructors being
>> >called, etc. This can mean lots of overhead in code space and stack
>> >space, the compiler's optimiser is hindered in re-ordering code, common
>> >subexpression optimisations, etc.
>>
>> Again, you can go back to comp.arch.embedded and find posts
>> from me going on for pages and pages making these points and
>> much more and explaining why I can't use C++ for most
>> embedded work -- for these reasons and a few more.
>
>C++ is an enormous language - it provides scope for a lot of good
>features that would benefit many programs. But it also provides scope
>for writing totally incomprehensible and uncontrolled programs. You
>can, of course, write crap in any language - but C++ provides so many
>more different ways of writing nonsense than most languages!

:)

>This was sort of the idea behind the EC++ subset of C++ - but
>unfortunately it was not a very good subset. Removing multiple
>inheritance and virtual base classes was a good thing. Removing
>exceptions is also good, IMHO, although some people might disagree :-)
>But removing namespaces and templates is just silly.

I can only guess about templates, but it may have been that
they couldn't insist on partial template specialization. I
would make that part of the spec, a rock hard requirement, if
I permitted templates in embedded.

>> However, that doesn't mean I wouldn't benefit from C++
>> semantics in embedded applications. Namespaces cost ZERO code
>> and provide a benefit I'd use, just to name a simple one.
>
>Agreed /almost/ 100%. Used badly, namespaces can make it confusing to
>find the right symbols compared to the simpler single global namespace
>of C. But used with at least half a brain, then they are all good.

You know? I like to imagine I have half a brain. Allow me
that much hope?

>> Another would be references.
>
>Agreed more than 100%.

My reason is because it permits optimizations you can't be
sure of, otherwise. (Stroustrup discusses this as his early
motivation in some old text I'd read from him many years
ago.)

>> There are many, many others
>> where the cost is quite predictable and very low and the
>> semantic power would improve the quality of the source code.
>
>There are several features that can greatly improve the quality of the
>source, if used well, but there is a risk of getting overly complicated
>and tying yourself in knots.

You always sound like you are so worried about neophytes
whose hands you must hold and coddle and for whom you must
set up restrictions and rules so they don't do something
dumb. You worry about the floor of performance.

I worry about doing the best I can for my clients. If I was
always worried I would fall through the floor, I'd stop
programming entirely because my clients don't deserve to be
helped by someone who needs a performance floor to keep them
from falling through.

>Classes /can/ be a very good way of encapsulating code, data, and
>concepts, as long as you don't go overboard. They also have the
>potential for being very inefficient if you have a processor with very
>poor pointer support.

I spent a lot of time studying exactly HOW classes are
implemented. This includes how inheritance, multiple and
otherwise, are managed. It's very interesting. But I did that
because I need to know WHAT I would be doing if I used them.

Again, my point here is that I'm not ignorant.

>Default arguments and overloaded functions /can/ be good, but they can
>also make code very confusing. Even more so for overloaded operators.

Not enough space here, or time, to go into this. But yes and
no and maybe all apply here. Again, these are options to
consider, not necessarily use. If I can argue that an
overloaded function is best for the client, then I'd use it.
Same would be true of operators, but I also have to be aware
of conversion operators that may also be present and permit
unintended connections.

A comprehensive view would take all this into account. If it
isn't appropriate, and it is risky to do, then don't do it.
If it is the better option in a particular case and you can
make that point stick to a room full of angry programmers,
then go for it. So far, I've not used overloaded operators in
a professional embedded product, though.

>Templates can provide the power to generate very efficient code, or very
>inefficient code - they need to be used with care, and with lots of
>testing and reading generated assembly code.

Code bloom, without specialization, can readily occur. But
again, everything is nuanced and there are no bright lines in
my mind. If I comprehensively inform myself and decide that
it is the better approach for a client, then I'd use them. I
haven't, yet, for embedded.

>> The use of lambdas being one I have harped on, after my own
>> fashion, for many years (here included.) I just used lambdas
>> for a commercial product and it GREATLY improved the result,
>> made it more readable and maintable and explainable -- even
>> to those who had never been exposed to them before.
>
>I haven't seen the need for lambdas in embedded coding, but I have used
>them regularly in Python programming. I have no specific objections to
>them in C++, except that they can be hard to follow for people who are
>not used to them.
>

Oh, cripes. I've been using iterator concepts and lazy
evaluation for decades with good results. These are subsets
of lambda calculus, as I'm learning more now. But it is a
VERY POWERFUL concept. One I've been using for almost two
decades already because they work so well and improve the
quality of the resulting code. If you are interested in
seeing a good example, I'd be happy to show you how why they
helped me recently and allow you to consider the alternative
options to see why this is the better way to handle what I
faced.

And they are NOT AT ALL hard to follow!! The C++11 syntax is
the ugliest, most vile way of specifying them I can imagine.
It's despicable. But that is syntax, not semantics.
Semantically, they are a thing of beauty and simplicity
itself. Anyone can get the idea. Anyone. I just spent a few
days doing a code review to programmers who'd never been so
much as even exposed to the concept, let alone the syntax.
And they came away wondering out loud why they'd never
bothered to learn about it before.

It took me 5 minutes to get the idea across so that they
actually understood it.

They are not "hard to follow."

Jon

On 17/06/12 21:05, Jon Kirwan wrote:
> On Sun, 17 Jun 2012 08:40:47 +0100, you wrote:
>
> > Have to say, I really don't like references in C or C++ code
> > (or even XC code for that matter) but they are
> > matter-of-fact in Pascal-class languages (derived from
> > Algol's ref type).
>
> I would use references because they permit a compiler to do
> better optimizations. They simply do. Of course, that doesn't
> mean the compiler author will do anything useful with that
> fact. But they could.
>
> Others might use them because they allow a quick-hack way of
> suddenly turning a "by value" parameter into something they
> can reach through and modify, breaking to earlier contract.
> Maybe that is your problem. But it's not mine. I care about
> better optimizations. A hope that has been repeatedly dashed
> over and over again, by what I see as regression rather than
> progress in that area. Supported by a few recent comments
> lately here in this group by you, if I recall.
>
> Jon
>

I don't think references give the compiler much more opportunity for
optimisations than pointers do. There are a few cases - it can be
better for alias analysis, the compiler can assume they are non-zero,
they can't change, etc. But for the most part, references are syntactic
sugar for pointers.

However, I think they are often nicer than pointers because it allows
the benefits of pointers (such as avoiding copying large items by value)
without many of the risks (the compiler can check that the reference is
valid and non-zero at compile time), and with a cleaner and neater
syntax. Cleaner source code and better static error checking is the
winning point for me - better optimisations is a nice bonus.

mvh.,

David

On Sun, 17 Jun 2012 08:40:47 +0100, you wrote:

> Have to say, I really don't like references in C or C++ code
> (or even XC code for that matter) but they are
> matter-of-fact in Pascal-class languages (derived from
> Algol's ref type).

I would use references because they permit a compiler to do
better optimizations. They simply do. Of course, that doesn't
mean the compiler author will do anything useful with that
fact. But they could.

Others might use them because they allow a quick-hack way of
suddenly turning a "by value" parameter into something they
can reach through and modify, breaking to earlier contract.
Maybe that is your problem. But it's not mine. I care about
better optimizations. A hope that has been repeatedly dashed
over and over again, by what I see as regression rather than
progress in that area. Supported by a few recent comments
lately here in this group by you, if I recall.

Jon

Beginning Microcontrollers with the MSP430