4 ms·

I'm still unsure why people start projects with C, or C++ (or other unsafe languages), that do not need it. I totally understand that there are use cases where

by sargun 11y ago

I'm still unsure why people start projects with C, or C++ (or other unsafe languages), that do not need it. I totally understand that there are use cases where C++ and C make sense. In my mind, these use cases are quite limited though - integration into 3rd party libraries, legacy codebases, and working in embedded environments. I also agree that performance can be a reason, but see Knuth's opinion on premature optimization. I also think that when writing C, and C++ it makes a lot of sense to restrict oneself as much as possible a la the kinds of standards in the Google Style Guide, or NASA's style guide. Can people tell me why they start projects in broad C++, and C still? I may be completely missing some piece of the puzzle.

pjmlp 11y ago
Sometimes there isn't any other choice. For example, in the mobile OS space if you want to write native apps, without rewriting 100% of the application code per platform and avoid toolchain debugging headaches, C and C++ are the only languages available in iOS, Android and WP SDKs. In WP case, there are APIs like DirectX that aren't fully exposed via WinRT, so you need to write a C++ wrapper for those type of APIs. There are other options, but they are either commercial (e.g. Xamarin), or require lots of DYI hacking with the SDKs toolchains. So if you want to remain productive and not pay for the commercial solutions, there aren't any other alternatives. Which means, even I with my safety rants, end up using them for my mobile OS hobby coding. However if I would be doing this commercially, Xamarin would be my first option.
- tosseraccount 11y ago
  Isn't slapping C onto objective C trivial for iOS and OSX? Just wrap to the GUI's objective C. You can use this trick for WTL on Window's C++, too.
  - jsmthrowaway 11y ago
    People seem to forget that Objective C is a superset of C. No slapping on required. You're already writing it. Avoid brackets and a few other things and it's C. You don't even have to rename .m to .c, but you can.
tangent128 11y ago
C is still the lingua franca; it's the only toolchain you can rely on a target system having, and the only real usable interface for calling between code in different languages. So my theory is that it's not so much that people are especially inclined towards starting projects in C, but that projects in C have fewer barriers to distribution and thus adoption. By natural selection, C code spreads and becomes standard; programs in Java, JS, Ruby, Haskell, Ocaml, etc. don't tend to leave their native ecosystem.
- groovy2shoes 11y ago
  This is exactly my reason for starting a couple of recent side-projects in C. You can pretty much count on the target system having an ANSI C compiler (even rather old systems), which can't be said for any other language. Have an ANSI C compiler? Great! You don't need anything else to build and install this program. You don't need to install a hefty runtime like the JVM and you don't need to know what a gem is. I don't think I'm immune to the hazards inherent in the language. I try my best be aware of them and to write safe code, and still find myself introducing a segfault now and then. Luckily, tools like valgrind and Coverity can really help to catch these kinds of issues early (of course, they can't catch everything, but I've been amazed by just how much they do catch).
