| 1 |
Jan Kundrát <jkt@g.o> wrote: |
| 2 |
>> And no, the languages are _not_ "source-incompatible". That would be a |
| 3 |
>> scandal! |
| 4 |
> |
| 5 |
> You might argue about this, but that doesn't change these facts. |
| 6 |
|
| 7 |
I think nobody had doubts that *theoretical* such examples can |
| 8 |
be constructed (I even mentioned the case of name collission on |
| 9 |
which your example builds). The question is how often does this |
| 10 |
occur in *real-world* projects. |
| 11 |
|
| 12 |
> does not change the fact that there *is* code out there |
| 13 |
|
| 14 |
Your example is not "code out there". I would bet that the |
| 15 |
name collission case hits less than 1% of existing projects. |
| 16 |
If name collissions would be the only case, it would not even be |
| 17 |
worth to discuss these things. The more restrictive syntax for |
| 18 |
string concatenation (mentioned in some bug posted in this thread) |
| 19 |
is a more realistic issue, but at least in this case, the project |
| 20 |
has already fixed the problem. |
| 21 |
|
| 22 |
Again: Numbers are needed; somebody (preferrably somebody with a fast |
| 23 |
machine, so I am out ;) ) has to try to compile w/test the whole |
| 24 |
~x86/~amd64 tree with CXXFLAGS=-std=c++11, and only then one can |
| 25 |
seriously discuss how "source-incompatible" the languages really are. |
| 26 |
|
| 27 |
My guess is still that you will observe less problems than with |
| 28 |
a minor gcc upgrade, but it is only a guess, of course. |
Archives