Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

C++14 Is Set In Stone

timothy posted about 2 months ago | from the but-it's-a-soft-stone dept.

Programming 193

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

Sorry! There are no comments related to the filter you selected.

Stone (4, Funny)

buchner.johannes (1139593) | about 2 months ago | (#47703709)

Wouldn't it more useful for it to be set in silicone?

Re:Stone (3, Informative)

makq (3730933) | about 2 months ago | (#47703733)

Silistone!

Still... (3, Interesting)

fyngyrz (762201) | about 2 months ago | (#47703739)

...using c. Although I do like to comment thusly, and so prefer a compiler that understands at least basic c++:

// comment

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.

Re:Still... (5, Funny)

makq (3730933) | about 2 months ago | (#47703783)

Various black hats appreciate your dedication to C.

Re:Still... (0)

Anonymous Coward | about 2 months ago | (#47704271)

Black hats love idiots who think using other languages (written in C) are somehow now immune from buffer overflows.

Go write some Python/Java/C# and I'll show you some overflows in their JVM that make a basic "Hello world" program crash. The main difference is that in C I choose to allow such bugs or behavior. In the other languages the bugs are *already* there in the JVM and there's nothing you can do about it. Your hello world program is susceptible.

Re:Still... (0)

Anonymous Coward | about 2 months ago | (#47704413)

Black hats love idiots who think using other languages (written in C) are somehow now immune from buffer overflows.

The difference is that the C code only has to be written right once, then all programs will be correct.

Re:Still... (1)

gnupun (752725) | about 2 months ago | (#47704673)

Java has good out-of-bounds checking for arrays, unlike the non-existent support in C. Could you explain how exactly a buffer overflow can happen in Java (calling native code is not allowed)?

Re:Still... (1)

TheRaven64 (641858) | about 2 months ago | (#47705015)

If you can't call native code, you probably don't have a working JVM. The Oracle JDK and OpenJDK each include around a million lines of C in their standard libraries. That doesn't mean that you won't find it easier to write secure code in Java, it just means that you probably don't have much less C code in your TCB for a Java program than you do for a C one.

Re:Still... (1)

angel'o'sphere (80593) | about 2 months ago | (#47704991)

A basic 'Hello World' program can not crash, and everything that has no input can't be made crash from the outside to a buffer overflow. 'Hello World' programs fall into that category.

I doubt you know all bugs of all JVMs that could a particular program of me make crash, if you only have acces to it from the outside, and would even go so far, you can not do it if you have console access.

And for that matter: it is hard enough to crash/abuse a C program if you can not debug/analize it.

Re:Still... (1)

cytg.net (912690) | about 2 months ago | (#47705399)

" JVM that make a basic "Hello world" program crash." with a reference to a .c ? Yes please show me that "hello world" .. oh cherrypicking a jvm from 2001 doesnt count.

Re:Still... (0)

The Evil Atheist (2484676) | about 2 months ago | (#47703787)

Have you ever written C code which uses a switch statement based on what type a struct/union is and calling the relevant code for it? Have you ever used qsort?

Re:Still... (4, Interesting)

fyngyrz (762201) | about 2 months ago | (#47704281)

Have you ever written C code which uses a switch statement based on what type a struct/union is and calling the relevant code for it?

No. When I use structures as objects (which is often), they almost always contain a pointer to a block of general methods appropriate to that structure, as well as containing any methods unique to the object, all of which are called through the object/structure, so it would be unusual, at least, to be testing the object type in order to choose an object-specific procedure to call. However, I do mark each object type with a specific ID and serial as they are created, along with a tag indicating what procedure created them, as these things facilitate some very useful memory management and diagnostic mechanisms.

Have you ever used qsort?

I am aware of qsort. But I have my own multi-method sort library that I use. Most of them locate the comparison mechanisms they are to use through the procedures specified by the objects they are asked to sort. Likewise list management, memory management, certain types of drawing primitives and image processing primitives, image handling mechanisms, associative storage, basically anything I have run into that I thought likely I would need more than once. I am positively locked into the idea that if I write it, I can fix it, and the number of bugs and problems that fall into the "maybe they'll fix the library someday" class are greatly reduced. I'm a little less picky if I have the source code to a capability I didn't actually write and can supply my own version if and as needed. A good example of something like that is SQLite. Actually having the source code and compiling it in reduces my inherent paranoia to a somewhat duller roar.

Re:Still... (0)

Anonymous Coward | about 2 months ago | (#47704477)

Have you ever written C code which uses a switch statement based on what type a struct/union is and calling the relevant code for it? Have you ever used qsort?

Isn't that why people use GLib/GObject? To use a well-tested, object oriented, multi-language, cross-platform abstraction layer on top of C.

Re:Still... (1)

K. S. Kyosuke (729550) | about 2 months ago | (#47704807)

Are you sure there isn't a better way [piumarta.com] , even in C?

Re:Still... (1, Informative)

Anonymous Coward | about 2 months ago | (#47703829)

Those are proper C comments since C99, no need for C++

Re:Still... (2)

jones_supa (887896) | about 2 months ago | (#47703885)

Interestingly, Visual Studio got C99 library support [msdn.com] last year. I'm mentioning this because the C support in VS has mostly been a desert scene with tumbleweeds passing by. I'm not sure how close VS is to full C99 support and what pieces are possibly missing. Does anyone know?

Re:Still... (1)

slashdice (3722985) | about 2 months ago | (#47704367)

VC++ is a C++ compiler. They generally only add C features when they're incorporated into C++ (which will be never for some of them).

Re:Still... (1)

jones_supa (887896) | about 2 months ago | (#47704869)

All right, so basically we're hanging on what kind of C-like features a subset of C++ happens to provide.

Re:Still... (1)

fyngyrz (762201) | about 2 months ago | (#47704113)

Ha. Funny. Thank you, didn't know that.

Re:Still... (1)

doti (966971) | about 2 months ago | (#47704777)

And also the bool type, and the ability to declare variables after the beginning of a function.

Re:Still... (4, Informative)

tlhIngan (30335) | about 2 months ago | (#47703853)

...using c. Although I do like to comment thusly, and so prefer a compiler that understands at least basic c++: // comment

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.

End of Line terminated comments ("//") actually are in the C spec as part of C99. And while it did take GCC a little while for that to be accepted in C mode, most other commercial compilers accepted them just fine. (C++ is not completely compatible with C, mind you, unlike Obj-C which is fully C compatible. This can cause issues if you try to compile C code using a C++ compiler rather than a C/C++ compiler)

Now, one interesting thing in C++14 is binary literals (using "0b" a la "0x" for hex). That seems handy, though it would be more appropriate to be in C than C++ as C generally needs that sort of specification. Though, annoyingly, they didn't seem to allow use of something like _ to break long literals up into human-readable groups. I mean, a 32-bit string of bits is already hard enough to visually see, allowing the use of something like "_" in the string to help arbitrarily break up and group long constants would be helpful. (Even in hex it would be useful when doing 64-bit values).

E.g., would you rather try to see which bit is set in a string like "0b001011010011011101011100" or have it broken up like "0b0010_1101_0011_0111_0101_1100" or "0b00101101_00110111_01011100". If it's a bit field, you may even want "0b001011_010011011_01_0_111_0_0" if breaking it into fields has meaning.

Such a small change to help readability...

Re:Still... (2)

adonoman (624929) | about 2 months ago | (#47703997)

I don't know if it was officially accepted, but I believe they added ' as a digit-group separator: 0b0010'1101'0011'0111'0101'1100

Re:Still... (0)

Anonymous Coward | about 2 months ago | (#47705227)

Yea because we would never confuse 'a' with 1'000'000.00

Re:Still... (5, Informative)

Anonymous Coward | about 2 months ago | (#47704049)

Though, annoyingly, they didn't seem to allow use of something like _ to break long literals up into human-readable groups.

Yes they did. It's not underscore, it's apostrophe. For example:
        auto a = 0b100'0001; // ASCII 'A'
        auto million = 1'000'000;

See here:
        http://isocpp.org/wiki/faq/cpp14-language#digit-separators>http://isocpp.org/wiki/faq/cpp14-language#digit-separators

Re:Still... (5, Informative)

Imagix (695350) | about 2 months ago | (#47704059)

Uh, yes they do. Don't rely on summaries to list all of the features of the language. From N3797: An integer literal is a sequence of digits that has no period or exponent part, with optional separating single quotes that are ignored when determining its value. Example: The number twelve can be written 12, 014, 0XC, or 0b1100. The literals 1048576, 1’048’576, 0X100000, 0x10’0000, and 0’004’000’000 all have the same value. — end example

Re:Still... (1)

dmbasso (1052166) | about 2 months ago | (#47704077)

E.g., would you rather try to see which bit is set in a string like "0b001011010011011101011100" or have it broken up like "0b0010_1101_0011_0111_0101_1100" or "0b00101101_00110111_01011100". If it's a bit field, you may even want "0b001011_010011011_01_0_111_0_0" if breaking it into fields has meaning.

Such a small change to help readability...

If you're really interested in readability you would probably define those bits, like:

#define HIGHSTUFF (0b001011 << 17)
#define NOTSOHIGHSTUFF (0b010011011 << 8)

and then or them together.

Alternatively you could define a macro for your bit field, like:

#include
#define bitfield(a,b,c,d) 0x##a##b##c##d
int main() {
        printf("%x", bitfield(f,f,f,f));
}

Re:Still... (0)

Anonymous Coward | about 2 months ago | (#47704169)

... Though, annoyingly, they didn't seem to allow use of something like _ to break long literals up into human-readable groups. I mean, a 32-bit string of bits is already hard enough to visually see, allowing the use of something like "_" in the string to help arbitrarily break up and group long constants would be helpful. (Even in hex it would be useful when doing 64-bit values).

E.g., would you rather try to see which bit is set in a string like "0b001011010011011101011100" or have it broken up like "0b0010_1101_0011_0111_0101_1100" or "0b00101101_00110111_01011100". If it's a bit field, you may even want "0b001011_010011011_01_0_111_0_0" if breaking it into fields has meaning.

Such a small change to help readability...

You can already use whitespace to separate strings in string constants:

"This" "Is" "Already" "One" "String"

Not sure if that applies to non-string "string" constants, though.

Re:Still... (1)

UnknownSoldier (67820) | about 2 months ago | (#47704349)

> Now, one interesting thing in C++14 is binary literals (using "0b" a la "0x" for hex).

Hey, it only took ~40 years for a C based language to add binary literals! (It will only take another 40 to standardize pragmas such as struct packing.)

Using 0b is dumb. They should of used a letter that isn't in hex, say 0z1101.

Using '_' would of been nice but the C++ community doesn't really have a fucking clue about solving real-world problems. Witness ...

Herb Sutter looking into adding Cario 2D into C++
"http://developers.slashdot.org/story/14/01/04/2115249/cairo-2d-graphics-may-become-part-of-iso-c"

This is your typical design-by-committee of a "Solution looking for a Problem"

--
"One of my most painful programming memories was working on a professional C++ compiler. My colleagues used to joke:
There are 2 problems with C++: It's design, and implementation. "

Re:Still... (0)

Anonymous Coward | about 2 months ago | (#47704443)

Herb Sutter looking into adding Cario 2D into C++
"http://developers.slashdot.org/story/14/01/04/2115249/cairo-2d-graphics-may-become-part-of-iso-c"

This is your typical design-by-committee of a "Solution looking for a Problem"

Yikes! So basically what he's saying is that from that point on libstdc++.so will _require_ libcairo.so in order to print hello world?

Re:Still... (1)

UnknownSoldier (67820) | about 2 months ago | (#47704639)

Unknown. Pure madness lies that way so maybe the committee has come to its senses ...

One can always hope/pray/etc...

Re:Still... (2)

Carewolf (581105) | about 2 months ago | (#47705353)

...using c. Although I do like to comment thusly, and so prefer a compiler that understands at least basic c++: // comment

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.

End of Line terminated comments ("//") actually are in the C spec as part of C99. And while it did take GCC a little while for that to be accepted in C mode...

What on Earth are you talking about?? Using C++ comments in C was a GCC extension that made it into C99.

Still... (1)

slashdice (3722985) | about 2 months ago | (#47704341)

// comments are in the c99 standard.

Re:Still... (1)

angel'o'sphere (80593) | about 2 months ago | (#47704939)

Year, it is really annoying that 'computers' don't really contain metal any,ore now as all important parts are made from semi conductors, I feel your pain :-/

Support for your position (4, Funny)

fyngyrz (762201) | about 2 months ago | (#47703757)

Wouldn't it more useful for it to be set in silicone?

Intend to stay abreast of the spec, do you?

Re:Support for your position (5, Funny)

Anonymous Coward | about 2 months ago | (#47703809)

You boob. Take your puns and go.

Re:Support for your position (2, Funny)

Anonymous Coward | about 2 months ago | (#47704133)

Okay. Ta-ta!

Re:Support for your position (3, Funny)

jones_supa (887896) | about 2 months ago | (#47704339)

Goodbye. Now I'm just gonna relax and listen the tits chirping.

Re:Support for your position (1, Funny)

Anonymous Coward | about 2 months ago | (#47704399)

Well, support for the c++ standard did seem to be sagging for a while. I'm glad it is finally getting some more support. Maybe we will seem some more perky behavior from it.

Re:Support for your position (3, Funny)

geekoid (135745) | about 2 months ago | (#47704205)

Did they make any changes in mammary allocation?

Re:Support for your position (2)

iluvcapra (782887) | about 2 months ago | (#47704481)

Yes, but it corrupted the malloc areola.

Re:Stone (2)

marxidad (337005) | about 2 months ago | (#47703765)

*silicon

Re:Stone (1)

Carewolf (581105) | about 2 months ago | (#47703803)

Wouldn't it more useful for it to be set in silicone?

Assuming you mean silicon, then; no - Setting things in stone is better than writing them in the sand.

Re:Stone (1, Informative)

geekoid (135745) | about 2 months ago | (#47703895)

silicon isn't sand. It's found in sand and stone, among other places.

Re:Stone (0, Flamebait)

Anonymous Coward | about 2 months ago | (#47703919)

In your vagina as well.

Re:Stone (-1)

Anonymous Coward | about 2 months ago | (#47705241)

Really Carewolf? Really?

Re:Stone (0)

Anonymous Coward | about 2 months ago | (#47703897)

Lithography is still the name of the process.

Re: Stone (1)

Anonymous Coward | about 2 months ago | (#47704029)

Silicon maybe.
Silicone is a little rubbury.

Re:Stone (0)

Anonymous Coward | about 2 months ago | (#47704243)

Wouldn't it more useful for it to be set in silicone?

Silicone is what they use for breast implants. Silicon is what chips are made of. That said, I'm not sure I wouldn't prefer the former... :-)

Re:Stone (1)

cluening (6626) | about 2 months ago | (#47704619)

Sounds a bit wobbly. Maybe silicon instead?

Oh god so what? (0, Flamebait)

Anonymous Coward | about 2 months ago | (#47703773)

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.

Re:Oh god so what? (1)

Arkh89 (2870391) | about 2 months ago | (#47703857)

I see a lot of people complaining about the complexity of the language. But it seems that no one dares to give any example. For my part (I had a 3-days introduction to C++, everything else was learnt by practicing) I don't find it really enormous. Aside from the auto (because type deduction = E.V.I.L., use typedef's if you don't want to spend your time typing std::someType::some_const_iterator), I fail to see what change is mandatory in the language structure. What you wrote few years ago is still correct and you don't have to use these new features to work...
So what is it?

Re:Oh god so what? (1)

Rockoon (1252108) | about 2 months ago | (#47703901)

use typedef's if you don't want to spend your time typing std::someType::some_const_iterator)

..because what is needed is another level of indirection combined with increased namespace clutter...

Why not just #define ...

Re:Oh god so what? (0)

Anonymous Coward | about 2 months ago | (#47703969)

Because #define isn't known to the compiler and doesn't obey scoping rules, bucknut.

Re:Oh god so what? (4, Insightful)

Anonymous Coward | about 2 months ago | (#47703989)

Any individual can choose a usable subset of a complex system. The problem is that each individual chooses a different subset.

So in the real world, you have to understand nearly all of it in order to be able to maintain other people's code or to work as a team.

I've been writing C++ since around 1990, when the idea of an STL was being bounced desperately around by Musser and Stepanov. Back then, C++ was a genuinely simple enough language to implement in - nobody pretended that it was anything more than a C compiler preprocessor, which is mostly what it still is, with a little bit of runtime support, but there's just so much of it.

Re:Oh god so what? (1)

Anonymous Coward | about 2 months ago | (#47704165)

Most of the people who complain about C++ are busy maintaining legacy C++ codebases, typically written before even C++98, making all of the worst possible decisions, ignoring best practices, etc. C is harder to make visibly screwed up, which is why people think it's better, even though it's really just that C makes it easier to write subtly broken code. For example, every obvious way to deal with integer overflow will break on particular sets of compiler optimizations, because C sticks it's fingers in it's ear and says "LALALALALA INTEGERS DON'T OVERFLOW LALALALALA I'M ELIDING YOUR SECURITY-CRITICAL OVERFLOW CHECKS LALALALALA".

Re:Oh god so what? (1)

fnj (64210) | about 2 months ago | (#47704357)

Most of the people who complain about C++ are busy maintaining legacy C++ codebases, typically written before even C++98, making all of the worst possible decisions, ignoring best practices, etc. C is harder to make visibly screwed up, which is why people think it's better, even though it's really just that C makes it easier to write subtly broken code. For example, every obvious way to deal with integer overflow will break on particular sets of compiler optimizations, because C sticks it's fingers in it's ear and says "LALALALALA INTEGERS DON'T OVERFLOW LALALALALA I'M ELIDING YOUR SECURITY-CRITICAL OVERFLOW CHECKS LALALALALA".

You do understand that integer overflow is not buffer overflow, right? Integer overflow has absolutely nothing to do with security.

Re:Oh god so what? (3, Insightful)

TechyImmigrant (175943) | about 2 months ago | (#47704581)

> Integer overflow has absolutely nothing to do with security.

Yes it does. I take it you don't write much crypto code?

Re:Oh god so what? (4, Informative)

TheRaven64 (641858) | about 2 months ago | (#47705041)

Integer overflow has absolutely nothing to do with security

Integer overflow has been in the top five causes of CVEs for several years running. Buffer overflows, sadly, are still at the top.

Re:Oh god so what? (1)

chuckugly (2030942) | about 2 months ago | (#47704379)

How would you assign a lambda to a variable without auto?

Re:Oh god so what? (4, Insightful)

geekoid (135745) | about 2 months ago | (#47703925)

COBOL is an excellent language for hat it was designed for. I can only assume your hate comes from ignorance.

It seems to me, your hate would be better directed at poor engineering and software engineering standards then the tools.

Re:Oh god so what? (1)

Lazere (2809091) | about 2 months ago | (#47704019)

Read it again. There was no hate for COBOL there, just a recognition of the hate others express.

Re:Oh god so what? (0)

Anonymous Coward | about 2 months ago | (#47704237)

COBOL is an excellent language for hat it was designed for. I can only assume your hate comes from ignorance.

It seems to me, your hate would be better directed at poor engineering and software engineering standards then the tools.

No. Its not.

I've coded in COBOL. If you want to know what's wrong with COBOL, learn PL/I.

Re:Oh god so what? (0)

Anonymous Coward | about 2 months ago | (#47704517)

I worked with COBOL-85 for a year, and honestly there is nothing to be ignorant about because the language has nothing.

IT HAS NO FUNCTION - I mean it, literally, and you can forget the rest of things such as data abstraction and closures. It's worse than writing assembly.

Re:Oh god so what? (2)

jones_supa (887896) | about 2 months ago | (#47703963)

With one thing you are spot on: C++ has a massive feature set. Even Bjarne says that he has trouble mastering the full feature set at any given moment.

But here's the catch: you're not supposed to know it all. C++ is like a large store where you go and "shop" just the features you need. You can keep it super simple and write C-style code and just use classes as the only C++ feature, if you want to.

Then again, modern C++ [msdn.com] allows you to also write many things much more elegantly and safely than before.

Re:Oh god so what? (5, Interesting)

ShanghaiBill (739463) | about 2 months ago | (#47704419)

But here's the catch: you're not supposed to know it all. C++ is like a large store where you go and "shop" just the features you need. You can keep it super simple and write C-style code and just use classes as the only C++ feature, if you want to.

That is fine if you are a team of one, and you never read code written by others.

Re:Oh god so what? (2)

jones_supa (887896) | about 2 months ago | (#47704835)

Doom 3 was written like that.

Re:Oh god so what? (4, Insightful)

fnj (64210) | about 2 months ago | (#47704455)

Err, the implication is that you can also write C++ that is not guaranteed to be maintainable by anybody short of a complete master, which even Bjarne says he is not. I think it is fair to estimate that the number of complete C++ masters in the world is in the single to double digits; no more. It may be you can identify another programming language for which that holds true. I don't think I can.

Other successful computer languages do not have that problem. Any competent C programmer can maintain any C code, and the same for python and Java. Perl is arguable; the problem is not complexity but opaqueness.

Re:Oh god so what? (1)

jones_supa (887896) | about 2 months ago | (#47704851)

Yeah, that's a good point.

Re:Oh god so what? (1)

geekoid (135745) | about 2 months ago | (#47704229)

C++ is C with classes. Templates didn't even come around until about after 1990.

Sheesh.

Oh god so what? (1)

slashdice (3722985) | about 2 months ago | (#47704533)

The problem (as if there's only one!) is that the c++ committee members only have one thing in common: They hate C!

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.

Re:Oh god so what? (1)

serviscope_minor (664417) | about 2 months ago | (#47705151)

The problem (as if there's only one!) is that the c++ committee members only have one thing in common: They hate C!

No, they all like C++, that's the one thing in common.

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.

You're an idiot and you've never clearly never followed the C++ standards committee process. Basically you're bitter because...

Maybe they should just stick to their failed language and leave the rest of us alone? ...you are actually a genuine failuer. By the way, branding one of the most successful computer languages of the present day and all time as a "failure" does indeed make you look ignorant and bitter.

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,

It's a balancing act. No one likes to use nonstandard features. They then add reatures which make writing the type of code that people actually write easier. So they do add features that reflect what people are doing with it.

That means adding features that no compiler can implement (like exported templates) or feature nobody can or should use (like std::vector or cout/cin)

My god, you're taking a few missteps from 16 years ago as why the committee today is bad? Is that the best you can do seriously?

And the only reason they put exported templates in is becuase of all the users clamouring for it.

Of course they're still full of dumb ivory tower ideas like adopting cairo.

Bsaically I've come to the conclusion that anyone using the phrase "ivory tower" is an angry, bitter, twisted person. Most likely both opinionated and stupid, but angry because no one will listen to their whitterings.

Why do we need Auto? (2)

EMG at MU (1194965) | about 2 months ago | (#47704087)

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.

Re:Why do we need Auto? (0)

netsavior (627338) | about 2 months ago | (#47704171)

Those poor ex-visual basic programmers have suffered through strong typing for too long.

Re:Why do we need Auto? (0)

Anonymous Coward | about 2 months ago | (#47704277)

Or those poor haskell programmers. Oh dear.

Re:Why do we need Auto? (5, Informative)

kthreadd (1558445) | about 2 months ago | (#47704365)

Auto does not mean loose typing. It still has a type, you just don't have to write it but it will be there and will be enforced by the compiler.

Re:Why do we need Auto? (0)

Anonymous Coward | about 2 months ago | (#47704373)

auto is plenty strong. strong doesn't need to mean redundant.

Re:Why do we need Auto? (4, Informative)

Xrikcus (207545) | about 2 months ago | (#47704779)

Lambdas are a primary place where auto is there precisely because C++ is a strong, statically typed language as far as possible. The alternative might be polymorphic lambdas, which would require dynamic typing. With auto the type you get, and can propagate through templates, is the type of that specific lambda. With polymorphism the type you'd get is the type of a lambda, from which you'd need to infer which lambda. Auto ensures that with a lambda, though the type is not easily known to the programmer, the type can be statically defined in the code and propagated accordingly.

Re:Why do we need Auto? (1)

Anonymous Coward | about 2 months ago | (#47704257)

It's rather useful in templates, where the type of an expression can be an arbitrarily-complex function of the parameter types.

Sure, there are alternatives, but they often require a lot of effort for something which the compiler can do easily.

Re:Why do we need Auto? (4, Informative)

e r (2847683) | about 2 months ago | (#47704305)

Herb Sutter responded to this on his blog (Sutter's Mill): http://herbsutter.com/2013/08/... [herbsutter.com]

Re:Why do we need Auto? (3, Interesting)

Anonymous Coward | about 2 months ago | (#47704311)

I used to think that, until I realized:

auto handler = boost::bind(&Class::write_callback, this, boost::ref(timer), boost::asio::placeholders::error, boost::asio::placeholders::bytes_transferred);

/// what is the type of handler?
boost::asio::async_write(device, buffer, handler);

Iterators another good one:

typedef void (*FunctionPtr)();
std::map<std::string, FunctionPtr> knownCommands;

/// elsewhere:
std::string command = "example";

/// what do you like more?
std::map<std::string, FunctionPtr>::iterator it = knownCommands.find(command);

/// or
auto it = knownCommands.find(command);


if (it != knownCommands.end()) { /* do something useful */ }

Re:Why do we need Auto? (3, Informative)

Anonymous Coward | about 2 months ago | (#47704327)

There are several cases where auto is critical.

For instance with lambdas, it is no longer even possible to write out the types:

auto itr = boost::make_filter_iterator([](const Bar &bar) {return bar.foo;},vect.begin(),vect.end());

The type of itr is boost::filter_iterator, but it cannot be written out because there is no way to enter to the type of the lambda.

It also eliminates nasty hacks like you see in BGL:

property_map::const_type pm = get(vertex_index,graph);

The property_map specialization framework is nasty and complex and conveys no meaning to the caller beyond what 'get' already says. So instead of the nasty property_map we use 'auto' and decltype(get(vertex_index,declval()), which is just as informative to the reader.

Another good use is to get rid of duplications:

auto ptr = make_shared(..);

Is better than the duplicative:

std::shared_ptr ptr = make_shared(..);

That isn't even touching how useful it is when working with template meta programming. There are many cases where building up a return type is incredibly complex, and not useful to the reader because the underlying type is obscured by template meta programming anyhow.

The improvements to auto are mostly fine tuning. Eg return type deduction eliminates the nasty idiom that has developed:

auto foo() -> decltype(the_return_function(...))
{
        return the_return_function(...)
}

The duplication is very common when using auto for a return.

Re:Why do we need Auto? (0)

Anonymous Coward | about 2 months ago | (#47704439)

So, you have a->foo()->bar(). Now, you need to call also a->foo()->baz(). Evaluating foo() is expensive so you don't want to do that twice and its return type is a horribly complex mess of templates and namespaces.
What do you do? Press magic key and get a list of return types which can be conveniently expanded? duh?

Except that's the wrong answer. If a language requires you to use an ide to fill out that kind of bullshit, it's a broken language. Thus, auto. (not that it wouldn't still be otherwise horribly broken..)

Re:Why do we need Auto? (1)

fnj (64210) | about 2 months ago | (#47704523)

This does not address your question specifically, but C++14 fixes some glaring holes in C++11. Well, one hole for damn sure. They clean forgot to put std::make_unique in C++11, even though std::unique_ptr was there. The hole was obvious to anyone who saw std::make_shared and then went to try and look up its obvious complement.

It was also high time and way beyond high time they added binary constants. Frustrating as hell they STILL found it too hard to support binary formatting in iostreams, though. Evidently it was too hard to add such a dead simple and obvious thing as std::bin, analogous to std::hex. So we already have a hole to fondly hope C++17 (sigh) deigns to fill for us.

Re:Why do we need Auto? (3, Informative)

Stele (9443) | about 2 months ago | (#47704575)

auto definitely makes writing looping constructs with iterators shorter/easier, without additional typedefs, but by far the nicest use for it is in writing templates, where a specialization or type-dependent mapping my occur in the template using a helper function, and you don't necessarily know what the intermediate type might be. Sure, you could use some complicated typedefs, which may require additional traits classes, but auto handles it nicely.

Re:Why do we need Auto? (1)

godrik (1287354) | about 2 months ago | (#47705137)

I use auto a lot. auto (or equivalent syntax) are used a lot in functional programming languages. Mostly in short functions where I do not really care what the proper typename is. It is clear how the variable behaves and that is I care about it. Often, I know I get some kind of iterator, but the actual type might not be easy to find. In particular, it might depend on a template parameter. So I guess I could add plenty of typedefs to get an easy to write type. But what is the point really?

C++14 dating is a lie! (0)

Anonymous Coward | about 2 months ago | (#47704093)

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?

Hmmm (0)

Anonymous Coward | about 2 months ago | (#47704115)

What you C++14 is what you get.

Re:Hmmm (0)

Anonymous Coward | about 2 months ago | (#47705325)

Carbon 14 set in stone. Just the thing to confuse future archeologists.

Where are my designated initializers? (3, Insightful)

Tough Love (215404) | about 2 months ago | (#47704127)

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.

Re:Where are my designated initializers? (1)

UnknownSoldier (67820) | about 2 months ago | (#47704425)

You want the committee to focus on practical problems?! LOL. You are more delusional then them! :-)

Recently they wanted to add a 2D graphics API to the language! Yeah, let's re-implement OpenGL ES.
http://developers.slashdot.org... [slashdot.org]

This is your typical design-by-committee of a "Solution looking for a Problem". God forbid we actually have _standardized_ pragmas like we do for OpenMP.

The committee has only one motivation:

  "Job security by obscurity."

C++ has a become a total cluster-fuck of over-engineering. It jumped the shark back in 2000 when they forgot the mantra of GOOD programming & design:

    Keep it simple, stupid!

D seems to clean up some of this crap but sadly it not properly supported across multiple platforms.

Re:Where are my designated initializers? (1)

jones_supa (887896) | about 2 months ago | (#47704679)

Recently they wanted to add a 2D graphics API to the language! Yeah, let's re-implement OpenGL ES. http://developers.slashdot.org... [slashdot.org]

Zee wot? Cairo is nothing like OpenGL ES.

Re:Where are my designated initializers? (0)

Anonymous Coward | about 2 months ago | (#47704913)

Also, some of the people of the committee would like to have a standardized API for text messaging. "Da Fuq" was, obviously, my first thought.

Re:Where are my designated initializers? (1)

fnj (64210) | about 2 months ago | (#47704633)

HEAR, HEAR!!! [Pounds fist on table repeatedly]. I have been dying for this since gcc added the nonstandard extension and then C99, seems a lifetime ago, codified it in the C standard. What the HELL, guys. With all the wang-yanking ivory tower crap they did implement in C++11 and 14, much of it very hard work to master using, let alone implementing, is there any way in hell you can blame us for calling you out on the immature assholery of not simply copying this dead-simple feature from C99?

This should have been the number one improvement put into C++03. Leaving it out of 11 was unforgiveable, and leaving it out of 14 is goddam obstruction.

And yeah, I agree with you, gcc not adding it as a nonstandard C++ extension is sick. Particularly if clang and maybe Microsoft joined them and they all tried to shame the C++ standards committee.

Re:Where are my designated initializers? (1)

Stele (9443) | about 2 months ago | (#47704667)

Maybe it's not part of C++ because this kind of initialization is trivial to do, and more readable, with helper classes and constructors. Just a theory - I wasn't even aware of designated initializers.

What I find pathetic is all of the C programmers who still think C++ is slow, bloated, or impossible to understand.

only 45 years to approve binary literals? (1)

4wdloop (1031398) | about 2 months ago | (#47704693)

...but I am glad they are here!
(yes gcc has them already...)

What about (1)

MouseTheLuckyDog (2752443) | about 2 months ago | (#47704765)

concepts?

Re:What about (1)

godrik (1287354) | about 2 months ago | (#47705071)

Indeed! Where are concepts! These is the number 1 addition to C++ most of us need! I am sure that they were not added for a good reasons. But programming template is currently a nightmare because of the duck typing of the meta programming system.

Dear standardization committee, we NEED a solution to the template compile time debugging problem.

C++ set in stone (3, Funny)

doti (966971) | about 2 months ago | (#47704947)

now we just need to throw the stone in the Marina Trench.

Garbage collection without smart pointers (0)

Anonymous Coward | about 2 months ago | (#47705339)

Still no automatic garbage collection without smart pointers.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?