C Top Programming Language For 2016, Finds IEEE's Study (ieee.org)

IEEE Spectrum, a highly regarded magazine edited by the Institute of Electrical and Electronics Engineers, has released its annual programming languages list, sharing with the world how several languages fared against each other. To assess the languages the publication says it worked with a data journalist and looked into 10 online sources -- including social chatter, open-source code production, and job postings. The publication has rated C as the top programming language this year, followed by Java, Python, C++, and R. From their article:After two years in second place, C has finally edged out Java for the top spot. Staying in the top five, Python has swapped places with C++ to take the No. 3 position, and C# has fallen out of the top five to be replaced with R. R is following its momentum from previous years, as part of a positive trend in general for modern big-data languages that Diakopoulos analyses in more detail here. Google and Apple are also making their presence felt, with Google's Go just beating out Apple's Swift for inclusion in the Top Ten. Still, Swift's rise is impressive, as it's jumped five positions to 11th place since last year, when it first entered the rankings. Several other languages also debuted last year, a marked difference from this year, with no new languages entering the rankings.The publication has explained in detail the different metrics it uses to evaluate a language.

Comments

As a C programmer

[OrangeTide]

I find the results shocking. As most people I deal with struggle to write moderately complex C programs.

Also the use of the word "best" is highly subjective.

Re:As a C programmer

[BarbaraHudson]

Maybe you're dealing with the wrong people? Or they're used to dealing with simple tasks.

Re:As a C programmer

[al0ha]

Nowhere in TFA does it say best - is says Most Popular, and that is not subjective.

Re:As a C programmer

[gmack]

People struggle with pretty much every language, it's just that the bugs are different in each.

Re:As a C programmer

[w1z7ard]

People struggle with pretty much every language, it's just that the bugs are different in each.

Sure, but I would argue some languages are dominating strategies over others. There are bugs which simply don't exist in some languages but do in others. Like null pointers or references do not exist in OCaml (instead, you must use the optional type explicitly).

Re:As a C programmer

[w1z7ard]

