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

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

On Monday, July 2, 2018 at 12:56:43 AM UTC-5, Maciej Sobczak wrote:
> > Oh, so the take-away is:
> [...]
> 
> Nothing of what you wrote is a take-away, because I did not write any of this.

And I quote from you below, emphasizing the recommendation to teach •classes•, •namespaces•, and C++ •standard-library* (oh, sorry, •encapsulation• and •templates• too, which a bad C++ instructor would skip or botch too, right?) as the ••enlightened way to bring OP's thinking-in-Ada to novice C++ students••.  Of these, only your unspecified allusion to Pimpl as an idiomatic work-around for lacking Ada's separately-compiled private portions of packages is higher in the food chain of bringing think-in-Ada to C++.  The others are not bringing think-in-Ada to C++ at all; they are merely garden-variety everyday barebones run-of-the-mill embracing of the commonplace party-line mantras in C++.

On Sunday, July 1, 2018 at 3:52:37 PM UTC-5, Maciej Sobczak wrote:
> Ada is strong in directing the user towards a good program structure. Pick this and try to show your
> students ••how to design the program in C++ using the tools that it has•• - •namespaces• and
> •classes•. The notion of packages in Ada do not map 1:1 into •namespaces• and •classes• in C++, but
> the big picture of encapsulation and program decomposition translates well. Show them how the
> physical structure of translation units in C++ can be used to enhance encapsulation [e.g., the PIMPL
> idiom]. Show them how to use •templates•. Use the •standard library• whenever you can.

Then in that paragraph, you switch to the negative, telling OP what not to do, but never positively telling the OP what to actually teach in Ada-think regarding C++'s utilization of or avoidance of pointers, lvalue references, rvalue references, ::std::unique_ptr, ::std::shared_ptr, and/or ::std::weak_ptr.  (Indeed, are only pointers “raw pointers” in your negative scorched earth or are all the others on the list too to be avoided? and where? and how?)  The OP is yearning for:  what portion of accesses and pools and subpools can be brought over from Ada's wise memory management (and the incrementally-formulating-a-proof-by-mathematical-induction rules thereof)? and how?

> Stay away from raw pointers as long as you can (which might as well be forever).

Then the next paragraph is hardly anything other than negatively casting aspersions on Luke & my advice to bring over more sophisticated specific thinking-in-Ada concepts, and what it would take to raise C++ up a bit, a little closer to Ada's level of software-engineering wisdom.  That next paragraph is repeatedly telling OP what /not/ to do, instead of advising which think-in-Ada concepts can be brought over to woo C++ programmers to Ada-think—if not woo over to Ada the language, woo over to the standing-on-the-sholders-of-giants-who-came-before software-engineering wisdoms throughout Ada.  Negativity and embrace-the-pure-tried-&-true-party-line-C++-way was not what OP was requesting.

> Now, I take the risk of being controversial here, but I have enough C++ experience to stand by my words:
> don't bother implementing your own broken version of integer ranges in C++, no matter whether with
> macros or with templates. Just don't.

Overtly declaring the range of integers over which this portion of code operates can be a key portion of eliminating all variants of the overflow/overrun vuln(erabilitie)s that worms utilize as their attack vector to insert machine code.  But never mind SEI software engineering principles, eh?  Obey the party-line mantra of C++ without deviation, eh?  Don't try to evangelize think-in-Ada to a nonAda audience, eh?  Keep all that Ada stuff behind your Ada community's closed doors, eh?

Btw, integer ranges were merely utilized in passing by me as an easy-to-see-at-a-glance example in crawl, walk, run warm-up to meatier topics to bring over from Ada:
1) pool-based memory management, emulating Janus Ada-esque sharing of single copies of generic/template instantiations to avoid bloat,
2) rendezvous idiom for multithreading,
3) C++'s Pimpl idiom to emulate Ada's separate compilation of private portion of packages,
4) emulation of discriminated records,
5) enum class as emulating Ada's strongly-type enumerations,
and so forth, each of which are too big for newsgroup postings.

> If you try to do this, you will teach your students something that
> they will not be able to reuse or translate in the real world, in the real existing code.

