6 ms·

I think you have that backwards. If anything, C code should be considered legacy code. C++ is capable of filling all the domains C dominates.

by nly 13y ago

jpmec 13y ago
Nope, can't do it unless you strip out things that are inherently C++. C++ does too many things "for the programmer's benefit" to allow it to fill the domains that C is good at. They are different languages with different benefits.
- nly 13y ago
  > Nope, can't do it unless you strip out things that are inherently C++ It's likely that your idea of what is 'inherent' to C++ is just wrong. First of all, C++ is almost a superset of common C so, yes, it can can really replace C entirely and completely. Whatever grievances you have with the language don't change the reality that even embedded code benefits from, and has been gaining ground in, C++ for quite some time. In any case, I'm not arguing C++ is inherently 'better' than C. I'm just saying betterunix's assertion that C++ is somehow 'legacy', and C somehow isn't, is weird and illogical.
  - betterunix 13y ago
    "I'm just saying betterunix's assertion that C++ is somehow 'legacy', and C somehow isn't, is weird and illogical." We do still have a need for a low-level language; C is not the greatest language but it gets the job done. There is also quite a bit of C code out there, proof-of-concept code, reference implementations, etc., and so not knowing C means being cut off from all of that. C++ is not as commonly used for such things, or if it is then only a minimum subset of it is used, and it has no advantage over C as a low-level language. The high-level features of C++ are polluted with low-level concerns that serve as nothing more than a distraction; this has not changed with C++11 and it does not look like it will change with C++14. So really, the only good reason to be learning C++ in this day and age is if you need to extend or maintain some part of the massive body of already-written C++ code. In other words, if you need to deal with legacy code.
    - nly 13y ago
      You seem to think I'm dismissing C. What I'm really trying to express is that I'd recommend people learn C++ and consider C an old-school 1980s, unsafe, rather laborious, subset of it. > We do still have a need for a low-level language C++ can be 'low-level' if that's what you're going to label C. How can you dismiss C++ as not being low-level and then later say it's 'polluted by low-level concerns'? > There is also quite a bit of C code out there... not knowing C means being cut off from all of that. I agree. Fortunately, you can't really effectively learn C++ without understanding its C legacy. > The high-level features of C++ are polluted with low-level concerns that serve as nothing more than a distraction Until you're working at a high level and need to dig deep and implement a gritty data structure or algorithm with a high-level interface. Sure, you can drop down from Java to C, for example, but then you're in the mud writing JNI bindings. Why do languages have to be constrained to 'high-level' and 'low-level' pigeon holes? Why can't there be room for a language that's good, but perhaps not elegant, slick or beautiful, across the spectrum? Honestly, I don't want a religious war about it. I just think some of your assumptions are typical of people who have obvious had a bad experience with C++, having used it in a specific context, and therefore think "It didn't work for me, therefore it must be horrible". On another note, C++ is at least improving and rapidly becoming better tooled, with a growing sense of developer community. C has had a few sprinkles of improvement, but has otherwise reached the end of its natural evolution.
      - orclev 13y ago
        If you need C you should write C. If you don't need C, you should write in something nice, I.E. not C++. Why sacrifice ease of use 90% of the time in order to gain access to low level features 10% of the time? Any high level language worth anything has the ability to call C code via some mechanism (some better than others, Java probably has the worst mechanism out of any high level language). Use two languages that work really well at what they do, rather than one that sucks equally at both.
        nly 13y ago
        That's just like, your opinion, man I think C++ is the best procedural, 'high level', statically typed language out there. I also happen to think it's the best portable 'low level' language out there. What would your recommendation be to go alongside C?
  - jpmec 13y ago
    I was objecting to filling "all" the domains. I was referring to classes as inherently C++. For example, constructors, destructors, virtual functions, namespaces. For example, AFAIK you cannot have a naked struct in C++. A struct is a class, and therefore can have methods, thus can have constructor and destructor. Also, exceptions are a big part of C++ that I don't think you can remove? If you want simple, obvious separation of data and logic, and you don't want exceptions or name mangling, then C is probably a better choice for that domain. I like C++, but it is not C and is unlikely that one will ever replace the other in all the domains. OTOH, if you want to write OO and you like C++, then it is not a bad choice. I think both are being used to write new systems, so neither is legacy :-)
    - nly 13y ago
      > I was referring to classes as inherently C++. > AFAIK you cannot have a naked struct in C++ The "class" keyword and the "struct" keyword differ only in default member visibility. You're free to use the struct keyword. Yes, such structs can have member functions, but they change little except to act as a convenience. A "naked struct" in C++ is called a POD ("Plain Old Data") type, and there are a few rules to ensure your structure meets that definition. The standard library has a type trait to test a class/struct to see if it meets that definition (called std::is_pod). > For example, constructors, destructors, virtual functions, namespaces. None of these actually interfere with any use cases or domain that I can think of. Constructors and destructors are insanely valuable features, even if you use nothing else. Functions are not virtual by default and impose no overhead unless used. > exceptions are a big part of C++ that I don't think you can remove? You can turn exceptions off at the compiler level. -fno-exceptions in GCC and Clang. RTTI can also be disabled. Disabling both in embedded cases is perfectly reasonable. > name mangling extern "C" {} blocks kill name mangling and allow you to export a C API and ABI compatible function.