C is still the most portable language in the universe. The only real language that works on all phones, in particuarl (ok, C++ does too but C is where you get all the amazing well written, optimized libraries you'd want on most devices).

Re:As a C programmer

[jellomizer]

First this is from the IEEE.

Many Software Developers are not affiliated with the IEEE as they may have followed the Computer Science discipline vs the Computer Engineering discipline.

So for the people IEEE would survey would be Engineers and companies with a Engineering discipline.

Now this Engineering discipline is about a make it once and make it right mentality. Meaning there is a preference towards more lower level coding, allowing detailed and measured controls over each line of code, at the expense of maintainability and programming time. C and Java is good for that type of coding.

However the Computer Science discipline is about making it maintainable, reusable, and fast deployment. This could cause less reliable programs with harder to calculate measures on performance. So languages such as Python and .NET have more appeal.

These different disciplines have cause many of flame war, as each other camp looks at the other guys code and says it is pure crap, because they focused so much on X and not on Y where Y is far more important and needed in real life.

The problem with C isn't that it is a hard language. It is a very simple language. But because it does things at a lower level there is often a lot of extra work (Memory Management and Pointers) that makes it difficult to get up to speed because it requires a lot more attention to detail on how each part works. While these other language you focus more on the problem being solved, even though your solution while solves the problem could be done so much better.

Re:As a C programmer

[phantomfive]

Also worth mentioning that not only does C run on the most different processors, C is the most portable between languages.....that is, if you write a library in C, it can be used in basically every other language.

Re:As a C programmer

[OrangeTide]

The title of the post was "C Best Programming Language For 2016, Finds IEEE's Study", but it has been edited to "C Top Programming Language For 2016, Finds IEEE's Study"

such is life getting first post.

Re:As a C programmer

[OrangeTide]

I guess it depends on what you consider to be portable. Is it write one and run anywhere, or does it count if you can modify the program to suit the environment you are porting to?

Re:As a C programmer

[jellomizer]

C in terms of its primitives are portable. However if you are making a Phone App, you are not going to have a lot of luck with making a cross compiled app with a UI that will work well with iOS and Android. Because a lot of the code requires calling libraries and OS particular functions. Sure you can do it with bunch of #ifdef
but it is nearly like writing a program over again for each system. You would be better off with a good source control.

Re:As a C programmer

[JustNiz]

I don't think they even teach actual programming skills in CS degrees any more.
As far as I can see Its now all web-based everything, and they what they are creating skilled is package/module integrators and project managers.

Re:As a C programmer

[Tablizer]

People struggle with pretty much every language, it's just that the bugs are different in each.

It's usually not the language that throws me for a loop (no pun intended), but the screwy poorly-documented API's and Web UI stacks (DOM, CSS, etc.), which seem to break whenever a new browser version comes out and have to be tested on gazillion devices and browser brands. Time to rethink web UI (non) standards: it's a fscking time sink. [Insert the rest of my usual UI rant here.]

Re:As a C programmer

[fahrbot-bot]

People struggle with pretty much every language, it's just that the bugs are different in each.

They're not "bugs" but features. Like languages, some are more popular than others. :-)

Re:As a C programmer

[goose-incarnated]

C is still the most portable language in the universe. The only real language that works on all phones, in particuarl (ok, C++ does too but C is where you get all the amazing well written, optimized libraries you'd want on most devices).

It's not only the portability that matters, it's the software reuse. You write your nifty image recognition library in Java and that's pretty much the only language that can use it. Same for Python, C++, etc. Do a locate \.so | wc -l on your system - chances are that the libraries *not* written in C are a rounding error. Pick just about anything remotely useful - chances are it'd more more useful if written in C, because at the very least you can open the executable using dlopen/dlsym and invoke main() with the correct arguments.

If you stick to a C-only subset of C++ you can write your library in C++, but at that point why bother with C++ anyway?

Re:As a C programmer

[gweihir]

Well, C is "best" in the sense that it does not stand in your way. If you know what you are doing, that is very nice.
It does not help you much either, and for the semi-competent and incompetent masses of "programmers", that is a real problem.

Personally, I went back to C as main language a while ago after trying a number of alternatives. The only change is that I use Python as glue-code these days and withe the core-workers as C-implemented Python classes.

Looks like I have to have a go at R some time these days though.

Re:As a C programmer

[gweihir]

You are certainly right about that. The nice thing about C is that the really incompetent will not get their code to run at all and weed themselves out that way. In contrast, a bad Java coder (for example) will usually get things to work, but very badly so.

Re:As a C programmer

[goose-incarnated]

Meaning there is a preference towards more lower level coding, allowing detailed and measured controls over each line of code, at the expense of maintainability and programming time.

I sorta agree with the rest, but this statement is dead wrong - if you want it reusable you write it in C. Anything written in Python/.Net/etc is only usable from a miniscule subset of languages, while the libzip.so on your system is reusable from everything. This is why the practical/engineering types write it in C - if they chose Python they'll have to rewrite it should they ever decide to use some other language. When they write it in C it need never be rewritten.

The problem with the software engineering/programming people is that they don't care about reusability, and it shows; once the project is done they move on to the next one. The people producing C libraries (like myself) are happily reusing the libraries we wrote two decades ago without having to rewrite them to use in another language. The people producing Python or C++ libraries abandon those libraries when they move to a new language - they don't have a choice.

Re:As a C programmer

[Anonymous Coward]

You need to learn how to read.

Re:As a C programmer

[Anonymous Coward]

If a Real(tm) programming language is too hard, my 11 year old daughter can teach you Scratch.

Re:As a C programmer

[Anonymous Coward]

Because you can hide the wicked complexity that high level C++ can efficiently represent behind your cute fwuffy C-style function calls?

Re:As a C programmer

[Anonymous Coward]

C in terms of its primitives are portable. However if you are making a Phone App, you are not going to have a lot of luck with making a cross compiled app with a UI that will work well with iOS and Android. Because a lot of the code requires calling libraries and OS particular functions. Sure you can do it with bunch of #ifdef
but it is nearly like writing a program over again for each system. You would be better off with a good source control.

What?

All you have to do is 'mkdir fuckphone iphone dickphone wasdphone xwindows winders' etc. And write your makefile so it links in the right platform bindings. #ifdef is the totally wrong way to handle this.

All the different platform link modules have to do is conform to a common API. How is that different to any and every other programming language?

Also the more difficult consideration, is that unless you want people to think you ride the short bus to work, you need to redesign the UI from scratch for each platform anyway, as they have totally different UI conventions, and you'll seem like an asylum dweller if you try to deliver an Android app on iOS or vice-versa.

Re:As a C programmer

[Anonymous Coward]

'If you stick to a C-only subset of C++'

And why would you need to do this?

Re:As a C programmer

[phantomfive]

software engineering/programming people is that they don't care about reusability, and it shows; once the project is done they move on to the next one. The people producing C libraries (like myself) are happily reusing the libraries we wrote two decades ago without having to rewrite them to use in another language.

That's quite a statement! And maybe true....

Re:As a C programmer

[phantomfive]

Looks like I have to have a go at R some time these days though.

What about R is attracting you?

Re:As a C programmer

[beelsebob]

No, as a pretty experienced C programmer too, it's *really* hard to find people who are even vaguely competent C programmers. You only need to set most people a completely trivial problem with vague exposure to pointers/memory management and they'll trip themselves up. "Implement memmov" usually is enough to catch out 95% of people.

Re:As a C programmer

[Anonymous Coward]

The same logic works for many other languages.

Re:As a C programmer

[phantomfive]

The same logic works for many other languages

Which languages?

Re:As a C programmer

[Anonymous Coward]

Ironic considering Android and iOS are essentially asylums.

Re: As a C programmer

[Anonymous Coward]

Yep. What this article tells me is that
good programmers have always known
that c (and maybe c++) is where
real work gets accomplished,
and those that got addicted to
interpreted crap are starting to
realize they were wasting their
time on hard to solve problems
that they 'discovered' were
actually difficult to solve with
an interpreted language.

Then again, I may be completely
full of crap as I have only
have 40+ years of experience.

Re: As a C programmer

[Anonymous Coward]

Assembly

Re: As a C programmer

[Anonymous Coward]

And clearly still use a 40 character wide terminal for everything.

Re:As a C programmer

[Anonymous Coward]

And maybe false too. Many languages incur significant overhead when calling "native" libraries and it can often be faster (and more portable even) to avoid that overhead. BTW what libraries are you using from 20 years ago that now bear any resemblance to back then - even libc has somewhat grown up...

Re:As a C programmer

[Anonymous Coward]

Have they rewritten the Java runtime in Java yet? Last time I looked, it was written in C.

Re:As a C programmer

[Anonymous Coward]

such is life getting first post.

Not much good when you don't read TFA first. One of the most annoying things about /.

Re:As a C programmer

[Anonymous Coward]

What is this "memmov" of which you speak? I've written a lot of useful C programs in my admittedly amateur style, and they do wonderful things. You don't need to have a PhD in C to write useful stuff.

Re: As a C programmer

[loufoque]

I see you do not understand what a mobile app is.
There is no real logic in the app, it's just UI for a web service. The UI is target-specific, in particular because it needs to respect platform-specific idioms and UX paradigms, and the UI is 100% of the app.

You're coming from the world of real applications which do real work and for which the UI is just a trivial interface driving a library. This is not what mobile is.

Re:As a C programmer

[Anonymous Coward]

memmov is a memcpy that specifically handles overlapping source & dest spans.

Re:As a C programmer

[Anonymous Coward]

I recall from my C class that the language only has 34 keywords and that one of its advantages is that it doesn't come with unnecessary baggage. As an embedded engineer, I appreciate this and also have never had to use a string package, or library, in my professional career.

Re:As a C programmer

[beelsebob]

memmov is a function with this signature:

void memmov(void *dst, const void *src, size_t count);

Which copies count bytes from src to dst, and correctly deals with the case where src and dst overlap each other.

Re: As a C programmer

[thinkwaitfast]

Assembly is in no way portable. It's processor specific.

Re:As a C programmer

[Jamu]

Not sure I could do that off the top of my head. I'd look up the greater-than and less-than operators and how they work with pointers. Not even sure if that's the right approach.

Re:As a C programmer

[thinkwaitfast]

And why would you need to do this?

misra?

Re:As a C programmer

[Anonymous Coward]

so, it's like memcpy?

Re: As a C programmer

[Anonymous Coward]

Assembly would need to be MUCH rewritten for different processors.
But yeah, it makes as much sense as saying "C runs on most processors" -- your C source code doesn't run, the compiled binary executable is what runs.

Re:As a C programmer

[OrangeTide]

I did read the article. The part of my post about "best" was purely about the /. title and not the article, that comment was not even the main component of my first post. (I'm assuming you are capable of recognizing structure)

Are you trolling me or are you actually a twit?

Re:As a C programmer

[jellomizer]

You are confusing the language and the OS feature. That libzip.so will need to be recompiled for every OS once compiled it isn't c code it is a compiled library. I could make a library in any other compiled language say FORTRAN.

If distribution your c code and the new system doesn't have the library then you get into dependacy hell.

Now C is considered portable because you can compile it on a different system. But that Python program I make I can run on Linux or Windows without any changes. Just as long as the interpreter is installed.

Re:As a C programmer

[swillden]

If you stick to a C-only subset of C++ you can write your library in C++, but at that point why bother with C++ anyway?

Or you could write your library in C++ but put it behind a C interface. Then you can use all of the expressive power of C++ internally, and provide an API that can be called from any language. And it will still be very close to as portable as if it were written in plain C, because we now have decent C++ compilers on very nearly every platform.

Re:As a C programmer

[Anonymous Coward]

> is says Most Popular, and that is not subjective.

they are measuring 'popularity' by the number of empty desk where nothing is getting written (job adverts) and by the number of people who _don't_ know how to use it (searches on Google, questions on Twitter, tutorials being read).

Re:As a C programmer

[superdana]

memcpy doesn't handle overlapping regions.

Re:As a C programmer

[superdana]

I think the point of the question is that it's actually spelled "memmove".

Re:As a C programmer

[dottrap]

so, it's like memcpy?

Yes, like memcpy, except memmove (there should be an 'e' at the end for the C89 ANSI compliant name) allows memory to overlap. memcpy can be optimized to be faster since it doesn't have this constraint.

Re:As a C programmer

[Xyrus]

The problem with the software engineering/programming people is that they don't care about reusability, and it shows; once the project is done they move on to the next one.

That's a bullshit statement and you know it. The people who maintain projects like Spring, Hadoop, etc. don't give a shit about re-usability? Yeah, ok.

The people producing C libraries (like myself) are happily reusing the libraries we wrote two decades ago without having to rewrite them to use in another language.

And I still happily reuse Java libraries I wrote from over a decade ago without having to worry about what particular machine they're going to be run on, what OS changes have been made, etc. I haven't been doing much python programming lately, but I'm pretty sure I can run the same scripts I wrote 10 years ago and still have them work just fine today.

In addition, there is absolutely nothing special about C. C is a language, nothing more. The compiler can produce binary lib files that can be linked in to other code, but that isn't limited in any way to just C.

Use the appropriate tool for the job, and avoid treating everything like nail just because you only know how to use a hammer.

Re:As a C programmer

[BarbaraHudson]

And the reason for that is that too many so-called "programmers" are shit because they haven't cut their teeth on a real programming language. They need something that holds their hands at every step, isolates them as much as possible from the underlying hardware and OS, and really don't have a clue as to how computers work.

Reading a few O'Reilly books might cut it for web monkeys, but then again, anything you can learn from an O'Reilly book can also be learned just as well by someone in India or eastern Europe. Real programmers can re-implement chunks of the standard c library with their own mods because they know what's going on. And they learn the hard way that, as your mom told you, if you pick it up, put it back when you're finished with it - "it" being memory. No need for so-called smart pointers. If you're depending on automatic memory management, you don't really know what your program is doing at any one point. Just look at the non-deterministic Java gc (though there are ways to fix that).

Re:As a C programmer

[PurpleAlien]

You can't compare arbitrary pointers in this case. You would have to cast them to integers (e.g., unsigned long) first and do the comparison there. Basically, the workflow is a) cast source and destination to long integers, b) compare if they overlap (dst - src >= len) and if so do a forward copy, otherwise a backward copy. The reason for not using a backward copy in all cases has to do with a speed penalty (for preserving alignment).

Re: As a C programmer

[Anonymous Coward]

VT100 terminal maybe?

Re:As a C programmer

[PurpleAlien]

That should of course be "compare if they overlap (dst - src >= len) and if not do a forward copy, otherwise a backward copy"

Re:As a C programmer

[arth1]

Yes, like memcpy, except memmove (there should be an 'e' at the end for the C89 ANSI compliant name) allows memory to overlap. memcpy can be optimized to be faster since it doesn't have this constraint.

And memmove() can call memcpy() if it determines there is no overlap, so there's not a lot of benefit to memcpy() for other than tiny copies that can be inlined.

Optimizing becomes more challenging when doing copies from unpinned threads on NUMA systems. You want to avoid reallocating a big block between CPUs, while at the same time avoiding big locks.

Re:As a C programmer

[Anonymous Coward]

Decent software engineers (like myself) evaluate what is important for a given project and make decisions based on that. If you think that every project needs to be portable/re-usable then think again. No one wants an "engineer" who can't prioritize and spends time on things that don't matter.

Re:As a C programmer

[Pseudonym]

I recall from my C class that the language only has 34 keywords and that one of its advantages is that it doesn't come with unnecessary baggage.

What that typically means in practice is that for anything beyond a certain scale, you need to write the unnecessary baggage yourself. And believe me, you will.

As an embedded engineer, I appreciate this and also have never had to use a string package, or library, in my professional career.

Some embedded devices do have complex UIs which might find it useful. I've never written the firmware for a modern digital TV or DVR might need to do some of that. But yes, most firmware (and I have worked on some) doesn't need to manipulate strings.

Re:As a C programmer

[arth1]

Do a locate \.so | wc -l on your system - chances are that the libraries *not* written in C are a rounding error. Pick just about anything remotely useful - chances are it'd more more useful if written in C, because at the very least you can open the executable using dlopen/dlsym and invoke main() with the correct arguments.

Well, personally, I find the fortran written fast fourier tranform (fft) libraries rather useful...
To call from C, even :)

I'm sure there's way to create good C versions too, but the librarary sources might need a lot of macros, and leave a lot more to the mercy of compiler optimizations.

Re:As a C programmer

[Pseudonym]

(ok, C++ does too but C is where you get all the amazing well written, optimized libraries you'd want on most devices).

You have clearly never had to support on very many third-party C libraries. The standard open source ones that have been around for decades (e.g. zlib, Berkeley DB) are indeed well-written and high-quality, but they are not the common case.

Re:As a C programmer

[Pseudonym]

Have they rewritten the Java runtime in Java yet?

Yes.

Last time I looked, it was written in C.

Not all of it. The original Sun class loader has been written in Java since 1.0.

Re:As a C programmer

[Curate]

Firstly, you can't safely cast pointers to unsigned long. Unsigned long isn't guaranteed to be big enough to hold a pointer value. Secondly, (dst - src >= len) is not even close to the correct condition for testing that the buffers overlap. Thirdly, the reason for not using a backward copy in all cases is that it corrupts the output buffer in 1 of the 2 overlapping cases. Those three huge errors aside, you make some good points.

Re:As a C programmer

[Anonymous Coward]

He's probably referring to its increasing popularity as described in the summary of the article.

Re: As a C programmer

[Pseudonym]

I see you do not understand what a mobile app is. There is no real logic in the app, it's just UI for a web service.

That's true in many cases, but it's far from the whole story. Well-written mobile apps try to minimise network communication because that can drain battery life much faster than a modest amount of computation.

Even badly-written mobile apps, like the Facebook client, do DSP on the device for things like its spyware voice recognition feature.

Re: As a C programmer

[warm_warmer]

Personally, I like Ruby.

In all seriousness, arguments along the lines of "very few people are competent C programmers" in my experience can be generalized to "very few people are competent <insert any programming language here> programmers". Yes, C is a more challenging language because it requires very strict discipline to do well, but 8+ years in the industry has shown me that good coders are the exception.

Re:As a C programmer

[Darinbob]

Personally, I am chuffed to finally be ahead of the curve! Time to grow my hipster Unix beard.

Re:As a C programmer

[warm_warmer]

Also worth mentioning that not only does C run on the most different processors, C is the most portable between languages.....that is, if you write a library in C, it can be used in basically every other language.

There can actually be surprising gotchas regarding portability. Good examples:

• - dereferencing pointers to multi-byte values can cause errors on some processors when the pointer address isn't word-aligned, but will work just fine on others
• - you can't make any assumptions around native word sizes without risking portability issues. This means being very explicit with your types (including <stdint.h> and being super careful about explicitly casting while bit shifting
• - ... you get the point

That's definitely not to say that you *can't* write portable code, just that C libraries may not be as plug-and-play as you'd like, often in surprising and dangerous ways.

Re:As a C programmer

[phantomfive]

- dereferencing pointers to multi-byte values can cause errors on some processors when the pointer address isn't word-aligned, but will work just fine on others

When was the last time you saw someone do that?

Re:As a C programmer

[mysidia]

"Implement memmov"? WTH would you do that? There's a reason that memmov() is a Library call.

It's rough to implement such subroutines accurately; even if you know what you are doing.

You don't need to be capable of doing low-level coding on a whim to be a competent C programmer.

Sounds like you're expecting the average C programmer to be a low-levell 3-Star or 4-Star pointers expert, and your standards may be unreasonably high, there.

Re:As a C programmer

[Darinbob]

If they're pointers to bytes then you can compare them directly. Alignment is the same forwards or backwards. If the regions overlap then sometimes you need a forward copy but sometimes a backwards copy! The direction depends upon where they overlap!

If you copy 0-100 over to locations 50-150, then you have to copy backwards, copy the 100 over first, then 99, etc. But if you're copying 50-150 over to 0-100, then you have to copy forwards, starting with 50 first.

That's the point in the interview where I suggest they can draw this on the whiteboard instead of trying to do it in their heads.

Re:As a C programmer

[Darinbob]

At which point someone should step forward and say that it's "memmove", not "memmov", at least in standard C. But extra credit if someone mentions "bcopy".

Re:As a C programmer

[warm_warmer]

Within the last year, working with a team writing libraries that needed to work on PC, ARM, and PIC architectures (that specific problem happened only on the PIC24 and PIC32 MCUs).

Re:As a C programmer

[phantomfive]

That's annoying. Were you doing some kind of pointer arithmetic or something?

Re:As a C programmer

[lgw]

There is no standard-required way to compare arbitrary pointers.

There is no standard-required integer type into which you can cast an arbitrary pointer. (intptr_t etc are technically optional).

It's architecture-specific whether comparing pointers as signed or unsigned is the correct thing to do.

There is no such thing as portable C because of crap like this, only "mostly portable C, eh, good enough".

Re:As a C programmer

[warm_warmer]

Unless you mean the actual dereference, like this:

uint32_t foo(uint8_t *byte_array) {
return &(uint32_t *)byte_array;
}
... because the above code will cause problems if the address of byte_array isn't word-aligned on some (like PIC32 and PIC16) MCUs.

Re:As a C programmer

[Darinbob]

C++ has some different rules about types, which some people think are better than the C rules.

Personally, I'd take the subset of C++ that still includes basic inheritable classes/structs, name spaces, etc. But avoid exceptions (hard to make this efficient a lot of times), avoid templates that are larger than a line or two (avoid the gawdawful code bloat it can lead to), etc. The "better C than C" version of C++ before the goal of every C++ standards committee became how new features they could cram in.

Re:As a C programmer

[warm_warmer]

Yes, we were parsing packet data, so every time we'd need to do something like get some value (like the length) out of the packet data, we'd need to ensure we weren't making byte alignment assumptions (in addition to endianness assumptions...).

Re:As a C programmer

[Anonymous Coward]

A C programmer will need to deal with problems like memmove every day. If this is too hard for too low level for you, then pick another language.

Re:As a C programmer

[Darinbob]

You can do both. Have the small straight forward language without lots of pitfalls, and at the same time make the code maintainable and reusable. However, avoid the "fast deployment", that means "rapid prototyping" which means speed matters more than quality and the customer ends up with mocked up prototype. Rapid prototyping is not part of the "science" of computer science.

And basically "computer science" has almost nothing to do with programming anyway, it's a broad interdisciplinary field that covers both mathematics and engineering.

Re: As a C programmer

[Dutch Gun]

I'd say that "good programmers" can and do learn a variety of languages, and will use the most appropriate one for the task at hand. There's nothing wrong with getting down to the metal when requirements call for it, but doing so is foolish for many types of projects where top performance isn't a requirement. I'm a game developer, so I live and breathe C++ of course. But I write my tools in C#, and our game's scripting language is in Lua.

Why C# for tools? Because it has reflection, and a fantastic library for all sorts of serialization, networking, and UI support.

Why Lua for game scripts? Because then we can recompile and reload our game scripts on the fly, without even stopping the game.

Which programming language is "best"? It's a stupid question to start with, because the only reasonable answer is "it depends on what you're looking for in a language".

Re:As a C programmer

[Darinbob]

If they chose Python 2.7 then they'll have to rewrite it for Python 3...

Re:As a C programmer

[Anonymous Coward]

I've never worked on a system with a UI. I have worked on both TVs and DVRs (a decade ago). The UI was left up to the customer (ie, manufacturer) as we just supplied a basic OS with APIs to all the hardware gizmos like dma/memory control, display lists and network decode. At the time there were a few commercial UIs that customers could buy and attach relatively painlessly or they could roll their own.

Actually, the same thing went for the OS. Even though we provided a perfectly good one (they're not hard to write), what we really did is provided hooks to the hardware access a typical system would require (it used to be called the HAL since we had custom hardware SOC built from IP libraries). I think we eventually ended up demoing, or at least promising that we could, boot nine different commercial OS's.

Re:As a C programmer

[Anonymous Coward]

>If you stick to a C-only subset of C++ you can write your library in C++, but at that point why bother with C++ anyway?

class MyAwesomeStatefulIMageManipLib {
void TonsOfAwesomeSauce(); ...
}; //The above uses all teh nice bits of classes and state etc.

extern "C" {
void* makeAwesomeLibHandle();
void invokveTonsOfAwesomeSauce(void *self) { ((MyAwesomeStatefulIMageManipLib*)self)->TonsOfAwesomeSauce(); }
} //The above gives a flat, c-style ABI to specific calls in the library. C++ code can use teh object, everyone else gets an ugly, handle-based way to use it.

Re:As a C programmer

[Pseudonym]

The people producing Python or C++ libraries abandon those libraries when they move to a new language - they don't have a choice.

That's certainly true of Python. Hell, you practically need to abandon your Python libraries when you move to the next version of Python.

But it's not true of C++. Binding well-written C++ libraries to other languages sometimes takes a little work (you do need to write a glue layer if there's a serious impedance mismatch, but then you need to do that with C too), but it does work and largely works quite well. Python, Java, Rust, Go, Haskell, O'Caml... you name it, you can The only languages which don't work well with C++ libraries are old languages like Tcl.

Look at LLVM as an instructive example. It's a large complex beast written in heavy C++, but there are bindings for every language you'd ever want to seriously write a compiler in.

Re:As a C programmer

[phantomfive]

Yeah, there are definitely things that you have to be aware of when doing cross-platform C.

I'm sure you already know it, but some compilers (like GCC) have __attribute__(packed) that can sometimes help in some situations like you were in.......

Re:As a C programmer

[phantomfive]

I think that code might cause problems on an intel pc too, not sure

Re:As a C programmer

[beelsebob]

You would need to implement memmove because, believe it or not, there are people out there who implement the libraries that memmove is implemented in. There are also people out there who implement libraries that need to know how to at *very* least do basic pointer operations, and how to work with raw memory.

As I said - it's very hard to find genuinely good C programmers - most ignore how very very simple functions are implemented.

For reference, a naïve (acceptable in an interview) implementation of memmove can be achieved in 4 lines of code. This isn't rocket science I'm asking about.

Re:As a C programmer

[Anonymous Coward]

If you look at the link about the metrics, you'll see that the ranking isn't confined to IEEE members, but draws from things like Google, Stack Overflow, etc., Only one metric, the IEEE Xplore library, is directly IEEE related.

Re: As a C programmer

[Anonymous Coward]

You don't see API as an UI? That is horrible.

Re: As a C programmer

[Anonymous Coward]

Still it is Java where I reuse code of others the most Simply because maven makes it so simple.

Re:As a C programmer

[johnw]

memcpy doesn't necessarily handle overlapping regions.

I've known at least one implementation (Norcroft C for the Acorn Archimedes) where the two were in fact the same function. memmov guarantees not to corrupt your data due to an overlap, memcpy does not guarantee that it will corrupt your data in that case.

The only reason to have a separate memcpy is it might be possible to make it faster by skipping the checks. The ARM's block copying capabilities were so blindingly fast by the standards of the day there was no need to implement a separate memcpy.

This ability meant that the GUI gave you solid window drags when almost everything else still had you dragging an outline.

Re:As a C programmer

[johnw]

You would need to implement memmove because, believe it or not, there are people out there who implement the libraries that memmove is implemented in.

But if you're the person implementing the standard library for a compiler then you're not constrained in the same way as someone asked to re-implement it in portable C. As various people have said, it's very hard when you can't rely on, for instance, a cast from a pointer to a long int working correctly.

If you're actually implementing the standard library function, you're not even constrained to writing it in C at all. It might well be done in raw assembler in order to make use of the maximum number of available registers.

Re:As a C programmer

[goose-incarnated]

The people producing C libraries (like myself) are happily reusing the libraries we wrote two decades ago without having to rewrite them to use in another language.

And I still happily reuse Java libraries I wrote from over a decade ago

You missed the point - if your library is in C, it can be used from just about every language. Your java code is reusable only from Java, or will you now claim that those libraries from over a decade ago are useful to you when you move to another language?

Re:As a C programmer

[goose-incarnated]

You are confusing the language and the OS feature. That libzip.so will need to be recompiled for every OS once compiled it isn't c code it is a compiled library.

At least you'll have the option - Your Java/.Net/Python/Haskell/Ruby/Javascript library can't be used from a different language. Even on the same OS, stuff written in Java can only be reused by Java. Stuff written in C can be reused by everything.

I could make a library in any other compiled language say FORTRAN.

I'll give you this - Fortran is still in high use for a good reason - but you can't make a library in Java, Python, etc.

If distribution your c code and the new system doesn't have the library then you get into dependacy hell.

Now C is considered portable because you can compile it on a different system. But that Python program I make I can run on Linux or Windows without any changes. Just as long as the interpreter is installed.

My point was not portability, but reuse - sure that Python library can run everywhere, but it can only be used from Python. That same library written in C will compile on different platforms too, and can be used from Python as well as other languages.

Re:As a C programmer

[goose-incarnated]

Not sure I could do that off the top of my head. I'd look up the greater-than and less-than operators and how they work with pointers. Not even sure if that's the right approach.

If you aren't worried about performance simply copy the block to a temporary spot before copying it to the destination.

Re: As a C programmer

[Anonymous Coward]

You pick C as a counter example to people wasting time on resolving the same problem over and over again? A huge amount of time in C is spent re-implementing variations on common patterns. I chose not to use C for some code precisely because I want to avoid resolving the same problems, and instead want to focus my time on the parts that are actually difficult and critical. I work with codes that run for hours to days at a time, and the critical bits get implemented in some combination of C, assembly, or OpenCL. But when 95+% of the code consumes only a couple seconds of cpu time out of days of total running, in which case I'll take whatever language is easiest to implement that code in, even if there is an order of magnitude performance hit. That is usually not C, as I worry about pointers and passing around error codes when trying to do onetime validation and format conversions on data that changes format frequently.

Re:As a C programmer

[byrtolet]

Reading a few O'Reilly books might cut it for web monkeys, but then again, anything you can learn from an O'Reilly book can also be learned just as well by someone in India or eastern Europe. Real programmers can re-implement chunks of the standard c library with their own mods because they know what's going on.

Are you implying that there are no "real" programmers in eastern Europe or in India?

Re:As a C programmer

[Anonymous Coward]

You are certainly right about that. The nice thing about C is that the really incompetent will not get their code to run at all and weed themselves out that way.

You might be surprised by the amount of code I've seen over the years in C that included bugs related to, or blatant disregard for, memory bounds, yet end up still working most of the time by dumb luck.

In contrast, a bad Java coder (for example) will usually get things to work, but very badly so.

I've also come across plenty of people that have no problem understanding memory and pointers, but are horrible at algorithm choice, documentation, security, and other important aspects of "good" code. Those people would make the same mistakes in either language. Understanding the basics of C enough to get the code to run is a very low bar, and doesn't weed much out in the end.

Re:As a C programmer

[Anonymous Coward]

Anything written in Python/.Net/etc is only usable from a miniscule subset of languages, while the libzip.so on your system is reusable from everything.

That depends heavily on what you are writing... like every thing else about what programming language is the "best." If you're writing some system code or numeric code, then probably sticking to C is a safe bet. But it is still not universal. OpenCL code can be called from a variety of languages including C. A variety of interpreted languages are very easy to interface with C in both directions (C library in interpreted language, or using interpreted language in C), some times with fewer than 5 lines of code to glue the two together. Plus, the big glaring hole in your statement, is there are a lot of languages that can compile to a library, with some fields C not even being the most common (I've worked in ones where Fortran libraries were far more common, and still callable from C like any other compiled library).

And that is just for lower level stuff. If you're writing higher level management, parsing or conversion code, then you don't need a compiled library where a shell interface will work fine. It isn't universal of course, but for many uses cases you have no problem calling a python command by just using the command line interface, which works fine from C.

The people producing Python or C++ libraries abandon those libraries when they move to a new language - they don't have a choice.

I've had no problems calling Fortran libraries I wrote 20 years ago from C and Python. I also have no problem calling some Perl utility scripts from C or Python that I wrote almost 20 years ago.

Re: As a C programmer

[murdocj]

Sounds like you don't have the appropriate libraries available. I worked for years in an environment with C and it was extremely productive. Never felt like I was "resolving the same problems" because the first time I solved it, I spent some time thinking about how to make the solution reusable.

Re:As a C programmer

[Anonymous Coward]

Even on the same OS, stuff written in Java can only be reused by Java

No. If you, for example, compile Object Pascal for the JVM you can go ahead and use Java libraries. As another Free Pascal example, you can also turn on the Objective-Pascal mode to interface with Objective-C libraries.

Re:As a C programmer

[angel'o'sphere]

The problem is: competent programmers believe that memmov() or memcoy() are trivial.
But they arent. I bet 90% of all programmers who consider themselves 'competent' did their first memmov() implementation wrong. And because they learned from that, they are now more competent.
I find it disgusting, that they don't remeber their own mistakes (and path of learning) and look down on others who probably only have less experience.

I for my part had my first implementation only right because I was used to the Apple ][ monitor and the build in dump and move commands (and their small problems).

If I had not had that experience I likely had looked at an inteviewer dumb folded and thought to my self "what an idiotic question is that? Moving memory is obviously trivial!" and had made the same mistakes you complain about.

Many C programmers working in embedded niche areas avoid pointers like the plague, and "memory management" is absolutely non existing, as they (try to) do everything with static preallocated memory. (E.g the automatic car driving software I was involved in as continious integration and test engineer is an multithreaded executable of about 500MB size, running on an ARM SoC with 8MB (IIRC) Ram, written in C++. It does not use dynamic allocated memory at all. And no smart pointers or something, it does not even _have_ a heap)

So even after 30 years of experience, they easy make simple mistakes you frown about, because they never really used those features in their daily life.

I find it really anoying that so many 'competent' C programmers don't know such stuff.

Re:As a C programmer

[angel'o'sphere]

I doubt you can write in 4 lines of C a memmov() function that works correctly, when source and target area are overlapping.

Re: As a C programmer

[fferreres]

Same applies to written English. In the past many people didn't need to write at all. Today, due to SMS and social media, written communication has skyrocketed. However, and in spite of "the horror" it's useful to them.

Same with programming. Many people can change their lives a bit by even learning basic programming. The good programmers will observe this as a surprise, but the reality is that it is expected ANDNKT A BAD THING. Especially if those with bad writing skills are rejected from journalistic positions and those with basic programming skill are not hired to do complex stuff only the best (or the proficient) can do.

Re: As a C programmer

[fferreres]

But you don't work in what he works on, which seems Machine Learning or 3D rendering. He didn't speak for others but for cases like his.

Re:As a C programmer

[angel'o'sphere]

because at the very least you can open the executable using dlopen/dlsym and invoke main() with the correct arguments.
That would crash your program on basically all platforms I have woked on.
main() is not the entry point for a C program. The entry point is a vendor/compiler specific library function, __main() or __init() or whatever, which is needed to set up the 'virtual machine' the C implememtation/compiler is realizing. After setting up the environment, e.g. initializing the stack and heap pointers/registers the initialization routine calls the programmer defined main().

Re: As a C programmer

[fferreres]

You should be less ignorant and recognize that while you where still learning to lay stones the Indian where inventing positional notation, and they also have some of the brightest mathematicians of all times, including geniuses of the scale of Gauss or Newton. Second, you should see companies like Facebook that built empires out of sloppy code in things like PHP. More importantly, if the task requires memory management, anybody can learn it and like anything else, 90% won't do it well. No news.

Re:As a C programmer

[angel'o'sphere]

Your Java/.Net/Python/Haskell/Ruby/Javascript library can't be used from a different language. Even on the same OS, stuff written in Java can only be reused by Java.
Sorry, you know nothing about programming.

First of all, to make statement to your favour: you can write a tiny C wrapper for every Language you mention to make it callable from any other you mention. And those wrappers usually can be generated automatically with tools.

Secondly: Java integrates via the scripting API basically into any language you mentioned, sometimes via specialized form like JPython or JRuby, JavaScript and Java can call each other everywhere where thy run together, e.g. in a browser, or in a scriptable Java Application.

Thirdly: all problems can be overcome easily by using interprocess communication or crafting a true remote interface.

I guess to have a hardore combined Phython and Java interpreter where Python and Java run in the same combined VM calling each other is just a finger excercise. Would a competent Phython implementor who knows JNI probably take half a day. And with my lack of knowledge of the Python internals I would probabl need lots of googleing and stackoverflow and 2 days or so.

I already did a CAD system in 1993-1987 that included a JVM as scripting engine and C++ code and Java was calling each other quite nicely.

The problem with C dinosaurs is: they did not notice the world moved on.

Re:As a C programmer

[goose-incarnated]

Your Java/.Net/Python/Haskell/Ruby/Javascript library can't be used from a different language. Even on the same OS, stuff written in Java can only be reused by Java. Sorry, you know nothing about programming.

First of all, to make statement to your favour: you can write a tiny C wrapper for every Language you mention to make it callable from any other you mention.

That's funny - in practice (on my system) I see all Java libraries only used by Java programs. Same with Python, etc. The C libraries, right now, are used by everything. The Java programs use the C libraries. The Python programs use the C libraries. The Ruby programs use the C libraries. And this is right now.

So, yes, sure you can write wrappers around your library, but in practice it's hardly ever done, and with good reason.

The problem with C dinosaurs is: they did not notice the world moved on.

Well, we couldn't move ahead to the next fad like everyone else (you, perhaps?) because someone has to keep the world running ;-)

Re: As a C programmer

[Anonymous Coward]

Not just what you're looking for in a language, but what the people around you know, what your legacy is, what compatibility is like, the likely future of the language and so on.

Programming is rarely done is isolation, we don't often get an empty repository and a free reign.
Not everyone picks up new languages as quickly, production systems don't always get the budget (time and money) that they really need to keep clean.
A good programmer, a really good programmer is pragmatic enough to work in the real world, and to take the victories he or she can.

Re:As a C programmer

[serviscope_minor]

Spoken like a man who doesn't remember the 80s or early 90s.

Re:As a C programmer

[jellomizer]

You are still confusing the OS Feature with the language and not considering the language type.
Python/Haskell/Ruby/Javascript are interpreted languages. There is a OS Particular and compiled program that reads the code and performs actions based on parsing out the text. .NET/Java Compiles into byte code than a particular program executes the bytecode as it is more efficient than trying to parse the real text.
C/C++/FORTRAN.... Are Compiled. There is a program (like GCC) that will interpret the text and convert it into Machine code

These libraries are often compiled in C just because it is a popular language for compiled code. However it doesn't have to be. There are other IPC processes in the OS that we can choose to communicate with other programs so you C code can talk to a Python Program or include your favorite java library as well. As well most of the languages will allow you to go the other way as well.

However it is rather poor form to mix languages (I am of the computer science discipline), I even shy away from including standard linux libraries in a python app, because it makes your code base much more difficult to maintain having to deal with multiple compilers and complex builds and difficult to trace problems, as well harder to distribute.

But to clarify my original point about reusability it was more about the programming discipline of trying to keep your functions and methods more generic and flexible so you don't have a lot of similar functions with minor tweaks. And this isn't a rib against the language it is just the Computer Engineering programming methodology will put value in generic code but not at the expense of performance. While the Computer Science methodology will be more willing to tradeoff performance for less rewriting code in the future. These are tradeoffs that we have to choose to make, they are not necessarily better or worse but people who follow a particular discipline have formed their habits and will default to what they know. Sure with my Computer Science Discipline will have to break the rule and make a particular function for only one job because it needs to run fast because I see it is a bottleneck. And yes the Computer Engineers will make generic functions as they know it will be needed over and over again other wise they will be spending too much time coding the same stuff.

Re:As a C programmer

[Anonymous Coward]

Strictly speaking you are right because C was designed to be 'usable' on all kinds of hardwares (e.g. char is not necessarily 8bit, segmented pointers, ...).

In practice, this is not a concern since nobody cares anymore about the portability for systems with 'strange' memory handling.

That being said, the standard C headers provide all the types needed to implement pointer arithmetic in a portable way: size_t, ptrdiff_t, intptr_t, uintptr_t.

The fact that they may not exist on some hypothetical architectures is irrelevant. It's like saying that explosion engines should not be used in cars because they would not work on the moon since there is no oxygen there.

Anyways, I have two critics:

The first is not about the language but about how the applications handle integer types. STOP DEFINING YOUR OWN INTEGER TYPES! The C99 include file should provide everything you will ever need. C99 is 17 years old so there are no excuses for not using it. If you really have to use an obsolete compiler then redeclare your own version of the stdint.h types in a custom include file.

The second is more fundamental. This is about size_t being a unsigned integer while ptrdiff_t is a signed integer. That often requires to mix signed and unsigned integers in the same expression which adds another level of complexity. My feeling is that the C standard libraries would have been more consistent if most functions using size_t had been using a signed integer type instead (e.g. intptr_t or the non-standard ssize_t). Of course, that was not done like that because that would imply that the maximal size of an object would be half of the whole memory (e.g. 32K on a 64K system which was not practical). That would be less of a problem on modern 64bits systems.

Re:As a C programmer

[serviscope_minor]

It's not only the portability that matters, it's the software reuse. You write your nifty image recognition library in Java and that's pretty much the only language that can use it.

Funny you should choose image recognition: that's one of the areas dominated by C++. Even in the frameworks where it does not appear so (Caffe, Torch, TensorFlow), the back end is all in C++, and the front end is in a scripting language.

MATLAB makes a small showing, too.

Another interesting one is ImageJ (very popular in scientific imaging, especially biology) which is Java of course. Naturally, one can link in C++ code via the JNI if you want to extend it with a native module. And of course if you're prepared to put in the effort, you can invoke a JVM from the other side and use it's features. Not worth it however.

Yes, by the way I am a computer vision engineer and no one does it in C.

If you stick to a C-only subset of C++ you can write your library in C++, but at that point why bother with C++ anyway?

Not entirely true. You only need to stick to the C subset in the interface. libstdc++ is very good and you're very unlikely to bump into trouble with the runtime these days.

Re:As a C programmer

[steve90]

I remember the solid window drags on the Archimedes. That was a fantastic computer for its time. You could run a very powerful desktop publishing application called Impressions off two floppies and I think 1MB of memory (no hard drive on the model I had). It also had an awesome version of Elite.

Re:As a C programmer

[johnw]

I doubt you can write in 4 lines of C a memmov() function that works correctly, when source and target area are overlapping.

#include <stdlib.h>
void memmov(void *dst, const void *src, size_t count) {
        memmove(dst, src, count);
}

How did I do?

Disclaimer - it's years since I did any serious C programming.

Re:As a C programmer

[gweihir]

It seems to be pretty much a big standard now, hence it will not be going away any time soon. And I do have the occasional statistical problem that would benefit from something like R. (I had an R tutorial a long time ago, so I have some idea about what it can do.)

Re:As a C programmer

[gweihir]

I do. You just do not realize how bad some "programmers" are these days.

Re:As a C programmer

[gweihir]

You underestimate how bad the worst "programmers" are these days.

Re:As a C programmer

[johnw]

I bet 90% of all programmers who consider themselves 'competent' did their first memmov() implementation wrong.

I'd agree with you. However, having now thought about it a bit more (and trying to drag my detailed knowledge of C back from hither regions of my brain), I'm tempted to suspect that it's not even possible to implement a robust and correct version of memmove() without having a special relationship with the compiler. In other words, it needs to be done by the implementation. You can't (in general) compare the two pointers which are passed in unless you have extra knowledge of the particular implementation on which you are running.

My best idea for a portable - horribly inefficient - implementation so far would be to malloc a temporary buffer, copy the data from the source to the temporary buffer, then copy it again to the destination. I'm open to better suggestions.

Re:As a C programmer

[Anonymous Coward]

You missed the point - if your library is in C, it can be used from just about every language.

You can achieve the same thing with Pascal. This is nothing special about C in particular.

Re:As a C programmer

[locofungus]

It's not that hard, although to write a strictly conforming version requires you to be allowed to write the if statement on one line.

Simple four line version (not strictly conforming as it depends on pointer lessthan comparison) (with C99 you can put the definition of i into the for() and then #include <stdint.h> and cast to intptr_t)

size_t i;
for(i=0; i<n; i++)
    (unsigned char*)dest>(const unsigned char*)src?(*((unsigned char*)dest+n-1-i) = *((const unsigned char*)src+n-1-i)):(*((unsigned char*)dest+i) = *((const unsigned char*)src+i));
return dest;

Somewhat more contrived (and inefficient) version that only depends on pointer equality comparison.

size_t i, rev=0;
for(i=0; i<n; i++) rev = rev || ((const unsigned char*)src+i) == (const unsigned char*)dest;
for(i=0; i<n; i++) rev ? (*((unsigned char*)dest+n-1-i) = *((const unsigned char*)src+n-1-i)):(*((unsigned char*)dest+i) = *((const unsigned char*)src+i));
return dest;

Of course, this is a very contrived problem and I generally disapprove of this sort of use of ?:.

Re:As a C programmer

[Anonymous Coward]

"Implement memmov"? WTH would you do that? There's a reason that memmov() is a Library call.

Well, last time I did that it was because I didn't have a libc for the architecture I was developing for.
Just compiling a memmove that was written for a different architecture doesn't really cut it.
Most functions declared in string.h are trivial to implement if you just want the basic functionality and could often be written as a one-liner in C.
The reason most of the exists as library calls at all is because many processors have ways to do those functions faster if care is taken such as using specialized memory copy instructions or starting with a conditional single byte copy to be able to do the rest of the memmove with bus aligned memory accesses.

Note that the optimizations are not only depending on the CPU but also the way it is wired to the bus or whatever other peripherals are available.
Some platforms have DMA functions capable of doing a memory to memory copy without CPU involvement.

Re:As a C programmer

[joboss]

What is memmov? I don't understand how you can truly move memory. You can copy memory and you can change a pointer. You can also zero out the previous memory but that seems silly. You could also swap but again that is silly since it would be called swap. If it's copy, you just need to do nothing if src == dest, and if dest > src && dest src + len I guess copy it backwards. Maybe you can also optimise it for alignment with a bit to do head + tail than biggest word size to fill the middle.

Re:As a C programmer

[Anonymous Coward]

Of course there is a thing like portable C. You just can't use the features with undefined behavior.
You can use the features with compiler defined behavior if you provide a suitable ifdef.

As for the specific example (dst - src >= len):
Comparing against a dst - len operation would require an intptr_t that as you pointed out is optional.
dst - src requires a ptrdiff_t type that isn't optional in C99 and can be found in stddef.h

It might seem like it would cause an incorrect copy on a platform with 16 bit addresses and you want to do an overlapping copy where the pointers are more than 32k apart.
This is however not a problem since that would require more than the entire available memory range to be used which is impossible to begin with.

Re:As a C programmer

[jeremyp]

If they're pointers to bytes then you can compare them directly.

No you can't.

You can't guarantee that two arbitrary pointers are comparable. Think of segmented architectures, for example.

Re:As a C programmer

[TheRaven64]

As for the specific example (dst - src >= len): Comparing against a dst - len operation would require an intptr_t that as you pointed out is optional. dst - src requires a ptrdiff_t type that isn't optional in C99 and can be found in stddef.h

This is correct, however it is undefined behaviour to compare two pointers to different objects. In particular, C is intended to support environments where objects are allocated as segments and can be relocated in a linear address space (I work on one such architecture and wrote the C compiler for it, though we actually do support this idiom because so much real-world code depends on it). In such an environment (which includes the version of C that targets the CLR), there is no guarantee that the ordering of two objects in memory will be stable.

Re:As a C programmer

[TheRaven64]

No one should mention bcopy, or any other function that uses source, destination argument order.

Re:As a C programmer

[TheRaven64]

Using C++ without templates is missing the point. One of the things I miss the most when writing C is the lack of efficient generic data structures. C equivalents of things like std::list, std::dequeue, and std::unordered_map all require lots of macros that cast things through void* (and therefore avoid any possibility of compile-time errors) and typically extra layers of indirection which hurt performance from d-cache misses more than templates will hurt from increased i-cache usage.

Apple's CoreFoundation is probably the nicest-designed C library providing core features, but it is a lot harder to work with than its Objective-C equivalent for similar performance and less efficient than a C++ version (though with stronger binary compatibility guarantees).

Re:As a C programmer

[TheRaven64]

If you're using zlib as an example of high-quality code, then I'd hate to see what you consider low-quality code. It has a horrible security record, poor layering, and badly designed interfaces. About the only thing it has going for it is performance.

Re:As a C programmer

[TheRaven64]

Look at LLVM as an instructive example. It's a large complex beast written in heavy C++, but there are bindings for every language you'd ever want to seriously write a compiler in.

Not a great counterexample - The LLVM C bindings are maintained by hand and all of the other bindings are machine-generated from the C bindings.

Re:As a C programmer

[fozzy1015]

You can compare pointer addresses in C. The signature uses void pointers so that any pointer type can be passed. In the function they are cast as a byte type so the arithmetic works(the third argument is the length in bytes). e.g.

void memmove(void * d, void * s, int len)
{
   char * src = (char*) s;
   char * dst = (char*) d;

   if (src < dst)
      for(int i = 0; i < len; ++i)
         dst[i] = src[i];
   else if (src > dst)
      while(len--)
         dst[len] = src[len];
}

Re: As a C programmer

[RavenLrD20k]

Yeah, he really needs to get up with the times.  80 Character punch cards are wh
ere real programmers get jobs done. Hell, I'd write this post in COBOL but Slash
dot would block it saying that I'm yelling.

Re:As a C programmer

[Anonymous Coward]

Now this Engineering discipline is about a make it once and make it right mentality. Meaning there is a preference towards more lower level coding, allowing detailed and measured controls over each line of code, at the expense of maintainability and programming time.

And then the Junior Engineer graduated to his second project, looked back at the possibility of reusing the nifty code from the first project, and realized the same thing as Every Senior Engineer out there - namely your statement is pure and utter BS.

Engineers might more often hit the "640kB" memory space restriction, so what you propose is forced upon them. But it is never the preference amongst competent engineers.

Re:As a C programmer

[Big Hairy Ian]

Surely as most compilers are written in C then we're all programming in C or more to the point we're all writing Machine Code :D

Re:As a C programmer

[Anonymous Coward]

I find the results shocking. As most people I deal with struggle to write moderately complex C programs.

Also the use of the word "best" is highly subjective.

Without c (or c++ for that matter), the other languages (which rely on runtime machines ala JVM, RVM, etc.) cease to exist.

Re:As a C programmer

[Anonymous Coward]

That comparison is undefined behaviour if s and d are from different allocations, for example malloc calls.
As far as I can tell, the only 100% portable solution with no undefined behaviour is something like:
int overlap = 0;
for (int i = 1; i len; i++) if (src + i == dst) { overlap = 1; break; }
and then use overlap to switch to backward copy.
Reason: only == or != is ok between pointers to potentially different allocations.

Re: As a C programmer

[Coisiche]

Let it slide... let it slide... No, can't

and a free reign

Exercise of sovereign power applies to nations, not offices, nor basements. If you mean that no restrictions apply, then it's "free rein".

Re:As a C programmer

[Anonymous Coward]

Posted it above: I think replacing >/ comparisons with a loop instead should work:
for (int i = 1; i len; i++) if (src + i == dst) { overlap = 1; break; }
Still, not a good idea to do that, so better leave memmove to your C library

Re:As a C programmer

[Jahta]

You are certainly right about that. The nice thing about C is that the really incompetent will not get their code to run at all and weed themselves out that way. In contrast, a bad Java coder (for example) will usually get things to work, but very badly so.

Actually bad C programs do run alright. It's just that after a while they fail in mysterious (and often non-obvious) ways because the developers weren't anywhere near as good at memory management and pointer arithmetic (for example) as they thought they were. Every language with a large developer base has good and bad coders; C is no different.

Re:As a C programmer

[Anonymous Coward]

Besides the typo, It has aliasing issues on all platforms and probably won't work as expected on big-endian either.
I expect it will also fail if you run it under ubsa (undefined behaviour sanitizer, -fsanitize=undefined).
For a lot of its issues, C has very good tools.
Without those tools, C is vastly harder to write and debug.
With those tools, it is easier than many other languages that simply lack good development tools.
A good C developer should never use a cast without having a very hard think about type safety, aliasing and undefined behaviour.
Just because you can cast however you want in C certainly doesn't mean you should or that you won't pay for it!

Re:As a C programmer

[Anonymous Coward]

This. The claim that you can only make useful libraries in C is pure BS, as there are many languages that you can compile into a library, and many interpreted languages that make it really easy to integrate into other languages. Yes, there are uses some languages are bad at. You shouldn't use Lua or Python for memory management and drivers, but it is still really easy to call Lua and Python functions from C if you want to make use of those languages. You can compile your java, fortran and pascal code into a library just fine.

Re: As a C programmer

[Anonymous Coward]

That's a terrible sonnet.

Re:As a C programmer

[Anonymous Coward]

Uhh, you can compile that java into a library linkable from other languages just the same as with C. C is not the only language for reusable libraries.

Re:As a C programmer

[BarbaraHudson]

No, just that "real programmers" are an increasingly small minority compared to code monkeys.

Re: As a C programmer

[BarbaraHudson]

And yet 774 million people in India don't have a toilet. Many have no running water and no electricity. Almost 40% of India's children are stunted. A kid dies every 4 minutes from diarrhea. Would you want to live there, where only the privileged have what we take for granted?

The lineup of people waiting for their own toilet would stretch to the moon.

Re: As a C programmer

[Anonymous Coward]

APIs are for programmers, UIs are for users. Pretty simple.

Sometimes the programmer is also the user, but rarely the other way around.

Re: As a C programmer

[obscuro]

Dammit!! Something this funny on a day I have no mod points.

Oh well... I SOLUTE YOU!!!

Re:As a C programmer

[phantomfive]

If you're into it (and like languages), you might be interested in learning APL. Gnu APL seems to work alright, and there's some good documentation. I've had to make my own key-mapping, but all the needed characters are in unicode, and that's part of the fun.

Re:As a C programmer

[lgw]

That being said, the standard C headers provide all the types needed to implement pointer arithmetic in a portable way: size_t, ptrdiff_t, intptr_t, uintptr_t.

intptr_t, and uintptr_t are optional in the standard.

ptrdiff_t can be useful, but it comes from subtracting pointers, and that's only well defined when they're pointers into the same array, which is almost never how memmove or memcpy are used.

the C standard libraries would have been more consistent if most functions using size_t had been using a signed integer type instead

Unsigned makes the most sense - you don't index negatively into arrays, you don't have negatively-sized objects, and only the Windows kernel has negative memory addresses. But they started with int, I guess, so it's now a jumble.

Re:As a C programmer

[lgw]

What's worse is: even in modern flat memory architectures, compiler writers who ran out of useful work to do may now "optimize" into gibberish the subtraction of two pointers not the same array. Bastards.

Re:As a C programmer

[mysidia]

a naïve (acceptable in an interview) implementation of memmove can be achieved in 4 lines of code. This isn't rocket science I'm asking about.

I am going to challenge you right here and now to produce your 4-Line my_memmove() function. This should be a breeze, since you've apparently done it before.
One line per statement.
I will write you the test sequence that code has to pass with an identical result to the Linux Glibc2.12 memmove() function.

Here's the test sequence: http://pastebin.com/Bix6mvqv

You would need to implement memmove because, believe it or not, there are people out there who implement the libraries that memmove is implemented in.

Yes, there are people who have implemented LibC once or twice, then published. It can surely be accomplished; However..... It is not less than a half day's project for a good C programmer to implement something like Memmove(); There are complications, and unless you simply have implemented your own memmove several times, even an advanced C programmer is not going to be able to just bang this out.

Re:As a C programmer

[mysidia]

That's clever, But each clause of a ? : statement, And Each Assignment in the same expression as a comparison or Boolean operator counts as an additional line of code.

Using those tricks is cheating and excessive usage is deprecated by most style guides.

Also, using memmove() in the implementation is clever, But also cheating.

Re:As a C programmer

[Anonymous Coward]

The template code bloat hasn't been an issue for years. The compiler only instantiates for types you use. You sound like someone who hasn't used C++ recently. And as stated elsewhere, you can use all sorts of C++ features as long as you wrap it with a C interface (although preventing exceptions from escaping is a trickier problem)

Re:As a C programmer

[Anonymous Coward]

> the 'virtual machine' the C implememtation/compiler is realizing

There's your problem right there.

Re: As a C programmer

[Anonymous Coward]

And they can't get v's and w's straight.

Re:As a C programmer

[Darinbob]

Then what's "diffptr_t" type in Standard C for?
Pointers are allowed to be compared, subtracted, etc, only when they point to the same array object, or one past the end of an array object, and so forth. In this case memory is being treated like a large array of bytes. This works on a standard C architecture even on a segmented architecture, though the pointer type provided can not address all of memory, so they add in *non-standard* features such as "far" pointers.

If it's a strictly standard compliants compiler then you can't use a 16-bit pointer to address all of memory, so you can't have any array that would cross segment boundaries and you can't treat memory like a large byte array. If you're using memcpy or memmove, then you must use them on objects that fully reside within the same segment.

Re:As a C programmer

[Darinbob]

The problem wtih templates is that they're just smart macros. That's fine, if you use them the way you should use macros - keep them small. But then they go and get abused and putting full data structures in them. Now when you use a generic "container of X" and a generic "container of Y", you end up with TWO copies of the code. It's bloat. Wasted RAM, and it means caching of code doesn't work as well either. A list of signed long and a list of unsigned long will end up sharing no object code. It's a major reason why C++ gets stereotyped as a generator of bloatware.

So a template by itself is ok, what's missing is the programmer discipline to use them well.

A proper object oriented language will use inheritance of classes rather than duplication of classes when creating generic data types.

Re:As a C programmer

[angel'o'sphere]

A LOC counting program would count both versions in the range of 20 - 40 lines.
To lazy to calculate it.

If you use LOC for software metrics, then every delimiter which might cause a bug because it is either the wrong delimiter or the left side or the right side is wrong is counted as one LOC.

So: a = 1 + 2 ; is 4 Lines Of Code.
Reason: the "a" can be wrong. The 1 can be wrong, the two can be wrong and the "+" can be wrong.
E.g. the "line" could have been supposed to be: aa = l + 2; (on a german keyboard you don't mix up + and -)

However often LOC counting programs just count ",", ";", "}" and ordinary operators (like |, ||, +, - etc.) as "line delimiters".
See: https://en.wikipedia.org/wiki/...
So an empty "for" statement:
for (int i = "something"; i ; is basically already 5 or 6 LOC.

On the other hand: you could have written both versions in on single line, except for the include.

Then again: would a good but surprised programmer come up with one of both versions in a job interview in a timely manner?

Re:As a C programmer

[angel'o'sphere]

That was supposed to be:

A LOC counting program would count both versions in the range of 20 - 40 lines.
To lazy to calculate it.

If you use LOC for software metrics, then every delimiter which might cause a bug because it is either the wrong delimiter or the left side or the right side is wrong is counted as one LOC.

So: a = 1 + 2 ; is 4 Lines Of Code.
Reason: the "a" can be wrong. The 1 can be wrong, the two can be wrong and the "+" can be wrong.
E.g. the "line" could have been supposed to be: aa = l + 2; (on a german keyboard you don't mix up + and -)

However often LOC counting programs just count ",", ";", "}" and ordinary operators (like |, ||, +, - etc.) as "line delimiters".
See: https://en.wikipedia.org/wiki/...
So an empty "for" statement:
for (int i = "something"; i < "max"; i++); is basically already 5 or 6 LOC.

On the other hand: you could have written both versions in on single line, except for the include.

Then again: would a good but surprised programmer come up with one of both versions in a job interview in a timely manner?

Re:As a C programmer

[angel'o'sphere]

Well, the prime mistake is that most people simply forget about overlapping source and destination and start at the beginning of both locations with a for loop.

Erm ... John Wulff? Is that you? Just seeing your nick.

My best idea for a portable ... welllll. That would only work on systems that have a heap and support malloc and free :D

- horribly inefficient - That is the difference between an engineer and a scientist :D

implementation so far would be to malloc a temporary buffer, copy the data from the source to the temporary buffer, then copy it again to the destination. That is from a scientific point of view not inefficient. It is an O(n) algorithm and fail proof. You could even write "src" it to disk and read it back to "dest" and it had the same "efficiency" but albeit a lot less "effectiveness" :D (can you say that in english?)

Re:As a C programmer

[angel'o'sphere]

Well, on the first glance it looks at least: clever!

However without Words grammar and spelling assist it lacks the red underline for me to determine which memmove is spelled correctly.

So as you have at least one spelling error, I can give you only half the points, sorry.

However, don't be disappointed: you are the first one who presented a working solution!

I just wished you had added a comment, or two.

Re:As a C programmer

[angel'o'sphere]

Really? Which C libraries are you talking about?

The Java VM is written in C++. It most certainly does not pull any C library on your system what ever that may be.

So you want to claim: just because Interpreters written in C need/use the stdc library or math.a or whatever they are somehow dependent on C? And C is "superior" or what? I bet your unix like system has hundreds of libraries written in C. And neither Ruby nor Python nor Java uses a significant amount of them. And that was not the point anyway. You claimed Java can not call Ruby, Ruby can not call Python, Python can not call Java: they only can call C, that was your claim. And that is wrong.

The world is not going on because of C programmers, sorry. The world is going on by its own.

Re:As a C programmer

[johnw]

No - no spelling error.

You asked for an implementation of memmov(), which by implication it appeared you wanted to work the same as memmove().

If I had spelled them both the same, then it definitely wouldn't have worked.

Re:As a C programmer

[johnw]

Erm ... John Wulff? Is that you? Just seeing your nick.

Sorry, no.

That would only work on systems that have a heap and support malloc and free :D

Which are both part of the standard library, so provided you're working in a hosted environment, you're fine.

That is from a scientific point of view not inefficient.

By the specific measure of how the amount of work varies with the amount of data to be handled, you're right - it's no worse than a good algorithm. However it is still very inefficient, because it involves twice as much work for any given amount of data as a good implementation would. Effectiveness is a measure of whether or not it does the job, which it would - just not efficiently.

Re:As a C programmer

[angel'o'sphere]

That is actually an interesting question.

I mean in pure C?

The inner function would be "extern 'C' char* membla(...)" and the outer one "static char* membla(...)" ... I don't think there is a possibility, but well ... my C is rusty.

What about C++? The linker certainly could distinguish them, but the compiler?

Re:As a C programmer

[angel'o'sphere]

Yepp,
but regardless if you write to a buffer in memory, and read it back, or a buffer on disk: you only do the work twice :D
And don't let me dig into the mysteries of memory mapped files ...

John Wulff is an old friend of mine, the oldest programmer I know in person, approaching 80 years now. Worked with plenty of famous people.

For some reason I thought "we" might have missed the fact that "we" are "both" on /.

Re:As a C programmer

[flargleblarg]

Almost... but not quite. If dst == src, then return immediately without doing anything. If not, then compare to decide whether to do a forward or backward copy.

Re:As a C programmer

[flargleblarg]

If you copy 0-100 over to locations 50-150, then you have to copy backwards, copy the 100 over first, then 99, etc.

Wrong. You don't have to copy backwards at all in this case. You can copy 50–100 over to 100–150 using a forward copy operation, and then copy 0–49 to 50–99 also using a forward copy operation. No backward copy is needed.

Re:As a C programmer

[flargleblarg]

char isn't a byte type. Use uint8_t if you want bytes.

Re:As a C programmer

[flargleblarg]

If you aren't worried about performance simply copy the block to a temporary spot before copying it to the destination.

Especially when moving several gigabytes up or down by 1 byte.

Re: As a C programmer

[flargleblarg]

The lineup of people waiting for their own toilet would stretch to the moon.

Average distance to the Moon is 238,900 miles. Divide this by 774 million and you get 1.63 feet or about 19.5 inches. Math checks out.

Re:As a C programmer

[flargleblarg]

Dude. Here is a three-line solution. One statement per line. Passes all your tests.

void *my_memmove(void *d, void *s, size_t c) {
... for (size_t x=(uintptr_t)d<(uintptr_t)s||c<1?+1:-1,i=x==1?0:c-1;c;c--,i+=x)
....... ((uint8_t *)d)[i] = ((uint8_t *)s)[i];
... return d;
}

(Indentation using periods because Slashdot's formatting system is braindead.)

Re:As a C programmer

[flargleblarg]

Whoops. I forgot to remove ||c<1, which my original solution needed before it was golfed down to this. Code still runs correctly with it, though. Here is the simplified version:

void *my_memmove(void *d, void *s, size_t c) {
... for (size_t x=(uintptr_t)d<(uintptr_t)s?+1:-1,i=x==1?0:c-1;c;c--,i+=x)
....... ((uint8_t *)d)[i] = ((uint8_t *)s)[i];
... return d;
}

Re:As a C programmer

[flargleblarg]

p.s. You'll need to #include <stdint.h> to get uint8_t and uintptr_t, naturally.

Re:As a C programmer

[mysidia]

Clever. But it has the complexity of a 10-line solution packed into 4 lines using C tricks that would be disallowed in real-world code by the style guide or code review.

Each use of the ternary operator counts as three additional lines worth.
Each use of a comma or semicolon as an operator counts as one additional line.
Each clause on the righthand side of an assignment operator that contains a relative comparison or boolean op counts as 1 additional line.

Re:As a C programmer

[beelsebob]

Right, and anyone who points out those concerns, and implements a naïve implementation that won't necessarily work correctly in every compiler, while pointing out where the failings are is likely to pass the interview. Someone who stands there and goes "uhhh... pointers... wtf are those?" (As 95% of people do), will not.

Re:As a C programmer

[Anonymous Coward]

> char isn't a byte type

Yes it is. The standard defines it as the smallest addressable unit which can hold a character on the machine it's implemented on.

In practice, this is a byte for every architecture.

Re:As a C programmer

[johnw]

The inner function would be "extern 'C' char* membla(...)" and the outer one "static char* membla(...)"

No, the outer one wouldn't be static (meaning in this context, private) because it has doesn't have the static keyword. You're also introducing the complication of wondering what it would look like to a C++ program, which if we're working in pure C doesn't matter.

I've now checked the signature of memmove() and realise that the one someone posted earlier in the thread is wrong. My implementation should therefore read:

#include <stdlib.h>
void *memmov(void *dst, const void *src, size_t count) {
    return memmove(dst, src, count);
}

Note that they're void* pointers, not char* pointers. This is one of the areas where C and C++ differ quite distinctly.

What about C++? The linker certainly could distinguish them, but the compiler?

Now you remind me of a project a long time ago (80s?) where we had to implement a comms library in pure C to run across 5 different platforms. The trouble was, at least one of the platforms didn't have an ANSI/ISO C conformant compiler (it was only a draft in those days), and something (K&R C) guaranteed you only 6 significant characters when things hit the linker. One platform did indeed recognise only 6 characters. We got around that with a header file containing:

#define EPC_OpenConnection EPC001
#define EPC_CloseConnection EPC002
#define EPC_WaitForOpen EPC003
#define EPC_WaitForClose EPC004

Ah the delights which are forgotten to today's programmers.

Re:As a C programmer

[goose-incarnated]

If you aren't worried about performance simply copy the block to a temporary spot before copying it to the destination.

Especially when moving several gigabytes up or down by 1 byte.

I did say If you aren't worried about performance. As an interview question, a qualifier like that is perfectly acceptable because the interviewer can always say "well, what if I *do* care about performance?" in which case you go with the increment/decrement based on the two pointer's relative position to each other.

Re:As a C programmer

[TheRaven64]

It's a tradeoff. Blowing away the i-cache is a good way of killing performance, but so is having a load of function calls that do almost no work. If you had to do a virtual method call for comparing two unsigned integers and a different virtual function call for comparing two signed integers when inserting them into a set then you'd have a lot more overhead. In a typical std::set implementation, the compare operations are inlined and so the costs are very low.

The real problem with C++ is that the programmer has to make the decision about whether to use static or dynamic dispatch up front and the syntax for both is very different, so you can't trivially switch between them when it makes sense to do so.

Re:As a C programmer

[locofungus]

I was responding with this in mind:

For reference, a naÃve (acceptable in an interview) implementation of memmove can be achieved in 4 lines of code.

In an interview situation, without any additional instruction, I would tend to assume "a line of code" is a semicolon delimited statement. Comma operator may, or may not, be allowed. I'd ask.

However, I'm really struggling to get this down to four "reasonable" lines in C.

Here's the best I've got (I've changed the signature to take an unsigned char* to avoid excessive casting in the function.

void* mm(unsigned char* dest, const unsigned char* src, size_t n)
{
    if(n)
    {
        if(dest < src) *dest = *src;
        mm(dest+1, src+1, n-1);
        if(dest > src) *dest = *src;
    }
    return dest;
}

I think I'd be willing to argue in an interview that this does a memmove in 4 lines of C.

I rather like this solution as it's fairly easy to see that it copies forwards if dest < src and it copies backwards if dest > src.

Re: As a C programmer

[Anonymous Coward]

"Bush Reigns In Federal Spending"

Re:As a C programmer

[flargleblarg]

Right. Just making a joke. Carry on. :)

Re:As a C programmer

[flargleblarg]

Yeah, but it is three lines of C (four if you count the function name/parameter line). So there. Bottom line counts. You asked for a 4-line solution and you got one.

Re: As a C programmer

[32771]

Hell yes, after 20 years programming C I'm coming to understand integer promotion.

Re:As a C programmer

[HeckRuler]

So... Do you guys think any other language would do a better job?

(Is there anything else that would even work on a PIC32 MCU?)

We're talking about "the most portable language". Even if there are gotchas, if it's the only game in town, it's the most portable by default.

Re:As a C programmer

[warm_warmer]

Hell no. :-) C is by far the most portable language. Really, my main point was just a warning that there aren't many libraries that were written with absolute, architecture-independent portability in mind, and the key take-away from that should be: add third-party dependencies very cautiously, and test the shit out of your code.

Re:As a C programmer

[mysidia]

> I think I'd be willing to argue in an interview that this does a memmove in 4 lines of C.

C requires you cast objects of type void*  before dereferencing such as  "*src".....

However, that bit of code crashes with a stack buffer overflow due to too many recursive calls if moving an object larger than approximately 200 Kilobytes.
At that point you might as well do this,  since it's essentially just using the stack as a temporary buffer anyways;   and this can handle objects of a bit more size  without crashing.....

void * my_memmove(void * dest, void * source, size_t n ) {
  char x[n];
  for( int i = 0 ; i < n ;  (x[i] =  *(char *)(source + i)) , i++ ) ;
  for( int i = 0 ; i < n ;  (*(char *)(dest + i) = x[i]) , i++ )  ;
  return dest; }

Re: As a C programmer

[Anonymous Coward]

Looks more like a mobile phone...

Re:As a C programmer

[Anonymous Coward]

I just test if the regions overlap and copy them into a temporary buffer if they do... it's going to be faster anyway given that I could work with words instead of bytes this way...

Re:As a C programmer

[Anonymous Coward]

TBH exceptions can sometimes be more efficient than other error mechanisms, especially when you have deep function call chains.
The idea behind templates is that more code now = less fast code later.

Re: As a C programmer

[Anonymous Coward]

so C is really hard
seems like the only benefit is that the small number of people who master it get very high salarys- sort of like a union or phd thing

Re:As a C programmer

[locofungus]

I wrote:

I've changed the signature to take an unsigned char* to avoid excessive casting in the function.

You then wrote

C requires you cast objects of type void* before dereferencing such as "*src".....

But if you're going to ignore my code and what I said, criticize something I didn't write and then write your own, it perhaps would be better not to try to do pointer arithmetic on void pointers.

Re:As a C programmer

[PurpleAlien]

I thought that was self evident and didn't add that...

C is the best

[Master5000]

C and assembly are all you need to know. The rest is just syntactic sugar. If you disagree you must be some hipster that thinks that javascript is a good language just because it's the only one you know.

Re:C is the best

[Anonymous Coward]

C is just a glorified macro assembler. Real programmers use butterflies anyways.

Re:C is the best

[TechyImmigrant]

>C and assembly are all you need to know.
Neither will do for designing digital logic.
We use HDLs to create the logic that makes the instructions. Instructions are way too high in the stack.

Verilog sucks and System Verilog makes amends, but neither is worthy of VHDL.
VHDL's syntax sucks because it's based on ADA. But the execution model makes sense, unlike Verilog.
C will fail to help you make a chip. System C exists, but seriously, don't go there.
MyHDL is a python HDL which should be awesome, but it isn't.

But C is most certainly not all I need to know.

Re:C is the best

[jellomizer]

Until after all that work getting it done you realize it needs to move to a different processor and/or operating system.

Re:C is the best

[Tablizer]

C and assembly are all you need to know. The rest is just syntactic sugar.

That's what the Lisp folks usually say: it can be any paradigm you want, even one you made up.

(Which can back-fire when you use it to model how your head works, leave the company, and the new guy discovers you are insane by his/her standards.)

Re:C is the best

[HiThere]

C is actually quite portable. But documenting it correctly so that someone else (or you a few years later) can understand what's going on it a beast.

C is more portable than either assembler or C++ (to bracket it with similar languages). It's not the most portable, for that you need either an interpreted language or one that runs on a virtual machine. Like Java, Python, Smalltalk, Ruby, etc., but it's probably the most portable language that compiles to native code.

Re:C is the best

[subanark]

javascript is a good language since it runs in the most trusted sandbox, your browser.

Re:C is the best

[fahrbot-bot]

C is just a glorified macro assembler. Real programmers use butterflies anyways.

Nice. 'course, there's an Emacs command to do that: C-x M-c M-butterfly

[I actually have that comic taped to my door.]

Re:C is the best

[Anonymous Coward]

Verilog is terrible for making spreadsheet macros, therefor it sucks.

Re:C is the best

[Anonymous Coward]

Never heard of SystemC?

Re:C is the best

[thinkwaitfast]

What if you need to talk to hardware (as system engineers typically do)?

Re:C is the best

[ChrisMaple]

C will fail to help you make a chip.

I've used and modified C programs that took SPICE output to optimize IC circuit speed, and interfaced with part of Verilog to calculate gate loading and speed. C was essential to our process of chipmaking.

Re:C is the best

[TechyImmigrant]

Never heard of SystemC?

Of course I have. I mentioned in the post.. "C will fail to help you make a chip. System C exists, but seriously, don't go there."

Re:C is the best

[subanark]

Then, sure, use C. I'm not saying C is a bad language, only that there is a very good reason to use javascript, namely, if some shady person told you that they have an awesome app written in C, Flash, or javascript. I'd go with javascript, as I'm not about to build a VM to test a single app.

Re:C is the best

[arth1]

What if you need to talk to hardware (as system engineers typically do)?

There's espruino, javascript for microcontrollers, which supports peek()/poke()/usr() and similar.

But really, the overhead is enormous, so unless cycles and bytes don't matter, it's not the way to go.

Re:C is the best

[goose-incarnated]

Until after all that work getting it done you realize it needs to move to a different processor and/or operating system.

Yeah, look how poorly that turned out for Linux when they wanted to port it to something other than x86/32...

Re:C is the best

[Anonymous Coward]

> C is just a glorified macro assembler.

I don't know why people keep saying this. Anyone who's programmed in C and assembler knows it's completely false.

Re:C is the best

[TechyImmigrant]

C will fail to help you make a chip.

I've used and modified C programs that took SPICE output to optimize IC circuit speed, and interfaced with part of Verilog to calculate gate loading and speed. C was essential to our process of chipmaking.

Fair enough. I was really aiming at HDLs for digital logic, but I didn't write with sufficient precision.

Do they mean C++ ?

[Anonymous Coward]

In the past I have spoken with many software people who did not really know the difference :-(

Re:Do they mean C++ ?

[Anonymous Coward]

The summary makes it clear that they differentiate between C and C++
Sounds to me like more people have started to program for microcontrollers with integrated memory.
Assembly and C are pretty much the only viable languages for them. Possibly a subset of C++ can be used.

Re:Do they mean C++ ?

[jellomizer]

I have seen most code written in mostly C and compiled in a C++ compiler. (They often will use those nice C++ extras)

Re:Do they mean C++ ?

[Anonymous Coward]

I have seen most code written in mostly C and compiled in a C++ compiler. (They often will use those nice C++ extras)

Such as trying to use C99-style mixed code and variable definition/initialization on a Microsoft compiler.

To be fair, Microsoft did acknowledge the existence of C99.

In 2014.

Their criteria are weird

[Cesare Ferrari]

C is a small language, certainly compared to the others in the top of the list (Java and Python libraries are just huge). By using postings and general 'chat' about languages to gauge interest, i'm a little worried that people attempting to get their head around the larger language libraries will be taken as equivalent to what will most likely be more targeted chat about C. To me this would suggest that C is probably underscored, whilst larger languages will be overscored if using this sort of approach (not that i've dug properly into their methodology!).

5 month too early???

[matthelm007]

I don't think 2016 is over yet, is it? Looks like someones pointer overflowed!

No jobs for C

[Shompol]

I spent some time looking for a position that required C a while back. Nobody hires for C anymore. Even shops that actually use C are too ashamed to admit it and advertise their positions as C++. So, looking at TFA:

We measured the demand for different programming languages on the CareerBuilder job site....Because some of the languages we track could be ambiguous in plain text—such as D, Go, J, Processing, and R—we use strict matching of the form “X programming” for these languages.

So off to CareerBuilder and i typed in "C programming", with quotes. Result: electrical engineering positions, other non-developer positions and false-positives. Conclusion: C is used but seldom by developers.

Re:No jobs for C

[OrangeTide]

I've mainly found only jobs for C. Because I look for Linux kernel and RTOS jobs.

Re:No jobs for C

[Anonymous Coward]

Nobody hires for C anymore.

I will counter your anecdote with one of my own. I have been employed for the past 5 years doing new C development and I see no signs of slowdown. There were 15 developers when I started and that has grown to around 40 now. A few of those are working in other languages but the majority is C work.

Re:No jobs for C

[Anonymous Coward]

Wow, a study conducted by "The Institute of Electrical and Electronics Engineers" finds jobs electrical engineers do? No shit.

Re:No jobs for C

[phantomfive]

Look for embedded programmers, or systems programmers. Sometimes those are something besides C, but a lot of times they are.
In other jobs I've done C programming, but only part of the time.

Re:No jobs for C

[Anonymous Coward]

C is the new COBOL.

Re:No jobs for C

[Anonymous Coward]

> C is the new COBOL.

C is always king. Everything you ever do, ever box you ever touch, every robot that ever loved you, had some or all of it programmed in C. These other languages are pleasant flowers, blooming in spring and blowing away in fall, with a new flower every year, but C is the mountain that they grow upon.

Re:No jobs for C

[luis_a_espinal]

I've mainly found only jobs for C. Because I look for Linux kernel and RTOS jobs.

This. I simply call bullshit on the upper-OP claim that nobody hires for C anymore. I mean shit, were I work, we hire for C (and C++ and Java, depending on the product.) People don't realize how much C is around us. Thermometers, thermostats, controllers. Anything with a PIC or AVR processor most likely runs something written in C.

Not to mention, as you said, jobs in kernel and RTOS development.

Re: No jobs for C

[Anonymous Coward]

Possibly over the top but beautifully written.

Re:No jobs for C

[jwhitener]

I just did a google search for 'c programmer job' and got thousands of results. Randomly clicked a few and they look real. Monster had a lot also. http://www.monster.com/jobs/search/?q=c-programmer

Re:No jobs for C

[Shompol]

Oh, I should have used Google. Will take a note for the future. Btw, here is an interesting "C developer" position at Morgan Stanley:

Position Description: ... The C team works closely with Bjarne Stroustrup to help the firm adopt a modern C approach to application and infrastructure development.,,

Re:No jobs for C

[OrangeTide]

The automotive SDKs that I've seen are C at the low-level. MISRA compliance requires that you use C and not C++.

The vast majority of anything that has software in it that isn't trying to be computer, is programmed in C.

"syntactic sugar" except for OOP

[mykepredko]

I would agree with you except for the fact that Java, C++, C#, Objective C and even Javascript all have Object Orientated Programming aspects to them which is much more than "syntactic sugar" (which is a great term).

Unfortunately for some, C saddles the user with the dreaded pointer. I'm not sure how pointers are taught today, but "back in the day" when I was taught pointers in university, the approach taken was pretty sadistic with the goal of instructors to demonstrate their intellectual superiority over their students by showing (and testing) the most bizarre and unlikely combinations of * and &. I suspect that this is reason for the fear of C and pointers (when all you really need to know about pointers is how to pass data to and from methods and how pointers can be used with strings).

Re:"syntactic sugar" except for OOP

[HiThere]

It doesn't matter HOW pointers are taught, they are inherently unsafe. Even reference counted pointers are unsafe, and I don't believe that those are currently a part of C. Pointers are a buffer overflow attack (or error) waiting to happen.

Re:"syntactic sugar" except for OOP

[fahrbot-bot]

It doesn't matter HOW pointers are taught, they are inherently unsafe.

And your point? Many, many things are "unsafe". Blah, blah, blah [Either you know where I'm going with this, or shouldn't be reading /. ...]

Re:"syntactic sugar" except for OOP

[erapert]

Even reference counted pointers are unsafe

In what way are ref-counted pointers unsafe?
Also isn't counting references basically what a garbage collector does anyway?

(I am aware that ref-counted pointers are not the same as garbage collection as implemented in Java, C#, and the like.
I'm also aware that garbage collectors don't necessarily literally count references when doing a sweep.
I'm just saying that the operations are similar in principle)

Re:"syntactic sugar" except for OOP

[cfalcon]

Pointers aren't inherently unsafe. They represent reality and offer speed. These two things will always have use, and safety is just doing the right damned thing with your code.

Re:"syntactic sugar" except for OOP

[Anonymous Coward]

Huh? Objects are just structs. Methods are just function pointers within the struct. Private data members are just another struct hidden behind the first struct. 'this' is just a reference back to original struct implicitly passed to the method. Inheritance, polymorphism, templates/generics -- you can do it all in C if you care to. The syntax and bookkeeping placed on the developer at that point becomes ridiculous, but all those OO features really just are syntactic sugar.

It doesn't matter though, two out of three developers can't program OO properly in Java or C#.

Re:"syntactic sugar" except for OOP

[thinkwaitfast]

If you understand how processors work, pointers are very easy.

Re:"syntactic sugar" except for OOP

[ChrisMaple]

The syntax for passing pointers to functions in C can be confusing, particularly when dealing with things like pointer to pointer to array of strings. **str[][] just isn't fun.

Re:"syntactic sugar" except for OOP

[Anonymous Coward]

When I first got "taught" pointers at uni it confused the hell out of me: all those boxes and arrows and obscure verbiage. Then I was programming in assembly one day for fun and it hit me: it's just a fancy way of saying memory address containing blah. &a just means memory address where a is stored. *a just means data contained in memory address a. Throw in a basic understanding of stack and heap allocation, malloc and co. and you're 99% done. Really, really dead simple.

Why we weren't just told this at the start remains a mystery. All those boxes and arrows... why?

Re:"syntactic sugar" except for OOP

[Anonymous Coward]

Oh come on, stop it with the "unsafe" bullshit. Everything is unsafe for the untrained, be it C or a power drill.
If you want something to stop you from shooting yourself in the foot, stop shooting yourself in the foot!

Re: "syntactic sugar" except for OOP

[Anonymous Coward]

It was probably mentioned in passing in the first five minutes. It should be obvious, considering C is a low level language.

Re:"syntactic sugar" except for OOP

[Anonymous Coward]

I would agree with you except for the fact that Java, C++, C#, Objective C and even Javascript all have Object Orientated Programming aspects to them which is much more than "syntactic sugar" (which is a great term).

Unfortunately for some, C saddles the user with the dreaded pointer. I'm not sure how pointers are taught today, but "back in the day" when I was taught pointers in university, the approach taken was pretty sadistic with the goal of instructors to demonstrate their intellectual superiority over their students by showing (and testing) the most bizarre and unlikely combinations of * and &. I suspect that this is reason for the fear of C and pointers (when all you really need to know about pointers is how to pass data to and from methods and how pointers can be used with strings).

Geaux Tigers!

(Did you attend the CS classes from the department-teetering-on-the-brink-of-discreditation too?)

Re:"syntactic sugar" except for OOP

[Anonymous Coward]

It doesn't matter HOW pointers are taught, they are inherently unsafe. Even reference counted pointers are unsafe, and I don't believe that those are currently a part of C. Pointers are a buffer overflow attack (or error) waiting to happen.

What a fucking wah baby. You're fucking pathetic. Grow a pair.

Re:"syntactic sugar" except for OOP

[Anonymous Coward]

This is probably one of the only things that I don't like with C.
Its pointer syntax is bad.
I don't have a suggestion for a better one, but at this point I leaning for something more verbose.

People that starts out with assembly or a basic flavor with peek/poke doesn't appear to have the problem with pointers that people who started out with higher level languages do.
I suspect this is because the syntax made it way more obvious that they were dealing with memory addresses and the verbosity of the operations made it clear how those addresses were used.

Re: "syntactic sugar" except for OOP

[Anonymous Coward]

> It should be obvious, considering C is a low level language.

C is not a low-level language.

Re:"syntactic sugar" except for OOP

[HiThere]

Reference counted pointers eliminate accidental overflow in non-recursive structures, but they don't address memory leaks due to looped links, and they don't address intentional attacks from referencing beyond allocated bounds.

Country? [Re:As a C programmer]

[Tablizer]

Being more devices and consumer goods probably have embedded programming in them, I suspect that accounts for most of the C increase, and it's probably being done overseas, where the manufacturing hubs are.

Keep that in mind before jumping on the C bandwagon.

I purchased a fairly basic electric fan, and it has a digital control for level and a timer. It's probably programmed in C. I even saw a toilet seat in one store that glows via an LED light that turns on when you sit on it, if the light is off. Could be C in that controller also. You may be sitting on C now and not even know it.

Re:Country? [Re:As a C programmer]

[cfalcon]

Who cares? Are you implying those controllers should be written in assembly? I'm not sure where your post is going.

C fucking rules. Interpreted drools!

Re:Country? [Re:As a C programmer]

[Tablizer]

No. Let me try to rephrase it.

The increase and/or popularity of C may be a result of embedded programmers working for manufacturing companies, who are mostly NOT in the USA or Europe. (At least manufacturing is not growing in here.)

Thus, if you live in the USA or Europe, you probably should NOT take these numbers (popularity) as a sign that C is a good employment opportunity. The growth is not where you live.

Being Slashdot content is written in English, I assumed mostly USA or UK readers. Perhaps I should have stated that. At least that's who my target audience for the location warning.

Clear now?

Re:Country? [Re:As a C programmer]

[Darinbob]

Lots and lots of embedded work being done in the US. Anyone who makes devices. Internet of Things, smart phones, dumb phones, automotive ignition, microwaves, toys, medical devices, anything anywhere that uses Linux, the traffic light at the corner, the security checkpoint at the airport, etc. Oh wait, encryption too, it's usually a mix of hardware, assembler, and C in many products. And the implementation of most scripting languages and their runtime code... All of that is happening within the US. And it's happening in other countries too of course, C isn't bigoted.

Re:Country? [Re:As a C programmer]

[Darinbob]

Where the devices are manufactured does not tell you anything about where the devices are designed and programmed. Sure, there may not be "growth" in C in the US, but growth comes and goes which means that the hordes of programmers in a fashionable language this year may be out of work in five years (after having to train their cheap replacements).

Re:Country? [Re:As a C programmer]

[Tablizer]

Where the devices are manufactured does not tell you anything about where the devices are designed and programmed.

It's usually easier and cheaper to co's for them to be close.

Re:Country? [Re:As a C programmer]

[Darinbob]

You design in location A, and you can manufacture *anywhere*. It helps if manufacturing is closer to location A during design, because you're more interested in quick turnarounds than in lowest possible cost. Once you're building in bulk it's not that important. And countries that are currently big on manufacturing cheaply are not very good at designing well. And the big design places are still the US, Europe, Korea, Japan. Those are where the big headquarters are, but not necessarily where the stuff gets put together.

Re:Country? [Re:As a C programmer]

[Tablizer]

For complicated products like photo-copier software, perhaps, but I'm thinking more of simpler gizmos, like the fan and toilet seat described earlier. That's where I see an increase computerization. The complicated things had chips for decades, but crock-pots, Barbies, etc. are getting them too now.

Embeded

[Anonymous Coward]

Embedded is getting popular right now, especially with IoT. Based on my experience, C is filling the role of Assembly for a lot of businesses. More importantly, this claim that C is the "top" language isn't very relevant to most developers because they won't be doing embedded work at the rate insinuated by this report.

Re:Embeded

[over_optimistic]

almost all embedded platforms these days work with gcc, and gcc supports c++ and you can do c++ on all of them.

Re:Embeded

[Anonymous Coward]

With C++ you have to be very skilled and careful or you might realize your harmless looking piece of code actually needs more stack than your embedded system has.
C++ (at least before C++11 and constexpr) also makes it very hard to ensure that certain data ends up in .rodata (and thus can be stored in flash/ROM instead of RAM).
Even if you go with constexpr (which admittedly is nicer than many things you have in C, but still fairly annoying to use) you still lack features like designate intializers, so you cannot easily initialize complex or sparse constexpr arrays.

Cant say i'm surprised

[maliqua]

Given the popularity of arduino and similar embedded devices that favor C I'm not really surprised at all to find C is still incredibly wide spread and popular

Re:Cant say i'm surprised

[Anonymous Coward]

Arduino uses C++

Re:Cant say i'm surprised

[thinkwaitfast]

I've never used any c++ specific constructs in any of my arduino programs.

Re:Cant say i'm surprised

[swillden]

I've never used any c++ specific constructs in any of my arduino programs.

So you've chosen not to use C++ features, but your code is compiled as C++, and all of the framework code that calls your code is C++ -- and it definitely uses C++ features. C++ is the Arduino language, not C.

Re:Cant say i'm surprised

[Anonymous Coward]

I don't understand why people think AVRs need to be programmed in Arduino-C++ dumbed-down. avr-gcc (WinAVR on windows) is extremely nice to use and doesn't hold your hand. True C (or C++, if you like) programming.

Re:Cant say i'm surprised

[Anonymous Coward]

Never used Serial.printf()? Really?

Re:Cant say i'm surprised

[thegarbz]

What you use is irrelevant.

Arduino on the whole in its most popular form uses C++, the examples use C++, the documentation talks C++, and I'm willing to bet you a marsbar that your programs most definitely have C++ constructs, just that you may not have written them yourself.

Re:Cant say i'm surprised

[thegarbz]

Arduino is C++. Another incredibly popular platform is the ESP8266 for IoT stuff, that is typically written in Lua, has an Arduino bootloader or is interfaced by an Arduino. In the hobby / messing around market that the Arduino represents C++ dominates well and truly.

That said most *products* aren't made on an Arduino and in the real world I get the sense that embedded projects do favour C.

Re:Cant say i'm surprised

[swillden]

I don't understand why people think AVRs need to be programmed in Arduino-C++ dumbed-down. avr-gcc (WinAVR on windows) is extremely nice to use and doesn't hold your hand. True C (or C++, if you like) programming.

I don't think anyone thinks they have to be programmed in Arduino C++, but the tools work well, so why look any further? What do you actually gain with avr-gcc?

highly regarded

[morinpatmorin]

IEEE Spectrum, a *highly regarded* magazine....

puhlease

Re:highly regarded

[Anonymous Coward]

IEEE Spectrum, a *highly regarded* magazine....

puhlease

It's a helluva lot more respected than some Ruby fanboi rag that you find a few ripped pages from on the floor of a shitter stall that ran out of toilet paper.

Object-oriented is a fad

[TheSync]

Object-oriented is a fad!

So is IPv6!

Re:Object-oriented is a fad

[phantomfive]

Object-oriented is a fad!

I wouldn't have believed you 10 years ago, but now OOP is out and uncool. The new hip people all program in functional style (and OOP is messing everything up). I'm waiting for someone to discover the new imperative programming paradigm.

Re:Object-oriented is a fad

[balbeir]

Nah, in 10 years someone will invent the GOTO statement and the Spaghetti Programming paradigm will be the coolest game in town.

Re:Object-oriented is a fad

[Anonymous Coward]

I wouldn't have believed you 10 years ago, but now OOP is out and uncool.

and thank $DEITY for that. I still, after many years of programming, haven't understood how to use OO properly.

Re:Object-oriented is a fad

[Dadoo]

Object-oriented is a fad!

I'm sure you meant that as a joke, but it's more correct than you know: https://www.infoq.com/news/201...

Re:Object-oriented is a fad

[TheRaven64]

As that article shows, the core of OO that Alan Kay describes is still useful (and even used in the current buzzwordy functional languages), it's just a bunch of cruft that's grown up around it that turns out to be not so useful.

Re:Object-oriented is a fad

[Anonymous Coward]

OOP is the only way to make reusable objects over log time, otherwise you end up with crap like Python modules.

Re:Object-oriented is a fad

[Anonymous Coward]

Oh Dear and here I am this old fart writing a smallc program that runs in a DOS window. Compiles fast, runs like a bat out of hell, processes 18,000 data records (csv text) in under a second and I can pipe/redirect the input/output. I can compile, run the program and redirect all in one line! And I already know the IDE!

Who knew I was so cool? ;\ (My K&R is dated 1976, just wish the dog had not urinated on it back in 85. Yellow Labs, great dogs, but dumb as dirt.)
   

Re:Object-oriented is a fad

[Anonymous Coward]

What a waste of time trying to read that link about OOP messing things up. Grabbing random silly quotes from the Internet and using that as the "evidence" that OOP does not work is not a very convincing argument.

Re:Object-oriented is a fad

[phantomfive]

Yeah, sorry, I don't think I'll be able to find you a convincing argument lol, I just presented it to show typical attitudes towards OOP these days.

The truth is, if you don't know how to organize your code, no programming methodology, no design pattern set, no hype is going to save you.

Re:Object-oriented is a fad

[phantomfive]

I'll be honest, although I linked to that article, I don't think it shows much of anything! lol. The main reason I linked to it was to give a sample of the attitude that is popping up recently, not because that attitude is right.

Which version of C would you use?

[galabar]

I'm about to start a project for fun using C and I was wondering what the best version would be C89? C99? C11? It seems that nothing in C99/C11 is all that compelling and I'd like to have solid multi-threaded support (POSIX threads). Any reason to use anything other than C89 features?

Re:Which version of C would you use?

[Anonymous Coward]

I'm about to start a project for fun using C and I was wondering what the best version would be C89? C99? C11? It seems that nothing in C99/C11 is all that compelling and I'd like to have solid multi-threaded support (POSIX threads). Any reason to use anything other than C89 features?

if the project is for "fun", use python. its more fun than C

Re:Which version of C would you use?

[Anonymous Coward]

make CFLAGS="-march=native -O3"
CFLAGS just kiked in YO!

Re:Which version of C would you use?

[thinkwaitfast]

ANSI

Re:Which version of C would you use?

[dottrap]

I'm about to start a project for fun using C and I was wondering what the best version would be C89? C99? C11? It seems that nothing in C99/C11 is all that compelling and I'd like to have solid multi-threaded support (POSIX threads). Any reason to use anything other than C89 features?

C99 has some really convenient features:
- inline functions (note: these work slightly differently than C++ because they fix the problem of guaranteeing symbol generation for linkage concerns)
- long long
- _Bool and
- (uint32_t, int8_t, ...)
- // comments
- not requiring all variables to be declared at the top of the scope
- local scoping for for-loop variables: for(size_t i=0; ival; i++)
- variadic macros
- snprintf
- designated initializers
- restrict (for the hardcore performance sensitive folks)

Microsoft dragging its feet on updating Visual Studio's C compliance to C99 and beyond has been the major reason for people sticking to C89. But the rest of the world has moved on. Microsoft finally started waking up and realized not being able to compile massively cross-platform open source projects like Git was a problem. Also, Microsoft's iOS compatibility bridge requires a good C compiler as Obj-C is a superset of C and Obj-C devs take for granted a lot of the above listed features. Visual Studio 2015 has *finally* started adding a bunch of the more popular C99 features so it can finally compile Git, though it is still missing things, with __STDC_VERSION__ still not up to date as a telltale sign.

Re:Which version of C would you use?

[Anonymous Coward]

I'm about to start a project for fun using C and I was wondering what the best version would be C89? C99? C11? It seems that nothing in C99/C11 is all that compelling and I'd like to have solid multi-threaded support (POSIX threads). Any reason to use anything other than C89 features?

Really?

Scoped variables makes C99 better than previous standards, because the code is more self-documenting; variables are declared where they are used, and this also has run-on benefits for macros, because you can easily fabricate, for example, loop macros which can be used without worrying about them being used multiple times in one function body.

The improvements to struct initializers and array initializers pay huge dividends when doing functional programming in C.

I'm not entirely sure which features are added in C99, but there is no downside to using C99, every modern C compiler, even MSVC supports C89, so there is no real reason not to, it's also the default in clang. I know if I ever use GCC without putting -std=c99 or -std=gnu99 I'm surprised at how much I rely on C99 features.

The only reason to use C89 was that MSVC was shit and didn't support C99, now it does, so I don't know why you wouldn't use it. There is no down-side, it doesn't add any execution overhead or linker overhead, it's just better. C11 seems to add much less, but I've hardly used it.

Re:Which version of C would you use?

[Anonymous Coward]

Forget about C89. There is a good reason to move away from those function declarations.
If you want to use POSIX threads either C99 or C11 will work but C11 has it's own thread support too.
Note that C11 threads aren't wildly supported, but on the other hand POSIX is seldom portable outside of a full blown operating system.
I suspect that most platforms that supports POSIX also supports C11 threads and that it is easier to write C11 thread support to non-POSIX platforms but I haven't looked into it.

Re:Which version of C would you use?

[TheRaven64]

C11 threads are also a horrible API full of mistakes that other threading libraries learned from and fixed two decades ago. It exists solely because someone thought that you can't have atomics in a language without a mechanism in the standard library for creating threads. C++11 threads are actually quite sensible. The only significant addition in C11 is the addition of a half-arsed port of C++11 atomics (right down to accidentally including a joke footnote from the C++11 draft spec that was removed before the C++11 spec was finalised). _Generic is vaguely useful.

R?

[Anonymous Coward]

wtf is R

Re:R?

[Anonymous Coward]

Let me Google that for you...

Not a Surprise

[ewhac]

The "winning" language was going to be Python, but a buffer overflow error caused C to be output at the top of the list.

C++11

[Anonymous Coward]

It's really very nice. closures, collections, "auto" type in for loops over collections
The downside is long compilation times and unintelligible error messages from template
classes.

sounds like a pump for C

[Anonymous Coward]

Everything new that is cool is generally C++.

KDE is C++ and is great. Gnome is C and it sucks ass.

for example.

Re: sounds like a pump for C

[Anonymous Coward]

Gnome's a lot more stable than KDE in my experience, though I agree it's horrible.

Bullshit.

[Anonymous Coward]

Bullshit.

Craton Ape

[Anonymous Coward]

Yeah, fuck Rust!

As a perl developer...

[CaptnCrud]

does this mean I can raise my rates? : p

Why is the language such a big deal?

[Theovon]

As someone who has written substantial code in enough languages that I’ve lost count, I am sortof (but not really) baffled by some people’s attitudes toward programming languages. Some are fiercely loyal to a particular language, willing to spent time bashing other languages, usually in ignorance of what people like about those other languages. Some people know only one language and live in fear for their lives that their one language will go out of style or they’ll have trouble finding work in that language. In early 2012, I didn’t know Java at all. When I found out that the language I needed to learn for a particular project was Java, I just learned it over about a month, although I did spend the next few months learning the finer points, more APIs, etc.

The reason I’m not really that baffled is that I’m this way when it comes to video games. About the only one I would ever play was Age of Empires (all versions). Recently, I’ve picked up Minecraft, but I don’t want to get completely sucked in because I have other things in my life I have to do. That being said, I’m not fiercely loyal to AoE. I just like it and played it enough to get good at. And as a life-long Lego fanatic, Minecraft appeals to me. I don’t live in fear that I won’t be able to play my favorite games.

Re:Why is the language such a big deal?

[Anonymous Coward]

Well probably because most people learn one major language and just stick with that (or stack of languages). They get confused over semantics and verbage ideosyncraci's as "some alien thing" because they aren't really invested in learning another language.

And yes, people will cheerlead their language because its there bread and butter. It needs to be the "best" because. No reason, just because.

C is for Cows

[Anonymous Coward]

C is for Cows! Moooooooooooo....Mooooooooooo....Moooooo say the C programming Cows!!!!!

A highly regarded magazine edited by IEEE?

[Anonymous Coward]

I almost fell out of my chair laughing. Highly regarded by whom? Science fluff nerds? Pictures are usually pretty though.

C programmer?

[TiggertheMad]

I would hire mysidia over you any day. The whole point of common library functions is someone writes something once, and make it perfect, and then re-use it until the end of time. A good programmer can re-invent the wheel. A great programmer knows where all the wheel stores are, and the pros and cons of each one. This isn't 1988 anymore where you have to write all your own header files from scratch in isolation.

Re:C programmer?

[beelsebob]

A great programmer knows where the wheel stores are, what the pros and cons of each are, *and* how to implement a new wheel when it turns out that none of the stores sell the right kind of wheel.

And the heaviest weighted metric is...

[Anonymous Coward]

... the people doing the research were all brought up on C, therefore it's the best. Just like everyone else's favourite language.

Big deal.

[Qbertino]

No, as a pretty experienced C programmer too, it's *really* hard to find people who are even vaguely competent C programmers.

Big deal. Try finding vaguely competent PHP programmers or LAMP Webstack programmers in general - that's a real drag.

Finding competent C programmers is probably compareatively easy, because whoever picked up C probably knows what he/her got him/herself into. At least after a week or so. So whoever voluntarily programms in C usually knows what problems they'll be facing.

Pointer "safety."

[fyngyrz]

Underrated.

There's nothing "unsafe" about pointers. Compromises of safety occur as a result of using pointers *wrong*.

There's plenty unsafe about programmers who don't understand what they're doing, and/or are careless, and/or assume that libraries that are black boxes beyond the API level to them are inherently safe.

Unfortunately, the typical metric for hiring programmers is "do you have a degree" rather than "do you know what you're doing."

Welcome to the Internet of Things

[OwMyBrain]

I'm sure the sudden resurgence of C (don't call it a comeback, it was here all along) is because of the sudden Internet of Things craze. I work in embedded systems and there is a lot of interest in "smart" devices right now. All those micro controllers going into those "smart" devices are going to use C, and that's often your only option. So, it's no surprise to me that C is back on top.

I also like to point out that my favorite programming language is (quite often) the one your favorite language is written in ;)

logical

[recharged95]

It's a case of critical needs....

C -- memory mgmt/direct access (rigid -- ok, lots of freedom but you can get hurt quick)
Java -- Object oriented (OOA/D) (semi rigid)
Pyhton -- lose the type safety for ease of development (loose)
C++ -- utmost flexibility (looser)

ROTFLMAO!

[whitroth]

And if you're "struggling" with "moderately complex" programs, perhaps what you learned about programming wasn't adequate. Maybe you're trying to make it be java.

Of course, I'm old school, and when I work on a moderately complex program, I flow chart it... and I can code directly from that.

                    mark

How do you regression test that stuff?

[Gazzonyx]

Look at LLVM as an instructive example. It's a large complex beast written in heavy C++, but there are bindings for every language you'd ever want to seriously write a compiler in.

Not a great counterexample - The LLVM C bindings are maintained by hand and all of the other bindings are machine-generated from the C bindings.

IIRC, you're involved with LLVM in some way, shape or form. How the heck do you regression test that hand-hacked stuff? I've come to realize lately that even the most trivial of refactorings can be dangerous. I suspect that the reason that the most trivial code changes are so dangerous is because when something seems trivial, we (or more accurately, I) lose perspective sometimes of the big picture and how far out things can be very loosely coupled. I'd be curious to know how you manage that kind of stuff on something that's so difficult to debug when it goes wrong and yet requires hand manipulation of certain things. Surely most of the LLVM guys are smarter than I am and I'm sure it would be automated if there weren't a darn good technical reason to have it that way.

Re:How do you regression test that stuff?

[TheRaven64]

There isn't much testing of the C bindings. They're also in the process of being deprecated in favour of machine-generated ones that are less API stable and have no ABI stability guarantees (precisely because most people don't actually use them from C, they use them from some other language with C bindings). For everything else, there's a bit regression test suite that works by feeding some code (source code when testing clang, IR or assembly when testing bits of LLVM) into one of the tools and then checking that the output matches. Bugs still slip in quite easily, unfortunately. The second tier of tests involves compiling and running a bunch of benchmarks and similar sample code and checking that they haven't got slower (by a statistically significant margin) and that they still produce the right answers. There's a network of buildbots that runs on a variety of operating systems and architectures that first builds and runs the regression test suite on every commit and then (less frequently) runs the executable tests. These catch most regressions, but not all - the rest are caught by users testing betas and filing bug reports.

There's been a lot of research work on improving this. The LLVM Miscompilation Detector, for example, had a semantic model of LLVM IR and would feed real and randomly-generated IR through the optimisation pipeline and then use a theorem prover to attempt to prove that the semantics of the before and after versions were the same. This could then be combined with the LLVM bugpoint tool to find the optimisation pass that performed an invalid transform.

c is the best

[daylight18]

I am working on http://c.happycodings.com/begi... to make c examples. I think C is the BEST