4 ms·

> I think realistically a "clean start" of C++ with the best of C++11 and earlier standards but removing a lot of the less worthwhile features would go a long w

by frou_dh 14y ago

> I think realistically a "clean start" of C++ with the best of C++11 and earlier standards but removing a lot of the less worthwhile features would go a long way. Won't happen though. I'm sure the big players are in standard C++ for the long haul. Though, the thing you mention, wouldn't that make a good (though ambitious) community project? Make a hot-rod non-standard C++ implementation using Clang as a starting point.

codewright 14y ago
C++ programmers 'hate giving things up' and there's an imperfect and sparse subset of the language that any given sampling of C++ programmers use. Getting consensus on what to take out would be difficult, considering a lot of the features aren't there to incrementally improve the lives of 'everyone', but rather to cope with an edge-case that could be a fatal problem for something specific. That's how a lot of committee work goes. I wouldn't mind seeing such a thing. I find C++ intimidating, but I don't think the answer is to completely forgo utilizing it. Realistically my solution is to only use features I understand in relation to how something similar would look in C.
- frou_dh 14y ago
  Those who had the gumption to get the project off the ground would get the decision-making hats (a better solution to "can't please everyone" than analysis paralysis!). All hypothetical of course.
- Shorel 14y ago
  > Realistically my solution is to only use features I understand in relation to how something similar would look in C. Absolutely true. I don't understand people trying to use every single language feature in every single program. And I'm thinking in general terms, not just C++.
cmccabe 14y ago
Luckily a subset of C++ with just the "good" features has already been made and is widely deployed. It's called C.
- frou_dh 14y ago
  Might you be interested in a dash of parametric polymorphism for type safety?
  - codewright 14y ago
    Or for that matter, the C++11 concurrency primitives, smart pointers, type inference (auto), nullptr, lambdas, static_assert, <regexp>, stuff like http://libsigc.sourceforge.net/ http://libsigc.sourceforge.net/ List goes on...
    - cmccabe 14y ago
      Language flamewars are dull. Very dull. But since you gave specifics, I will too. Concurrency primitives in C: it's a library issue. In userspace, use libatomic-ops. In kernel space, you've got atomic_t and it works well. static_assert: the kernel has BUILD_BUG_ON. You can easily roll your own in userspace in a line or two. It should get added to C at some point, but it's not a huge issue. type inference via "auto": C++ only needs this because it adopted the "stutter" syntax 30 years ago. "Foo foo = new Foo()" is not something you see in C. nullptr: C++ only needed this because it had function overloading. Since NULL is actually just a macro for 0, it easily matches functions where it "shouldn't". C doesn't need this hack. Note that you still have the "pointer to bool" conversion path in C++-- have fun with that. (C doesn't have bools.) lambdas: gcc has supported nested functions in C for a while. Not too many people use them because honestly, they are not that useful in C, as good as they may be in other languages. regexp: there's a ton of libraries out there for doing regular expressions in C. PCRE is a well-known one. Or even just regex.h. However, if you find yourself using this a lot, it might be a warning that you're using the wrong language for the job. parametric polymorphism: now we're getting closer to the heart of the issue, aren't we? A lot could be written about this, but let me just say this: the C++/Java type system leans heavily on inheritance, which is an antipattern. C tends to encourage you to use composition, which is the right way to do things anyway. You can create vtables of function pointers in C when you really need to, which isn't as often as a lot of Java/C++ programmers have been trained to think.

by frou_dh 14y ago

codewright 14y ago

C++ programmers 'hate giving things up' and there's an imperfect and sparse subset of the language that any given sampling of C++ programmers use. Getting consensus on what to take out would be difficult, considering a lot of the features aren't there to incrementally improve the lives of 'everyone', but rather to cope with an edge-case that could be a fatal problem for something specific. That's how a lot of committee work goes. I wouldn't mind seeing such a thing. I find C++ intimidating, but I don't think the answer is to completely forgo utilizing it. Realistically my solution is to only use features I understand in relation to how something similar would look in C.

frou_dh 14y ago
Those who had the gumption to get the project off the ground would get the decision-making hats (a better solution to "can't please everyone" than analysis paralysis!). All hypothetical of course.
Shorel 14y ago
> Realistically my solution is to only use features I understand in relation to how something similar would look in C. Absolutely true. I don't understand people trying to use every single language feature in every single program. And I'm thinking in general terms, not just C++.

cmccabe 14y ago

Luckily a subset of C++ with just the "good" features has already been made and is widely deployed. It's called C.

frou_dh 14y ago
Might you be interested in a dash of parametric polymorphism for type safety?
- codewright 14y ago
  Or for that matter, the C++11 concurrency primitives, smart pointers, type inference (auto), nullptr, lambdas, static_assert, <regexp>, stuff like http://libsigc.sourceforge.net/ http://libsigc.sourceforge.net/ List goes on...
  - cmccabe 14y ago
    Language flamewars are dull. Very dull. But since you gave specifics, I will too. Concurrency primitives in C: it's a library issue. In userspace, use libatomic-ops. In kernel space, you've got atomic_t and it works well. static_assert: the kernel has BUILD_BUG_ON. You can easily roll your own in userspace in a line or two. It should get added to C at some point, but it's not a huge issue. type inference via "auto": C++ only needs this because it adopted the "stutter" syntax 30 years ago. "Foo foo = new Foo()" is not something you see in C. nullptr: C++ only needed this because it had function overloading. Since NULL is actually just a macro for 0, it easily matches functions where it "shouldn't". C doesn't need this hack. Note that you still have the "pointer to bool" conversion path in C++-- have fun with that. (C doesn't have bools.) lambdas: gcc has supported nested functions in C for a while. Not too many people use them because honestly, they are not that useful in C, as good as they may be in other languages. regexp: there's a ton of libraries out there for doing regular expressions in C. PCRE is a well-known one. Or even just regex.h. However, if you find yourself using this a lot, it might be a warning that you're using the wrong language for the job. parametric polymorphism: now we're getting closer to the heart of the issue, aren't we? A lot could be written about this, but let me just say this: the C++/Java type system leans heavily on inheritance, which is an antipattern. C tends to encourage you to use composition, which is the right way to do things anyway. You can create vtables of function pointers in C when you really need to, which isn't as often as a lot of Java/C++ programmers have been trained to think.