8 ms·

"C++ in 2018? SURE (You masochist)" I know this is tongue in cheek, but if one is doing anything related to real time graphics programming I'm not aware of an

by fsloth 8y ago

"C++ in 2018? SURE (You masochist)" I know this is tongue in cheek, but if one is doing anything related to real time graphics programming I'm not aware of any good alternatives.

colordrops 8y ago
WebGL? I do get that hardcore games are more suited to compiled code non garbage collected though.
- fsloth 8y ago
  I suppose WebGL is okay for shader prototyping, for example using Shadertoy [0]. However, you can use it only within the context of a browser framework. That is still not the optimum deployment nor development platform for a variety of scenarios. The original joke though, was that C++ was for masochists. I'm not sure developing a web application is any less painfull... [0] https://www.shadertoy.com/ https://www.shadertoy.com/
  - pjmlp 8y ago
    I used to think like that specially given how poorly many demos run on mobile devices that don't have any issues dealing with ES 3.x games. However the demos one gets to see from production work at Siggraph are quite impressive when running on proper desktop cards.
lloeki 8y ago
> I'm not aware of any good alternatives. Vulkan/C? Metal/ObjC†/C? From C libs you can probably get to bindings to other languages like D, Haskell, Rust, Go†. † depending on your definition of "real time" (soft vs hard), both kernel-wise and GC-wise.
- fsloth 8y ago
  "Vulkan/C? Metal/ObjC†/C? " Vulkan and C are a sane option. Although, with C and linear algebra one starts to miss C++ operator overloading and existing libraries like eigen [0] or glm[1] with their graphics and computational geometry targeting API:s really soon. If one deploys only to OS X/IOS, Metal and ObjC, sure. "From C libs you can probably get to bindings to other languages like D, Haskell, Rust, Go†." With the added complexity of the binding layer, and sub-par collection of existing examples and resources. With C++ both OpenGL and Vulkan have excellent didactic material, including: https://vulkan-tutorial.com/ https://vulkan-tutorial.com/ https://learnopengl.com/ https://learnopengl.com/ [0] http://eigen.tuxfamily.org/index.php?title=Main_Page http://eigen.tuxfamily.org/index.php?title=Main_Page [1] https://glm.g-truc.net/0.9.9/index.html https://glm.g-truc.net/0.9.9/index.html
  - wtetzner 8y ago
    For Rust, there's [1] for OpenGL and [2] for Vulkan. I don't know about Vulkano, but Glium is much more pleasant to use than the raw OpenGL API. [1] https://github.com/glium/glium https://github.com/glium/glium [2] https://github.com/vulkano-rs/vulkano https://github.com/vulkano-rs/vulkano
    - fsloth 8y ago
      The sentence in the top of the readme for the github repo is: "Glium is no longer actively developed by its original author." Which links to: https://users.rust-lang.org/t/glium-post-mortem/7063 https://users.rust-lang.org/t/glium-post-mortem/7063 Which pretty much states that Glium is not a really long term viable solution at the moment. I've toyed with cool open source libraries for 20 years. I'm too old to get caught up with something new and shiny only to find out it wasn't structurally sound. That is why C++ is a good choice. It has huge traction. The ecosystem is basically bullet proof. It has lot of practical libraries that are so well used that while not bullet proof themselves, it is likely they will stay alive as long as you need to compile your code.
      - wtetzner 8y ago
        Immediately after that, it says: "That said, PRs are still welcome and maintenance is continued by the surrounding community." > Which pretty much states that Glium is not a really long term viable solution at the moment. Except what that post-mortem is _really_ saying is that OpenGL is not a long-term viable solution. The whole post-mortem is about the fact that OpenGL drivers are so buggy that you can't write portable code to target it.
