Is a cfront tool available for the new C++? For any other modern languages?
Comeau C/C++ is a C-generating C++ compiler, like cfront.
What do you mean by “cfront tool”? Cfront was the first C++ compiler. But since failure to add exception support, it has been discontinued. Modern C++ is way beyond the scope of Cfront.
For any other modern languages?
And what do you mean by that? If you mean whether other compilers exist that compile a high-level language into C code then the answer is yes, there are plenty. The Glasgow Haskell Compiler is just one out of many.
I believe a number of languages, at least in their infancy, just "compile" to C code, letting a good compiler (often gcc...) to generate optimized native code. I think GHC is (for some implementations?) such language, and there are some others I don't recall.
I know also lua2c, converting Lua code to C.
Bigloo
Bigloo enables full connections
between Scheme and C programs, between
Scheme and Java programs, and between
Scheme and C# programs.
Gambit-C
Gambit benchmarks
Related
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)?
C and C++ are different languages, blababla we know that.
But if those language are different, why is it still possible to use function like malloc or free ? I'm sure there are all sort of dusty things C++ has because of C, but since C++ is another language, why not remove those things to make it a little less bloat and more clean and clear ?
Is it because it allows programmers to work without the OO model or because some compilers doesn't support high-level abstract features of C++ ?
Because C++ would be right out dead if it wouldn't be compatible to C the way it is now. No one, except the fanbois, would like C++ if it wouldn't be compatible to C. (I know I'm probably going to be downvoted for this. Be it so!).
About "Why there's no "pure" C++ language... Well, there is at least one. The most popular one is called D, it's great, well-designed, feature-rich, pleasant to code with, and you can use C libraries with it.
Ah, and almost nobody uses it. :)
The direct reason is that C++ is not bad enough to give people a good reason to port millions of lines of their legacy code to more modern, and as you described, "pure" languages like D.
Most operating systems expose a C API, so if you want to use C++ for systems programming, you need some level of C interoperability.
That the C standard library was incorporated into the C++ standard library has historical and practical reasons: C++ began its life as an extension of C, and the C standard library was ready to use. It would be silly to exclude part of the library (like malloc and free) just because there are more idiomatic C++ alternatives: if you want to do stupid things, C++ gives you the power to do so.
For actual language semantics, the same applies - but to a lesser degree - and because of backwards-compatibility, C++ can never be entirely free of its C heritage.
It's designed so that you can port C code and compile it as C++ code directly, and it allows for incremental upgrading of existing code. If C++ didn't have malloc/free, you couldn't compile existing C code as C++, because you'd have to pay some poor shmuck to go through and find all the malloc calls and replace them, which is expensive.
C++ was designed to be compatible with C -- in fact it was originally a superset of C, but the C language has since changed to break that.
This means that C libraries -- including the C run-time library -- can be called from C++ code. It does not mean that it is a good idea to do so!
If you want a "pure" C++ then you can just use C++ without calling any C libraries.
[As others have said since I started typing this: The Design & Evolution of C++ is a good place to start reading for the background on this.]
I suggest you take a look at The Design & Evolution of C++ to get a better feel for the reason the language turned out the way it is. There are historical reasons why C++ grew out of C and was made backward compatible with it.
The early versions of C++ were built on top of C and in fact the compiler translated C++ code to C which was in turn compiled by the local C compiler. Bjarne Stroustrup is a great believer in backwards compatibility and would, I'm sure, resist any attempt to take functionality away.
You can read all about in in Bjarne's book The Design and Evolution of C++.
There were plenty of more pure languages. They didn't get widely used, though, because they were too far outside the comfort range of most programmers. C++, on the other hand, allowed programmers to slowly ramp up by allowing C styles.
What you're doing is looking at languages like C# or Python and wondering why C++ doesn't look like them, but forgetting that getting there required stepping stones like C++ and Java, or Awk and Perl.
To adapt a quotation I heard earlier: C# is Microsoft's version of Sun's for-idiots version of Bell's version of C-enhanced-by-Simula.
All are right. To sum up: the reason is politics. If you want something to be popular, enhance something already popular and you have a ready market. Design something new and no one will be interested unless you are Sun, design some utter crap, but throw billions of dollars into library development and marketing.
malloc() and free() are required so that you can call into C language libraries from C++ code. The C language library might return a pointer to memory allocated with malloc() that must be freed by the caller with free(); or, less commonly, it might require a pointer to memory allocated with malloc() that it can internally reallocate with realloc() or free with free().
Seems all compilers can deal with both c and c++,like gcc ,msvc...
Is it because these 2 languages are exactly very much alike?
Actually, GCC (GNU Compiler Collection) has two different front-ends, gcc and g++. To specify C++, you can also use a .cpp (or a few others) extension, or -x c++, when executing gcc. However, this requires extra options (like linking in the C++ standard library).
cl, Microsoft's C++ compiler, does not support modern C. However, it will compile C source files as a variant of C89, and you can specify this explicitly with /TC.
For both, you are correct that there's a lot of shared code, regardless of which front-end is used (GCC also has many more). However, the languages do have significant differences, which are discussed elsewhere (this question among others).
There is no dedicated compiler for C/C++ because there is no such language....
If you are going to write a C++ compiler then you will have to be able to compile C too, so you may as well also provide one.
There may still be some C compilers around that do not have a companion C++ compiler with them though.
No. That's not true. Look at Pelles which is a C only compiler.
The semantics of the core language constructs for C and C++ remain more or less identical, and C++ was designed to add structural elements to C rather than change or remove existing language features. Therefore if you go to the trouble to build a C++ compiler, having it also compile C is relatively trivial (at least for ISO C90). C99 diverges in some significant ways from C++, and some C++ compilers either do not support C99, or include C99 features as extensions in their C++ compiler.
C++ is also highly inteoperable with C, C++ for example wholly includes ISO C90's standard library, and can link any C library. C++ libraries can be given a C linkage compatible interface for use by C code (although that is often less straightforward than C++ calling C code).
Early C++ tools were not true compilers, but rather C++ translators, which generated C code for compilation by a native C compiler. Comeau C++ still takes this approach in order to support C++ on any target with a C compiler, which is useful in embedded environments where some targets are not well served by C++ tools.
TCC is an example of a C compiler which is not a C++ compiler. Actually compiling C++ is a huge pain; the only reason so many C compilers also support C++ is that there's a pretty big demand for C++.
C++ is a superset of C. I don't know if this is still true, but it at least used to be common for c++ compilers to convert code to C as a first step in compiling.
Edit:
I've always heard that it is a superset. Since GMan says no, I looked at Wikipedia which says, "C++ is often considered to be a superset of C, but this is not strictly true.[21] Most C code can easily be made to compile correctly in C++, but there are a few differences that cause some valid C code to be invalid in C++, or to behave differently in C++." (See http://en.wikipedia.org/wiki/C%2B%2B for details.) So I stand a bit corrected.
Edit 2:
I've read a bit further in the Wikipedia article. Sounds like this is more accurate: C++ started as C; C++ evolved by adding new features to C. At some point, C++ changed enough to no longer be a pure superset of C. Since then, C has also evolved, and now has some features that C++ doesn't. So they're closely related, but no longer wholly compatible with each other.
No, LCC compiler is for C only.
GCC has gcc and the g++ components which compile C and C++ code.
clang-llvm has a C front-end. There is an experimental, separate C++ front-end.
IBM's Visual Age is split into xlc and xlC compilers.
Portable C Compiler is C only.
Last time I used it, Labwindows/CVI suite by National Instruments was a C only compiler.
It isn't true, there are several, and there were plenty in the 1980s before C++ compiler products started to appear :-) However given a C++ compiler the marginal cost of producing a C compiler out of the same codebase is relatively small, and even going the other way isn't a major increment, at least compared tom starting from scratch with either.
Probably a pretty vague and broad question, but do all C++ compilers compile code into C first before compiling them into machine code?
Because C compilers are nearly ubiquitous and available on nearly every platform, a lot of (compiled) languages go through this phase in their development to bootstrap the process.
In the early phases of language development to see if the language is feasible the easiest way to get a working compiler out is to build a compiler that converts your language to C then let the native C compiler build the actual binary.
The trouble with this is that language specific constructs are lost and thus potential opportunities for optimization may be missed thus most languages in phase two get their own dedicated compiler front end that understands language specific constructs and can thus provide optimization strategies based on these constructs.
C++ has gone through phase 1 and phase 2 over two decades ago. So it is easy to find a `front end' of a compiler that is dedicated to C++ and generates an intermediate format that is passed directly to a backed. But you can still find versions of C++ that are translated into C (as an intermediate format) before being compiled.
Nope. GCC for example goes from C++ -> assembler. You can see this by using the -S option with g++.
Actually, now that I think about it, I don't think any modern compiler goes to C before ASM.
No. C++ -> C was used only in the earliest phases of C++'s development and evolution. Most C++ compilers today compile directly to assembler or machine code. Borland C++ compiles directly to machine code, for example.
No. This is a myth, based around the fact that a very early version of Stroustrup's work was implemented that way. C++ compilers generate machine code in almost exactly the same way that C compilers do.
As of this writing in 2010, the only C++ compiler that I was aware of that created C code was Comeau*. However, that compiler hasn't been heard from in over 5 years now (2022). There may be one or two more for embedded targets, but it is certainly not a mainstream thing.
* - There's a link to their old website on this WP page. I'd suggest not clicking that unless your computer has all its shots up to date
This is not defined by the standard. Certainly, compiling to C-source is a reasonable way to do it. It only requires the destination platform to have a C-compiler with a reasonable degree of compliance, so it is a highly portable way of doing things.
The downside is speed. Probably compilation speed and perhaps also execution speed (due to loads of casts for e.g. virtual functions that prevents the compiler to optimise fully) will suffer.
Not that long ago there was a company that had a very nice C++ compiler doing exactly that. Unfortunately, I do not remember the name of the company and a short google did not bring the name back. The owner of the company was an active participant in the ISO C++ committee and you could test your code directly on the homepage, which also had some quite decent ressources about C++.
Edit: one of my fellow posters just reminded me. I was talking about Comeau, of course.
Does C++ code gets converted to C before compilation ?
A few C++ compilers (the original cfront, Comeau C++) use C as an intermediate language during compilation. Most C++ compilers use other intermediate langauges (e.g. llvm).
Edit: Since there seems to be some misunderstanding about the history: "C with classes" started out using a preprocessor called "Cpre". At that time, it was seen strictly as a dialect of C, not a separate language in itself. In December 1983, people were starting to view it as a separate language, and the name C++ was invented. As it happens, development of cfront started in April 1983, so a reasonably usable version became available (to a select few) just about the same time as the name "C++" came into use. This appears to be mostly coincidence though.
As far as producing C as its output, that was really quite common on Unix. Just for example, the Berkeley Pascal compiler and at least a couple of Fortran compilers also produced C as their output.
There is, however, a huge difference between Cpre and Cfront. Although both produced C as their output, Cpre did virtually no syntax checking of its own -- it looked for a few specific things, and did a relatively mechanical translation on them. It wasn't until the C compiler looked at the result that real syntactical analysis was done. If your code contained a syntax error, it was almost certain that it wouldn't be caught until the C compiler parsed the output from Cpre.
Cfront, however, did full syntactical analysis of the source code itself, so (short of a bug in its code generator) you'd never see a syntax error from the C compiler. The C compiler was simply used as a code generator so nobody needed to rewrite CFront to accommodate different processors, object file formats, etc.
If you want to get into more detail, chapter 2 of The Design and Evolution of C++ is devoted almost entirely to the "C with Classes" time frame (and there are various other details about it spread throughout the book).
No, but like most myths there's a shred of truth to this. The original compiler for C with classes (which later became C++) was nicknamed CFront and did translate to C.
Not in most modern compilers.
The original C++ compiler was actually a preprocessor however. It generated C code, which was then compiled by a C compiler.
In the early days of C++ compilers, some did it that way. I haven't seen a C++ compiler implemented that way since the late 1980s however.
As others have answered. NO.
However if you want to use an OOP language like C#, and have your code compiled into C I recommend you take a look at Vala.
the title seems to ask is C++ a superset of C, i.e. can you just dump any c code in a c++ compiler and it will work? In which case, yes it is, sort of...
one major difference is that C automatically casts pointers for you, c++ does not, you need to cast the manually...
any one remember anything else?
thats all I remember from the horrible process of converting a massive C project to compile under c++ for some reason...