Design in C++11/14/17

[Mitsuru]

Dear experts,

I suppose that there exist proper design beyond conventional object oriented programming (c.f. GoF design pattern) in C++11/14/17 which enable a variety of programming paradigm via std::shared_ptr, std::function, lambda expression, std::any, or so. These should replace old design&implementation (c.f. strategy pattern is easily represented by std::function), and they are sometimes more useful, vice versa.


Do you know helpful documents to design software based on such a new functionalities in modern C++?

Kind regards

[Niccolo]

A working and expanding document on the subject by Stroustrup and Sutter

https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md

I also suggest Stroustrup's "Tour" book for professional developers.

Josuttis on the STL is a good resource (C++14 - a new release on C++17 is nearly finished).

[Mitsuru]

Dear Niccolo

Thank you for your comment.

Maybe I wonder if there is a long way for modern C++ to prevail as well-known easy-to-use design technique similarly to OOP.

[George P]

@Niccolo,

Josuttis' book on C++17 is now complete.

Paperback at Amazon:

C++17 - The Complete Guide: First Edition
https://www.amazon.com/dp/396730017X/

or eBook:
https://leanpub.com/cpp17

I purchased the eBook a couple of weeks before it was finished. I learned good things about C++17 from even the introduction, nearly every "page" has something about the language standard that should be helpful in writing code.

His English editor did a very good job of rewriting his German English (his words) and making the text clear and understandable even for a beginner.

[Niccolo]

Maybe I wonder if there is a long way for modern C++ to prevail as well-known easy-to-use design technique similarly to OOP.

I'm not exactly sure what this means, but C++ has been through decades of use and development, and since it holds a position as the primary language in which most of the most ambitious applications are built, I can't say it has a long way to go to "prevail".

Ease of use, however, makes some sense when I recall all of the comparisons I've heard and read between C++ and various languages like Java, C#, Python, Visual Basic (the list is quite long).

I've always found myself reminded, as a result of those comparison, of a quote attributed to Einstein - "Keep it simple, but no simpler".

His was a caution against that tendency we all have to want simple methods and approaches, which occasionally threaten to oversimplify that which is, by it's very nature, not open to simplification. Einstein's own theory of relative was a kind of expansion on Newton, where the simpler method of Newton is still perfectly applicable to the kind of engineering and physical observations common to human experience, but entirely unsuficient to explain nature at a deeper level the way relativity did.

Some only need Newton's version. It works, it's simple, it ignores some facts but it does so in a context where they are not particularly relevant.