pjmlp 8y ago
C# is slowly getting there thanks to Unity efforts with HPC# and Microsoft's improvements on SIMD support, stack allocation and slices. Then on the browser you are stuck with GLSL 3.0 shaders, or any JS library that generates them on the fly. But yeah for the layer that actually talks to the metal, it is still going to be C++ for many years, specially thanks to the ongoing language improvements since C++11 revision. Metal and DirectX shaders are C++ dialects, and Google is driving the effort of making HLSL having first class support on Vulkan as well. Oh, and NVidia has designed they latest GPGPUs specifically to run C++ code optimally.
- golergka 8y ago
  I'm a fulltime Unity lead developer and I love C# as a business logic (or game logic) language, but it becomes quite ugly for hot code that is perfomance-critical. Once you get thousands of objects that you have to process every frame, you have to throw the usual C# object-oriented style and things like Linq (and I'm a fan of Linq!) out of the window and write code that reads like C. And when you get to object pools, well, that's practically the same thing as writing your own allocator (only instead of allocating arbitrary memory, you allocate objects). Seriously, for this kind of tasks there's nothing better than C/C++ - and I write this as someone who is actively AFRAID of power of C++ and uses less powerful tools whenever and wherever possible (because I don't want all that power to shoot in my own leg).
  - fsloth 8y ago
    "things like Linq" It's really easy to accidentally create a simple Linq query that underneath turns into O(N^2) and suddenly the production application crawls to a halt. Actually happened.
    - golergka 8y ago
      That's why you should know where to write code optimized for perfomance and where to write code optimized for readability. It's the latter 95% of the time.
jdc 8y ago
Depending on what libraries you need, Nim and D seem like decent alternatives.
- fsloth 8y ago
  "Nim ... seem like decent alternatives." Note that I specified real time graphics development as the focus area here for C++. While I don't want to get into platform wars, on that front Windows is a really strong contender, for various ecological reasons. Nim does not seem to be well supported on windows [0]. The typical cyphers for poor windows support in open source projects, that seem to hold true for Nim, are that: a) No mention of MSVC support as a compiler option b) Installer does not install the complete required language runtime, and the end user must hunt the missing DLL:s by themselves. c) Need to manually configure various paths While these are not a technical blocks, they imply strongly that Windows support is not one of the key priorities for the project. "Here you go, have a nice language - and oops, good luck debugging our runtime". Whereas in industrial quality setups that have lot of users you can pretty much expect it to work out of the box. [0] https://nim-lang.org/install_windows.html https://nim-lang.org/install_windows.html
  - dom96 8y ago
    Wow. We really need to fix our install page if people are reaching this conclusion. Hey, Nim dev here. I can assure you that Windows is incredibly well supported by Nim. > a) No mention of MSVC support as a compiler option https://nim-lang.org/faq.html#how-do-i-use-a-different-c-compiler-than-the-default-one https://nim-lang.org/faq.html#how-do-i-use-a-different-c-com... > b) Installer does not install the complete required language runtime, and the end user must hunt the missing DLL:s by themselves. The DLLs are all included in the .zip file. Even if they weren't, you do not need to "hunt" them, there is a link for them at the bottom of the download page. > Need to manually configure various paths You don't. It's easy to think that when you only read the headings though :( Here is an excerpt from under the heading: > The zip file includes a simple application called finish.exe that can attempt to add the first directory into your PATH. This tool also checks for the presence of a C compiler and can install MingW, the GNU C compiler collection for Windows. The installation isn't perfect, we did have an installer in the past but it proved more trouble than it was worth (NSIS is very archaic and INNO is a PITA). Despite this, you won't find many languages with Windows support that is as good as Nim's.
deleted 8y ago
[deleted]
eahman16 8y ago
There's absolutely nothing wrong with C++ if you use a small subset of it, like for example Carmack did in Doom 3. The only problem that arises with C++ is when people want to use EVERYTHING in the language, because if it exists, it has to be in my project, right?
- TimMurnaghan 8y ago
  If you're using a small subset why on earth is it the right language? I had the misfortune to try to mentor a new quant who felt they had to write C++ "for speed" . But refused to use the STL as they were going to use a subset. So they wrote Fortran-like C++, array as the only data structure, bad lookup algorithms and leaked like a sieve. Things are in the language for a reason - if you've got the issue then you use the feature. I hardly ever recommend C++ these days as it's not worth the slower dev time. There are a few cases where run-time really does trump everything else and it's still appropriate. In that case the code will be templated to within an inch of its life, because that's how to write real C++.
  - bsenftner 8y ago
    Let's just be honest: today's dev's can't write in C/C++ because they don't have the formal training. They are primarily script language devs who can't work at the low level required by C/C++. The formally educated programmers who were taught low level large-scale systems programming are too few to create the programmer farms you all work it (which I left for scientific software development, where the devs are older and we all work in C/C++ or assembly.)
    - ahartmetz 8y ago
      You don't need formal education to understand why some things are the way they are in C++, you need to understand how a CPU works. A small amount of assembly programming is sufficient for that - it is actually very simple to understand, just hard to write nontrivial programs...
    - atomic-hedge 8y ago