Why not?  Is the professor's teaching copyrighted and licensed only under a restrictive license?  Why can't his students go forth and prosper as evangelists of a better way?  Why must C++ be practiced as only, say, the Boost's mailing-list prescribes?  Why should the The One True And Only Way cult be the only C++ culture permitted?  Why should thinking-in-Ada/thinking-in-SEI-software-engineering be a code smell in C++?

> You will be blamed afterwards for the bad teaching

C++ community runs a black list to ostracize heretics disbelieving in The One True And Only Way cult, eh?  Wow, who knew?

> and you will have nothing to defend yourself.

Yeah right, nothing other than an ever-bigger-every-year group of well-trained students who evangelize the better way in code reviews and the mental battle that is corporate or open-source software development.  Which, btw, is the only defense a professor ever has over the years in the end:  whose lives did the teaching transform toward the better?

> Just don't. It is true that some attempts have been made in this direction,

Yeah like the following yet another major contribution of think-in-Ada deep-wisdom worthy of taking to C++, eh?:
> #define begin { 
> #define end } 

If begin-end instead of {} is some of the think-in-Ada deep-wisdom with which to enlighten C++ students with Ada's better way, then perhaps I have drastically overestimated how much Ada's deep-wisdom has disseminated out from the luminaries/_LRM_/_AARM_/_Rationale_s to the tens of thousands of Ada programmers.  Ada wisdom has so much more software-engineering wisdom to teach C++ students than mere surface-level syntax.

> but none got any recognizable acceptance. C++ is not the language for doing ranges

I suppose C++ is not the language for doing interval arithmetic over the real-numbers-with-tolerances either, eh?  I suppose C++ classes cannot represent scalar data types well at all, eh?  I suppose that the people who build out such libraries (even for inclusion into the C++ standard library) are fools (and should be put on that aforementioned black list “with nothing to defend [themselves]” for practicing C++ without the proper license from The One True And Only Way cult), eh?  Here are some libraries for interval-arithmetic over real numbers in C++, utilizing C++ classes (gasp!) for “micromanaging” each number:

https://docs.oracle.com/cd/E19422-01/819-3696/iapgCreference.html
http://www-sop.inria.fr/members/Sylvain.Pion/cxx/interval/interval.pdf

> and I'm not sure whether this is entirely bad - don't confuse them with range-checked arrays,

Yeah right, the upper and lower bounds of an integer constrainment range is strictly forbidden to be utilized when calculating the number of elements in, say, a ::std::vector or ::std::array, eh?  Magic-number numeric-literals are best, eh?  Constants out of left field are almost as good, eh?  The equivalent of 'First and 'Last on a constrained integer range—no, no, that is far too much colocation of concepts so that the programmer doesn't need to looking hither and yon for some named constant, eh?

> which are available in the standard library and are (and should be) used. In the same spirit, don't get
> obsessed too much on defining gazillion of incompatible types for everything, as some Ada books insist
> on.

or that C++'s enum class was added for

or that strong typedefs are yearned as being (analogous to MyType is new Type in Ada):
https://foonathan.net/blog/2016/10/19/strong-typedefs.html

Yeah right, C++ programmers haven't been yearning for Ada's strong typing on those “gazillion of incompatible types”, eh?

> Classes as separate types are good for medium to big design concepts,

and tiny design concepts such as each number or each type alias

> but not for micromanaging integers.

And not for micromanaging 3 categories of complex numbers in the C++ standard and Boost libraries:  complex, quaternions, octonions, eh?
https://www.boost.org/doc/libs/1_34_0/doc/html/boost_math/quaternions.html
https://www.boost.org/doc/libs/1_34_0/doc/html/boost_math/octonions.html

And not micromanaging the aforementioned interval-arithmetic real numbers, eh?

> Don't bother with reimplementing Ada in C++ at this level and you
> will be successful in your teaching.

Yeah right, teaching students to be evangelists of better ideas is a recipe for being a bad teacher, eh?  Teaching novices to be verbatim-copy drones of The One True And Only Way cult is the only way to be successful in teaching, eh?

> You have skipped other important points that I have made.

To be fair, I subjected your other points to additional scrutiny this time around, to dismantle them too.