6 ms·

As a C/C++ developer, C# feels like unreachable high level heaven. But then again, I prefer my code to have no garbage collector, be portable without any proble

by Kenji 10y ago

As a C/C++ developer, C# feels like unreachable high level heaven. But then again, I prefer my code to have no garbage collector, be portable without any problems and have very high performance. So, C++ it is. If I was writing a Windows-only GUI app with no resemblance of realtime requirements, I would only use C#.

pjmlp 10y ago
Across how many compilers and operating systems is your code portable without any problems?!
- vvanders 10y ago
  When written with discipline C++ is very portable. I've worked on codebases that spanned devices with ~8mb of memory to full-blown desktop PC and arches(x86/MIPS/ARM/PPC just to name a few).
  - raverbashing 10y ago
    Across devices it seems it is very portable. Now, across compiler vendors and versions it is hard
    - Impossible 10y ago
      Generally speaking when you are targeting that wide of a range of devices you are targeting a wide range of compilers. It requires some discipline but it's far from the hardest thing in the world assuming you are regularly building and testing for all platforms. I'd say that most major C++ applications or libraries compile in Clang, GCC and MSVC without issue and often build for less common targets as well (icc, nvcc for cuda support, etc.) Things definitely get harder when you move to weirder embedded platforms.
      - vvanders 10y ago
        Yup, we targeted GCC, MSVC, plus a few proprietary compilers. As long as you stick to a reasonable set of features(which you should anyway for sanity reasons) it works pretty well. Having a good CI is a must though but it's not nearly as hard as porting an old codebase backwards.
  - pjmlp 10y ago
    Writing with discipline is a synonym for writing castrated C++, to avoid touching language features not yet implemented or with slight semantic differences across compilers. One of the things that attracted me to Java was that I finally could write something where I could use 100% of language features and actually use it everywhere. C++17 is around the corner, yet most embedded, mainframe and commercial UNIX vendors are between C++11 and C++14, in the few cases where they already support anything from C++14. Then there are the UB and implementation defined differences across those compilers.
- DrBazza 10y ago
  It's just a configuration problem - at one job, we had a million line code base compiling with clang, gcc (2 versions, can't recall which), on 2 versions of solaris, 2 versions of linux, and linux 32bit and 64bit, plus windows on VS2010, and 2015, so that makes 18 *nix builds and 2 windows builds, so 20 different C++ builds of one code base. All unit tested, and regression tested. Get your CI system of choice working, e.g. TeamCity, fix your makefiles, and you're good to go.
  - pjmlp 10y ago
    Having done C and C++ across UNIX and Windows, during the late 90's throughout mid-2000's, using the OS vendor's compiler tooling, it was a bit more than just configuration. For example, back then aCC wasn't even fully C89 compliant. Of course when one uses the famous trio (gcc, clang, msvc) the world gets simplified a lot.
atemerev 10y ago
There is Rust now. Why stay with C++?
- endorphone 10y ago
  Comments like this appear on HN with frequency, and they betray a complete detachment from reality. Like what an outsider would think looking at the industry. A very mature language, rapidly evolving, with an enormous volume of well proven libraries and tools, or a cutting edge, barely production level (with a breaking changes language), tiny library new toolset. And you question why someone doesn't just transition? Is that serious?
  - vvanders 10y ago
    > barely production level (with a breaking changes language) Oh no you didn't. There's an argument to be made in Rust vs C++ but to my knowledge there hasn't been a breaking change in Rust since 1.0 and there's been a ton of work to keep it that way.
    - steveklabnik 10y ago
      There technically have been some small changes, just like in C++. The key is, as you said, you aren't even sure there were ones. That's how we like to keep it, and that's part of where all that work goes. The rest goes into making sure nothing breaks accidentally :) Trivial example: shortly after 1.15 was released, a new API was found to have a soundness hole, so a breaking change was made to fix it in 1.15.1.
- snuxoll 10y ago
  Because you like the ability to dynamically link to your dependencies so the entire world doesn't need to be rebuilt just to upgrade libxyz. I love Rust, and I've been trying to get a hobby project written in it - but it really stinks that I can't just rely on my distribution to keep dependencies up-to-date like I can something written in C or C++.
deleted 10y ago
[deleted]
weq 10y ago
So when your cloudbleeding, your atleast doing it as fast as possible, right?? ;) Sure if u write game engines, do it in C/C++. Embedded devices? Probably a good choice. I work at a startup, and we only have a few devs. I share my C# code-base across the client/server/mobile platform and even cross-compile it to a few other lauinages in between. If i need speed, i just extern out to a C/C++ dll i need and get it (never need to). Or integrate a microservice in eralang. C# is just like C++, to write fast code, u need to understand the hardware. Its just C#, the hardware includes the garbage collector.
- Kenji 10y ago
  >Sure if u write game engines, do it in C/C++. Embedded devices? Probably a good choice. Bingo. Those two things are exactly what I do professionally and as a hobby.