I think you have that backwards. If anything, C code should be considered legacy code. C++ is capable of filling all the domains C dominates.

by nly 13y ago

I think you have that backwards. If anything, C code should be considered legacy code. C++ is capable of filling all the domains C dominates.

jpmec 13y ago

Nope, can't do it unless you strip out things that are inherently C++. C++ does too many things "for the programmer's benefit" to allow it to fill the domains that C is good at. They are different languages with different benefits.

nly 13y ago
> Nope, can't do it unless you strip out things that are inherently C++ It's likely that your idea of what is 'inherent' to C++ is just wrong. First of all, C++ is almost a superset of common C so, yes, it can can really replace C entirely and completely. Whatever grievances you have with the language don't change the reality that even embedded code benefits from, and has been gaining ground in, C++ for quite some time. In any case, I'm not arguing C++ is inherently 'better' than C. I'm just saying betterunix's assertion that C++ is somehow 'legacy', and C somehow isn't, is weird and illogical.
- betterunix 13y ago
  "I'm just saying betterunix's assertion that C++ is somehow 'legacy', and C somehow isn't, is weird and illogical." We do still have a need for a low-level language; C is not the greatest language but it gets the job done. There is also quite a bit of C code out there, proof-of-concept code, reference implementations, etc., and so not knowing C means being cut off from all of that. C++ is not as commonly used for such things, or if it is then only a minimum subset of it is used, and it has no advantage over C as a low-level language. The high-level features of C++ are polluted with low-level concerns that serve as nothing more than a distraction; this has not changed with C++11 and it does not look like it will change with C++14. So really, the only good reason to be learning C++ in this day and age is if you need to extend or maintain some part of the massive body of already-written C++ code. In other words, if you need to deal with legacy code.
  - nly 13y ago
    You seem to think I'm dismissing C. What I'm really trying to express is that I'd recommend people learn C++ and consider C an old-school 1980s, unsafe, rather laborious, subset of it. > We do still have a need for a low-level language C++ can be 'low-level' if that's what you're going to label C. How can you dismiss C++ as not being low-level and then later say it's 'polluted by low-level concerns'? > There is also quite a bit of C code out there... not knowing C means being cut off from all of that. I agree. Fortunately, you can't really effectively learn C++ without understanding its C legacy. > The high-level features of C++ are polluted with low-level concerns that serve as nothing more than a distraction Until you're working at a high level and need to dig deep and implement a gritty data structure or algorithm with a high-level interface. Sure, you can drop down from Java to C, for example, but then you're in the mud writing JNI bindings. Why do languages have to be constrained to 'high-level' and 'low-level' pigeon holes? Why can't there be room for a language that's good, but perhaps not elegant, slick or beautiful, across the spectrum? Honestly, I don't want a religious war about it. I just think some of your assumptions are typical of people who have obvious had a bad experience with C++, having used it in a specific context, and therefore think "It didn't work for me, therefore it must be horrible". On another note, C++ is at least improving and rapidly becoming better tooled, with a growing sense of developer community. C has had a few sprinkles of improvement, but has otherwise reached the end of its natural evolution.
    - orclev 13y ago
      If you need C you should write C. If you don't need C, you should write in something nice, I.E. not C++. Why sacrifice ease of use 90% of the time in order to gain access to low level features 10% of the time? Any high level language worth anything has the ability to call C code via some mechanism (some better than others, Java probably has the worst mechanism out of any high level language). Use two languages that work really well at what they do, rather than one that sucks equally at both.
      - nly 13y ago
        That's just like, your opinion, man I think C++ is the best procedural, 'high level', statically typed language out there. I also happen to think it's the best portable 'low level' language out there. What would your recommendation be to go alongside C?
- jpmec 13y ago
  I was objecting to filling "all" the domains. I was referring to classes as inherently C++. For example, constructors, destructors, virtual functions, namespaces. For example, AFAIK you cannot have a naked struct in C++. A struct is a class, and therefore can have methods, thus can have constructor and destructor. Also, exceptions are a big part of C++ that I don't think you can remove? If you want simple, obvious separation of data and logic, and you don't want exceptions or name mangling, then C is probably a better choice for that domain. I like C++, but it is not C and is unlikely that one will ever replace the other in all the domains. OTOH, if you want to write OO and you like C++, then it is not a bad choice. I think both are being used to write new systems, so neither is legacy :-)
  - nly 13y ago
    > I was referring to classes as inherently C++. > AFAIK you cannot have a naked struct in C++ The "class" keyword and the "struct" keyword differ only in default member visibility. You're free to use the struct keyword. Yes, such structs can have member functions, but they change little except to act as a convenience. A "naked struct" in C++ is called a POD ("Plain Old Data") type, and there are a few rules to ensure your structure meets that definition. The standard library has a type trait to test a class/struct to see if it meets that definition (called std::is_pod). > For example, constructors, destructors, virtual functions, namespaces. None of these actually interfere with any use cases or domain that I can think of. Constructors and destructors are insanely valuable features, even if you use nothing else. Functions are not virtual by default and impose no overhead unless used. > exceptions are a big part of C++ that I don't think you can remove? You can turn exceptions off at the compiler level. -fno-exceptions in GCC and Clang. RTTI can also be disabled. Disabling both in embedded cases is perfectly reasonable. > name mangling extern "C" {} blocks kill name mangling and allow you to export a C API and ABI compatible function.