Razengan 8y ago
Swift or Objective-C with Metal, so far so good. Console-quality graphics on phones and tablets.
tylerhou 8y ago
I think he means "C++ in 2018" to build a standard webapp, which definitely is masochistic because you can be much more productive on e.g. Rails. Just like how using PHP to build a real-time graphics engine is also probably masochistic.
- bsenftner 8y ago
  People who don't know say these things. Try writing web applications in C/C++, it's a deluxe development situation. Where do you think web browsers come from? Everyone afraid of C/C++ are shooting themselves in the feet.
  - criddell 8y ago
    When I started to learn Rails, the intro was a Twitter-like messaging app. Somebody that knows what they are doing could turn that out in an hour. Is the situation in C++ frameworks very far off?
    - bsenftner 8y ago
      The same. Using Restbed, a C++ embedded web server framework, a twitter messaging app is about an hour of work.
- 52-6F-62 8y ago
  It's getting better. I've been starting to dig into Crow to see if it might be a worthwhile option as a C++ web app framework: https://github.com/ipkn/crow https://github.com/ipkn/crow https://github.com/jolks/crow-template https://github.com/jolks/crow-template (Relies on libboost https://www.boost.org/ https://www.boost.org/) Seriously, it makes putting together a simple API a breeze. I haven't had the chance to try anything more complex yet.
esistgut 8y ago
There is a growing Rust game development community [0] but of course C++ still has the edge. [0] https://www.reddit.com/r/rust_gamedev/ https://www.reddit.com/r/rust_gamedev/
sjwright 8y ago
Jai? (Obviously not yet a good alternative, but worth being aware of in case it perfectly suits your project...) https://inductive.no/jai/ https://inductive.no/jai/
- fsloth 8y ago
  Any language with a FFI (i.e. ~all of them) can be used to interface with DLL:s with a C interface. That was really not the point...
bsenftner 8y ago
I write integrated servers with the web server, the database server, a video server, and a facial recognition application all bundled together in C++. The application screams: try 1/16th the memory footprint of a traditional multi-server Internet application, it is 4000% faster, and can run on a $100 Intel Compute Stick. Try this in any other language...
- Jyaif 8y ago
  I'm doing the same thing, and I've got a couple questions: How do you handle redundancy, e.g. if your Intel Compute Stick goes offline for any reason? How do you handle crashes of your applications?
- mwcampbell 8y ago
  What C++ web server library/framework do you use? Or did you roll your own? For the database, are you using SQLite or something else?
  - bsenftner 8y ago
    Restbed is the C++ framework, and yes, we use SQlite.
- gm-conspiracy 8y ago
  Is this for an art installation or does it have a more business-oriented purpose?
  - bsenftner 8y ago
    Government contracts; software is used by covert agencies.

by fsloth 8y ago

"C++ in 2018? SURE (You masochist)" I know this is tongue in cheek, but if one is doing anything related to real time graphics programming I'm not aware of any good alternatives.

colordrops 8y ago

WebGL? I do get that hardcore games are more suited to compiled code non garbage collected though.

fsloth 8y ago
I suppose WebGL is okay for shader prototyping, for example using Shadertoy [0]. However, you can use it only within the context of a browser framework. That is still not the optimum deployment nor development platform for a variety of scenarios. The original joke though, was that C++ was for masochists. I'm not sure developing a web application is any less painfull... [0] https://www.shadertoy.com/ https://www.shadertoy.com/
- pjmlp 8y ago
  I used to think like that specially given how poorly many demos run on mobile devices that don't have any issues dealing with ES 3.x games. However the demos one gets to see from production work at Siggraph are quite impressive when running on proper desktop cards.

lloeki 8y ago

> I'm not aware of any good alternatives. Vulkan/C? Metal/ObjC†/C? From C libs you can probably get to bindings to other languages like D, Haskell, Rust, Go†. † depending on your definition of "real time" (soft vs hard), both kernel-wise and GC-wise.

