I mainly use C++ to do scientific computing, and lately I've been restricting myself to a very C-like subset of C++ features; namely, no classes/inheritance except complex and STL, templates only used for find/replace kinds of substitutions, and a few other things I can't put in words off the top of my head. I am wondering if there are any official or well-documented subsets of the C++ language that I could look at for reference (as well as rationale) when I go about picking and choosing which features to use.
There is Embedded C++. It sounds mostly similar to what you're looking for.
Google publishes its internal C++ style guide, which is often referred to as such a subset: https://google.github.io/styleguide/cppguide.html . Ben Maurer, whose company reCAPTCHA was acquired by Google, describes it as follows in this post on Quora:
You can basically think of Google's
C++ subset as C plus a bit of sugar:
The ability to add methods to structs
Basic single inheritance.
Collection and string classes
Scope based resource management.
They also publish a lint tool, cpplint.py.
Not long ago I listened to this SE-Radio podcast - Episode 152: MISRA with Johan Bezem, which introduces MISRA, standard guidelines for C and C++ to ensure better quality, try looking at it.
The GCC developers are about to allow some C++ features. I'm not aware of any official guidelines, yet, but I am pretty sure that they will define some. Have a look at initial report on the mailing list.
Well, latest developments (TR1, C++0x) in C++ made it very much generic, allowing you to do imperative, OOP or even (limited) functional programming in C++. Libraries like Boost also enable you to do very power declarative template-based meta-programming.
I think Boost is the first thing to try out in C++. It's a comprehensive library, which also includes several modules that enable you to program in functional style (Boost.Functional) or making compile-time declarative meta-programming (Boost MPL).
OpenCL has been using C for writing kernels, but they have recently added (or will soon add) C++ bindings and perhaps Java. OpenCL leaves out a number of performance robbing features of C. Excluded are things like function pointers and recursion. Smart pointers and polymorphism also create overhead.
Restrictions on C:
SIMD programming languages
Slightly off topic: Here is a good discussion comparing OpenCL with CUDA using C.
OpenCL or CUDA Which way to go?
The SEI CERT C++ Coding Standard gives a list of rules for writing safe, reliable, and secure systems in C++14. This is not a subset of C++ per se, but as a coding standard like the other answers is a subset in effect by avoiding unsafe, undefined, or easily-misused features (including some common to C).
Related
I was reading a tutorial on C++ and the following line came up. No other details were provided to explain further
C++ is a "federation of languages" and supports multi-paradigm programming, there are many options available to us.
What does it mean when C++ is called federation of language and also what is multi-paradigm programming?
This is the explanation from Effective C++ Third Edition 55 Specific Ways to Improve Your Programs and Designs
By Scott Meyers, Item 1: View C++ as a federation of languages.
Today's C++ is a multiparadigm programming language, one supporting a
combination of procedural, object-oriented, functional, generic, and
metaprogramming features. This power and flexibility make C++ a tool
without equal, but can also cause some confusion. All the "proper
usage" rules seem to have exceptions. How are we to make sense of such
a language?
The easiest way is to view C++ not as a single language but as a
federation of related languages. Within a particular sublanguage, the
rules tend to be simple, straightforward, and easy to remember. When
you move from one sublanguage to another, however, the rules may
change. To make sense of C++, you have to recognize its primary
sublanguages. Fortunately, there are only four:
C. Way down deep, C++ is still based on C. Blocks, statements, the preprocessor, built-in data types, arrays, pointers, etc., all come
from C. In many cases, C++ offers approaches to problems that are
superior to their C counterparts (e.g., see Items 2 (alternatives to
the preprocessor) and 13 (using objects to manage resources)), but
when you find yourself working with the C part of C++, the rules for
effective programming reflect C's more limited scope: no templates, no
exceptions, no overloading, etc.
Object-Oriented C++. This part of C++ is what C with Classes was all about: classes (including constructors and destructors),
encapsulation, inheritance, polymorphism, virtual functions (dynamic
binding), etc. This is the part of C++ to which the classic rules for
object-oriented design most directly apply.
Template C++. This is the generic programming part of C++, the one that most programmers have the least experience with. Template
considerations pervade C++, and it's not uncommon for rules of good
programming to include special template-only clauses (e.g., see Item
46 on facilitating type conversions in calls to template functions).
In fact, templates are so powerful, they give rise to a completely new
programming paradigm, template metaprogramming (TMP). Item 48 provides
an overview of TMP, but unless you're a hard-core template junkie, you
need not worry about it. The rules for TMP rarely interact with
mainstream C++ programming.
The STL. The STL is a template library, of course, but it's a very special template library. Its conventions regarding containers,
iterators, algorithms, and function objects mesh beautifully, but
templates and libraries can be built around other ideas, too. The STL
has particular ways of doing things, and when you're working with the
STL, you need to be sure to follow its conventions.
"Federation of languages" means the big breadth of diverse features and ways to apply the C++ language.
Multiparadigmatic languages combined paradigms. Examples are F-Sharp, OCaml and Swift. So it's a group of language-styles.
Yes this is from Effective C++. The writer is just saying that C++ grammar comes from a series of sub-languages. Read about it here.
As for multi-paradigm programming, it's the ability of a language to support more than one programming style. This allows flexibility for different tasks. A google search should answer this for you.
While developing a new product, we decided to go for a mix of C++ and C#, haven been told that bridging them to allow the C# code to call the C++ code would be easy (spoiler, it's not).
We're pretty experienced C++ programmers and not at all C# programmers so we pretty much just had to believe what we've read. A few attempts to call C and Objective-C was promising and we even found a few articles that showed how to make an unmanaged C++ class available in C# -- or at least we thought. The C++ code in the articles, wasn't C++, but instead the horrible monster C++/CLI that Microsoft seems to think is C++. Since we're doing the C# stuff to get some bits "for free" in macOS and Windows, C++/CLI isn't an option either :-(.
Anyway, plenty of people have claimed that it's easy to call C++ code from some specific programming language, but so far, I haven't seen a single one that will allow me to do so (I haven't been paying too much attention to this, so please provide me with an obvious example). C++ invariably always means C with no C++ stuff at all; no namespaces, classes, no stl, lambdas or anything. Just plain dumb C.
So, are there any languages, besides C++(/CLI) that will allow me to do the following:
Create an instance of a class, using a C++ constructor, and dispatch it with a C++ destructor.
Call member functions on an object ( foo f; f.foo();) with a C++ class.
Use std::vector, std::find_if, std::string and other stuff from the stl. Complete coverage of the stl is not required.
Use overloaded functions (i.e. f(), f(int), f(std::string))
Use overloaded operators (foo operator + (foo, foo))
Use C++11, C++14 and/or C++17 features.
Use RAII (rather important IMHO).
Use namespaces.
No. There is no such language.
Unless you count Objective-C++. But that falls pretty much in the same bucket as C++/CLI, in being C++ with some extensions. And C++/CX is another such beast.
There are some interop tools that can work with C++ classes (SWIG for example), but I have never heard of a tool that is capable of instantiating C++ templates (like vector or find_if) on demand.
What languages will call C++ with no explicit bridging?
The short answer to this question is: NONE
Remember that a programming language is a specification written in some technical report, usually in English. For examples, read n1570 (the spec of C11) or R5RS (the spec of Scheme). For C++, see n3337.
Actually, you are interested in implementations, e.g. in compilers and interpreters for your programming languages. These implementations are practically software. And then the answer might become: it depends (notably on the ABI used & targetted by your compiler and system).
See for examples this list of ABIs for Linux.
plenty of people have claimed that it's easy to call C++ code from some specific programming language,
The C calling conventions are quite common, and it might help to declare every C++ function callable from outside as extern "C". But there is no silver bullet, and details matter a lot.
So, are there any languages, besides C++(/CLI) that will allow me to do the following:
list of C++ features skipped
Probably not.
You probably need at least to understand more about memory management approaches. I recommend understanding more about garbage collection, e.g. by reading the GC handbook (at least for underlying concepts & terminology). Learn more about foreign function interfaces (in some cases, the libffi might help) and language bindings.
You might also consider generating some of the C++ or C glue code, maybe with SWIG (or write your own C++ glue code generator).
On operating systems providing dynamic linking capable of loading plugins at runtime (e.g. Linux with dlopen(3)/dlsym(3); but other OSes often have similar facilities) you could even consider generating some C or C++ glue code at runtime in some temporary file, compile it as a temporary plugin, and dynamically loading that plugin. You could also consider JIT-compiling libraries like GCCJIT or LLVM (or libjit).
I recommend reading SICP, the Dragon Book, and probably Lisp In Small Pieces. Of course, learn something about OSes, e.g. Operating Systems: Three Easy Pieces. Reading about Linkers and Loaders could also help.
As an excellent example of cleverly gluing C++, look into CLASP and see this video.
But whatever approach you take, you'll need a lot of work (years, not weeks).
C++ as a language does not have a defined ABI (Application Binary Interface) - which basically means that there is no universal standard of what a C++ class/function call/template would look like in binary form on any given platform, or across platforms.
What that means is that there is no universal way to call C++ code from other languages, on different platforms, or even across compilers on the same platform. It also means that the people who are telling you "it's easy to call C++ code from XYZ language" are mostly incorrect (or at least incredibly incomplete).
Where there are interfaces it's either because the provider of the interface controls the ABI (C++/CLI with .NET), or because there is a translation layer from C++ to something like the C calling convention (Boost::python).
Some work has been done towards attempting to define an ABI per-platform (http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4028.pdf), but as far as I'm aware it has not yet been accepted into C++17.
You can look into using C++ interpreter, which allows for the fine-grained control you ask for. But I don't know of any that "just works", see also:
Have you used any of the C++ interpreters (not compilers)?
D easily interfaces with C.
D just as easily interfaces with C++, but (and it's a big but) the C++ needs to be extremely trivial. The code cannot use:
namespaces
templates
multiple inheritance
mix virtual with non-virtual methods
more?
I completely understand the inheritance restriction. The rest however, feel like artificial limitations. Now I don't want to be able to use std::vector<T> directly, but I would really like to be able to link with std::vector<int> as an externed template.
The C++ interfacing page has this particularly depressing comment.
D templates have little in common with
C++ templates, and it is very unlikely
that any sort of reasonable method
could be found to express C++
templates in a link-compatible way
with D.
This means that the C++ STL, and C++
Boost, likely will never be accessible
from D.
Admittedly I'll probably never need std::vector while coding in D, but I'd love to use QT or boost.
So what's the deal. Why is it so hard to express non-trivial C++ classes in D? Would it not be worth it to add some special annotations or something to express at least namespaces?
Update:
"D has namespace support in the works" from Walter Bright.
FWIW Qt has an actively developed binding for D: http://www.dsource.org/projects/qtd
I think many components in boost are too highly tied to C++ to be portable meaningfully to other languages.
Using e.g. std::vector is possible if you spend the time on writing regular (e.g. namespace-level) functions that forward to the appropriate member functions. Tedious, but affordable (for higher-level components; probably not for std::vector).
Also, I very recently checked in the standard library a sealed array and sealed binary heap implementation that use reference counting, malloc/free, and deterministic destruction instead of garbage collection (see http://www.dsource.org/projects/phobos/browser/trunk/phobos/std/container.d). Other containers will follow. These containers use three specific techniques (described in my upcoming article "Sealed Containers") to achieve deterministic destruction without compromising program safety.
Hopefully sealed containers will obviate any need to link with STL containers, even for tight applications that can't afford garbage collection.
As Hans Passant mentions in a comment, the level of interoperability you want between D and C++ isn't even supported among different C++ compilers. There is a C++ ABI (Application Binary Interface) standard that seems to have some support, but I'm not sure exactly how extensive (Intel, GCC and ARM compilers seem to follow the ABIs). I haven't had a need to use it, and I'm not sure whether or not Microsoft adheres to it for their x86 or x64 compilers (I imagine it might for ia64, since that's where the ABI standard started).
See "Interoperability & C++ Compilers" by Joe Goodman for some details on the C++ ABI.
Maybe Walter Bright can be convinced to support D interoperability with C++ libraries/objects that follow the ABI standard (though I'm not sure where he might prioritize it).
Just for fun I've been interfacing to some C++ code.
That probably won't answer for your question, but I think you (and some folks among the D community) might be interested in some notes I've made then. Here it goes: TechNotes.
I would like to create a domain specific language as an augmented-C++ language. I will need mostly two types of contructs:
Top-level constructs for specialized types or declarations
In-code constructs, i.e. to add primitives to make functions calls or idiom easier
The language will be used for scientific computing purposes, and will ultimately be translated into plain C++. C++ has been chosen as it seems to offer a good compromise between: ease of use, efficiency and availability of a wide range of libraries.
A previous attempt using flex and bison failed due to the complexity of the C++ syntax. The existing parser can still fail on some constructs. So we want to start over, but on better bases.
Do you know about similar projects? And if you attempted to do so, what tools would you use? What would be the main pitfalls? Would you have recommendations in term of syntax?
There are many (clever) attempts to have domain specific languages within the C++ language.
It's usually called DSEL for Domain Specific Embedded Language. For example, you could look up the Boost.Spirit syntax, or Boost.rdb (in the boost vault).
Those are fully compliant C++ libraries which make use of C++ syntax.
If you want to hide some complexity, you might add in a few macros.
I would be happy to provide some examples if you gave us something to work with :)
You can try extending an open source Elsa C++ parser (it is now a part of a Mozilla's Pork project):
https://wiki.mozilla.org/Pork
The way to extend C++ is not to try to extend the language, which will be extremely difficult and probably break as new base compiler releases implement new features, but to write class libraries to support your problem domain. This has been what C++ programming has been all about since the language's inception.
If you really want to extend C++, you'll need a full C++ parser plus name and type resolution. As you've found out, this is pretty hard. Your best solution is to get an existing one and modify it.
Our DMS Software Reengineering Toolkit is an infrastructure for implementing langauge processors. It is
designed to support the construction of tools that parse languages, carry out transformations, and spit out the same language (with enhanced code) or a different language/dialect.
DMS has a full C++ Front End, that parses C++, builds abstract syntax trees and symbol tables (e.g., all that name and type resolution stuff).
The DMS/C++ front end is provided with DMS in source form, so that it can be customized to achieve the kind of effect you want. You'd define your DSL as an extension of the C++ front end, and then write transformations that convert your special constructs into "vanilla" C++ constructs, and then spit out compilable result.
DMS/C++ have been used for a wide variety of transformation tasks, including ones that involved extending C++ as you've described, and including tasks that carry out massive reorganizations of large C++ applications. (See the Publications at that website).
To solve you first bullet, maybe you can use C++0x new features "initializer lists", and "user defined litterals" avoiding the need for a new parser. They may help for the second bullet, too.
I am a beginner programmer in C++, and I still learning the bases, but I have a simple question about The Standard library and STL in C++, I think this is not from The Core of the language, I mean this library just make programming and portability easier, and that mean if I learned and mastered C++ rules, I can build my own, I mean in general this call experience by practicing.
Example: cout is the standard output function, but if I want to program a GUI software for Windows for example, I will never just look at it!!
My Question:Is that True?and if not, Why?
You can't really be said to be a C++ programmer without a good knowledge of the standard library. And writing your own is a very bad idea. I strongly recommend you get a copy of Nicolai Josuttis's book and embrace the power it will give you. You will learn, for example, that streams are not only good for performing I/O in console applications.
And maybe you should also take a look at Good Idea / Bad Idea Should I Reimplement Most Of C++?, which discusses the pros & cons of writing your own standard library.
You are correct that the C++ standard library are not part of the "core language" and that most of what the standard library offers you can be achieved independently using only the features core language.
However, it is much to your advantage to learn the standard library. Why waste time rewriting functions that are already there for you? If you chose to rewrite them anyway, your versions will likely be buggy. That's just one of the truths of software development, no matter how good you are, but more so if you're a beginner to the language. In contrast, the implementations out there are tried and tested in the field.
Looking for Your sample that std::cout is not useful withing GUI programming is not entirely true. Even if You will not use cout it is worth to know std::basic_ostream for simple string formatting abilities.
You won't use everything from the STL, but MAN are those string and container classes, and sometimes the algorithms, useful!