How wonderful that talks of this exiting conference are available for everyone to see for free. Cheers to organisers, sponsors and contributors. Thanks to all speakers for the high quality talks. Thanks Bjarne for the C++!
Great talk. Totally agree with the second half of his talk. I'd like to see the Standards Committee focus on his top-ten list at 1:03:00, especially modules, instead of getting bogged down in minor features.
Here I was worried that C++ was changing too quickly (3 year cycles vs. the +10 years between C++98 and C++11), yet Bjarne complains that the committee is not putting the pedal to the metal! I am surprised and glad at how willing Bjarne is to take risks and push for the development of C++ as a modern language. I would love to see features in the standard library (filesystems and networking, perhaps even graphics some day) that may encourage users of library-plentiful languages such as Python to try C++.
Up-vote because I agree with 80% of what you say. What I strongly disagree is this: "even graphics one day". **NO!!** We _already_ have OpenGL ES 2.x (WebGL), OpenGL ES 3.x, and Vulkan which is _cross platform_, shipping today, and solves an existing problem. We _don't_ need crap like the _2D Cairo Proposal_ written by people who don't understand the basics of "shaders": www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4021.pdf
If you have ever developed on C# - it's must easier and developer friendly - but that easiness comes at costs of performance degrade. It's bit amusing to see "garbage collection" as a plusses of C# and as a plusses of C++ - only from different angle. The main reason why programming language is difficult to evolve is because no matter in which direction you drag it - it touches multiple technical and might be philosophical domains. And reaching an agreement is difficult - since change to language itself has some advantages and some disadvantages. C# sacrifies easiness to use over performance - and it's good as a tool or utility, but not fully scalable for large projects. C++ committee reminds me large organization, many headed, almost like hydra monster. Each has it's own head (committee) and heads don't necessarily "speak" the same language. I understand that being closer to hardware is somehow important, because application performance, but programming language is not necessarily close to hardware itself - for example 3D engine games might have stuff written in assembly to speed up 3d engine. After huge major change to C++ itself it might become different language itself, like this happened with C#. But if you follow the pattern - C++ > C# > natural language - then eventually programming language tries to become closer to what human speaks - because it's easier to understand terminology upon which your mind operates on, and more difficult to understand foreign terminology which is new to you, unclear, non-understandable. Typically for fluent communication it makes sense first to identify vocabulary and terminology, so it would be easier for people to discuss specific subject. Remove synonyms, misleading terms, unclear terms , difficult to understand terminology - with narrower vocabulary it will be easier to discuss specific subject. Programming language evolution should eventually push natural language evolution as well (Which did not change much for 2016 years) - natural language must be well-constructed and possess attributes of programming language - whatever you write is executed. Identify narrower goals for each language improvement - and then it might be so that programming language itself does not needs to be improved, but libraries, tools, and everything else. It's also possible that our chaotic thinking ( = non-structured) reflects to what we do (political kind of discussion, leading nowhere) - and we need to improve not the programming language itself, but ourselves - meaning how we think, construct and model world, problem domains. How in general we try to solve particular problem. Identify requirements, constraints. If problem is in general too complex - simple divide and conquer will do the trick. Why don't split C++ into several dialects, where each will solve it's own problem domain. C++ for multithreading. C++ for math and so on. :-)
I'd rather prefer to see two things in C++ 1. Minimal, but solid STL foundation. Like: - basic set of collections - basic streaming and IO, easy to use and extend - instead of current IOSTREAM crap - solid foundations of collection-agnostic iteration and ranges, instead of current situation when you either need to pull huge chunk of Boost or write tons of boilerplate to implement simple transforming range 2. Industry-wide package, dependency and build manager, with simple way to define one component of distribution with all of its dependencies With these two, we'll be able to have such things as FS, networking, etc. as standalone components, which can then be developed under supervision of committee (if they want so) without slowing down standard progression. Having one small core and several pieces atop is much easier to mantain and develop than one huge 1600+ pages monstrosity.
Although your lay solid arguments and you do have a point, you lost me at "C# sacrifies easiness to use over performance - and it's good as a tool or utility, but not fully scalable for large projects". How much years of experience do you have in software development, because if you claim in 2017 that you can't develop a big scalable project using the C# ecosystem you either have been in the industry working specifically in the C++ domain, or you simply don't have the experience and the knowledge to make that statement.
But too much confidence can lead to "technological hubris" .. always check if your assumptions are true. So many times I saw a code that was supposedly .. or at lest superficially supposedly "free of abstraction cost" that was not even close to free after the real compiler tryined to optimize it within the real program in the real world case scenario.
Technical Specifications. It's for stuff not quite ready to be part of the International Standard C++, but which still is worked on, specified, compilers can implement it etc. When it's time to make a TS feature part of the IS, it would be a known quantity - available and used in the real world. For more details, please see the Standard C++ website: isocpp.org/std/iso-iec-jtc1-procedures
Kunzite M I did some googling and didnt find much about TS.. I did see a result showing Technical Specifications, but I wasnt sure if that was what TS was... with that said I thank you for providing me a solid source to read up on it. I guess one can say TS, is Bleeding Edge Features that may or may not make it into C++.
Minor pet peeve: for c++17 they added a syntax for folding multiple arguments(probably templates again), but the normal variadic functions are still done the old C-way with va_list, va_start, va_arg and all that mess. Is this ever going to change?
Maybe committee members should defer a little more to Bjarne's suggested direction and feature priorities. Spending time on many little features seems less important than major stuff. Thanks for uploading.
matured quite a bit since this post. i guess experience has taught me. getting accustomed to eye strain. thats the biggest issue. new glasses soon. if only crispr gene editing were able to allow my eyes to be those suited for screen staring.
Maybe instead of focusing forces on something that is difficult to evolve - it would be useful to standardize something smaller - like for example call stack determination. On windows there are huge amount of API's for performing stack trace determination, but when you start to analyze them - none of them works good enough / reliably. I'm now not taking about linux, etc - since there might be different libraries, composed differently - don't know if working. (And non-portable anyway) On C# call stack determination existed from very very begging of language. (But does not have good performance). I've now just opened source code for call stack determination (as well as it's design) over here: sourceforge.net/p/diagnostic/svn/HEAD/tree/src/ sourceforge.net/p/diagnostic/svn/HEAD/tree/ - "7. Stack trace determination". but main problem is that this is small utility, it does not have background support. At any time when Microsoft decides to break API compatibility - my call stack determination will perish. Maybe instead of trying to push big thing, we should push smaller things. They makes developer's life easier.
The development of C++ will be slow and bogus until committee will select "reference compiler", or at least "staging compiler", where all proposed features will reside and can be tested by community. Current situation with "MSVC has X, GCC has Y, CLang has Z" is a definite "dialect hell". I'd say this is #1 issue which committee should really address firsthand. Of course, there are other issues on the table. But this one I'd consider as showstopper.
Buzzword (~57 minutes). I couldn't help juggling the letters, and came up with both a word, and a phrase. In the words of Madonna: Strike a POAZ, there's nothing to it. POAZ... ☺ Whoop, the rocks rolled away...
I would love a generic type method pointer container. Possibly with a return type parameter and a parameter for passing values. Something like // if you wanted) a float return and pass an int method_ptrm_ptr; // that would point to an object-method like so: m_ptr=object.method; //and be callable like this: m_ptr(); // imagine method_ptrm_ptr_array[10]; and cycling it for (auto x:m_ptr_array)x(); having several sets of methods to call in the event of this or that. Thats something I would love to have available: If(something)for(auto x:m_ptr_a)x(); if (!something_else)for(auto x:m_ptr_b)x();
www.codeproject.com/Articles/7150/Member-Function-Pointers-and-the-Fastest-Possible this seems to be the most reasonable discussion on the matter I can find. I dont see why it would be a problem, like just make a general container-type that can hold any object.member* ptr, only requiring an existing object on creation.
Methods are in no way associated with object instances. Calling a method is exactly the same as calling a function with the object pointer as a first argument.
the thing that give c++ a lot of push is C... because you can program in C and use extra from C++ without the burden of many high level construct. I don't care about bound checking or pointer safety when my C code work, it works faster without all those check.
I hope Rust will maturize soon and leave C++ behind. Indeed, C++ is an old, convoluted, full of legacy, controversial tool and to work with is very time consuming process. It is not the programming language of the future.
Armin Hamar Sorry, but you are misinformed, Rust works without GC. There is a WIP to make an API for pluggable GCs, but it is far from its finish. Maybe you meant Go (which doesnt work without GC)?
When i need ARC i use Swift. Rust is so ugly in Comparison Look at this Example: Rust: let fname = &*env::args().nth(1).unwrap_or("/usr/share/dict/words".into()); C++: std::string name = (argc > 1) ? argv[1] : "/usr/share/dict/words"; Swift: var file = (CommandLine.argc > 1) ? CommandLine.arguments[1] : "/usr/share/dict/words"; From my perspektive Swift is the easiest to read and Rust is pretty ugly.But hey it is your opinion. And that was only one Commandline arg!
And operator overloading needs to be redone in both languages ! Rust uses Words not Characters(+,- usw.) and C++ has Only an Fixed Amount of Operators (Bad) Swift uses Charackters(+,-,=) and allows to create own Operators with func + ( ) { } wich is very nice precedence can be also be used. So i hope swift or wes or jai will replace C++ and not Rust wich has sometimes an very bad syntax.
Armin Hamar Operator overloading is not so important feature, moreover it should be not "overloading" but just functions with symbolic name (e.g. Haskell and Scala). The most important is compile-time memory checking. Neither Swift nor C++ have it, Swift has runtime refcounting, and it is possible to get loops, memory leaks and null dereferences, same as in C++. Not enough for the language of 21th century.
I guess adoption rate is the measure of success here. If you look at learning curve, speed of implementation, fragmentation of implementations/platforms, it is hardly successful.
That is a good thing! D is a language (like C++ and many languages) that sought to solve a specific problem or set of problems in another language. In D's case, for example, one problem it sought to remedy was the extreme verbosity of templates and lack of constraints in C++'s meta-programming facilities. It is a good thing that C++ and the community are aware of this problem and are aware of alternative solutions such as that provided by D. This is related to Bjarne's point that C++ (and other languages) must continue to catch up and continue to improve. Just as C learned from C++, C++ can learn from D. C++ made C a better language, and D can make C++ a better language. We should encourage languages to learn from one another in mutually beneficial competition, not discourage the dissemination of better techniques.
I'd say it's more about evolving a now really old language so that it will be easier to use, future-proof and still follow its main design principles. And if in that course it collides feature- or principlewise with other (possibly younger) languages like D, so be it and more power to them for making an effort and not being stuck in the past.
Kevlin! You personally told me once that the fact of having such a peculiar name was a blessing and a curse at the same time. Back then, I did not know what you meant. Now I understand.
Read the previous post. It should be pretty sound. I don't think his measure of success is refined enough to call C++ successful. Or, it's deemed succesful in a less than meaningful manner.
Lawrence Millar-Madigan Really? We're not consuming training materials, talks, presentations, updated standards, developer hours, lifespan and hair color? But it's not getting notably better. In Bjarne's defense, he said something along the lines of "you want something else, go somewhere else". That kind of settles everything, doesn't it.
FUNNY- I HAVE TO COMMENT. because, only fool can say "DONT". You invent C++, but your judgement too poor. Its unacceptable. we need language that can solve all, we donot need 1000 funny language and funny stupid teacher [expending taxpayer money] who unable to reasoning everything. If you are not capable to teach, then we have to replace HUMANOID ROBOT as teacher in your place.
Ah, that wonderful feeling I get each year when the CppCon videos start to show up in my youtube feed...
Thanks to all the presenters.
How wonderful that talks of this exiting conference are available for everyone to see for free. Cheers to organisers, sponsors and contributors. Thanks to all speakers for the high quality talks. Thanks Bjarne for the C++!
Long live c++ and Bjarne!
Great talk. Totally agree with the second half of his talk. I'd like to see the Standards Committee focus on his top-ten list at 1:03:00, especially modules, instead of getting bogged down in minor features.
I look forward to this every year :)
33:10 "Theory is a lousy guide for what to do but it is an excellent guide for how to do it" Brilliant!
how about the c++ committee + nvidia + amd would decide some standard way to define matrix/tensor/vector multiplication for gpus and cpus
Thanks for the motivation Stroustrup!
@1:25:36 cool star. 😎
Here I was worried that C++ was changing too quickly (3 year cycles vs. the +10 years between C++98 and C++11), yet Bjarne complains that the committee is not putting the pedal to the metal! I am surprised and glad at how willing Bjarne is to take risks and push for the development of C++ as a modern language. I would love to see features in the standard library (filesystems and networking, perhaps even graphics some day) that may encourage users of library-plentiful languages such as Python to try C++.
Up-vote because I agree with 80% of what you say. What I strongly disagree is this: "even graphics one day". **NO!!** We _already_ have OpenGL ES 2.x (WebGL), OpenGL ES 3.x, and Vulkan which is _cross platform_, shipping today, and solves an existing problem.
We _don't_ need crap like the _2D Cairo Proposal_ written by people who don't understand the basics of "shaders":
www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4021.pdf
If you have ever developed on C# - it's must easier and developer friendly - but that easiness comes at costs of performance degrade. It's bit amusing to see "garbage collection" as a plusses of C# and as a plusses of C++ - only from different angle.
The main reason why programming language is difficult to evolve is because no matter in which direction you drag it - it touches multiple technical and might be philosophical domains. And reaching an agreement is difficult - since change to language itself has some advantages and some disadvantages. C# sacrifies easiness to use over performance - and it's good as a tool or utility, but not fully scalable for large projects.
C++ committee reminds me large organization, many headed, almost like hydra monster. Each has it's own head (committee) and heads don't necessarily "speak" the same language. I understand that being closer to hardware is somehow important, because application performance, but programming language is not necessarily close to hardware itself - for example 3D engine games might have stuff written in assembly to speed up 3d engine.
After huge major change to C++ itself it might become different language itself, like this happened with C#.
But if you follow the pattern - C++ > C# > natural language - then eventually programming language tries to become closer to what human speaks - because it's easier to understand terminology upon which your mind operates on, and more difficult to understand foreign terminology which is new to you, unclear, non-understandable.
Typically for fluent communication it makes sense first to identify vocabulary and terminology, so it would be easier for people to discuss specific subject. Remove synonyms, misleading terms, unclear terms , difficult to understand terminology - with narrower vocabulary it will be easier to discuss specific subject.
Programming language evolution should eventually push natural language evolution as well (Which did not change much for 2016 years) - natural language must be well-constructed and possess attributes of programming language - whatever you write is executed.
Identify narrower goals for each language improvement - and then it might be so that programming language itself does not needs to be improved, but libraries, tools, and everything else.
It's also possible that our chaotic thinking ( = non-structured) reflects to what we do (political kind of discussion, leading nowhere) - and we need to improve not the programming language itself, but ourselves - meaning how we think, construct and model world, problem domains.
How in general we try to solve particular problem. Identify requirements, constraints. If problem is in general too complex - simple divide and conquer will do the trick. Why don't split C++ into several dialects, where each will solve it's own problem domain. C++ for multithreading. C++ for math and so on.
:-)
I'd rather prefer to see two things in C++
1. Minimal, but solid STL foundation. Like:
- basic set of collections
- basic streaming and IO, easy to use and extend - instead of current IOSTREAM crap
- solid foundations of collection-agnostic iteration and ranges, instead of current situation when you either need to pull huge chunk of Boost or write tons of boilerplate to implement simple transforming range
2. Industry-wide package, dependency and build manager, with simple way to define one component of distribution with all of its dependencies
With these two, we'll be able to have such things as FS, networking, etc. as standalone components, which can then be developed under supervision of committee (if they want so) without slowing down standard progression. Having one small core and several pieces atop is much easier to mantain and develop than one huge 1600+ pages monstrosity.
Although your lay solid arguments and you do have a point, you lost me at "C# sacrifies easiness to use over performance - and it's good as a tool or utility, but not fully scalable for large projects". How much years of experience do you have in software development, because if you claim in 2017 that you can't develop a big scalable project using the C# ecosystem you either have been in the industry working specifically in the C++ domain, or you simply don't have the experience and the knowledge to make that statement.
I like his emphasis on practicality and usefulness
1:38:03 "There's a lot of impressions out there, and very often they're wrong."
But too much confidence can lead to "technological hubris" .. always check if your assumptions are true. So many times I saw a code that was supposedly .. or at lest superficially supposedly "free of abstraction cost" that was not even close to free after the real compiler tryined to optimize it within the real program in the real world case scenario.
Great talk. More please
51:10 the middle example deduces to const char* instead of std::string :/
thanks
Rustig aan meneer straustrup ik begrijp het wel. :)
Amazing presentation
7:00 I used to have a sign on my office wall that read, "Anything Worth Doing Is Worth Doing Good Enough."
1:04:50 Ive been jumping back n forth while watching this video... and missed some stuff but what are these TSs?
Technical Specifications.
It's for stuff not quite ready to be part of the International Standard C++, but which still is worked on, specified, compilers can implement it etc. When it's time to make a TS feature part of the IS, it would be a known quantity - available and used in the real world.
For more details, please see the Standard C++ website: isocpp.org/std/iso-iec-jtc1-procedures
Kunzite M
I did some googling and didnt find much about TS.. I did see a result showing Technical Specifications, but I wasnt sure if that was what TS was... with that said I thank you for providing me a solid source to read up on it. I guess one can say TS, is Bleeding Edge Features that may or may not make it into C++.
looking forward to module, module, ...
At 1:03:00 he expresses his disappointment in the progress
Great! Wonderful talk
Minor pet peeve: for c++17 they added a syntax for folding multiple arguments(probably templates again), but the normal variadic functions are still done the old C-way with va_list, va_start, va_arg and all that mess. Is this ever going to change?
Thanks to Variadic Template, you don't have to write that kind of code.
Maybe committee members should defer a little more to Bjarne's suggested direction and feature priorities. Spending time on many little features seems less important than major stuff. Thanks for uploading.
I was thinking the same thing.
I mis-read the title as: **Blame** Stroustrup "The Evolution of C++ Past, Present and Future"
Dear Mr. Stroustrup
Can you upload video tutorial of getting started with C++ with all the current ways of doing things in this language ?
^_^
as a jr dev, product manager, and just overall blossoming professional learning discipline. this talk hit home.
i just wasnt devoted to exceptionalism. didnt know it was okay to be that good. i think one has to give him/her self permission to be the best
Embrace the itch
reach for the stars
matured quite a bit since this post. i guess experience has taught me. getting accustomed to eye strain. thats the biggest issue. new glasses soon. if only crispr gene editing were able to allow my eyes to be those suited for screen staring.
I use gunnar optics every time I code. I never get eyestrain. Definitely a valuable tool.
Bjarne doesn't seem too thrilled about the library features. 1:00:34
Maybe instead of focusing forces on something that is difficult to evolve - it would be useful to standardize something smaller - like for example call stack determination. On windows there are huge amount of API's for performing stack trace determination, but when you start to analyze them - none of them works good enough / reliably. I'm now not taking about linux, etc - since there might be different libraries, composed differently - don't know if working. (And non-portable anyway) On C# call stack determination existed from very very begging of language. (But does not have good performance).
I've now just opened source code for call stack determination (as well as it's design) over here: sourceforge.net/p/diagnostic/svn/HEAD/tree/src/
sourceforge.net/p/diagnostic/svn/HEAD/tree/ - "7. Stack trace determination".
but main problem is that this is small utility, it does not have background support. At any time when Microsoft decides to break API compatibility - my call stack determination will perish.
Maybe instead of trying to push big thing, we should push smaller things. They makes developer's life easier.
I love C++ and Bjarne is my inspiration but I want to be better than him, so that I can make sure after he's gone I can keep C++ going.
You could become better... Just learn Assembly.
45:41 Whoa! This is a good trick. :D
And yet in 2016 "modules" are (still) nowhere to be found ...
Working in VS2015 with a compiler switch, doesn't work with Intellisense though so it's not that useful yet
Love C++, But I can't help writing code in C with Classes.
The development of C++ will be slow and bogus until committee will select "reference compiler", or at least "staging compiler", where all proposed features will reside and can be tested by community. Current situation with "MSVC has X, GCC has Y, CLang has Z" is a definite "dialect hell". I'd say this is #1 issue which committee should really address firsthand.
Of course, there are other issues on the table. But this one I'd consider as showstopper.
Calculus gives POWER!
The real reason behind C++ succes? Well... there is no competition!!
I feed upon it
I like ur x1 x2 system prob gonna steal it
Buzzword (~57 minutes). I couldn't help juggling the letters, and came up with both a word, and a phrase. In the words of Madonna:
Strike a POAZ, there's nothing to it. POAZ... ☺
Whoop, the rocks rolled away...
the genie came out of the bottle and gave me wisdom
My hero Best book sare The c++ language and Programming Its fun to solve problems!
I would love a generic type method pointer container. Possibly with a return type parameter and a parameter for passing values. Something like
// if you wanted) a float return and pass an int
method_ptrm_ptr; // that would point to an object-method like so:
m_ptr=object.method; //and be callable like this:
m_ptr(); // imagine method_ptrm_ptr_array[10]; and cycling it for (auto x:m_ptr_array)x(); having several sets of methods to call in the event of this or that.
Thats something I would love to have available:
If(something)for(auto x:m_ptr_a)x();
if (!something_else)for(auto x:m_ptr_b)x();
we have function and it can be used as you want
Do you mean regular function templates? How would that work tho? I want to fill a map/vector with pointers to any method/object.
RatgCM Torres Like I'm trying to figure this out, but I dont see how regular template functions can do that. Or like, how do you mean?
www.codeproject.com/Articles/7150/Member-Function-Pointers-and-the-Fastest-Possible this seems to be the most reasonable discussion on the matter I can find.
I dont see why it would be a problem, like just make a general container-type that can hold any object.member* ptr, only requiring an existing object on creation.
Methods are in no way associated with object instances. Calling a method is exactly the same as calling a function with the object pointer as a first argument.
wow. scathing takedown of the c++ design by committee. that explains quite a bit
Ik heb hier 2 maanden aan gewerkt ey
the thing that give c++ a lot of push is C... because you can program in C and use extra from C++ without the burden of many high level construct.
I don't care about bound checking or pointer safety when my C code work, it works faster without all those check.
Interfaces mr no worries
Popularity doesn’t mean the best. The most popular router on newegg is the WRT54G, which is an obsolete piece of crap.
I like his paper choice Funny.
I hope Rust will maturize soon and leave C++ behind. Indeed, C++ is an old, convoluted, full of legacy, controversial tool and to work with is very time consuming process. It is not the programming language of the future.
Linker Nick yes but rust is not better (GC)
Armin Hamar Sorry, but you are misinformed, Rust works without GC. There is a WIP to make an API for pluggable GCs, but it is far from its finish. Maybe you meant Go (which doesnt work without GC)?
When i need ARC i use Swift. Rust is so ugly in Comparison Look at this Example:
Rust:
let fname = &*env::args().nth(1).unwrap_or("/usr/share/dict/words".into());
C++:
std::string name = (argc > 1) ? argv[1] : "/usr/share/dict/words";
Swift:
var file = (CommandLine.argc > 1) ? CommandLine.arguments[1] : "/usr/share/dict/words";
From my perspektive Swift is the easiest to read and Rust is pretty ugly.But hey it is your opinion. And that was only one Commandline arg!
And operator overloading needs to be redone in both languages !
Rust uses Words not Characters(+,- usw.) and C++ has Only an Fixed Amount of Operators (Bad)
Swift uses Charackters(+,-,=) and allows to create own Operators with func + ( ) { } wich is very nice precedence can be also be used.
So i hope swift or wes or jai will replace C++ and not Rust wich has sometimes an very bad syntax.
Armin Hamar Operator overloading is not so important feature, moreover it should be not "overloading" but just functions with symbolic name (e.g. Haskell and Scala).
The most important is compile-time memory checking. Neither Swift nor C++ have it, Swift has runtime refcounting, and it is possible to get loops, memory leaks and null dereferences, same as in C++. Not enough for the language of 21th century.
Its a filosofical book The language of the machine
WAAROM!!!!!!!!!!!!!!!!!!!!
day 2 page 483 till end but i am wierd
Cool accent
What a rant lol. Bjarne deserves to let the stuff out ..
I aint the smartest but i try u old corpse
My world shall be born after understandig :P
I guess adoption rate is the measure of success here. If you look at learning curve, speed of implementation, fragmentation of implementations/platforms, it is hardly successful.
and again and again
Numeric functions idk wtf i am talking about i am stupid
Where is math?
C++ basically chasing D...
Exactly!
That is a good thing! D is a language (like C++ and many languages) that sought to solve a specific problem or set of problems in another language. In D's case, for example, one problem it sought to remedy was the extreme verbosity of templates and lack of constraints in C++'s meta-programming facilities.
It is a good thing that C++ and the community are aware of this problem and are aware of alternative solutions such as that provided by D. This is related to Bjarne's point that C++ (and other languages) must continue to catch up and continue to improve.
Just as C learned from C++, C++ can learn from D. C++ made C a better language, and D can make C++ a better language. We should encourage languages to learn from one another in mutually beneficial competition, not discourage the dissemination of better techniques.
I'd say it's more about evolving a now really old language so that it will be easier to use, future-proof and still follow its main design principles.
And if in that course it collides feature- or principlewise with other (possibly younger) languages like D, so be it and more power to them for making an effort and not being stuck in the past.
I hope so. I would like have the features of D without a GC
Kevlin! You personally told me once that the fact of having such a peculiar name was a blessing and a curse at the same time. Back then, I did not know what you meant. Now I understand.
You are C denier and criticizing C++ deniers.
Death before surrender
To be honest wtf its gonna be funny
Meditation
cryptografie
If it wasn't abundantly clear, McDonald's and Coca Cola are successful too. That doesn't make them good.
Read the previous post. It should be pretty sound. I don't think his measure of success is refined enough to call C++ successful. Or, it's deemed succesful in a less than meaningful manner.
You work with c++, you don't consume it. It's popularity is a stronger indication of value.
Lawrence Millar-Madigan Really? We're not consuming training materials, talks, presentations, updated standards, developer hours, lifespan and hair color? But it's not getting notably better.
In Bjarne's defense, he said something along the lines of "you want something else, go somewhere else". That kind of settles everything, doesn't it.
production java
Well than. Homunclus is born. back again.
Nietzsche told me its hard to understand blood
"Simple to read and understand" so, when they would start, cos std libraries not readable by real human being.
Abstraction makes code unmaintainable by anyone other than the guy who wrote it.
You're joking right?
second time is faster
The myth of psychology power of the brain (Fuck em its a ghost)
cout
My own ideas will be c++ i dont wtf they thinking
hehe
Zijn jullie gek allemaal. Waarom zou je niet gewoon met functies werken ey
insects
Das is dingen simpel maken jullie gare of gierig of dom
Its to easy
f(x); jullie zijn gek. ga boeken lezen want tering ey luister naar de maker
Heisenbugs haha
ahhh its barney starsoup +++ back at it again with the rubbish object orientated memes
FUNNY- I HAVE TO COMMENT. because, only fool can say "DONT". You invent C++, but your judgement too poor. Its unacceptable. we need language that can solve all, we donot need 1000 funny language and funny stupid teacher [expending taxpayer money] who unable to reasoning everything. If you are not capable to teach, then we have to replace HUMANOID ROBOT as teacher in your place.