How many people code in C these days, and if so, why?

[nctnico]

Now I'm sure there are fixes for much or all of this, and I'm sure I'll hear an unending stream of them. And I'm sure some of them involve jumping thru a bunch of annoying hoops. But for me it just isn't worth the hassle.

Your problem seems to be being stuck to VS (which is not the best tool to work on code; it is pretty clumsy).  When I need to work on a VS project I load the same project in Eclipse CDT and use VS only to compile.

Funny, I was recently watching a video of a guy who teaches C++, and he's been working for years with one of the biggest game companies (Electronic Arts) and he writes game engines for them. And it sounds like he and his company use only Visual Studio.

That doesn't mean it is a good idea. But if you don't know any better then every screw looks like a nail. Last year I had to make some modifications to the Unreal engine and VS was just not up to the job to take on such a large project and work at a comfortable speed (on a machine with 18GB of memory!). Eclipse to the rescue!

Something was definitely wrong there. Used Unreal and Visual Studio for years and it works perfectly.

Edit: intellisense was probably running in background. Normally when I set up my workstation it's the first thing I disable  It's the reason why we use Visual Assist most of the time.

Probably but Eclipse CDT can do the things Intellisense does with the Unreal engine codebase just fine (after setting the memory limits higher) without needing an extra plugin. 'Whole tomato' which makes 'Visual Assist' does ring a bell from the time I used VS almost daily at one my previous employers.

[bd139]

10k files in VS is a pain in the fucking arse. We're at 30k on one project and it barely works. We have guys using vim and command line tools because it shits the bed (as it's still a damn 32-bit process)

C# or C/C++ ? for our tools coded in C# someone had the great idea to put everything (all the tools) in the same solution. It just kill the IDE. I think it's doing a lot less in C++ because it was never a problem even if the file count is higher.

As for the debugger. Yeah try opening a 30gb minidump, if windows will even create one without barfing  . Oh and then there's the 20 minute wait for it to cache all the sodding symbols so you can get a stack trace from a thread.

There must be a better way. I think a lot of VS users suffer stockholm syndrome.

30gb well yeah it's a lot never seen that.

Was C#. Look down...

As for the debugger. Yeah try opening a 30gb minidump...

I think that is not a "mini-dump", it is a "maxi-dump" 

It is a minidump based on the host machine...



Two socket machine. Maxxed out. NOT a hypervisor

Most people don't get to wrestle shit like this. I wouldn't recommend it 

[maginnovision]

For me... Between VS, eclipse, netbeans I definitely rank them in that order. I only use eclipse because it's a requirement for some projects but I'm used to it so it's not bad but I definitely prefer VS. It's all a matter of opinion though based on individual experiences so it's really not worth arguing about. Supposed to be arguing about C anyway, haha.

[Kosmic]

10k files in VS is a pain in the fucking arse. We're at 30k on one project and it barely works. We have guys using vim and command line tools because it shits the bed (as it's still a damn 32-bit process)

C# or C/C++ ? for our tools coded in C# someone had the great idea to put everything (all the tools) in the same solution. It just kill the IDE. I think it's doing a lot less in C++ because it was never a problem even if the file count is higher.

As for the debugger. Yeah try opening a 30gb minidump, if windows will even create one without barfing  . Oh and then there's the 20 minute wait for it to cache all the sodding symbols so you can get a stack trace from a thread.

There must be a better way. I think a lot of VS users suffer stockholm syndrome.

30gb well yeah it's a lot never seen that.

Was C#. Look down...

As for the debugger. Yeah try opening a 30gb minidump...

I think that is not a "mini-dump", it is a "maxi-dump" 

It is a minidump based on the host machine...



Two socket machine. Maxxed out. NOT a hypervisor

Most people don't get to wrestle shit like this. I wouldn't recommend it 

hmmm the whole database is in RAM ? 

[bd139]

