Re: Teaching C/C++ from Ada perspective?

["Dan'l Miller" <optikos@verizon.net>]

On Friday, July 6, 2018 at 2:43:21 PM UTC-5, Dmitry A. Kazakov wrote:
> On 2018-07-06 20:51, Randy Brukardt wrote:
> > "Maciej Sobczak" <see.my.homepage@gmail.com> wrote in message
> > news:670baa25-a987-45a0-991f-ec3aa2878233@googlegroups.com...
> >>> In any case, semantic coupling is many times more important than
> >>> compile-time coupling, since it causes actual maintenance problems.
> >>> Perhaps
> >>> focusing on that would make the differences more apparent???
> >>
> >> So let's do focus on that. Is there some short example that you would like
> >> to present to demonstrate this point?
> > 
> > Not off-hand; I shouldn't have wasted the time on this discussion in the
> > first place.
> > 
> > But I'll say that examples involving empty packages and useless withs don't
> > really prove anything regardless of the language involved - they're not very
> > realistic. I'd suggest looking at examples of privacy (which Ada is very
> > strict about) and comparing to other languages (which I don't know well
> > enough to do myself).
> 
> I would add that much depends on optimization. If the compiler looks 
> into a body in order to perform certain types of optimization then no 
> matter how excellent Ada's separation of interface and implementation 
> is, it must recompile clients if the body was changed.
> 
> But Ada will still beat others here, because for quick runs you can turn 
> the optimization off being sure that when you turn it on, then due to 
> the separation the optimized code will still work.

Do you use this rule with GNAT or nonGNAT compilers?  Given GNAT's GIGI/GIMPLE/RTL optimizing backend, might GNAT not respect private-package boundaries when optimizing?

> It is a really a plague in C++: the debug version works and the release 
> crashes. Never happened in Ada to me.

I agree 100%.  This happens precisely because of C++'s “as-if” rule*, permitting the optimizer to interact deleteriously with one or more undefined behaviors (UBs).

* The name is a misnomer.  A better name would be the ‘carte-blanche’ rule, because the optimizer is handed a blank check to fill out untrustworthily whenever one or more UBs occur in a program.

https://stackoverflow.com/questions/15718262/what-exactly-is-the-as-if-rule

It is “as if”** an enemy of C++ snuck into the standards committee and planted the worst possible contortion of the past momentum of C++ culture into the letter of the standard to break vast quantities of real-world programs when the optimizer is turned on.  If they really want this carte-blanche rule in C++-with-optimization, then then C++ absolutely must error all UBs when compiled with optimization.  But they didn't require such.

** Perhaps that is the real reason that it is called the “as if” rule instead of the ‘carte blanche’ rule.

This is the reason that multiple C++ shops with which I have been employed have all picked only one optimization level and performed all development & debugging & everything at only that one optimization level; builds with the optimizer turned off or to any different level were strictly prohibited.