Skip to main content
added 52 characters in body
Source Link
JDługosz
  • 598
  • 2
  • 9

Back in the day, using a C++ compiler as “a better C” was promoted as a use case. In fact, early C++ was exactly that. The underlying design principle was that you could use only the features you wanted and would not incur the cost of features you were not using. So, you could overload functions (by declaring the intent via the overload keyword!) and the rest of your project not only would compile just fine but would generate code no worse than the C compiler would produce.

Since then, the languages have diverged somewhat.

Every malloc in your C code will be a type mismatch error. Li1ewise — not a problem in your case with no dynamic memory! Likewise, all your void pointers in C will trip you up, as you will have to add explicit casts. But…why are you doing it that way … you will be led down the path of using C++ features more and more.

So, it might be possible with some extra work. But it will serve as a gateway to larger scale C++ adoption. In a few years people will complain about your legacy code that looks like it was written in 1989, as they replace your malloc calls with new, rip out blocks of code of loop bodies to just call an algorithm instead, and berate the unsafe fake polymorphism that would have been trivial had the compiler been allowed to do it.

On the other hand, you know that it would be all the same had you written it in C, so is it ever wrong to write in C instead of C++ given its existence? If the answer is “no”, then using cherry-picked features from C++ can’t be wrong either.

Back in the day, using a C++ compiler as “a better C” was promoted as a use case. In fact, early C++ was exactly that. The underlying design principle was that you could use only the features you wanted and would not incur the cost of features you were not using. So, you could overload functions (by declaring the intent via the overload keyword!) and the rest of your project not only would compile just fine but would generate code no worse than the C compiler would produce.

Since then, the languages have diverged somewhat.

Every malloc in your C code will be a type mismatch error. Li1ewise, all your void pointers in C will trip you up, as you will have to add explicit casts. But…why are you doing it that way … you will be led down the path of using C++ features more and more.

So, it might be possible with some extra work. But it will serve as a gateway to larger scale C++ adoption. In a few years people will complain about your legacy code that looks like it was written in 1989, as they replace your malloc calls with new, rip out blocks of code of loop bodies to just call an algorithm instead, and berate the unsafe fake polymorphism that would have been trivial had the compiler been allowed to do it.

On the other hand, you know that it would be all the same had you written it in C, so is it ever wrong to write in C instead of C++ given its existence? If the answer is “no”, then using cherry-picked features from C++ can’t be wrong either.

Back in the day, using a C++ compiler as “a better C” was promoted as a use case. In fact, early C++ was exactly that. The underlying design principle was that you could use only the features you wanted and would not incur the cost of features you were not using. So, you could overload functions (by declaring the intent via the overload keyword!) and the rest of your project not only would compile just fine but would generate code no worse than the C compiler would produce.

Since then, the languages have diverged somewhat.

Every malloc in your C code will be a type mismatch error — not a problem in your case with no dynamic memory! Likewise, all your void pointers in C will trip you up, as you will have to add explicit casts. But…why are you doing it that way … you will be led down the path of using C++ features more and more.

So, it might be possible with some extra work. But it will serve as a gateway to larger scale C++ adoption. In a few years people will complain about your legacy code that looks like it was written in 1989, as they replace your malloc calls with new, rip out blocks of code of loop bodies to just call an algorithm instead, and berate the unsafe fake polymorphism that would have been trivial had the compiler been allowed to do it.

On the other hand, you know that it would be all the same had you written it in C, so is it ever wrong to write in C instead of C++ given its existence? If the answer is “no”, then using cherry-picked features from C++ can’t be wrong either.

Source Link
JDługosz
  • 598
  • 2
  • 9

Back in the day, using a C++ compiler as “a better C” was promoted as a use case. In fact, early C++ was exactly that. The underlying design principle was that you could use only the features you wanted and would not incur the cost of features you were not using. So, you could overload functions (by declaring the intent via the overload keyword!) and the rest of your project not only would compile just fine but would generate code no worse than the C compiler would produce.

Since then, the languages have diverged somewhat.

Every malloc in your C code will be a type mismatch error. Li1ewise, all your void pointers in C will trip you up, as you will have to add explicit casts. But…why are you doing it that way … you will be led down the path of using C++ features more and more.

So, it might be possible with some extra work. But it will serve as a gateway to larger scale C++ adoption. In a few years people will complain about your legacy code that looks like it was written in 1989, as they replace your malloc calls with new, rip out blocks of code of loop bodies to just call an algorithm instead, and berate the unsafe fake polymorphism that would have been trivial had the compiler been allowed to do it.

On the other hand, you know that it would be all the same had you written it in C, so is it ever wrong to write in C instead of C++ given its existence? If the answer is “no”, then using cherry-picked features from C++ can’t be wrong either.