As you already say, if you are very concerned about performance in a situation with lots of small objects you can use structs. Simply ignoring structs because you are too lazy to use them does not make D slow. With a bit of experience and a few rules of thumb it's not hard to choose.
But structs do not have the same treatment as classes.
I think maybe you're talking about what is called "scope" now. It allocates the memory for the class on the stack. Yeh, it doesn't cover every possible use case of by-value classes, but it can be a nice optimization.
And a heck of lot difficult to spot. At least, in C++, it's obvious what is a pointer and what it is not.
Yes you use structs when you want an efficient aggregate value type. Classes and structs have different semantics in D. It's pretty easy to choose once you get the hang of it. If you are likely to want to put virtual functions on the thing, make it a class. If you want to pass lots of them around by value, make it a struct. If you can count on your fingers how many instances you will have, make it a class -- the hit from allocation won't matter. There is some gray area in-between, granted, but in practice it's usually pretty clear, and the benefit is that you do completely eliminate the slicing problem by going this route. If you really can't decide you can also write the guts as a mixin and them mix them into both a class and a struct wrapper. Or just write it primarily as a struct, and aggregate that struct inside a class. The use cases that are left after all that are pretty insignificant.
Why do all that? no thanks. C++ is much better in this regard.
D's template system has gone far beyond C++'s.
Nope. It hasn't.
It's even far beyond what C++0x is going to be.
Nope, it isn't.
Alias template parameters
C++ has typedef.
template mixins
Mixins are bad from a design standpoint.
static if
C++ can do it with templates.
a host of compile-time introspection facilities, the ability to run regular functions at compile-time
And introduce big complications in the code.
type tuples
Boost provides them.
D metaprogramming is to C++ metaprogramming as C++ OOP is to OOP in C. It takes a technique that the previous language begrudgingly permitted and turns it into one that is actually supported by the language.
Nope. The C++ and D template type system are exactly the same. In fact, if you ask Walter, all the template tricks in D are done using the C++'s Turing complete template system.
The GC is the way to go for complex application. The reason is simple: the GC has a global overview over all memory usage of the application (minus special stuff like OpenGL textures). This means that the GC can reuse previously allocated memory blocks, defragment memory transparently, automatically detect and elimitate leaks etc.
But with tripling memory usage, at least. Which does not help performance at all.
Somewhat less obvious is that a GC allows for by-reference assigments being the default. In C++, by-value is default. a = b will always copy the contents of b to a. While this is OK for primitive stuff, it is certainly not OK for complex types such as classes. In 99.999% of all cases, you actually want a reference to an object, and not copy that object. But, as said, the default behavior of assignment is "copy value".
It depends on the object. I wouldn't say 99.999%. More like 50%-70%. Forcing all classes to be accessible by reference is silly, in my opinion.
This is a big problem in practice. The existence of shared_ptr, reference counting pointers etc. are a consequence. We could redefine the default behavior as "pass a reference of b to a", but who will then take care of the lifetime of b? Using a GC, this last question is handled trivially; when the GC detects 0 references, b is discarded.
The non deterministic nature of finalization creates big problems though. At least with shared ptrs, objects are not held up alive until the gc says it's time to delete them. Which may be never.
Now, once you have by-reference as default, things like closures get much easier to introduce. Neither D nor C++ have them at the moment, but C++0x requires considerably more efforts to introduce them. Functional languages all have a GC for a reason.
I disagree. The design of C++0x is retarded. They should have introduced closures by creating value objects which represents the closure.
D did another thing right: it did not remove destructors, like Java did. Instead, when there are zero references to an object, the GC calls the destructor *immediately*, but deallocates the memory previously occupied by that object whenever it wishes (or it reuses that memory). This way RAII is possible in D, which is very useful for things like scoped thread locks.
In order to now how many references are to an object, there are only two solutions: a) reference counting, b) object tree traversal. The first one has the problem of cycles, and so it is not used, and the second one is very costly and it is also not used. So, your comment is totally wrong. D has RAII, but it does not use reference counting or object scanning and marking.
They also simplified the syntax, which is one of the major problems of C++. Creating D parsers is not hard. Try creating a C++ parser.
Indeed, but not relevant to this thread of the discussion (regarding performance).
Now, what they got wrong:
- operator overloading
- const correctness
- lvalue return values (which would solve most of the operator overload problems)
- no multiple inheritance (which does make sense when using generic programming and metaprogramming; just see policy-based design and the CRTP C++ technique for examples)
- crappy standard library called Phobos (getting better though)
- and ANOTHER de-facto standard library called Tango, which looks a lot like a Java API and makes little use of D's more interesting features like metaprogramming, functional and generic programming
And for these reasons and others, C++ is still preferable, in my book, than D.
But the syntax is all wrong. It's easy to forget that an object is allocated as 'scope', because the syntax is the same as in heap allocation.
And the template system is D is exactly the same as in C++. The differences are superficial, only in syntax. D's templates is a Turing complete system, just like in C++.
I don't think D will ever have the high performance of C++, because D objects are all allocated on the heap. The D 'auto' keyword is just a compiler hint (last time I checked) to help in escape analysis. D has structs, but one has to design upfront if a class has value or reference semantics, and that creates a major design headache. Avoiding the headache by making everything have reference semantics negates the advantages of struct.
D is a mix of C and Java, with the C++ template system bolted on top. It is no way C++. D is not what a veteran C++ programmer excepts as the next generation C++.
Yes, more effort goes into a modern game, but the tools have vastly improved as well.
The price of a game does not reflect the effort to develop it, but the effort to experiment with new engines, graphics tricks, art etc. Most of this effort is thrown away, and the price reflects that.
If game developer companies were more focused, this would not have occurred.
End-to-end encryption is required at all levels of the internet. Until that is available, the internet will never be secure, because someone will be able to read the non-encrypted data you send and reply with a fake response.
Does it matter if the doom is this year or, let's say, in 100 years? it's still doom. You may live, your children may not.
Why do you look at this in such a narrow view? even if this destruction comes, let's say, in 1000 years, or in 10000 years, it's still something to be concerned with.
Unless all you care about is yourself and only yourself.
The first few fights were interesting, due to good "AI". But then it was all fighting. No spectacular events in any form whatsoever. Just endless corridors with fighting, and the occasional horror scene that did not blend well to the fighting atmosphere of the game.
Compare that to HL1...the giant squid monster that hunts with sound, the monster you had to kill using the controls of a satellite, the Indiana Jones-like tunnels roller coaster level, the Grand Canyon level etc!!! one surprise after the other.
FEAR is, to me, a very mediocre game. The list of superior games is long...
Slashdot Mirror
...made you look, didn't you?
Not even Ballmer would have said that...
I don't think so. The reasons are purely economical. There are more jobs in their home countries than in the US.
Here:
http://en.wikipedia.org/wiki/Douglas_Engelbart
He also invented the mouse, the GUI, and ARPANET.
In Japan, computers need no stinking 'e' to access the internet, computers have the internet preinstalled!!!
Windows 3.2? is this a new version of Windows? when did it come out?
Or make the O/S looking like single-user, while being multi-user transparently.
For example, I don't see why, as a user, can't change the contents of the Windows System folder.
While I change it, Windows can pretend that I change the one and only Systems folder, while in reality, I change my own copy of the folder.
I see a new Slashdot meme coming along:
In Japan, things are better bla bla bla...
Could not it be done with Haskell? Haskell creates code equal to C especially for math problems (or so they say).
Which, in practical terms, means, that Windows is over-engineered. Unix is simpler and achieves the same results.
But structs do not have the same treatment as classes.
And a heck of lot difficult to spot. At least, in C++, it's obvious what is a pointer and what it is not.
Why do all that? no thanks. C++ is much better in this regard.
Nope. It hasn't.
Nope, it isn't.
C++ has typedef.
Mixins are bad from a design standpoint.
C++ can do it with templates.
And introduce big complications in the code.
Boost provides them.
Nope. The C++ and D template type system are exactly the same. In fact, if you ask Walter, all the template tricks in D are done using the C++'s Turing complete template system.
But with tripling memory usage, at least. Which does not help performance at all.
It depends on the object. I wouldn't say 99.999%. More like 50%-70%. Forcing all classes to be accessible by reference is silly, in my opinion.
The non deterministic nature of finalization creates big problems though. At least with shared ptrs, objects are not held up alive until the gc says it's time to delete them. Which may be never.
I disagree. The design of C++0x is retarded. They should have introduced closures by creating value objects which represents the closure.
In order to now how many references are to an object, there are only two solutions: a) reference counting, b) object tree traversal. The first one has the problem of cycles, and so it is not used, and the second one is very costly and it is also not used. So, your comment is totally wrong. D has RAII, but it does not use reference counting or object scanning and marking.
Indeed, but not relevant to this thread of the discussion (regarding performance).
And for these reasons and others, C++ is still preferable, in my book, than D.
But the syntax is all wrong. It's easy to forget that an object is allocated as 'scope', because the syntax is the same as in heap allocation.
And the template system is D is exactly the same as in C++. The differences are superficial, only in syntax. D's templates is a Turing complete system, just like in C++.
I don't think D will ever have the high performance of C++, because D objects are all allocated on the heap. The D 'auto' keyword is just a compiler hint (last time I checked) to help in escape analysis. D has structs, but one has to design upfront if a class has value or reference semantics, and that creates a major design headache. Avoiding the headache by making everything have reference semantics negates the advantages of struct.
D is a mix of C and Java, with the C++ template system bolted on top. It is no way C++. D is not what a veteran C++ programmer excepts as the next generation C++.
The next version will be...
C++!!!
And it will be considered harmful!!! :-)
Oh really? I have a horse near where I have my wallet!!! :-)
It may not be Atlantis, but what if it is indeed an ancient city of some kind?
Yes, more effort goes into a modern game, but the tools have vastly improved as well.
The price of a game does not reflect the effort to develop it, but the effort to experiment with new engines, graphics tricks, art etc. Most of this effort is thrown away, and the price reflects that.
If game developer companies were more focused, this would not have occurred.
End-to-end encryption is required at all levels of the internet. Until that is available, the internet will never be secure, because someone will be able to read the non-encrypted data you send and reply with a fake response.
Does it matter if the doom is this year or, let's say, in 100 years? it's still doom. You may live, your children may not.
Why do you look at this in such a narrow view? even if this destruction comes, let's say, in 1000 years, or in 10000 years, it's still something to be concerned with.
Unless all you care about is yourself and only yourself.
The first few fights were interesting, due to good "AI". But then it was all fighting. No spectacular events in any form whatsoever. Just endless corridors with fighting, and the occasional horror scene that did not blend well to the fighting atmosphere of the game.
Compare that to HL1...the giant squid monster that hunts with sound, the monster you had to kill using the controls of a satellite, the Indiana Jones-like tunnels roller coaster level, the Grand Canyon level etc!!! one surprise after the other.
FEAR is, to me, a very mediocre game. The list of superior games is long...
TOS is dead, Jim...
Ok. How about the Allah Particle?
What would they do? force us to decrypt it? that's a violation of human rights.
They have so much money coming from their other products...
Apparently, the same one used by 3DRealms to compile DNF...