Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon.

Pages: 1-4041-

GCC begins move to C++

Name: corbet 2010-05-31 11:39

GCC begins move to C++
[Development] Posted May 31, 2010 13:53 UTC (Mon) by corbet

It's now official: the GCC compiler is moving to a C++ implementation. "I am pleased to report that the GCC Steering Committee and the FSF have approved the use of C++ in GCC itself. Of course, there's no reason for us to use C++ features just because we can. The goal is a better compiler for users, not a C++ code base for its own sake." The next step is the bashing out of a set of C++ coding standards limiting the set of C++ language features which can be used.

Full Story (comments: none)

Name: Anonymous 2010-05-31 11:58

GCC is dead to me.

Name: Anonymous 2010-05-31 12:00

Who cares, it's not as if anyone on /prog/ contributes to it

Name: Anonymous 2010-05-31 12:00

>>2
Same here

Name: Anonymous 2010-05-31 12:01

>>3
Right, because all of us wrote a ansi C compiler when we were twelve.

Name: Anonymous 2010-05-31 12:02

>>1
Good troll you almost got m--% yaourt -S pcc

Name: Anonymous 2010-05-31 12:16

I liked GCC better when it was called GNU C Compiler.

Name: Anonymous 2010-05-31 12:58

>>7
http://upload.wikimedia.org/wikipedia/commons/c/cd/Cn.png

Name: Anonymous 2010-05-31 13:06

>>8
Back to xkcd, please

Name: Anonymous 2010-05-31 13:08

They were beginning to approach the performance and code generation quality of other compilers, so in order to keep the staple mediocrity that characterizes them, they had to make some bold move

Name: Anonymous 2010-05-31 13:27

Why is this a bad thing? They're not rewriting it.

As far as I can tell from the mailing list they're planning to allow only a small subset of C++ into the code.

For example, I think it goes without question that at this point we are limiting ourselves to C++98 (plus "long long" so that we have a 64-bit integer type); C++0x features should not be used.  Using multiple inheritance, templates (other than when using the C++ standard library, e.g. std::list<X>), or exceptions also seems overly aggressive to me.

Doesn't LLVM already use C++ and all of it's associated ass-rape like templates?

Name: Anonymous 2010-05-31 14:15

>>11
  * multiple inheritance where appropriate, but NOT virtual inheritance

Nipaaaaaa.

Name: Anonymous 2010-05-31 16:29

>>11
LLVM's C++ is every bit as usable and sane as Qt.

Which doesn't say much, but if I were forced at gunpoint to use the language, I'd work with one of those two. They're about the only really sane C++ code I've seen.

Name: Anonymous 2010-05-31 16:51

>>12
The allowed language subset has yet to be agreed upon.

Nothing to Nipaa about.

>>13
We are talking about a subset of the C++98 standard which is going to be allowed in the code of the compiler itself. Not what the compiler supports.

Name: Anonymous 2010-05-31 16:59

>>14
Since gcc is supposed to be self-hosting, we're also talking about what the compiler supports.

Name: >>13 2010-05-31 17:51

>>14
Yes, that is exactly what I was referring to. I'm not sure how you misconstrued my post, but try reading it again.

Name: Anonymous 2010-06-01 1:17

>>13
LLVM
Pronounced 'lolvum' (rhymes with 'ovum')

Name: >>14 2010-06-01 5:12

>>15,16
Disregard that            .

I know it's supposed to be self-hosting but it's a pity there will be no way to boostrap it with something like tcc.

Name: Anonymous 2010-06-01 6:44

>>18
Just add more stages.

Are there any compilers that can bootstrap from a dirt simple interpreter?

Name: Anonymous 2010-06-01 10:33

Oh boy now the compiler will be slower and consume more memory, and building the compiler will be slower and consume memory.

It's like a turducken, except the turkey is shit, the duck is shit and the chicken is shit.

Name: Anonymous 2010-06-01 10:41

>>20
They won't rewrite it in C, they'll be able to write additions in C++.

Name: Anonymous 2010-06-01 11:01

>>21
The parts that are already OO kludged in C will likely be rewritten, and over time more and more will be C++. Then the machobullshit programmers will start using the shittier parts of the language just to show how hard d00ds they are and it'll all be shit.

Name: Anonymous 2010-06-01 11:21

>>20
You're funny.

Clang is C++, and it's both lighter and faster than GCC.

Name: Anonymous 2010-06-01 11:30

>>23
clangclangclang.jpg

Name: Anonymous 2010-06-01 11:37

>>20
Cool story, bro

Name: Anonymous 2010-06-01 13:31

>>20

lol, i spilled shit all over my chair.

Name: Anonymous 2010-06-01 13:38

>>25
Cool story, [x]
Back to the imageboards, please

Name: Anonymous 2010-06-01 14:17

>>27
I'm not your x, y.

Name: Anonymous 2010-06-01 15:25

>>28
back to z, please

Name: Anonymous 2010-06-01 17:19

>>28
>>29
Same v's

Name: Anonymous 2010-06-01 18:41