Yes sort of. However this particular scenario was caused by a memory leak and spinlock deadlock (ReaderWriterLockSlim in C# is BUGGY AS HELL which makes a mockery of their "concurrent" data structures). Usually doesn't run that hot. Working set is around 800gb and 30% CPU load.

[Kosmic]

Supposed to be arguing about C anyway, haha.

Back On topic,

I would say that I used C when the project was smaller and when resource efficiency was important. The problem with C (and even more with assembly) is the fact that they don't scale very well. It's possible to create a huge application with C but it's really hard and tricky to keep the control as the application is growing.

On the other side OOP and C++ give you some tools to scale your application but you end up being a bit less performant and efficient.

So for me, it's all about using the right tool for the right job. Personally, I tend to use C on MCU, C++ for big application that need performance and C# when I  don’t really care about performance and I just want to do something quick (90% of what I’m doing at home)

[dietert1]

As far as i understand, object oriented development is good for libraries and APIs (abstraction).
When i have to produce firmware for an embedded project, i rarely arrive at writing a library (e.g. operating system). But i may be using one. So in general it will be C++ nowadays. Though  cpp files and a C++ compiler don't mean object oriented development.

Regards, Dieter

[coppice]

As far as i understand, object oriented development is good for libraries and APIs (abstraction).
When i have to produce firmware for an embedded project, i rarely arrive at writing a library (e.g. operating system). But i may be using one. So in general it will be C++ nowadays. Though  cpp files and a C++ compiler don't mean object oriented development.

Regards, Dieter

C++ is terrible for libraries. If you write a library in C it is trivial to make it callable from pretty much anything. If you write a library in C++ you need to be constrain yourself more or less to writing in C if you want to make it callable from a wide variety of other languages.

[IanB]

On the other side OOP and C++ give you some tools to scale your application but you end up being a bit less performant and efficient.

There have been many comments in this thread about bloat and inefficiency, and why C++ is not suitable for low level hardware. It would take me a while to search back and find them all.

One comment by (I don't remember who) mentioned about non-deterministic behavior, and you don't know when things are going to happen (?), which is absolutely not a property of the C++ language. It doesn't have managed memory like Java or C#, there are no garbage collectors, and you do know exactly when memory will be allocated and de-allocated according to the standard. You have complete control over resources.

I just watched a very interesting presentation about coding for low level hardware in C++, about as close to the metal as you can get. It is worth a watch, as food for thought if nothing else.

[dietert1]

As far as i understand, object oriented development is good for libraries and APIs (abstraction).
When i have to produce firmware for an embedded project, i rarely arrive at writing a library (e.g. operating system). But i may be using one. So in general it will be C++ nowadays. Though  cpp files and a C++ compiler don't mean object oriented development.

Regards, Dieter

C++ is terrible for libraries. If you write a library in C it is trivial to make it callable from pretty much anything. If you write a library in C++ you need to be constrain yourself more or less to writing in C if you want to make it callable from a wide variety of other languages.

I know there are other languages than C and C++. As i wrote before i rarely arrive at writing libraries, but i often use some. I guess that probably applies to most of the contributors here. Using C++ with STL is something very nice in comparison to old fashioned C style. But some won't ever understand.

Regards, Dieter

[nuclearcat]

Here is big article, unfortunately in russian (not sure if google translate can do it's job) https://habr.com/ru/post/347980/
It can be condensed to fact, that they did cooperative efforts to write most efficient code to do some simple task (button and letds) , and they got much more readable C++ with OOP 400 bytes in flash and 72 bytes in stack, VS pure C much less flexible and readable 396 byte in flash and 72 bytes in stack.
Assembly is near identical (no performance difference).

Yes, C++ have many sweet features that is better to avoid on MCU (for example even silly vectors), but if you just use it for OOP and some "safe" features - it is not less efficient than C.

[0db]

Linus Torvalds "Nothing better than C"

[maginnovision]

I'm going to take linus' opinion about as seriously as Stroustrups. They're both too invested in their languages of choice.

[coppice]

I'm going to take linus' opinion about as seriously as Stroustrups. They're both too invested in their languages of choice.

Note that Linus didn't say there was nothing as good as C. He said there was nothing better. When C appeared there were languages like Coral (rather UK centric), BCPL, some variants of Algol, some variants of PL/1, and so on, targeting the same kind of "working close to the metal" style that is so necessary for systems software, and low level embedded software. There were a few proprietary ones from people like DEC, too. They all did a pretty good job. One or two had some very useful things C lacked, such as nested versions of structures, but nothing that made any of them truly stand out. C is the one we are left with in 2020.

[engrguy42]

And while all the fanboys are one-upping each other over the finer points of their chosen language, the C# guy is gettin' shit DONE 

[bd139]

Actually no we just used iPython and scipy.fftpack about 2 days ago and are now slacking on here until our fixed term contract is up while getting the stink eye from the permanent employees writing shit in C# laboriously 

(and there’s LabJackPython for ref)

[engrguy42]

Oh, and a simple raytracer I wrote last year in C++. Can't do that shit in C#.

The best tool for the job...

BTW, who gives a F*** what Linus Torvalds thinks?

[bd139]

https://github.com/lukehoban/LINQ-raytracer/blob/master/LINQRayTracer.cs ?

[engrguy42]

https://github.com/lukehoban/LINQ-raytracer/blob/master/LINQRayTracer.cs ?

And your point is.....

[bd139]

Oh, and a simple raytracer I wrote last year in C++. Can't do that shit in C#.

?

[engrguy42]

Oh, and a simple raytracer I wrote last year in C++. Can't do that shit in C#.

?

Wow. You got me on that one. 

[intmpe]

C is typical for small microcontrollers like the PIC and even the ARM.

Having said that most "good" c compiler vendors will provide libraries to perform functions that would otherwise require a lot of coding - i.e. fractional mathematics and a bunch of other stuff that the microcrontroller does not natively support. They provide libraries to bit bang pins, software rs232, lcd code ... the list goes on and on.

So even if you do buy a C compiler its not a complete pain in the ass like it was in the old days (I personally used to hate the language), but with the libraries I am satisfied enough. I am still pissed that the pricks who wrote if thought it was a good idea to put a ; a the end of every line. The syntax sucks ass and is unnecessary. Even pascal had better syntax but the purists would never accept that. Delpi though has gone open source - it still has a following. There is a guy in Adelaide with an Oberon based compiler and mikroelectronica sell their compilers in C, Basic and Pascal so the environement and choice is still rich. Pascal is still alive and kicking from several sources.

On the other hand if you program using Visual Studio on the PC desktop, you have the choice of C# and VB. Now I have used both and was once also a Quickbasic programmer. Quickbasic was structured basic. VB.net is only notionally related to basic. Sure some of the syntax is there but Visual Studio forces you to write code in an object orientated way so if you were transported from 1985 using the dos basic compiler to todays vb.net you would be completely lost and it would only be vaguely related to basic.

On the other hand it is relatively simple to convert C#.net to VB.net and back again. The syntax is slightly different but Visual Studio forces the same code structure so I have done that many times - either one is usable and I don't consider them to be much different. VB.net used to be the most widely used desktop language in the world but Microsoft stopped publishing the download numbers (probably when they integrated them all together - you can mix vb.net and c# code blocks in a single project) - besides it was probably embarrassing - I mean look what happened to J# .. they had to kill it off. C++ proper is in Visual studio but I would say it is no where near as popular as the other two as it was developed earlier and lacks the same code structure as the .net languages. Of course if you are on linux or the desktop you can use c++ in VS or g++ as a front end to gcc. Basically if you have a favourite language for a chip there is probably a compiler for it.

Ironically for the first time in 20 odd years I have had to recently write code for the PIC using assember for speed.

[Berni]

No raytracing in C#? Here is one then done completely in C# then:
https://github.com/mellinoe/veldrid-raytracer

As a bonus it also translates the C# code into shader scripts to execute on the GPU. But go ahead and compare even the CPU only version for speed.

Yes we know C# is typically not quite as fast as C++, but with some care to optimize things it gets the same sort of ballpark performance. You can't really objectively say if C++ or C# is better. They are good at different things, but they are both powerful languages that can do a lot.

Its the programmer behind the keyboard that determines the performance of the code, the language just gives him the tools to do it.

[SiliconWizard]

https://github.com/lukehoban/LINQ-raytracer/blob/master/LINQRayTracer.cs ?

And your point is.....

What exactly was yours? Guess he just posted that to show it was possible (and of course it is - as long as you have reasonable FP support, I don't see how you could not write a raytracer in almost any language. Heck, I guess you could even write one with pure fixed point too, although that would require some serious thinking.)

"Can't do that shit in C#."

With that formulation, we actually don't know whether this was meant as a general statement (which then is obviously wrong), or simply that YOU can't write a raytracer in C#. Which is completely possible and even a fair point, but then I guess you should maybe express things in a bit clearer way so we know your intent is to talk about what YOU use and why (which is on-topic indeed), rather than make it pass as a general fact.

[engrguy42]

I humbly apologize for making an inaccurate comment. Humbly. It was a terrible mistake. I'm duly ashamed. I now realize that even slightly inaccurate comments have no place on this forum.

Yes, you can use C# for raytracing. I was merely basing it on my experience whereby CUDA (NIVDIA's GPU API) is pretty much reliant on C/C++, and that's what I was using.

But yes, there are exceptions.

My bad. I'm a very very very bad boy.