by celerity on 11/2/17, 6:46 PM with 61 comments
by CamTin on 11/2/17, 8:38 PM
https://www.youtube.com/watch?v=TH9VCN6UkyQ
Just as the scripting languages took a big bite out of C/C++ usage starting in the 90s, I think we're seeing another couple use-case for C/C++ pull off:
1) stuff that is performance sensitive but security sensitive as well (Rust) 2) stuff that is soooo performance sensitive that Rust and C++ are actually too bloated, but which isn't really security sensitive so the guarantees that Rust/Modern C++ offer aren't worth it (Jai, Blow's language).
Category 1 is clearly real, but Category 2 might be too small to sustain itself (though Blow makes an economic argument that it would be worth it).
Are we just going to keep peeling back C/C++ users from the pack with more specifically-useful languages until there are none left except for those maintaining legacy code? Or are there use-cases where C++ will continue to make sense?
I guess a lot of this depends on whether or not we can meaningfully "modernize" C++ through the standards process without simply bolting on a lot more features that add to the bloat. I wouldn't wager much that this trick can be pulled off.
by chrisaycock on 11/2/17, 8:14 PM
For example, Java has an interface, in which methods are declared but not defined. The proposal for metaclass gives a demonstration of what an interface in C++ could look like:
interface Shape {
int area() const;
void scale_by(double factor);
};
// the dollar sign ($) prefix indicates reflection and metaprogramming
$class interface {
// the constexpr indicates compile-time execution
constexpr {
// raise an error if there are data members
compiler.require($interface.variables().empty(),
"interfaces may not contain data");
// loop over all functions
for (auto f : $interface.functions()) {
// raise an error if move/copy functions are present
compiler.require(!f.is_copy() && !f.is_move(),
"interfaces may not copy or move");
// function must be public
if (!f.has_access())
f.make_public();
compiler.require(f.is_public(),
"interface functions must be public");
// function must be virtual
f.make_pure_virtual();
}
}
// add a destructor
virtual ~interface() noexcept { }
};
See the full proposal here:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p070...
by 0xFFC on 11/2/17, 7:55 PM
Update: From Herb's blog :
"Also, a vocal minority in the committee strongly want a syntax that does not include the $ character (not just for $class, but also for $expr reflection) because they have large code bases that use $ in source code that is not C++ code but is processed to emit C++; removing $ is an easy change at any time and we’ll just follow what the committee decides for reflection syntax (in fact, the alternative syntax I showed in the endnote above removes the need to write $). So further work is needed on those items, but fortunately none of it affects the core model."
https://herbsutter.com/2017/07/26/metaclasses-thoughts-on-ge...
P.S. I really hope that vocal minory would win ;)
But overall the proposal is what I have been talking about for a long time.
by makecheck on 11/3/17, 9:39 PM
C++ needs a new strict set of rules that (ideally for individual files, to start) prohibits some set of older/deprecated features from even compiling. That way, you know where the language is going and you adapt.
by WoodenChair on 11/2/17, 9:46 PM
by jstimpfle on 11/2/17, 10:01 PM
Now we only write
struct Point {
int x;
int y;
};
class Point {
private:
int x;
int y;
public:
Point() =default;
~Point() noexcept =default;
Point(const Point&) =default;
Point& operator=(const Point&) =default;
Point(Point&&) =default;
Point& operator=(const Point&&) =default;
};