>>20
Oh, God! The inline templates, they do nothing!

Name: Anonymous 2010-06-01 18:57

>>6
pcc
How is PCC these days?

Name: Anonymous 2010-06-01 20:11

­

Name: Anonymous 2010-06-01 21:29

I really don't want to care about this, but a question comes to mind: why the fuck?‽! would you want to use C++ for gcc?

Name: Anonymous 2010-06-01 21:39

>>32
Pronounced 'pucci'.

Name: Anonymous 2010-06-02 0:28

>>35
wwwwwww

Name: Anonymous 2010-06-02 0:34

>>34
Because it's a better language.

Name: Anonymous 2010-06-02 0:35

It's now official: GCC is a professional trolling machine.

Name: Anonymous 2010-06-02 3:11

Well, I hope GCC will die and we'll all happily move to clang.
Or it doesn't support lambdas yet?

Name: Anonymous 2010-06-02 4:38

>>39
$ clang++ test.cpp
In file included from test.cpp:1:
/usr/include/c++/4.4.3/iostream:38:10: fatal error: 'bits/c++config.h' file not found
#include <bits/c++config.h>
         ^
0  libLLVM-2.7.so  0x0000003595bc8e4f
1  libLLVM-2.7.so  0x0000003595bc94a5
2  libpthread.so.0 0x00007fe83f2070f0
3  clang           0x000000000086576d
4  clang           0x0000000000865bb3
5  clang           0x00000000006c98b1
6  clang           0x00000000006cab92
7  clang           0x00000000006cb675
8  clang           0x00000000006fdce1
9  clang           0x00000000006ffbaa
10 clang           0x00000000008fe8ae
11 clang           0x00000000008d5431
12 clang           0x00000000008ebf74
13 clang           0x00000000008eddc5
14 clang           0x00000000008ee92f
15 clang           0x00000000008e23b1
16 clang           0x00000000009064ba
17 clang           0x000000000090702b
18 clang           0x00000000009072fb
19 clang           0x00000000008e5b5f
20 clang           0x00000000008d959f
21 clang           0x00000000008d98ba
22 clang           0x00000000005e3c3b
23 clang           0x000000000041f2e9
24 clang           0x00000000004134ea
25 clang           0x00000000004167bb main + 1771
26 libc.so.6       0x00007fe83ea15b1d __libc_start_main + 253
27 clang           0x00000000004119b9
Stack dump:
0.    Program arguments: /usr/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -S -disable-free -disable-llvm-verifier -main-file-name test.cpp -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -munwind-tables -target-cpu x86-64 -resource-dir /usr/lib/clang/1.1 -fmessage-length 210 -fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-wDih0Q.s -x c++ test.cpp
1.    /usr/include/c++/4.4.3/ostream:380:7: current parser token 'basic_ostream'
2.    /usr/include/c++/4.4.3/ostream:376:5: parsing struct/union/class body 'basic_ostream::'
clang: error: compiler command failed due to signal 11 (use -v to see invocation)

$ cat test.cpp
#include <iostream>

int main()
{
    std::cout << "Oh God I am not good with Sepples.\n";
    return 0;
}
2010 will be the year of Clang!

Name: Anonymous 2010-06-02 8:04

>>37
no, that's c1x. sepples is in the same category as php, visual basic, and java.

>>40
if you want to use sepples, pay for an ENTERPRISE SEPPLES COMPILATION SOLUTION.

Name: Anonymous 2010-06-02 8:46

>>41
c1x doesn't look all that hot to me. Improvements, sure, but it really doesn't seem to change much.

Name: Anonymous 2010-06-02 9:32

>>42
Good. Too many revision committees want to change too much just because they can. C is very good as it is.

Name: Anonymous 2010-06-02 9:34

>>42
adding threads doesn't change much?

Name: Anonymous 2010-06-02 9:50

>>44
Since that aspect is just a codification of libraries already widely in use, no, it doesn't.

Meanwhile, it doesn't fix the one thing that's seriously wrong in C: the order of precedence of the bitwise operators.

Name: Anonymous 2010-06-02 10:19

Since that aspect is just a codification of libraries already widely in use, no, it doesn't.
how about apple's closures proposal (http://www.open-std.org/JTC1/SC22/wg14/www/docs/n1451.pdf)? don't know if that'll make it into the standard, but that'd be a pretty big change for the better.

Meanwhile, it doesn't fix the one thing that's seriously wrong in C: the order of precedence of the bitwise operators.
In converting from B to C, one wants to replace & by && in such a statement; to make the conversion less painful, we decided to keep the precedence of the & operator the same relative to ==, and merely split the precedence of && slightly from &. Today, it seems that it would have been preferable to move the relative precedences of & and ==, and thereby simplify a common C idiom: to test a masked value against another value, one must write
if ((a&mask) == b) ...
where the inner parentheses are required but easily forgotten.
http://cm.bell-labs.com/cm/cs/who/dmr/chist.html

Name: Anonymous 2010-06-02 10:22