To that extent, after 40+ years of development behind me, I find that for those targets which require the kind of features found in C++ (and, in part, it's roots in C), virtually every other language I've "had to work in", for whatever reasons they do come up, simply can't compare well. When simplicity is a priority, it is likely not the kind of target which demands the performance and feature set found in C++.

If I were to contribute to the Linux kernel I'd have to work in C. That's Torvalds domain, and C is a requirement, and it is suitable. I could argue that C++ would be advantageous, and back that up with engineering data through experiment, but it would be of no use. Torvalds will never budge from that position.

C was purpose built as an assembler level language to write the UNIX operating system. By absorbing most of C into C++, Stroustrup designed a path for this language which still can address that level which gave C its historic position, while expanding the level of organization from which applications can be built.

While it can be used for simple targets, it really isn't that suitable for them. That isn't to say it would be inferior as a result, or as a choice of language, but that the language is capable of such deep and wide targets, it isn't always the best of first choice for simpler targets.

In various businesses, there are needs for custom applications, or simple applications (or both), which can be built by developers of lesser experience and knowledge. For them, a simpler language may be a better choice.

A good example of this is in scientific work. Many scientist, with PhD's and high reputations, are simply not interested in being programmers, but still require the use of a computer for research work. Many use Python for its simplicity, some use C# or Java for a better performance, but they have no patience, time or purpose in learning C++. I doubt there will ever be a time when C++ would be a suitable choice for them.

I sometimes wonder why many who do use C++ choose to do so, when their skills (and intent in development them) is moderate. C++ is used to engineer software of high ambition, like CAD engines, physical simulation systems (CAD + simulation = building machines in a computer for manufacture), game engines (more work than most realize), photo image editing systems, all of which have intensive demands on hardware. I find many want to use C++ for games, which is a good choice if their skills are up to that, or other simple applications. Some are more casual students, not serious enough to consider a path to engineering.

Many don't even think of software development as an engineering discipline (and it is, but only if approached that way for a reason).

An example of engineering in software is also the first example of a software engineer (the person who invented the discipline in engineering) - the computer software that was on the spacecraft that landed on the moon.

In other words, peoples lives depended on that software and hardware. No one trusts that to a casual author, not even in the late 60's.

Stroustrup has pointed to the reasonable assertion that C++ is cumbersome, requires a bit too much expertise...but he never claimed it was the best, or that it was supposed to be simple - though he agrees the language should support those ideals as is possible in the context.

That context brings in the original C, and it's purposes. It's actually the problem, if there is one. Languages without that baggage, like C# and Java, are less troublesome to the programmers, simpler to learn, and easier to use.

The cost of that, however, is how far one can reach. The level of performance, control, and suitability for the targets of the highest ambition. They can't do that.

So, for the foreseeable future, which could be many decades, there won't be just one or two languages. There will be at least 3 or 4 levels of languages, and C++ will likely always be toward that low/deep hardware/high performance level which requires some (toward the extreme) expertise, while there must be languages that are simpler and "safer" for lesser skilled hands in various industries or personal exploration.

[Mitsuru]

Dear Niccolo

Thank you for your opinion and thinking, and if you minded my previous comment, I deeply apologize.

I have experience in C, C++,Java, C#, perl, python etc, and have no discrimination between them, each language works in each right place.

As you listed, I am now tackling CAD-like or simulation systems (previously image processing also) in C++ for its high performance & generic design possibility, so that I have no option to use other languages.

As my little knowledge, modern C++ evolved to enable more generic design with less bottleneck. But, I think it is fact that C++ has high degree of freedom to do the same thing in different manners. For that reason, I sometimes need best practice of design in modern C++.
(c.f. I feel that std::function is simpler than dynamic polymorphism via virtual function. But, how about their bottleneck of computation?)

What I meant in "Maybe I wonder if there is a long way for modern C++ to prevail as well-known easy-to-use design technique similarly to OOP." is my hope that C++ will become more popular and there
will appear many best-practice documents which withstand the test stone of time.


Kind regards

[Niccolo]

...if you minded my previous comment, I deeply apologize.

Oh, I didn't intend to convey some kind of irritation, not at all.

I do think C++ already prevailed, but that the audience is not quite as large as that for languages suited toward more casual interest. C++ is nasty, like English. I mean, words like tough, laugh, though...just that alone is enough to drive teachers nuts with young kids. Split infinitives, supposedly dead wrong on a technical level, now ok because of...Star Trek?

I know there is popularity to C++, but many, of that category I describe who need languages to be simple, don't prefer it. For C#, for example, a great many love the language and prefer it, and they feel bogged down when working in C++. They avoid it as a result. When I have to work in C# I feel like my desk has been stuffed into a phone booth.

I think the direction Alexandrescu took with the D programming language is something like what you're talking about. It is a bit simpler while retaining most of the power and performance, but hardly anyone knows it exists.

[Mitsuru]

Dear Niccolo

Thank you for your reply, and I am happy to hear that you have no irritation.

I grasp what you mean. C++ is already popular, and it is powerful in performance and descriptiveness. After familiar with C++, I felt Java/C# is something too fit into the mold (...don't get me wrong, my opinion is that they are too object oriented, particularly as to design of class library. what confusing deep class hierarchy is!).

>I think the direction Alexandrescu took with the D programming language is something like what you're >talking about. It is a bit simpler while retaining most of the power and performance, but hardly anyone >knows it exists.

Like "Modern C++ design"? Yes, some C++ library (c.f. some boost library, CGAL etc.) adopts his design concepts. They are designed to have so simple interface that easy to use with generic purposes, but complex in the inner implementations.
Nevertheless, should C++ experts encapsulate such a arts and provide simple API? It is OK, but, when I make others to take over my code, I am a little annoyed.... I cannot keep away from C++, but anyone cannot understand it, sometimes it is problem.

Anyway, thank you for your sincere opinion.

[Niccolo]

...when I make others to take over my code, I am a little annoyed. I cannot keep away from C++, but anyone cannot understand it, sometimes it is problem.

Oh, how I can relate.

I find myself all to happy to blame them for it, but alas, if they can use std::vector or std::map, I find myself required to adhere to similar simplicity, such as those are.

I discovered, some decades ago, a process I've found useful in this regard.

I begin by writing application pseudo level code, as if the library or class already existed, so as to express a user viewpoint on using it first, and to write it to the standard of the most obvious and convenient I would desire. Many times this has been for an early version of a library that already existed, but then I "pretend" it doesn't, so as to enforce an interface better than what I had written, from which I then refactor.

[Mitsuru]

Dear Niccolo

Thank you for your telling great strategy, I keep in mind what you told me.

Enforcement for others. C++ needs training and experience, then developers notice the usefulness of modern techniques which were constructed by experts who experienced the same roads.

Sometimes I think in my heart, Please, Experts, leave your great techniques in writing for lost lambs, me and everyone.

Anyway, I deeply appreciate your helpful opinions, thank you so much.

Kind regards