Since the new runtime will depend on implicit try finally constructs quite a bit more than it used to, it's important we ensure the C++ target is alive and kicking. For this Nim's tester testament and the CIs need a mode that run every non-JS-test with nim cpp so that we can see where we used importc constructs etc that bite with the C++ target (this will be mostly const issues).
Araq
All 14 comments
well, with the targets list, it's possible to run each test with both c and c++ targets.. gonna take a while but might be worth it - else the C target will become what C++ is today - unhappy.
speaking of targets, which C and C++ version specifically? perhaps this should be specified and tested for?
arnetheduck
on 25 May 2018
well, with the targets list, it's possible to run each test with both c and c++ targets.. gonna take a while but might be worth it - else the C target will become what C++ is today - unhappy.
Yeah, well, I agree. Both should be tested constantly.
speaking of targets, which C and C++ version specifically? perhaps this should be specified and tested for?
Roughly C89 (oldest C version that makes sense) and the most recent C++ version (assuming C++ is getting more strict / more clearly specified all the time). Alternatively the C++ that Visual Studio actually supports...
Araq
on 25 May 2018
I think that C++ is more of a moving target than C is, and relying on a moving target is much more work - see what happened to JVM languages and scala in particular since java started moving again.
In my opinion it is nice that Nim can compile to C++, keeping C as the reference target is a safer bet
andreaferretti
on 25 May 2018
The point is that C++ implements our run-time better (through its better support for exceptions handling). It's high time that we fix the various small issues that make using C++ less practical. The modern C++ standards make only relatively small changes to the small subset of C++ that we use, so it will be much less of a problem to switch between them.
zah
on 25 May 2018
Granted, but the C compiler has advantages as well:
- faster compilation times
- C is a simpler and much more known language, should one inspect nimcache
- it is easier to generate libraries that can be used from other languages
In general, when language A compiles down to language B, you sort have to know B even if you only work with A - be it for debugging, FFI, understanding performance and so on. C is a relatively simple language, and the burden of understanding basic C concepts is not high. Nim is powerful but complex because of the interaction of many features. C++ also is powerful and complex.
If C++ becomes the de facto target, users will have more difficulties learning Nim - I, for one, have a very basic understanding of the subtleties of C++
andreaferretti
on 25 May 2018
If C++ becomes the de facto target, users will have more difficulties learning Nim - I, for one, have a very basic understanding of the subtleties of C++
The code generator treats C++ as a C with try statements, there is nothing to worry about.
faster compilation times
Since sighashes arrived in Nim, for me most time is spent in the Nim compiler itself.
it is easier to generate libraries that can be used from other languages
You can keep using the C backend for this, it's not going away.
Araq
on 25 May 2018
Good to know, I was a little worried :-)
andreaferretti
on 25 May 2018
C++ backend could use std :: iterators for Nim's iterators.
Also, newest g++ and clang supports a concepts.
Just a dreams. :)
data-man
on 25 May 2018
in general, the more you rely on c++ features, the more you'll have to make nim follow c++ semantics, or live with subtle edge case bugs that will appear when you least want or need them too - far into your project when changing it is expensive..
also, would be interesting to see numbers on what the c++ backend does to binaries in terms of RTTI etc - a trivial test might be to bootstrap nim compiler with c and c++, and see which one runs the test suite better.
arnetheduck
on 25 May 2018
Roughly C89
if that's the case / if that's advertised / if that's a feature, perhaps at least the linux tests should run with that gcc flag enabled (-std=c89 --pedantic)
arnetheduck
on 25 May 2018
Support for iterators and C++ concepts has a huge advantage: a generated code will be compatible with tons of modern C++ libraries, including std :: *
data-man
on 25 May 2018
@arnetheduck what about long long types for 64-bit values?
Such variables cannot work under -std=c89 as it supports up to 32-bit only, unless we depend on GCC's extensions which in turn it will work with long type as a 64-bit and not with long long as it won't recognize it.
Should we go with std=c99 instead so we can please C++11 that depends on it, that is in case we generate C++11?
stefanos82
on 6 Jul 2018
The C version/dialect that we target is just what clang, gcc and Visual C++ accept as C. --pedantic excludes all the posix headers anyway iirc, when I tested it years ago, it was unusable.
Araq
on 6 Jul 2018
The tests are now run in C++ mode, some had disabled, we will fix them one after another, but I consider this issue complete.
Araq
on 17 Jan 2019
Related issues
liquid600pgm
路
3Comments
zzz125
路
4Comments
hlaaftana
路
3Comments
capocasa
路
3Comments
awr1
路
3Comments
Most helpful comment
Granted, but the C compiler has advantages as well:
In general, when language A compiles down to language B, you sort have to know B even if you only work with A - be it for debugging, FFI, understanding performance and so on. C is a relatively simple language, and the burden of understanding basic C concepts is not high. Nim is powerful but complex because of the interaction of many features. C++ also is powerful and complex.
If C++ becomes the de facto target, users will have more difficulties learning Nim - I, for one, have a very basic understanding of the subtleties of C++