creshal 11y ago
> I'm still unsure why people start projects with C, or C++ (or other unsafe languages), that do not need it. I totally understand that there are use cases where C++ and C make sense. On Linux it's easy: It is (or was, until very recently) the least sucky alternative. All others have (or had) issues with OS support (C#), distribution (Java: OpenJDK vs. Oracle JDK; Python: 2.5 to 3.4 parallel in use by different distributions; Vala: Every compiler update breaks the language; etc. pp.), availability of libraries (Ruby, PHP, Perl… for anything that's not their speciality) or general obscurity (OCaml, …). Go and Rust (and JS, C# and Vala recently) seem to be changing this, thankfully. But those too will depend on the availability of high-quality bindings for all the C(++) libraries you have to use to get anything substantial done.
d0lph 11y ago
Written properly, C++ is not unsafe. Certain language own certain domains, for better or worse, this means that most developers interested in low level programming will know C/C++, and that the will be a substantial amount of tooling already in place.
- cmrx64 11y ago
  > Written properly, C++ is not unsafe. This is abusing what "unsafe" means. As a language, C++ is inherently unsafe. However, some C++ programs ("written properly") are correct. If written properly C++ is not unsafe, then written properly C is not unsafe.
  - SCHiM 11y ago
    No I think he meant that if you adhere to certain language constructs the language is just as memory safe as Rust/others. Eg. Don't use C++ as C with vectors, use C++ with the more modern language features: It's the difference between: // where f is of type fstream of a file containging "this is a string\r\n"No I think he meant that if you adhere to certain language constructs the language is just as memory safe as Rust/others. Eg. Don't use C++ as C with vectors, use C++ with the more modern language features: It's the difference between: std::string A = "ab" + std::string("c"); // And: char Buffer[512] = {}; strcat(Buffer, "ab"); strcat(Buffer, "c"); Or alternatvily: std::vector<uint8_t> SomeData = { 1,2,3 } std::vector<uint8_t> OtherData(SomeData.begin(), SomeData.end()); // and: std::vector<uint8_t> SomeData = { 1,2,3 } std::vector<uint8_t> OtherData; OtherData.reserve(3); memcpy(...) In the first one you're 'protected' by the stl code, which is arguably the same level of protection as afforded by any memory safe language’s library code. std::string A = "ab" + std::string("c"); // And: char Buffer[512] = {}; strcat(Buffer, "ab"); strcat(Buffer, "c"); Or alternatvily: std::vector<uint8_t> SomeData = { 1,2,3 } std::vector<uint8_t> OtherData(SomeData.begin(), SomeData.end()); // and: std::vector<uint8_t> SomeData = { 1,2,3 } std::vector<uint8_t> OtherData; OtherData.reserve(3); memcpy(...) In the first one you're 'protected' by the stl code, which is arguably the same level of protection as afforded by any memory safe language’s library code.
tosseraccount 11y ago
Because you can't release a single file statically compiled native binary that relies only on established system calls. People typically can't install packages anymore. They can grab an exe.
- w8rbt 11y ago
  This is the reason I ported several Python and Java apps to C++. One exe and it just works.
autoreleasepool 11y ago
> Can people tell me why they start projects in broad C++, and C still? I may be completely missing some piece of the puzzle. Sure. --- Compelling features: - Unrivaled portability (yes, contrary to folklore C - and to a lesser extent C++ - is more portable than Java) - Excellent libraries - Excellent documentation and learning resources - Unrivaled tooling - perfect mapping to how the computer works - Unrivaled performance (other than Rust) - exceptional, engaging, and intelligent community (specifically referring to the cpp community) --- Why start a C++ project today? - you want to write a web browser - you want a platform agnostc GUI - you want to learn OpenGL or Vulkan - you want to use Unreal and you're not a visual learner - you're want to write the business logic for a cross platform application and share as much code as possible - you're implementing you're own programming language - your implementing an algorithm or data structure you've been studying - you're bored - you like programming in C++ - you want to learn template meta-programming - you want to learn functional programming - you want to learn how to write a device driver - you need the performance - you are not writing mission critical software (aka 99% of all side projects) - you're a curious person - you're a contrarian and everyone you know uses Java - you want to become a more well-rounded engineer - you want to learn about the ins and outs of language design and features - you want make a lot of money - you only know C++ Those are a few reasons. Hope that helps you solve your puzzle. PS: Do the anti-C people realize that a kernel in Rust/Nim/whatever would be under a big unsafe block anyways? Yeah, you have to program "unsafe" code eventually. Those nice high level abstractions are not omnipresent, you know. They need something to abstract.
- steveklabnik 11y ago
  > a kernel in Rust/Nim/whatever would be under a big unsafe block anyways? Only portions of it do. The whole point of unsafe is that you can encapsulate it, and then go from there.
  - autoreleasepool 11y ago
    Definitely. The ability to encapsulate code that is less strictly checked by the compiler is what makes Rust such a compelling alternative to C. I definitely think Rust is the ideal choice for a hobby kernel from scratch in 2016. My point is that unsafety is unavoidable. You can encapsulate unsafe Rust or wrap plain old C, it's, for all practical purposes, the same. At that level language features matter a lot less. I agree we should minimize and encapsulate loosely checked code as best we can.
J_Darnley 11y ago
> Can people tell me why they start projects in ... C still? Okay. Based on my current project (Porting AVS out of shit-tier Microsoft C++). I want a region of memory in which I can treat as a bitmap and set pixels at given location to given colours. I know of no other language that gives me this block of memory to draw into. That's probably because I don't know enough. Most languages seem to tout how immutable things are. That's a big word for many people and it just means "does not change". If other languages want my attention then maybe they need more than a "Hello, World!" and some string processing. Show me your malloc equivalent and see if I can go from there.
- GregBuchholz 11y ago
  >I want a region of memory in which I can treat as a bitmap... ...Show me your malloc equivalent and see if I can go from there. http://www.lispworks.com/documentation/HyperSpec/Body/f_mk_ar.htm http://www.lispworks.com/documentation/HyperSpec/Body/f_mk_a... https://wiki.haskell.org/Numeric_Haskell:_A_Vector_Tutorial#Unboxed_Arrays:_Data.Vector.Unboxed https://wiki.haskell.org/Numeric_Haskell:_A_Vector_Tutorial#...
  - J_Darnley 11y ago
    Thank you.

by sargun 11y ago

pjmlp 11y ago

Sometimes there isn't any other choice. For example, in the mobile OS space if you want to write native apps, without rewriting 100% of the application code per platform and avoid toolchain debugging headaches, C and C++ are the only languages available in iOS, Android and WP SDKs. In WP case, there are APIs like DirectX that aren't fully exposed via WinRT, so you need to write a C++ wrapper for those type of APIs. There are other options, but they are either commercial (e.g. Xamarin), or require lots of DYI hacking with the SDKs toolchains. So if you want to remain productive and not pay for the commercial solutions, there aren't any other alternatives. Which means, even I with my safety rants, end up using them for my mobile OS hobby coding. However if I would be doing this commercially, Xamarin would be my first option.

tosseraccount 11y ago
Isn't slapping C onto objective C trivial for iOS and OSX? Just wrap to the GUI's objective C. You can use this trick for WTL on Window's C++, too.
- jsmthrowaway 11y ago
  People seem to forget that Objective C is a superset of C. No slapping on required. You're already writing it. Avoid brackets and a few other things and it's C. You don't even have to rename .m to .c, but you can.

tangent128 11y ago

C is still the lingua franca; it's the only toolchain you can rely on a target system having, and the only real usable interface for calling between code in different languages. So my theory is that it's not so much that people are especially inclined towards starting projects in C, but that projects in C have fewer barriers to distribution and thus adoption. By natural selection, C code spreads and becomes standard; programs in Java, JS, Ruby, Haskell, Ocaml, etc. don't tend to leave their native ecosystem.

groovy2shoes 11y ago
This is exactly my reason for starting a couple of recent side-projects in C. You can pretty much count on the target system having an ANSI C compiler (even rather old systems), which can't be said for any other language. Have an ANSI C compiler? Great! You don't need anything else to build and install this program. You don't need to install a hefty runtime like the JVM and you don't need to know what a gem is. I don't think I'm immune to the hazards inherent in the language. I try my best be aware of them and to write safe code, and still find myself introducing a segfault now and then. Luckily, tools like valgrind and Coverity can really help to catch these kinds of issues early (of course, they can't catch everything, but I've been amazed by just how much they do catch).

creshal 11y ago

> I'm still unsure why people start projects with C, or C++ (or other unsafe languages), that do not need it. I totally understand that there are use cases where C++ and C make sense. On Linux it's easy: It is (or was, until very recently) the least sucky alternative. All others have (or had) issues with OS support (C#), distribution (Java: OpenJDK vs. Oracle JDK; Python: 2.5 to 3.4 parallel in use by different distributions; Vala: Every compiler update breaks the language; etc. pp.), availability of libraries (Ruby, PHP, Perl… for anything that's not their speciality) or general obscurity (OCaml, …). Go and Rust (and JS, C# and Vala recently) seem to be changing this, thankfully. But those too will depend on the availability of high-quality bindings for all the C(++) libraries you have to use to get anything substantial done.

d0lph 11y ago

Written properly, C++ is not unsafe. Certain language own certain domains, for better or worse, this means that most developers interested in low level programming will know C/C++, and that the will be a substantial amount of tooling already in place.

cmrx64 11y ago
> Written properly, C++ is not unsafe. This is abusing what "unsafe" means. As a language, C++ is inherently unsafe. However, some C++ programs ("written properly") are correct. If written properly C++ is not unsafe, then written properly C is not unsafe.
- SCHiM 11y ago
  No I think he meant that if you adhere to certain language constructs the language is just as memory safe as Rust/others. Eg. Don't use C++ as C with vectors, use C++ with the more modern language features: It's the difference between: // where f is of type fstream of a file containging "this is a string\r\n"No I think he meant that if you adhere to certain language constructs the language is just as memory safe as Rust/others. Eg. Don't use C++ as C with vectors, use C++ with the more modern language features: It's the difference between: std::string A = "ab" + std::string("c"); // And: char Buffer[512] = {}; strcat(Buffer, "ab"); strcat(Buffer, "c"); Or alternatvily: std::vector<uint8_t> SomeData = { 1,2,3 } std::vector<uint8_t> OtherData(SomeData.begin(), SomeData.end()); // and: std::vector<uint8_t> SomeData = { 1,2,3 } std::vector<uint8_t> OtherData; OtherData.reserve(3); memcpy(...) In the first one you're 'protected' by the stl code, which is arguably the same level of protection as afforded by any memory safe language’s library code. std::string A = "ab" + std::string("c"); // And: char Buffer[512] = {}; strcat(Buffer, "ab"); strcat(Buffer, "c"); Or alternatvily: std::vector<uint8_t> SomeData = { 1,2,3 } std::vector<uint8_t> OtherData(SomeData.begin(), SomeData.end()); // and: std::vector<uint8_t> SomeData = { 1,2,3 } std::vector<uint8_t> OtherData; OtherData.reserve(3); memcpy(...) In the first one you're 'protected' by the stl code, which is arguably the same level of protection as afforded by any memory safe language’s library code.

tosseraccount 11y ago

Because you can't release a single file statically compiled native binary that relies only on established system calls. People typically can't install packages anymore. They can grab an exe.

w8rbt 11y ago
This is the reason I ported several Python and Java apps to C++. One exe and it just works.

autoreleasepool 11y ago

> Can people tell me why they start projects in broad C++, and C still? I may be completely missing some piece of the puzzle. Sure. --- Compelling features: - Unrivaled portability (yes, contrary to folklore C - and to a lesser extent C++ - is more portable than Java) - Excellent libraries - Excellent documentation and learning resources - Unrivaled tooling - perfect mapping to how the computer works - Unrivaled performance (other than Rust) - exceptional, engaging, and intelligent community (specifically referring to the cpp community) --- Why start a C++ project today? - you want to write a web browser - you want a platform agnostc GUI - you want to learn OpenGL or Vulkan - you want to use Unreal and you're not a visual learner - you're want to write the business logic for a cross platform application and share as much code as possible - you're implementing you're own programming language - your implementing an algorithm or data structure you've been studying - you're bored - you like programming in C++ - you want to learn template meta-programming - you want to learn functional programming - you want to learn how to write a device driver - you need the performance - you are not writing mission critical software (aka 99% of all side projects) - you're a curious person - you're a contrarian and everyone you know uses Java - you want to become a more well-rounded engineer - you want to learn about the ins and outs of language design and features - you want make a lot of money - you only know C++ Those are a few reasons. Hope that helps you solve your puzzle. PS: Do the anti-C people realize that a kernel in Rust/Nim/whatever would be under a big unsafe block anyways? Yeah, you have to program "unsafe" code eventually. Those nice high level abstractions are not omnipresent, you know. They need something to abstract.

steveklabnik 11y ago
> a kernel in Rust/Nim/whatever would be under a big unsafe block anyways? Only portions of it do. The whole point of unsafe is that you can encapsulate it, and then go from there.
- autoreleasepool 11y ago
  Definitely. The ability to encapsulate code that is less strictly checked by the compiler is what makes Rust such a compelling alternative to C. I definitely think Rust is the ideal choice for a hobby kernel from scratch in 2016. My point is that unsafety is unavoidable. You can encapsulate unsafe Rust or wrap plain old C, it's, for all practical purposes, the same. At that level language features matter a lot less. I agree we should minimize and encapsulate loosely checked code as best we can.

J_Darnley 11y ago

> Can people tell me why they start projects in ... C still? Okay. Based on my current project (Porting AVS out of shit-tier Microsoft C++). I want a region of memory in which I can treat as a bitmap and set pixels at given location to given colours. I know of no other language that gives me this block of memory to draw into. That's probably because I don't know enough. Most languages seem to tout how immutable things are. That's a big word for many people and it just means "does not change". If other languages want my attention then maybe they need more than a "Hello, World!" and some string processing. Show me your malloc equivalent and see if I can go from there.

GregBuchholz 11y ago
>I want a region of memory in which I can treat as a bitmap... ...Show me your malloc equivalent and see if I can go from there. http://www.lispworks.com/documentation/HyperSpec/Body/f_mk_ar.htm http://www.lispworks.com/documentation/HyperSpec/Body/f_mk_a... https://wiki.haskell.org/Numeric_Haskell:_A_Vector_Tutorial#Unboxed_Arrays:_Data.Vector.Unboxed https://wiki.haskell.org/Numeric_Haskell:_A_Vector_Tutorial#...
- J_Darnley 11y ago
  Thank you.