7 ms·
C11, yo
- lmm 14y ago>which drives coders away from C, which harms (a different type of) portability. I'd say writing as much code as possible in other languages (whether guile or perl/python/ruby/java/...) improves portability. C code tends to be less portable than that written in higher level languages.
- EliRivers 14y agoI disagree. C compilers are everywhere. A C compiler is the standard tool expected (and provided) with every embedded processor I've ever worked with. As a rule of thumb, if a microprocessor is meant to be user-programmable, you get a C compiler with it. It will be a long time before I get a Ruby interpreter for a blackfin processor.
- lmm 14y agoYou get a C compiler sure, but will a given C program work on it? Maybe not for ruby, but I'd certainly expect most new processors to run Java. A quick search suggests there are ruby interpreters for blackfin - and if you have a ruby interpreter you can be reasonably confident any given ruby program will behave correctly on it.
- tobiasu 14y agoThere is a bare-metal ruby cross-compiler? Or are you talking about the ruby interpreter written in C running on an OS written in C? Java is available? Again are we talking about a bare-metal Java compiler (possibly supported by hardware being able to execute a subset of Java natively), or the large collection of software written in C and C++ that is supplied by Oracle?
- lmm 14y agoRuby interpreter written in C running on an OS written in C. No this is not inconsistent; I said move as much code as possible away from C. That which is impossible to move has to stay in C (and will probably be responsible for 99% of the headaches when porting to a new architecture).
- EliRivers 14y ago"A quick search suggests there are ruby interpreters for blackfin" I disagree. A google search for blackfin ruby interpreter did not suggest that to me.
- kelnos 14y agoGood luck getting a JVM working reasonably well on a low-horsepower CPU. C is always your best bet for something usable.
- drv 14y ago"All the major C compilers have committed to implementing these features": including MSVC, which doesn't even implement C99? "Static compile-time assertions allow the use of sizeof() and friends" could already be done with the preprocessor and typedefs; see e.g. C_ASSERT: http://msdn.microsoft.com/en-us/library/windows/desktop/ms679289(v=vs.85).aspx http://msdn.microsoft.com/en-us/library/windows/desktop/ms67... It will still be nice to have a standard way to do it, though.
- sageikosa 14y agoTechnically, Microsoft doesn't tout their C++ compiler as a C compiler, just a C++ compiler that has support for certain older C features.
- hornd 14y agoThere are very few C compilers that implement the whole of C99.
- stephencanon 14y agoIf you don't support the standard you don't have a C compiler; MSVC is a lot of things but a C compiler is not one of them.
- jibsen 14y agoAccording to Herb Sutter on Visual C++ (assuming this is still the official stance): "We do not plan to support ISO C features that are not part of either C90 or ISO C++." http://herbsutter.com/2012/05/03/reader-qa-what-about-vc-and-c99/ http://herbsutter.com/2012/05/03/reader-qa-what-about-vc-and...
- brigade 14y agoMicrosoft doesn't consider themselves a C compiler vendor. They only ship a C compiler because they shipped a C compiler. Really, I think we'd be better off if they actually removed it from future toolkit releases. That way no one would be confused into thinking that Microsoft supported C.
- angersock 14y agoI support a lot of the language cleanup, but goddamnit can we either a.) bring pitchforks to Redmond to get proper VS support, b.) bring pitchforks to $CLANG_DEV_LOCATION to get proper Windows support for Clang thus obviating the need for a, or c.) write some shims so that C11-ish features are available in Windows. :( There is a world outside of Linux and mobile.
- kevingadd 14y agoI don't know if Microsoft will ever have enough C-only customers to actually get around to supporting C11. They do a bad enough job of supporting larger subsets of their customers (like .NET developers).
- pmr_ 14y agoMaybe I'm misinterpreting your language but I don't see how pitchforks will help. There are simply not enough Windows users among clang/llvm developers and none of the companies that are invested in clang/llvm use it for Windows technology. If Windows users want a working C/C++ compiler they will have to stand up and actually contribute, but that seems to be a foreign concept to many of the developers coming from that platform (purely anecdotal and I have no real evidence). It is not like anybody is actively trying to make clang/llvm not work under Windows. On the other side of the fence Microsoft has repeatedly stated that they are not interested in supporting more of ISO C than they already do and want to focus on C++ (even going so far as to recommend the C++ compiler for developing C code). And apparently that "focus" on C++ hasn't even helped them overtake or even get even with their free (beer and freedom both) alternatives. That goes a long way to show in what state their compiler division is and so I wouldn't even bet on getting anything halfway decent should they commit to C11. That is not to say that there are highly competent people on that team, but there is simply to much to do and too many old mistakes to rectify first.
- cremno 14y ago>they are not interested in supporting more of ISO C >* For C++11 conformance, we're interested in implementing the C99 Standard Library Source: https://connect.microsoft.com/VisualStudio/feedback/details/748766/c-11-header-cinttypes-is-missing-microsoft-visual-studio-ultimate-2012-rc-11-0-50522-1 https://connect.microsoft.com/VisualStudio/feedback/details/...
- comex 14y agoI love $new_C_stuff, but variable-length arrays are generally a security hole waiting to happen. Be very careful before using them.
- eridius 14y agoWhat do you mean by that? All I can think of is taking user-supplied input as the length of the VLA, but I would hope anyone using VLAs are not stupid enough to think that giving the user control over the size of their stack frame is a good idea.
- comex 14y agoI'd say that most of the time when you want an array whose size is variable, the size relates in some way to user input. Your mileage may vary.
- pascal_cuoq 14y agoVariable length arrays: If, because of parameters outside the programmer's control, a call to malloc() fails to allocate an array of n doubles, it returns NULL. If, because of parameters outside the programmer's control, the variable-length definition “array double arr[n];” fails to allocate an array of n doubles, the behavior is undefined. Your choice.
- cygx 14y agoSee http://stackoverflow.com/a/12412774/48015 http://stackoverflow.com/a/12412774/48015 for the rationale behind the introduction of VLAs.
- popee 14y agoHow do you "allocate" memory on stack? You can always do 'double arr[huge_constant]' and, depending on resources, overflow heap data. Or with recursion. Damn those bugs >:-) The thing about C is that programmer should do check size before calling function with double arr[n]. Isn't that point of C? On the other hand, user can make fast stack allocation which, depending on situation, can be good. Stack is insecure by default, OS should put it really far from other parts. In embedded systems, well there you must always think about these kind of things. Btw, how are (p)thread stacks implemented? Every thread has it's own stack, that's ein interesting situation.
- pascal_cuoq 14y ago> How do you "allocate" memory on stack? I have no idea why you would be asking me this, unless you are quibbling over the idiom associating the verb “allocate” and the complement “on the stack”, in which case Google should be able to find you about 56000 uses, in context, of this precise association. > The thing about C is that programmer should > do check size before calling function with double arr[n]. > Isn't that point of C? What part of “because of parameters outside the programmer's control” do you not understand? What limit, in a portable C program, do you check the value of n against before allocating a VLA of size n?
- Aardwolf 14y agoI don't really see how variable length arrays save time? Those seem like a feature that belongs in C++ but definitely not in C imho. However, what I like to see in C are "//" style comments, declaring variables at other places than start of scope, the integer types with bit size specified, etc... But the VLA's? They're created on the stack, right? So you'd need malloc for large ones anyway. What actually would save time (for the coder of course) in C, imho, would be a way to automatically clean up resources no matter where you exit a scope or function. Something like destructors do in C++. E.g. if you could type something like "onleave free(myresource);" which would execute what you type after "onleave" whenever the scope exits.
- brigade 14y agoHowever, what I like to see in C are "//" style comments, declaring variables at other places than start of scope, the integer types with bit size specified, etc... All of those are already in C99... And malloc() takes more time than subtracting a variable from the stack pointer. Though VLAs have pitfalls so you probably don't want to use them outside of throw-away code anyway.
- lobster_johnson 14y ago> However, what I like to see in C are "//" style comments, declaring variables at other places than start of scope Good news, those are both part of C99 (http://en.wikipedia.org/wiki/C99 http://en.wikipedia.org/wiki/C99), which is supported by both GCC and Clang.
- cjh_ 14y agoRegarding your 'onleave' idea; go has a similar construct called defer [1], it is exactly what you are talking about and (imo) is a really elegant way of dealing with cleanup. [1]http://golang.org/doc/effective_go.html#defer http://golang.org/doc/effective_go.html#defer
- buster 14y agoAs someone who just started playing around with C++ after many many many years of absence, i must say i am surprised how well it goes. I love the new "auto" keyword for variable declarations. I had a hard time to get into pointer arithmetics again but it's slowly coming back. Also i took this opportunity to use LLVM/clang, Qt5, Qt Creator and all in all i'm really surprised. I thought everything would be much more cumbersome, i'd have to dig through terrible error messages or reinvent basic stuff on my own, but so far the stdlib and Qt offer what i need. If you're like me amd avoided C/C++ like the plague, i'd suggest you try again next time, it may not be as bad as you remember :P
- archangel_one 14y agoJust FYI: this article is about C11, not C++11. It was easier in the past when their revisions came in different years ;-)
- buster 14y agoI know, but it's slightly related :P
- jstanley 14y ago"Variable-length arrays, alone, would save a tremendous amount of time and energy" That is, until you overflow the stack with no way to know if that's going to happen and no way to recover if it does.
- Someone 14y agoFirstly, that can happen with fixed-length arrays or even without arrays, too. Secondly, I don't have access to the official standard, but it would surprise me if it required VLA's to be stack allocated. That would give implementers of the language too little leeway. In fact, I see no clear reason why the standard would mention the word 'stack' at all. A quick check of the candidate PDF of the standard seems to confirm that, but that's not the real standard, and it may be a shortcoming of the iOS PDF reader.
- tytso 14y agoUnfortunately, Variable Length Arrays (VLA's) are optional in C11. So use of VLA's may lead to portability problems, especially if you care about your code getting compiled on minority compilers.... such as MSVC. For this reason I'm not planning on allowing the use of C11 features in e2fsprogs, because I know there are people compiling libext2 so they can access ext[234] filesystems using FUSE on Windows (and MacOS, but MacOS is at least using a reasonable compiler).
- huhtenberg 14y agoNo computed goto's :-/
- cpeterso 14y agoWhy are C11's char16_t and char32_t simply typedefs for uint16_t and uint32_t instead of new distinct types? C++ needed a distinct char16_t type so functions could be overloaded for both char16_t and uint16_t. I guess the C standards committee wants to ease char16_t adoption for code that is already using uint16_t for UTF-16.