// circle and shape are user-defined types
circle* p = new circle( 42 );
vector<shape*> v = load_shapes();
for( vector<circle*>::iterator i = v.begin(); i != v.end(); ++i ) {
if( *i && **i == *p )
cout << **i << “ is a match\n”;
}
for( vector<circle*>::iterator i = v.begin();
i != v.end(); ++i ) {
delete *i; // not exception safe
}
delete p;
The new modern C++ looks like this: #include <memory>
#include <vector>
// ...
// circle and shape are user-defined types
auto p = make_shared<circle>( 42 );
vector<shared_ptr<shape>> v = load_shapes();
for_each( begin(v), end(v), [&]( const shared_ptr<shape>& s ) {
if( s && *s == *p )
cout << *s << " is a match\n";
} );
To be honest, as a C++ programmer who dates back to the days of Turbo C++ (i.e. before the days of STL), I can honestly say I no longer have any time for the old or new STL based C++.The modern day C++ language is just too full of noise!
To remain relevant C++ needs to try to become a nice, easy to use language without the massive level of noise.
To be honest, as a 10 year+ veteran of C++, I have to say I don't miss it one bit.
- safe by default: you have to opt in to extra magic / conversions. c++ is totally broken here. sure, we'll let you easily use uninitialized data/classes with auto generated constructors, and do conversions on your arguments, that was what you meant, right? I mean really, the shortest and quickest thing to do should always be the safest. make the speed freaks opt in to the 'leet / magic stuff'.
- still keep the option to use exceptions for stuff that, you know, is actually exceptional in your project.
I'm actually looking at modern java and finding it not horrible, but there are some issues in java that don't exist in c++ like 1) nulls 2) type erasure of generics 3) stupid object.equals() defined by default and not typesafe. Sigh.
#include <memory>
#include <vector>
// ...
// circle and shape are user-defined types
auto p = make_shared<circle>( 42 );
auto shapes = load_shapes();
for (auto s : shapes) {
if( s && *s == *p )
cout << *s << " is a match\n";
}
Not sure what MS is thinking.As someone who uses Lisp as well as C++, i disagree.
> from fun and exciting games, to high-performance scientific software, to device drivers, embedded programs, and Windows client apps.
So the flexibility we're talking about is the ability to write an enormous range of types of programs. Are you seriously proposing to write some of these in Lisp? Device drivers, say? Embedded programs? (There are embedded environments where realtime constraints and/or memory limitations mean that you can't cons, but C++ still runs in those environments.)
High performance games don't like the latency of garbage collecting. You can work around it, but it might be awkward.
You can also write the memory manager in C++. Writing it in Lisp might be problematic, both because you don't want to cons or garbage collect while running the memory manager, and also because you need to handle blocks of raw memory handed to you by the OS.
And if you're going to write a Windows client app in Lisp, well, that sounds like masochism to try to write in Lisp, but then I think it pretty much sounds like masochism no matter what language you write it in.
Lisp, and many other languages, including functional, in my belief, are more powerful than C++.