Slashdot Mirror
C++14 Is Set In Stone
jones_supa (887896) writes "Apart from minor editorial tweaks, the ISO C++14 standard can be considered completed. Implementations are already shipping by major suppliers. C++14 is mostly an incremental update over C++11 with some new features like function return type deduction, variable templates, binary literals, generic lambdas, and so on. The official C++14 specification release will arrive later in the year, but for now Wikipedia serves as a good overview of the feature set."
Wouldn't it more useful for it to be set in silicone?
NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
I like to stay as close to the metal as I can get. I'd use assembler, but many of my projects are cross platform, so c it is.
I've fallen off your lawn, and I can't get up.
Intend to stay abreast of the spec, do you?
I've fallen off your lawn, and I can't get up.
C++ used to be a lightweight set of templates for C. It was good. It was versatile. It was useful. It was easy to learn and easy to develop with it.
Now it's one of a million things in the computing world suffering so much feature creep, designed by people who have been tinkering with the platform for the past 30 years - that being the only reason they have had enough time to properly learn all its features.
One day we'll return to a time when computing tools are written for the user rather than for the glory (or the profit) of the tool-builder. We'll understand once again where apparent monstrosities like Visual Basic and COBOL came from: a desire to enable the non-expert to quickly find, understand and implement the features he/she needs for a specific set of use cases. We will return to a time when development and administration was a skill not outsourced to one of a dozen big companies across the planet.
I liked a lot of the C++11 features. Lambdas, move semantics, std::mutex, and consistent initializers are all cool things.
Looking at C++14 I see a lot of expansion of the support of the auto type. I have not found a scenario where I perer auto, so I'm curious about such a large focus on it.
C++14 can not be used to date someone. Believe me, I've tried:
#include "your roommate"
#define SAFEWORD pineapple
int main(void) {
exit 1;
}
And that's as far as I get without compiler errors. Maybe I should try older. Anyone know a way to discover age of carbon based things?
What you C++14 is what you get.
It's just pathetic that so many years down the road the committee can't get its act together to provide this much loved C99 feature at least for POD. This is a major issue, if not the major issue) with porting C code. The word wanking comes to mind. Here, GCC guys really need to take the lead but it's starting to feel like GCC guys are actually holding back on it. It's not like the coding is a challenge.
When all you have is a hammer, every problem starts to look like a thumb.
// comments are in the c99 standard.
Copyright (c) 1990 - 2014 Dice. All rights reserved. Use of this comment is subject to certain Terms and Conditions.
So you get a mix of people trying to bolt their favorite features from cobol, haskell, java, etc onto C. You know, to improve it. Maybe they should just stick to their failed language and leave the rest of us alone?
The second problem (as if there were only two!) is that they don't update the language to reflect what people what people are doing with it, they update the language to reflect what they think people should do with it. That means adding features that no compiler can implement (like exported templates) or feature nobody can or should use (like std::vector<bool> or cout/cin). I think they've started getting a little bit better in this regard, adopting better parts of boost rather than just making shit up. And clang++ implements draft proposals and provides feedback. Of course they're still full of dumb ivory tower ideas like adopting cairo.
Copyright (c) 1990 - 2014 Dice. All rights reserved. Use of this comment is subject to certain Terms and Conditions.
...but I am glad they are here!
(yes gcc has them already...)
4wdloop
concepts?
now we just need to throw the stone in the Marina Trench.
factor 966971: 966971
Still no automatic garbage collection without smart pointers.
And it only took 30 years to implement.
Washington state baby yeah :)
this kind of initialization [performed with C99 designated initializers] is trivial to do, and more readable, with helper classes and constructors
A designated initializer for static data can initialize data in a read-only section. "Helper classes and constructors" mutate an object, which inflates the size of your program's read-write section.
with some new features like function return type deduction,
Hey, K&R C had function return type deduction back in the 70's .
...of course it always guessed "int", but IT HAD IT.
What kind of automatic garbage collection do you want? The tracing garbage collection seen in Java and Python is fine for memory, but most programs access resources other than memory. Java and Python* don't guarantee that finalizers will ever be called. This means a program relying on automatic garbage collection leaks resources unless the programmer is disciplined enough to apply the dispose pattern consistently. True, Java and Python provide syntactic sugar for the dispose pattern within a single block of code. But when an object's lifetime exceeds one block of code, such as when an object holds a reference to another object, the programmer's conceptual overhead of the dispose pattern is at least as large as manual object lifetime management in C++.
* CPython calls the __del__ method on anything not held cyclically because its reference semantics resemble C++'s std::shared_ptr, but other Python implementations can and do behave differently.
After all, this is the organization that accepted open corruptions that created the monster known as OOXML, and then expect people to pay hundreds just to take a peek at this so-called 'standard' that even M$ wouldn't really use it except to sabotage ODF.
C++ has always been a steaming pile of hacks build on top of an insecure, unsafe language that was glorified assembler. No amount of new hacks on top of the old hacks will ever fix this software disaster. It created one software disaster after another such as Netscape 6.
I think you mean Sillicon
silicone:
Any of a class of synthetic materials that are polymers with a chemical structure based on chains of alternate silicon and oxygen atoms, with organic groups attached to the silicon atoms. Such compounds are typically resistant to chemical attack and insensitive to temperature changes and are used to make rubber, plastics, polishes, and lubricants.
(stolen from DaBum) I am dyslexia of borg - your ass will be laminated.
Now, to drop it off a bridge, into the East River!
"Flyin' in just a sweet place,
Never been known to fail..."
...C++14 decays to N++14 as well.
I mean like supporting writing of shared objects without having to deal with inconsistent mangling approaches between compilers, having to resort to manually-maintained export files? Or having to use the exact same version of the compiler between the library and the code using it? Being able to expose functions throwing exceptions through a library (gasp! who wants to do that?) or to reliabily use an std container through the library interface?
Without all this, you can't write C++ code spliting the logic into multiple binaries in a platform-independant way...
This is the main reason why all libraries are still written in C, or at least expose interfaces in C.
I must confess I'm not a C++ master (more like a beginner). :)
But I have written code in many languages:
Assembly (x86, x64, AVR, ARM)
asp, asp.net
Basic (think Commodore 64)
Batch script
C
C++
C#
Clipper (anyone)
D
Delphi
Java
Javascript
Lua
Matlab
Pascal
Perl
Php
Python
Shell script
VB script
Verilog
VHDL
I have not yet used but I'm interested in F# and Go. (async and concurrent programming among other things)
I think C++ lacks certain features, native data types, and (a feel of) simplicity that other modern languages have.
For example I like Pascal style strings much more where you can determine it's length in O{1} time among other things (return, concate, resize). (same for arrays, where in C you have to pass length separately, and hope you won't cause buffer/stack overflow)
Template meta-programming is a great, sometimes magical tool
(which you can dig your grave with if you are not careful -- debugging, maintaining, understanding, editor intellisense).
I do not expect anyone to start programming in assembly, I wouldn't. Though there are High Level Assemblers out there, (the lack of) portability is a major disadvantage of it.
But I have not yet worked on a processor that had not supported carry flag, and I do not know any way to access it from native C code. (Lets say shifting a 1024 bit integer, adding, subtracting them....) Checking for integer overflow is also a pain in the ass (pre check/post check. And I have not found any way writing my code that would get the compiler to produce the right assembly.) Also on processors I worked on multiplying 2 registers results in a register pair because that't how multiplication works and extends the range of possible results (and this is why there is a carry flag used during addition), but C is blissfully or painfully ignorant of this (depending where you are looking it from) and this is usually where code readability starts going down the toilet when you are precasting integers and alike. (When you need to multiply two 32 bit int (and maybe then divide it so the result is still 32 bit), but you cast it to int 64 pre multiplication, will it result full 64 bit multiplication (software multiplication on 32 bit processor)?)
But I guess code efficiency does not matter and that is why we have longer response times now on GHz processors, than we had on 486... (and of course because of bling)
Reading code examples about why you need auto in the comments makes me cry. WTF is boost::asio::placeholders::bytes_transferred!? (It was a rhetorical question, don't answer it:)
This is what the improved readable code looks like?
So C is not close enough to hardware to understand it and generate efficient code, and not high level enough to abstract and understand things that humans would like to use naturally. We have to think in bits and clocks to write some broken codes.
I'm an embedded developer so I'm stuck with C (and C++) for now.