Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
Programming

A New C Standard Is On the Way 305

Posted by samzenpus
from the new-guidelines dept.
Esther Schindler writes "Last year, Danny Kalev — a former member of the C++ standards committed — explained the new features in C++. Now, in C11: A New C Standard Aiming at Safer Programming, he shares an overview of the changes in C — 13 years after the ratification of the C99 standard. Kalev describes the goodies in C11, including multi-threading support, safer standard libraries, and better compliance with other industry standards."
This discussion has been archived. No new comments can be posted.

A New C Standard Is On the Way

Comments Filter:
  • Hmm (Score:2, Funny)

    by mholve (1101)

    No wonder they're not popular. C99? C11? It should be "C... X!" :p

    • The only thing we know for sure is that the ultimate version will be C42. Also, C14 will be rather popular but all implementations will generate binaries that will randomly fail, and will trip off airport security systems if you have them in you mobile devices with you.
      • by cpghost (719344)

        The only thing we know for sure is that the ultimate version will be C42.

        But by then, we'd have lost the hardware to that software answer (unless someone still has a C64 in the attic)

  • On the way? (Score:5, Informative)

    by TheRaven64 (641858) on Monday June 25, 2012 @04:23PM (#40444653) Journal
    It's not on the way, it was released last year. Both gcc and clang are already a good way along implementing it, and we've added a big chunk of the library support to FreeBSD libc already.
  • C11???? (Score:5, Funny)

    by highphilosopher (1976698) on Monday June 25, 2012 @04:27PM (#40444703)

    That's great! I'm still using C4, and every time I compile my code blows up!

  • by Anonymous Coward on Monday June 25, 2012 @04:27PM (#40444719)

    C11 will make var arrays, one of the most widely used C99 features, optional due to pressure from Microsoft, who refuses to implement C99.

    • Do you have any references that this is "due to pressure from Microsoft"? Last I checked, VC++ team has plainly stated that they are simply not interested in working on vanilla C, so why would they care about what is and isn't in C11?

      • by Tough Love (215404) on Monday June 25, 2012 @06:00PM (#40445921)

        Last I checked, VC++ team has plainly stated that they are simply not interested in working on vanilla C, so why would they care about what is and isn't in C11?

        Given that Microsoft's implementation of C++11 also sucks, exactly what is the VC++ team interested in working on?

        • by shutdown -p now (807394) on Monday June 25, 2012 @06:13PM (#40446123) Journal

          For VS 2010, C++11 (then 0x) implementation was actually better than g++. It looks dated today because g++ has more frequent releases and it didn't take it long to catch up and overtake. Ditto for Clang.

          For VS 2012, yeah, it's lagging behind, mostly because a lot of time was spent on C++/CX [microsoft.com] language extensions for Metro. They did update existing features to be spec conforming - e.g. lambdas were previously implementing draft semantics which have changed in the FCD, so those were updated to match the latter. It also adds a bunch of minor stuff like range-for and strongly typed enums, and a good chunk of new libraries (most notably atomics, threads and futures). Here [microsoft.com] are the details.

          There is talk about doing a separate release later on specifically for VC++ to catch up with C++11 support. If you care about that, rather than just seeing it as an opportunity for some MS bashing, please add your vote here [uservoice.com] (I did).

          • Re: (Score:2, Interesting)

            by Anonymous Coward

            Clang only ever looked dated compared to VC++ because the damn thing wasn't even finished yet. I doubt VC++ will ever catch up again with it, though. Clang in a relatively short time managed to go from barely able to compile C++03 to possibly the most complete implementation of C++11.

    • That's easy to fix, just don't use Microsoft's crappy compiler. The days when it could compete effectively with GCC are long gone, and LLVM is coming up fast too.

    • Re: (Score:3, Interesting)

      by Anonymous Coward

      Which is ironic, because Microsoft's Visual Studio team has stated they have no intention of supporting anything newer than C95. I don't understand why Microsoft is even allowed representation on the ISO committee.

      And the bounds-checking API which Microsoft "contributed" is useless. It's clunky, and requires more boilerplate coding than just using the standard interfaces with proper bounds checking. Plus they added a completely new errno_t typedef, which will probably breaks tons of existing code. Not to me

  • by Montreal (594947) on Monday June 25, 2012 @04:29PM (#40444745)
    C99 -> C11, come on guys ...
  • The multi-threaded stuff sounds nice. But bounds checking, really? How difficult is it to check buffer size before copying?

    • Re: (Score:5, Insightful)

      by hawguy (1600213) on Monday June 25, 2012 @05:05PM (#40445175)

      The multi-threaded stuff sounds nice. But bounds checking, really? How difficult is it to check buffer size before copying?

      Given the number of buffer overflow bugs that are found in C programs, apparently it's fairly difficult to do it consistently and correctly.

    • It's not difficult at all, but people forget about doing it all the time. The point of those new interfaces is really more about forcing you to do that check (the function will do it, but you have to provide the size of the buffer to it).

    • by JustNiz (692889)

      Why do you need to explicitly check the buffer size at all?
      A well-designed program ensures you can't crash the buffer to start with.

      • Re: (Score:2, Insightful)

        Are you suggesting it is possible to create a program that doesn't involve buffers?
        Even the simplest Hello World program uses buffers. Even fancy languages that have run-times and virtual machines use buffers. Buffers are an integral part of designing software because they are an integral part of how the machine works at the hardware level.

        • by JustNiz (692889)

          I'm not sure how you think printf"(hello world\n"); uses any dynamic (i.e. user-created/maintained )memory but never mind thats not my point here.

          What I am saying is that you write your code such that once you created a buffer, your program knows its length and is written in such a way that it isn't possible to crash it.

          For example, only use bounded functions like strncpy() rather than unbounded ones like strcpy().

  • All the fuss over C, yet there's still no "H" programming language...

    • by jd (1658)

      Personally, I think they should have named this standard MMXII.

  • by JustNiz (692889) on Monday June 25, 2012 @04:33PM (#40444789)

    If I wanted plastic scissors I'd use Java. Give me my scalpel back.

  • I don't get it... (Score:2, Insightful)

    by xor.pt (882444)
    Why didn't they include some simple OOP features aswell? I understand this is a language for low level programming, and needs to be close to the metal, but many OOP features don't carry any significant overhead, and could just be avoided anyway.
    • If you want OOP and C go with C++ instead.
      C is supposed to be a high level assembly language, so simplicity and brevity are key.

      I find that Objective-C is pretty nice to. It is a very strict super-set of C that adds some OOP functionality and is no where near as complex as C++, in fact it is just a library or two sitting on top of a C compiler to interpret the OOP syntax. It is a shame that it is so tightly bound to Apple products.

      • Objective C, like Smalltalk, has an issue with construction and destruction: Overridden methods use the sub/derived version if called during the execution of the super/base class constructor. This means writing a sub/derived class has the potential to break the already-debugged super/base class constructruction, which must be rechecked for every sub/derived class.

        C++ gets this ALMOST exactly right: Base class constructors get the base class version, derived class constructors get the derived class versio

    • by jd (1658) <<moc.oohay> <ta> <kapimi>> on Monday June 25, 2012 @04:49PM (#40444975) Homepage Journal

      Because C is an ultra-clean procedural language. The entire purpose of using it is the purity. C with OOP can be found in ObjectiveC, C++, C# and D.

      • Because C is an ultra-clean procedural language.

        Haha, ultra-clean is not a term I would apply to either C or its demon child C++. Speaking as someone who has written hundreds of thousands of lines of both.

    • OOP sucks (Score:3, Informative)

      by Weezul (52464)

      What features do you want?

      Automatic memory management? Isn't this what makes C++ so fucking insanely complex? Bad idea.

      Overloading? Umm, that's extremely dangerous in subtle complex code like operating system schedulers, computational code, etc. Very bad idea.

      Inheritance? Nah. Almost as bad as overloading, but also useless for most most activities.

      Templates? No, they're even worse than overloading. I suppose Java interfaces or Haskell typeclass could provide a safe form of overloading. I certainly

      • by jgrahn (181062)

        What features do you want?

        Automatic memory management? Isn't this what makes C++ so fucking insanely complex?

        No. Have you ever used C++?

      • Re:OOP sucks (Score:4, Informative)

        by serviscope_minor (664417) on Tuesday June 26, 2012 @04:27AM (#40450199) Journal

        Automatic memory management? Isn't this what makes C++ so fucking insanely complex? Bad idea.

        You're doing it wrong, frankly.

        If your programs are full of new/deletes in mismatched pairs, then you're missing out on much of the point of C++.

        Overloading? Umm, that's extremely dangerous in subtle complex code like operating system schedulers, computational code, etc. Very bad idea.

        WTF? I write computational code for a living. Good numerics libraries full of operator overloading make my code much, much more simple, reliable and correct. So, I'll stick with overloading thankyouverymuch.

        Inheritance? Nah. Almost as bad as overloading, but also useless for most most activities.

        I've honestly no idea what you're talking about. Classic OOP inmheritance has its uses, and it's used throughout the Linux kernel for instance (see e.g. vtables). C++ just adds compiler support. Other inheritance is just aggregation of data which is an entirely reasonable thing to do.

          Templates? No, they're even worse than overloading. I suppose Java interfaces or Haskell typeclass could provide a safe form of overloading. I certainly acknowledge the desire to parameterize a struct on another type, but that's extremely complex for a low level language.

        Templates are what makes sane numerics libraries great, and container libraries. In fact you've just admitted that they're useful, but for some reason, you don't want expressivity in your low level language. Also, C++ allows parameterization on an int, as well as a type, which is an especially powerful featureand is missing from almost all other generics systems.

        Lambda expressions, ala C++0x? Interesting proposal, not exactly sure how the memory management works out, but perhaps one could grant the compiler the ability to build closures in this way, but subject to the programer's memory management.

        You tell the compiler whether you want the closure to capture by reference or by making a copy of the data. In the former case, the memory in managed in exactly the same way as normal (via destructors) in the referenced variables. In the latter case, the lambda justs acts like a class with a bunch of data members and calls the destructors when it goes out of scope.

        Yes, I'll grant that lambda expressions make sense, but not C++0x's lambda expressions, since they impose a memory management scheme. In essence, lambda expressions in C should be just-in-time optimizations that the programer controls manually.

        I don't think you understnd lambdas. A lambda is a shorthand for making a struct with a bunch of data members and an overloaded operator(). That is all. It interacts with the language in exactly the same way as all other structs.

        In truth, most object oriented language 'features' are actually bad design choices, well unless your doing GUI work where the error object oriented programming creates aren't catastrophic.

        Now we have a kernel of truth which doesn't apply to C++. Yes, OO concepts are somewhat limited in scope. They are useful for some things, but not for others. People have widely abused them to apply to everything either by choice or because languages often provide few other mechanisms. C++ does provide those other mechanisms and doesn't force you to make make everything a massive ovject heirachy.

        Apart from in a small number of libraries I use, I make very little use of classic OO concepts like polymorphism etc. I use classes and methods, but as an encapsulation and occasionally aggregation mechanism. That's a far cry from classic OO, though.

        Yes, there are vaguely functional features like parametric polymorphism and lambda expressions that might aid low-level programming, but they're complex enough to require a proof-of-concept language first. C must avoid the mad dash into standardization that created C++'s complexity.

        lolwut? C++ a mad dash in t standardisation? Good troll, sir.

  • Who needs threads? (Score:4, Insightful)

    by spaceyhackerlady (462530) on Monday June 25, 2012 @05:09PM (#40445223)

    I've never been a fan of putting multi-threading/multi-tasking in a programming language. You get one abstraction of threads/tasks, and that's it. If you want to do it differently, you have to do it yourself with library calls. So why not leave it that way and keep the language simple?

    Unless there is an awfully good reason not to (and I haven't encountered one yet), I use pthreads.

    ...laura

    • I've never been a fan of putting multi-threading/multi-tasking in a programming language.

      This is probably to promote and facilitate the use of C on multi-core machines, but I haven't RTFA.

    • by moogla (118134)
      They standardized the naming convention of thread primitives for C11-compliant compilers and C-libraries. The system can still use posix threads under the hood, but now there is a <threads.h> intended to be forward compatible that you can leverage.

      You will still be able to use one or the other. In some implementations you may be able to leverage both facilities (like using _Thread_local storage qualifiers in code that otherwise uses posix threads).
      • by Jerslan (1088525) *
        Yeah, but you really should try to code for a single standard... Mixing them because one or even most implementations support it is bad juju IMHO.

        GCC and Clang/LLVM may support using _Thread_local with a pthread, but some other compiler you may need to use (for some strange reason) might not and then you would need to do a lot of work to get things going with that compiler.

        It's a pet peeve of mine when I see a lot of mixed standards... If you're going to use pthread, use pthread. Don't try to mix it w
    • by Mr Thinly Sliced (73041) on Monday June 25, 2012 @06:27PM (#40446317) Homepage Journal

      IIRC it's because without putting explicit constraints on the memory model (needed for threading), you end up with holes of varying sizes when talking to memory from threads.

      It's mostly to do with CPU caching / memory barriers and having a consistent temporal view of data in and out.

      If it's not in the language, you end up with each platform/compiler having their own approach to barriers / atomics which makes glueing different bits of code together with different approaches a crap shoot when it comes to consistency.

      Here's a good place to start [open-std.org]

  • by PaddyM (45763) on Monday June 25, 2012 @05:17PM (#40445305) Homepage

    cause this language goes to 11
    *puts on sunglasses*

  • Bullshit (Score:4, Insightful)

    by Tough Love (215404) on Monday June 25, 2012 @05:48PM (#40445707)

    Where did C99 go awry? Some of its mandatory features proved difficult to implement in some platforms. Other C99 features were considered questionable or experimental, to such an extent that certain vendors even advised C programmers to replace C with C++.

    Speak for yourself Microsoft. It is not our fault that you can't implement C99 features properly or on time. For the rest of us C99 is alive, well and popular. Just avoid Microsoft's shoddy compiler and you will be fine. Both GCC and LLVM do the job properly.

    By the way, similar comments apply to Microsoft's tardy and dodgy implementation of C++11.

  • Nothing says irrelevant standard like having standardized multithreading support on year 2011.
  • I'd like an updated "The C programming language", although not necessarily by K and almost certainly not R! 'cos otherwise, I'll wind up buying some other book and I'll hate it because it's not as nice as K&R. And then I'll be all cross. :(
  • Here are two successful examples: Clang and OpenCL.
  • by RKBA (622932) on Monday June 25, 2012 @11:18PM (#40448731)
    Anything but the pure C as defined in the sacred Whitebook [amazon.com] pollutes the simple beauty of C and obscures the language's clarity and its similarity to the instruction sets of most common CPUs.

Chemist who falls in acid is absorbed in work.

Working...