On quinta-feira, 4 de fevereiro de 2016 11:56:11 PST Marcin Gałązka wrote:
> Of course, maintaining compatibility is a burdensome thing and has lots of
> cons. But IMO maintaining partial compatibility is not the answer. As soon
> as most C programs cease being compatible with C++, you stop getting the
> benefits of maintaining any compatibility at all. Therefore, there seem to
> be only three possibilities: you can maintain compatibility and reap
> benefits of it while accepting the burden, you can break compatibility and
> get no benefits of it but also free yourselves of the burden, or you can
> maintain partial compatibility and get no benefits while still bearing the
> burden. And I'm afraid C++ chooses this third way.
The problem is that the C standard is developed independently from the C++
standard. That means the members of WG14 are allowed to add features that
don't make sense in C++, duplicate C++ features or are simply incompatible
with C++ syntax.
If you were to ask them to always talk to WG21 before adding features, you'll
probably get the same reaction as you're getting here, though.
The people most interested in compatibility are the compiler writers, though.
You should be able to find supporters with them.
> * No VLA support. As soon as VLAs were added to C, they seem quite a natural
> way to declare many arrays that previously had to be allocated with malloc.
> Therefore, we can expect newer C code to use VLAs quite often. This is one
> big reason why one may be unable to painlessly transfer their C code to
> C++, just by compiling it with a C++ compiler and mixing in C++ features
> whenever convenient (and this possibility was, correct me if I'm wrong, one
> of the big factors of the success of C++). Since some mainstream C++
> compilers support VLAs anyway, perhaps - just perhaps - adding it to the
> standard wouldn't be that problematic?
VLAs were briefly added to C++14 drafts, at least the parts of them that were
sane. They were removed later because of issues. So you should consult the
list of issues to see why the C++ standards committee decided this should not
be added. Hopefully, those will be fixed so we can have some VLAs in C++ code
-- they're useful.
In addition to the issues, there were aspects of VLAs that the committee felt
were duplicating functionality existing in C++, namely that of template
container classes. We have a solution for passing arrays across function
calls, we don't need VLAs for that.
> * No support of the register keyword. This keyword is likely to be used in
> headers. Therefore, this might create compatibility issues in one of the
> most important fields: the ability to use C APIs by #including C headers.
> Again, since some mainstream compilers support it anyway, perhaps adding it
> to the standard would be acceptable.
I understand you meant restrict here, not register.
I've also been told there were issues with this, but I have no recollection of
what they are. Maybe something related with classes with members.
> * No support of bounds-checked functions. The issue here is similar to that
> of VLAs: their use seems natural in C, so one may fail to be able to
> compile existing C code by a C++ compiler.
Because we have template container classes, which do the bounds checking.
Duplicated functionality is not needed and the C++ standards committee feels
that if something can be solved by a library, it should be solved by a library
not a core language change.
Maybe C should stop adding those features that C++ has already solved. If they
aren't willing to add templates (not _Generic), they should maybe simply not
add the feature at all. _Atomic and _Complex come to mind too.
I imagine this would not be a popular proposal among WG14 people.
> To sum up, in my opinion, C++ should choose one of two alternative paths:
> either maintain compatibility with C to greatest possible extend, or drop
> it radically by gradually deprecating and removing facilities inherited
> from C, that are considered 'evil' in C++. The latter option will give many
> opportunities to clean up the language. The former will give the benefits
> listed above. Trying to balance between these two extremes offers benefits
> of neither of these options, but drawbacks of both.
Bjarne Stroustrup posted a paper once about the incompatibilities and where/
how they hurt. You should look it up and read it. Most of your concerns are
listed there.
That said, I don't expect any solution of this short of developing both
languages in lockstep.
--
Thiago Macieira - thiago (AT)
macieira.info - thiago (AT)
kde.org
Software Architect - Intel Open Source Technology Center