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]

'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

[phantomfive]

The same logic works for many other languages

Which languages?

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]

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

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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...

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

[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

[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

[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.

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: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: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.

"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

[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

[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

[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.

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)

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.

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

[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

[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: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.

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

[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

[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.

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.]

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?

[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?

[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

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.

As a perl developer...

[CaptnCrud]

does this mean I can raise my rates? : p

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!

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:C is the best

[thinkwaitfast]

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

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: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: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.

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.

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: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...

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 ;)

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.

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.

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.

c is the best

[daylight18]

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