fsloth 8y ago
"Vulkan/C? Metal/ObjC†/C? " Vulkan and C are a sane option. Although, with C and linear algebra one starts to miss C++ operator overloading and existing libraries like eigen [0] or glm[1] with their graphics and computational geometry targeting API:s really soon. If one deploys only to OS X/IOS, Metal and ObjC, sure. "From C libs you can probably get to bindings to other languages like D, Haskell, Rust, Go†." With the added complexity of the binding layer, and sub-par collection of existing examples and resources. With C++ both OpenGL and Vulkan have excellent didactic material, including: https://vulkan-tutorial.com/ https://vulkan-tutorial.com/ https://learnopengl.com/ https://learnopengl.com/ [0] http://eigen.tuxfamily.org/index.php?title=Main_Page http://eigen.tuxfamily.org/index.php?title=Main_Page [1] https://glm.g-truc.net/0.9.9/index.html https://glm.g-truc.net/0.9.9/index.html
- wtetzner 8y ago
  For Rust, there's [1] for OpenGL and [2] for Vulkan. I don't know about Vulkano, but Glium is much more pleasant to use than the raw OpenGL API. [1] https://github.com/glium/glium https://github.com/glium/glium [2] https://github.com/vulkano-rs/vulkano https://github.com/vulkano-rs/vulkano
  - fsloth 8y ago
    The sentence in the top of the readme for the github repo is: "Glium is no longer actively developed by its original author." Which links to: https://users.rust-lang.org/t/glium-post-mortem/7063 https://users.rust-lang.org/t/glium-post-mortem/7063 Which pretty much states that Glium is not a really long term viable solution at the moment. I've toyed with cool open source libraries for 20 years. I'm too old to get caught up with something new and shiny only to find out it wasn't structurally sound. That is why C++ is a good choice. It has huge traction. The ecosystem is basically bullet proof. It has lot of practical libraries that are so well used that while not bullet proof themselves, it is likely they will stay alive as long as you need to compile your code.
    - wtetzner 8y ago
      Immediately after that, it says: "That said, PRs are still welcome and maintenance is continued by the surrounding community." > Which pretty much states that Glium is not a really long term viable solution at the moment. Except what that post-mortem is _really_ saying is that OpenGL is not a long-term viable solution. The whole post-mortem is about the fact that OpenGL drivers are so buggy that you can't write portable code to target it.

pjmlp 8y ago

C# is slowly getting there thanks to Unity efforts with HPC# and Microsoft's improvements on SIMD support, stack allocation and slices. Then on the browser you are stuck with GLSL 3.0 shaders, or any JS library that generates them on the fly. But yeah for the layer that actually talks to the metal, it is still going to be C++ for many years, specially thanks to the ongoing language improvements since C++11 revision. Metal and DirectX shaders are C++ dialects, and Google is driving the effort of making HLSL having first class support on Vulkan as well. Oh, and NVidia has designed they latest GPGPUs specifically to run C++ code optimally.

golergka 8y ago
I'm a fulltime Unity lead developer and I love C# as a business logic (or game logic) language, but it becomes quite ugly for hot code that is perfomance-critical. Once you get thousands of objects that you have to process every frame, you have to throw the usual C# object-oriented style and things like Linq (and I'm a fan of Linq!) out of the window and write code that reads like C. And when you get to object pools, well, that's practically the same thing as writing your own allocator (only instead of allocating arbitrary memory, you allocate objects). Seriously, for this kind of tasks there's nothing better than C/C++ - and I write this as someone who is actively AFRAID of power of C++ and uses less powerful tools whenever and wherever possible (because I don't want all that power to shoot in my own leg).
- fsloth 8y ago
  "things like Linq" It's really easy to accidentally create a simple Linq query that underneath turns into O(N^2) and suddenly the production application crawls to a halt. Actually happened.
  - golergka 8y ago
    That's why you should know where to write code optimized for perfomance and where to write code optimized for readability. It's the latter 95% of the time.

jdc 8y ago

Depending on what libraries you need, Nim and D seem like decent alternatives.

fsloth 8y ago
"Nim ... seem like decent alternatives." Note that I specified real time graphics development as the focus area here for C++. While I don't want to get into platform wars, on that front Windows is a really strong contender, for various ecological reasons. Nim does not seem to be well supported on windows [0]. The typical cyphers for poor windows support in open source projects, that seem to hold true for Nim, are that: a) No mention of MSVC support as a compiler option b) Installer does not install the complete required language runtime, and the end user must hunt the missing DLL:s by themselves. c) Need to manually configure various paths While these are not a technical blocks, they imply strongly that Windows support is not one of the key priorities for the project. "Here you go, have a nice language - and oops, good luck debugging our runtime". Whereas in industrial quality setups that have lot of users you can pretty much expect it to work out of the box. [0] https://nim-lang.org/install_windows.html https://nim-lang.org/install_windows.html
- dom96 8y ago
  Wow. We really need to fix our install page if people are reaching this conclusion. Hey, Nim dev here. I can assure you that Windows is incredibly well supported by Nim. > a) No mention of MSVC support as a compiler option https://nim-lang.org/faq.html#how-do-i-use-a-different-c-compiler-than-the-default-one https://nim-lang.org/faq.html#how-do-i-use-a-different-c-com... > b) Installer does not install the complete required language runtime, and the end user must hunt the missing DLL:s by themselves. The DLLs are all included in the .zip file. Even if they weren't, you do not need to "hunt" them, there is a link for them at the bottom of the download page. > Need to manually configure various paths You don't. It's easy to think that when you only read the headings though :( Here is an excerpt from under the heading: > The zip file includes a simple application called finish.exe that can attempt to add the first directory into your PATH. This tool also checks for the presence of a C compiler and can install MingW, the GNU C compiler collection for Windows. The installation isn't perfect, we did have an installer in the past but it proved more trouble than it was worth (NSIS is very archaic and INNO is a PITA). Despite this, you won't find many languages with Windows support that is as good as Nim's.