>>46
http://cm.bell-labs.com/cm/cs/who/dmr/chist.html
Did you have a point you wanted to make by posting that?

Name: Anonymous 2010-06-02 10:28

>>47
it's never going to be fixed.

Name: Anonymous 2010-06-02 10:34

>>47
It's the source for the quote directly above it, you moron.

Name: Anonymous 2010-06-02 11:28

>>48
I don't see how that follows.

>>49
You aren't terribly bright, are you?

Name: Anonymous 2010-06-02 11:33

>>50
It never needs to be fixed, as it is not that much of an issue (it is not that hard to remember the inner parentheses).

You don't appear to be bright - the link was for the quote which was information for you. You should accept it instead of dismissing it and being a dick.

Name: Anonymous 2010-06-02 12:36

>>49
Hey, ASSHOLE, my news reader can't view quotes, subjects, or signatures, so FUCK YOU.

Name: >>47 2010-06-02 14:07

>>49,51
You don't appear to be bright - the link was for the quote which was information for you.
Jesus fucking Christ. I only quoted the link because there was no point in quoting the entire quote as well. My question was in what way the quote was related to the issue that order of precedence of bitwise operators is fucked up. Do you think you can understand that, now that I've spelled it out? Knobhead.

Name: Anonymous 2010-06-02 14:09

Don't do weed, kids.

Name: Anonymous 2010-06-02 14:23

>>40
I lol'd

Name: Anonymous 2010-06-02 15:39

>>43
Don't get me wrong, C is a dandy thing, but c1x introduces so slight a difference that there is hardly any difference at all.
 
>>44
I'm with >>45, threads should be in, but nothing is actually changing for the programmer: they're already here of their own volition.

This closures thing is scary. Apple's rationale is actually good:
Closures are an ideal form of a succinct description of units of work that are easily and trivially farmed off to anonymous threads of execution once copied. The predominant form of a closure rarely uses __block storage and as such is an immutable object that can be accessed by multiple threads safely in a trivial fashion in essentially an asynchronous form. Synchronous uses, say for sorting or searching, are cheap because they need never leave the stack, and the __block form is generally safe because there is no parallelism implied.
While this is great, /prog/ probably wants to use them to write buttsorters or something. I'd want them in because I'd also like to see coroutines. Closures in C are probably only good for concurrency. Everything else seems like terrible practice to me.

Name: Anonymous 2010-06-02 16:15

Blocks and libdispatch are already in OS X 10.6 and FreeBSD. Mike Ash has a series of articles explaining on how blocks work in practice at http://www.mikeash.com/pyblog/.

Name: Anonymous 2010-06-03 14:46

>>53
Are you serious? You couldn't see it? Holy shit.
to make the conversion less painful, we decided to keep the precedence of the & operator the same relative to ==, and merely split the precedence of && slightly from &. Today, it seems that it would have been preferable to move the relative precedences of & and ==
You:
in what way the quote was related to the issue that order of precedence
Spelt out enough for you?

Name: Anonymous 2010-06-03 15:18

>>45
Meanwhile, it doesn't fix the one thing that's seriously wrong in C: the order of precedence of the bitwise operators.
Yes, that's the one thing that is wrong with C. Not the interchangeability of arrays and pointers; not null-terminated strings and buffer overflows; not the dangers of pointer arithmetic; not the many preprocessor and macro pitfalls. No, bitwise operator precedence is the one problem with C.

Name: Anonymous 2010-06-03 15:28

buffer overflows; not the dangers of pointer arithmetic;
If you want auto-magical bounds checking and to be protected from the *gasp* dangers of pointer arithmetic then you or your project are not suited to C and you should choose a different language.

Name: Anonymous 2010-06-03 15:48

>>59
not null-terminated strings

that is a problem of the C standard library, not C itself.

Name: Anonymous 2010-06-03 16:05

>>58
Goddamn moron. You still haven't explained why you think your link demonstrates that it's never going to be fixed.
Given the level of reading comprehension you've demonstrated in this thread, though, I think I have my answer anyway.

>>59
interchangeability of arrays and pointers
Not actually a problem.

null-terminated strings and buffer overflows
Not a language issue.

dangers of pointer arithmetic
... Are you sure you understand what C is for?

not the many preprocessor and macro pitfalls
You mean the one pitfall? The preprocessor is a separate language anyway.

Name: Anonymous 2010-06-03 16:21

>>62
You goddamn moron. It's as if there are more than just me and you in this thread or something, isn't it?

Name: Anonymous 2010-06-03 21:19

>>1
Eeeew.

Name: Anonymous 2010-06-04 2:36

DOOMSDAY IS COMING

Name: Anonymous 2010-06-09 15:42

http://gcc.gnu.org/wiki/CppConventions

Name: Anonymous 2010-06-09 18:35

gsc: gnu sepples compiler
Don't change these.
Name: Email:
Entire Thread Thread List
All trademarks and copyrights on this site are owned by their respective parties. All comments and posts are the responsibility of their own posters.
- Tinychan + 2ch Mode -