by Kenji 10y ago

pjmlp 10y ago

Across how many compilers and operating systems is your code portable without any problems?!

vvanders 10y ago
When written with discipline C++ is very portable. I've worked on codebases that spanned devices with ~8mb of memory to full-blown desktop PC and arches(x86/MIPS/ARM/PPC just to name a few).
- raverbashing 10y ago
  Across devices it seems it is very portable. Now, across compiler vendors and versions it is hard
  - Impossible 10y ago
    Generally speaking when you are targeting that wide of a range of devices you are targeting a wide range of compilers. It requires some discipline but it's far from the hardest thing in the world assuming you are regularly building and testing for all platforms. I'd say that most major C++ applications or libraries compile in Clang, GCC and MSVC without issue and often build for less common targets as well (icc, nvcc for cuda support, etc.) Things definitely get harder when you move to weirder embedded platforms.
    - vvanders 10y ago
      Yup, we targeted GCC, MSVC, plus a few proprietary compilers. As long as you stick to a reasonable set of features(which you should anyway for sanity reasons) it works pretty well. Having a good CI is a must though but it's not nearly as hard as porting an old codebase backwards.
- pjmlp 10y ago
  Writing with discipline is a synonym for writing castrated C++, to avoid touching language features not yet implemented or with slight semantic differences across compilers. One of the things that attracted me to Java was that I finally could write something where I could use 100% of language features and actually use it everywhere. C++17 is around the corner, yet most embedded, mainframe and commercial UNIX vendors are between C++11 and C++14, in the few cases where they already support anything from C++14. Then there are the UB and implementation defined differences across those compilers.
DrBazza 10y ago
It's just a configuration problem - at one job, we had a million line code base compiling with clang, gcc (2 versions, can't recall which), on 2 versions of solaris, 2 versions of linux, and linux 32bit and 64bit, plus windows on VS2010, and 2015, so that makes 18 *nix builds and 2 windows builds, so 20 different C++ builds of one code base. All unit tested, and regression tested. Get your CI system of choice working, e.g. TeamCity, fix your makefiles, and you're good to go.
- pjmlp 10y ago
  Having done C and C++ across UNIX and Windows, during the late 90's throughout mid-2000's, using the OS vendor's compiler tooling, it was a bit more than just configuration. For example, back then aCC wasn't even fully C89 compliant. Of course when one uses the famous trio (gcc, clang, msvc) the world gets simplified a lot.

atemerev 10y ago

There is Rust now. Why stay with C++?

endorphone 10y ago
Comments like this appear on HN with frequency, and they betray a complete detachment from reality. Like what an outsider would think looking at the industry. A very mature language, rapidly evolving, with an enormous volume of well proven libraries and tools, or a cutting edge, barely production level (with a breaking changes language), tiny library new toolset. And you question why someone doesn't just transition? Is that serious?
- vvanders 10y ago
  > barely production level (with a breaking changes language) Oh no you didn't. There's an argument to be made in Rust vs C++ but to my knowledge there hasn't been a breaking change in Rust since 1.0 and there's been a ton of work to keep it that way.
  - steveklabnik 10y ago
    There technically have been some small changes, just like in C++. The key is, as you said, you aren't even sure there were ones. That's how we like to keep it, and that's part of where all that work goes. The rest goes into making sure nothing breaks accidentally :) Trivial example: shortly after 1.15 was released, a new API was found to have a soundness hole, so a breaking change was made to fix it in 1.15.1.
snuxoll 10y ago
Because you like the ability to dynamically link to your dependencies so the entire world doesn't need to be rebuilt just to upgrade libxyz. I love Rust, and I've been trying to get a hobby project written in it - but it really stinks that I can't just rely on my distribution to keep dependencies up-to-date like I can something written in C or C++.

deleted 10y ago

[deleted]

weq 10y ago

So when your cloudbleeding, your atleast doing it as fast as possible, right?? ;) Sure if u write game engines, do it in C/C++. Embedded devices? Probably a good choice. I work at a startup, and we only have a few devs. I share my C# code-base across the client/server/mobile platform and even cross-compile it to a few other lauinages in between. If i need speed, i just extern out to a C/C++ dll i need and get it (never need to). Or integrate a microservice in eralang. C# is just like C++, to write fast code, u need to understand the hardware. Its just C#, the hardware includes the garbage collector.

Kenji 10y ago
>Sure if u write game engines, do it in C/C++. Embedded devices? Probably a good choice. Bingo. Those two things are exactly what I do professionally and as a hobby.