deleted 8y ago

[deleted]

eahman16 8y ago

There's absolutely nothing wrong with C++ if you use a small subset of it, like for example Carmack did in Doom 3. The only problem that arises with C++ is when people want to use EVERYTHING in the language, because if it exists, it has to be in my project, right?

TimMurnaghan 8y ago
If you're using a small subset why on earth is it the right language? I had the misfortune to try to mentor a new quant who felt they had to write C++ "for speed" . But refused to use the STL as they were going to use a subset. So they wrote Fortran-like C++, array as the only data structure, bad lookup algorithms and leaked like a sieve. Things are in the language for a reason - if you've got the issue then you use the feature. I hardly ever recommend C++ these days as it's not worth the slower dev time. There are a few cases where run-time really does trump everything else and it's still appropriate. In that case the code will be templated to within an inch of its life, because that's how to write real C++.
- bsenftner 8y ago
  Let's just be honest: today's dev's can't write in C/C++ because they don't have the formal training. They are primarily script language devs who can't work at the low level required by C/C++. The formally educated programmers who were taught low level large-scale systems programming are too few to create the programmer farms you all work it (which I left for scientific software development, where the devs are older and we all work in C/C++ or assembly.)
  - ahartmetz 8y ago
    You don't need formal education to understand why some things are the way they are in C++, you need to understand how a CPU works. A small amount of assembly programming is sufficient for that - it is actually very simple to understand, just hard to write nontrivial programs...
  - atomic-hedge 8y ago

Razengan 8y ago

Swift or Objective-C with Metal, so far so good. Console-quality graphics on phones and tablets.

tylerhou 8y ago

I think he means "C++ in 2018" to build a standard webapp, which definitely is masochistic because you can be much more productive on e.g. Rails. Just like how using PHP to build a real-time graphics engine is also probably masochistic.

bsenftner 8y ago
People who don't know say these things. Try writing web applications in C/C++, it's a deluxe development situation. Where do you think web browsers come from? Everyone afraid of C/C++ are shooting themselves in the feet.
- criddell 8y ago
  When I started to learn Rails, the intro was a Twitter-like messaging app. Somebody that knows what they are doing could turn that out in an hour. Is the situation in C++ frameworks very far off?
  - bsenftner 8y ago
    The same. Using Restbed, a C++ embedded web server framework, a twitter messaging app is about an hour of work.
52-6F-62 8y ago
It's getting better. I've been starting to dig into Crow to see if it might be a worthwhile option as a C++ web app framework: https://github.com/ipkn/crow https://github.com/ipkn/crow https://github.com/jolks/crow-template https://github.com/jolks/crow-template (Relies on libboost https://www.boost.org/ https://www.boost.org/) Seriously, it makes putting together a simple API a breeze. I haven't had the chance to try anything more complex yet.

esistgut 8y ago

There is a growing Rust game development community [0] but of course C++ still has the edge. [0] https://www.reddit.com/r/rust_gamedev/ https://www.reddit.com/r/rust_gamedev/

sjwright 8y ago

Jai? (Obviously not yet a good alternative, but worth being aware of in case it perfectly suits your project...) https://inductive.no/jai/ https://inductive.no/jai/

fsloth 8y ago
Any language with a FFI (i.e. ~all of them) can be used to interface with DLL:s with a C interface. That was really not the point...

bsenftner 8y ago

I write integrated servers with the web server, the database server, a video server, and a facial recognition application all bundled together in C++. The application screams: try 1/16th the memory footprint of a traditional multi-server Internet application, it is 4000% faster, and can run on a $100 Intel Compute Stick. Try this in any other language...

Jyaif 8y ago
I'm doing the same thing, and I've got a couple questions: How do you handle redundancy, e.g. if your Intel Compute Stick goes offline for any reason? How do you handle crashes of your applications?
mwcampbell 8y ago
What C++ web server library/framework do you use? Or did you roll your own? For the database, are you using SQLite or something else?
- bsenftner 8y ago
  Restbed is the C++ framework, and yes, we use SQlite.
gm-conspiracy 8y ago
Is this for an art installation or does it have a more business-oriented purpose?
- bsenftner 8y ago
  Government contracts; software is used by covert agencies.