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

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-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
Newer Posts
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 -