Humans are animals just like any other. For what reason do we not allow experimenting on humans while we allow it on other animals? Because humans are supposedly much more sentient, superior, a higher life form or whatever crap. Neanderthals are probably not any different in that way (it is probable, though, they disappeared because we humans killed them off), so why should we allow experimenting on the basis that they're a different species (which means they can still interbreed with humans and produce fertile offspring)?
I'm not against experimenting per-se, even on humans, but the whole "if it's not a homo sapiens, it's alright to do anything with it" is just stupid.
No one wants to play a dumbed-down game for the masses. It's actually because of those games have a bad reputation. When you make art, you don't care about making it more suitable for all ages or whatever. You just make it a fine piece of art, however it should be.
Also, how does an advisory rating reduce the target demographic? Ratings are not even enforced in most countries; only extremist parents are gonna care about them.
The answer is simple: why care about the ESRB rating in the first place? Those ratings are silly and only favor censorship. Which is evil.
Just make a game as good as possible, target it to actual adult people and do not mold it around a special rating. If it gets rated M, just bear with it.
More and more games are M-rated nowadays anyway. I believe it improved sales more than reduced them.
The whole point of those systems is to differentiate humans from bots. However, unless you believe we have a soul of some kind, there is simply no way to do that, as we are a machine ourselves.
Deleting default constructors and operators is already in some compilers, such as GCC 4.4, which is indeed not stable yet.
The fact that most people write bad code in a language (i.e. they use a bad dialect) is no good reason not to write good code in that language. Because such bad code exists doesn't necessarily mean you have to make your code around it.
In fact, that class appears to be very wacky. If I ever came across such code, I would rewrite it for clarity.
I already said it was fairly useless and what it needed to become very useful. It's just a few lines to show you what RAII is like, because whatever you might boast it was obvious you needed to be given an example. Making it really useful would require using rvalue references and variadic templates. ZOMG some other new features not in the current standard! (which can somehow be emulated in C++03, with some well-known shortcomings)
I've written my first auto-pointer classes in 1996
Which was necessarily defective. std::auto_ptr sucks hard, that's why it's being deprecated. std::unique_ptr, its replacement, is better, but still not perfect in my opinion since it takes a pointer and not an object; this is useful for dealing with legacy code or APIs but modern code shouldn't require construction to perform ownership transfer like this. (it being dangerous is why the constructor has been made explicit in the first place)
Instead you used a piece of fantasy code for a fantasy compiler. How smart! Now you're the epitome of a C++ programmer!
When talking about what code should be like I'd rather use the ideal solutions, even if few compilers implement them, rather than ugly workarounds.
As you can see, you're doing delete outside of a destructor. It is clear from your code you understood nothing of the ownership issues I took time to explain to you. You also probably didn't read up on RAII or exception-safety, since your code is not conforming to those principles, and is thus garbage.
By the way, in modern C++, you simply never use raw pointers that are not views outside of low-level implementation details, and views are to be treated carefully. Even, I personally recommend not to use raw pointers at all to avoid confusion and use resettable references instead for views.
Now don't go and write some other bogus code that indeed does delete in the destructor. That is not sufficient to be good code. You may only delete something you're the sole owner of. That is why ownership is so important and different ownership policies need different implementation mechanisms.
The "= delete" you consider to be a syntax error is a feature of the new yet-to-be-finalized C++ standard (known as C++0x) which allows deleting of member functions that are defined by default. Indeed, in that case, the default copy constructor and assignment operator are erroneous since they do not copy the underlying resource. Redefining them is possible, but I chose here to make the object non-copyable and non-assignable for the sake of simplicity. The way to do that in C++03 is usually to redeclare them and make them private, not providing the definition. I thought you might not understand such basic techniques, so I chose to use a way that conveyed the intent better.
Ok, let's give an example to you about that pointer that cannot be accessed. This is of course a fairly useless object (albeit if you add move, swap and inplace construction support, it then becomes quite useful).
Incredibly enough, once the destructor of scoped_obj has been called, there is no way to access ptr anymore. So there is no reason to set it to null. Writing ~scoped_obj() { delete ptr; ptr = 0; } would just be silly. Understand that simple point now? And since C++ code should follow RAII, resource reclamations should look like this (be done in destructors).
WTF are you talking about?
It is clear you understand very little of what I'm talking about, which is probably linked to your complete lack of modern C++ knowledge, so I'll just stop there. It seems your problem with C++ is that it doesn't refuse bad code at compile-time. Well, I wish you good luck with programming then. Even Haskell is no panacea on those terms.
It's not because Bjarne Stroustrup created the language something like 15 years ago that he is some kind of C++ god. Actually I would even recommended to be careful and critical about what he says, and there are quite a few people "better" than him in C++ I would say. I don't get why people have a tendency to consider whoever created some programming language as the reference to use that language. Languages, but even more practices, evolve.
There are quite a few good C++ programmers out there, I assume most posters of comp.lang.c++.moderated on Usenet are decent for example. It's just a matter of what the person has learnt, has he kept himself informed on what is going on in the community like the recommended practices nowadays or the latest break-through designs, etc. If he learnt "C with classes" ages ago and never evolved, even 30 years of experience won't turn the person into a very experienced C++ developer.
Note that what I've been saying is not necessarily parallel programming oriented. I don't really see how making objects stateless brings any direct help to parallel programming; sure, that means concurrent read accesses are allowed, but that doesn't parallelize the code.
From the post of the original poster, he probably meant code that does not modify its input, which is known as pure functions. The reason there is no such standard keyword is because such a thing would only be useful to the optimizer, hence it is only to be an attribute.
In C and C++, constness can be cast away at the programmer's whim (using either a C++ const_cast<> operator or a regular C cast operator). Also, fields declared "mutable" in C++ can be modified even in constant context. That's why "const" is not a "stateless" modifier in C and C++.
It is a feature of the type system. Like all features of the type system, you can always choose to get around them in C or C++. But that is your choice.
Moreover, it makes perfectly sense in some scenarios to implement an object with stateless semantics with state under the hood, for example in the case of lazy initialization. Of course that means you have to make sure you initialize your object only once even in concurrent situations, but people that do that sort of thing know enough to take care of that.
Sadly, formal object modelling isn't used by many companies. Most corporate code is more akin to spaghetti code. The more people have worked on it, the greater the mess you'll find when you look at it.
RAII is the only good way to program in C++, the end. If you don't follow it, your code is simply utter exception-unsafe leaky crap. Coding in C++ is about dealing with resource ownership (one of these resources being objects in memory), ownership being attached to some object. Spaghetti code is not permitted by the standard idioms.
Setting member variables to 0 in a destructor for instance is important to avoid memory corruption and to detect when a pointer is accessed after an object is already destroyed.
As I already told you, the pointer doesn't exist anymore once the destructor has been called. It cannot be accessed anymore. It is just useless to modify its value.
If there's even the slightest chance of a dangling pointer (or reference, for that matter), it's always good to set things to sane values before leaving a function. Otherwise, the slightest programming error can corrupt swathes of memory.
There are different scenarios for dealing with references to resources: - either you own the resource (you're responsible for destruction whenever you don't need it anymore, and usually you don't allow aliasing at all, your resource is strictly private) - either you alias a resource owned by someone else and are guaranteed to outlive it (you just have a regular pointer or reference, this is mostly useful for views or the like) - either you co-own a resource along with other objects, which means the resource still lives till everyone doesn't need it anymore (you have a shared_ptr) - you want to alias a resource but have a way to know it has been reclaimed. I personally never found an use for it outside of breaking cycles in shared ownership scenarios that use reference counting.
Usually, a program only needs to deal with the two first scenarios: shared ownership is not needed unless you really want to share state or perform some memory usage optimizations by avoiding duplicates of the same object in memory. Since communication between threads usually means using shared (or global) state, and since that means using specific ownership mechanisms, those spots are fairly obvious in the code.
In the light of multithreading, some programmers do not understand that they MUST NOT access memory from two threads at once. That leads to horrible forms of spaghetti code when
How is const not a good stateless modifier? Of course, it's up to you to decide what your object should allow when constant. It's up to you to maintain the right invariants and semantics, which are what modeling resources and values as objects is for.
The good practices of C++ are to *not* use pointers, only perform resource reclamation in destructors (which means setting the pointer to null after freeing is useless, since the pointer doesn't exist any more), and not use useless "empty" states when it doesn't make sense, because they're usually dangerous states with limited possibilities (it mostly makes sense only for dynamically-sized collections). So you're mostly recommending the worse practices ever.
To not have stateful objects in C++, simply design them to be immutable or to act as views, which are quite the recommended designs these days. It basically makes sense for values to be stateless, but entities should be stateful.
As usual, people are talking of "C/C++". However there is no such thing. There is C, and then there is C++. They are very different languages. C++ suffers from a rather poor reputation because most people don't really know it, and because most code that has been written in it is really C-ish (C with classes) or worse, Java-ish (as if C++ was about OOP...).
Anyway, my point is that it's a language that needs to be learnt separately from C altogether. It's both as low-level and as high-level as you want, bringing you the best (or worse, depending on how you use it) of both worlds.
If the cost of making the extension yourself is far lower than that of buying the extension, then obviously it's the price of the extension that is much too high.
And that's what the problem with that kind of things is in practice, extensions are priced much more than their real value to amortize the cost of the main product. The solution is simple: just price the extensions correctly. If that means your extensions become super cheap, then why not make extensions that are actually valuable?
Ubuntu loses on any disk intensive operation, especially when it is required to perform synchronisation (with sqlite, for example). That's not surprising at all, given how the default ext3 Ubuntu partition is set up.
Data cannot be illegal. It is distributing data which may be illegal or not, depending on the rights you hold upon the data. It is also illegal to receive data from an illegal distributer, since that makes you an accomplice.
Depending on your country, you may also be able to distribute data in a limited way without acquiring distribution rights from the copyright holder. This is known as fair use.
All systems that want to check whether someone is distributing some data illegally are necessarily doomed to have false positives, because you cannot check if the person is sending the data to his family, for example, which is within fair use in most countries. If you have acquired distribution rights, the system may also not know of it.
So that kind of system will always be a bother since it will turn in a lot of false positives, even if it actually worked and was well-designed to actually care about people's rights.
Slashdot Mirror
I meant the <video> tag, sorry.
Why not just tell those guys about the standard tag?
Humans are animals just like any other. For what reason do we not allow experimenting on humans while we allow it on other animals? Because humans are supposedly much more sentient, superior, a higher life form or whatever crap.
Neanderthals are probably not any different in that way (it is probable, though, they disappeared because we humans killed them off), so why should we allow experimenting on the basis that they're a different species (which means they can still interbreed with humans and produce fertile offspring)?
I'm not against experimenting per-se, even on humans, but the whole "if it's not a homo sapiens, it's alright to do anything with it" is just stupid.
No one wants to play a dumbed-down game for the masses. It's actually because of those games have a bad reputation.
When you make art, you don't care about making it more suitable for all ages or whatever. You just make it a fine piece of art, however it should be.
Also, how does an advisory rating reduce the target demographic? Ratings are not even enforced in most countries; only extremist parents are gonna care about them.
The answer is simple: why care about the ESRB rating in the first place?
Those ratings are silly and only favor censorship. Which is evil.
Just make a game as good as possible, target it to actual adult people and do not mold it around a special rating. If it gets rated M, just bear with it.
More and more games are M-rated nowadays anyway. I believe it improved sales more than reduced them.
Does this mean they won't delete all my content on a whim if they think it contains illegally hosted copyrighted material?
Well if some malicious person uses your computer, it's your fault for not protecting it.
It's no different from ID theft.
The whole point of those systems is to differentiate humans from bots.
However, unless you believe we have a soul of some kind, there is simply no way to do that, as we are a machine ourselves.
CAPTCHAs are thus doomed to fail.
GCC 3.4 is quite outdated.
2.95 is just plain old. Why not code in Fortran while you're at it?
Deleting default constructors and operators is already in some compilers, such as GCC 4.4, which is indeed not stable yet.
The fact that most people write bad code in a language (i.e. they use a bad dialect) is no good reason not to write good code in that language.
Because such bad code exists doesn't necessarily mean you have to make your code around it.
In fact, that class appears to be very wacky. If I ever came across such code, I would rewrite it for clarity.
I already said it was fairly useless and what it needed to become very useful. It's just a few lines to show you what RAII is like, because whatever you might boast it was obvious you needed to be given an example.
Making it really useful would require using rvalue references and variadic templates. ZOMG some other new features not in the current standard! (which can somehow be emulated in C++03, with some well-known shortcomings)
I've written my first auto-pointer classes in 1996
Which was necessarily defective. std::auto_ptr sucks hard, that's why it's being deprecated.
std::unique_ptr, its replacement, is better, but still not perfect in my opinion since it takes a pointer and not an object; this is useful for dealing with legacy code or APIs but modern code shouldn't require construction to perform ownership transfer like this. (it being dangerous is why the constructor has been made explicit in the first place)
Instead you used a piece of fantasy code for a fantasy compiler. How smart! Now you're the epitome of a C++ programmer!
When talking about what code should be like I'd rather use the ideal solutions, even if few compilers implement them, rather than ugly workarounds.
As you can see, you're doing delete outside of a destructor.
It is clear from your code you understood nothing of the ownership issues I took time to explain to you. You also probably didn't read up on RAII or exception-safety, since your code is not conforming to those principles, and is thus garbage.
By the way, in modern C++, you simply never use raw pointers that are not views outside of low-level implementation details, and views are to be treated carefully.
Even, I personally recommend not to use raw pointers at all to avoid confusion and use resettable references instead for views.
Now don't go and write some other bogus code that indeed does delete in the destructor. That is not sufficient to be good code.
You may only delete something you're the sole owner of. That is why ownership is so important and different ownership policies need different implementation mechanisms.
The "= delete" you consider to be a syntax error is a feature of the new yet-to-be-finalized C++ standard (known as C++0x) which allows deleting of member functions that are defined by default.
Indeed, in that case, the default copy constructor and assignment operator are erroneous since they do not copy the underlying resource. Redefining them is possible, but I chose here to make the object non-copyable and non-assignable for the sake of simplicity.
The way to do that in C++03 is usually to redeclare them and make them private, not providing the definition. I thought you might not understand such basic techniques, so I chose to use a way that conveyed the intent better.
Ok, let's give an example to you about that pointer that cannot be accessed.
This is of course a fairly useless object (albeit if you add move, swap and inplace construction support, it then becomes quite useful).
template<typename T>
struct scoped_obj
{
scoped_obj(const T& t) : ptr(new T(t)) {}
~scoped_obj() { delete ptr; }
scoped_obj(const scoped_obj&) = delete;
scoped_obj& operator=(const scoped_obj&) = delete;
T* operator->() { return ptr; }
const T* operator->() const { return ptr; }
private:
T* ptr;
};
Incredibly enough, once the destructor of scoped_obj has been called, there is no way to access ptr anymore. So there is no reason to set it to null.
Writing ~scoped_obj() { delete ptr; ptr = 0; } would just be silly.
Understand that simple point now? And since C++ code should follow RAII, resource reclamations should look like this (be done in destructors).
WTF are you talking about?
It is clear you understand very little of what I'm talking about, which is probably linked to your complete lack of modern C++ knowledge, so I'll just stop there.
It seems your problem with C++ is that it doesn't refuse bad code at compile-time. Well, I wish you good luck with programming then. Even Haskell is no panacea on those terms.
It's not because Bjarne Stroustrup created the language something like 15 years ago that he is some kind of C++ god. Actually I would even recommended to be careful and critical about what he says, and there are quite a few people "better" than him in C++ I would say.
I don't get why people have a tendency to consider whoever created some programming language as the reference to use that language. Languages, but even more practices, evolve.
There are quite a few good C++ programmers out there, I assume most posters of comp.lang.c++.moderated on Usenet are decent for example.
It's just a matter of what the person has learnt, has he kept himself informed on what is going on in the community like the recommended practices nowadays or the latest break-through designs, etc. If he learnt "C with classes" ages ago and never evolved, even 30 years of experience won't turn the person into a very experienced C++ developer.
Note that what I've been saying is not necessarily parallel programming oriented.
I don't really see how making objects stateless brings any direct help to parallel programming; sure, that means concurrent read accesses are allowed, but that doesn't parallelize the code.
From the post of the original poster, he probably meant code that does not modify its input, which is known as pure functions.
The reason there is no such standard keyword is because such a thing would only be useful to the optimizer, hence it is only to be an attribute.
In C and C++, constness can be cast away at the programmer's whim (using either a C++ const_cast<> operator or a regular C cast operator). Also, fields declared "mutable" in C++ can be modified even in constant context. That's why "const" is not a "stateless" modifier in C and C++.
It is a feature of the type system.
Like all features of the type system, you can always choose to get around them in C or C++.
But that is your choice.
Moreover, it makes perfectly sense in some scenarios to implement an object with stateless semantics with state under the hood, for example in the case of lazy initialization. Of course that means you have to make sure you initialize your object only once even in concurrent situations, but people that do that sort of thing know enough to take care of that.
Sadly, formal object modelling isn't used by many companies. Most corporate code is more akin to spaghetti code. The more people have worked on it, the greater the mess you'll find when you look at it.
RAII is the only good way to program in C++, the end.
If you don't follow it, your code is simply utter exception-unsafe leaky crap.
Coding in C++ is about dealing with resource ownership (one of these resources being objects in memory), ownership being attached to some object.
Spaghetti code is not permitted by the standard idioms.
Setting member variables to 0 in a destructor for instance is important to avoid memory corruption and to detect when a pointer is accessed after an object is already destroyed.
As I already told you, the pointer doesn't exist anymore once the destructor has been called.
It cannot be accessed anymore. It is just useless to modify its value.
If there's even the slightest chance of a dangling pointer (or reference, for that matter), it's always good to set things to sane values before leaving a function. Otherwise, the slightest programming error can corrupt swathes of memory.
There are different scenarios for dealing with references to resources:
- either you own the resource (you're responsible for destruction whenever you don't need it anymore, and usually you don't allow aliasing at all, your resource is strictly private)
- either you alias a resource owned by someone else and are guaranteed to outlive it (you just have a regular pointer or reference, this is mostly useful for views or the like)
- either you co-own a resource along with other objects, which means the resource still lives till everyone doesn't need it anymore (you have a shared_ptr)
- you want to alias a resource but have a way to know it has been reclaimed. I personally never found an use for it outside of breaking cycles in shared ownership scenarios that use reference counting.
Usually, a program only needs to deal with the two first scenarios: shared ownership is not needed unless you really want to share state or perform some memory usage optimizations by avoiding duplicates of the same object in memory.
Since communication between threads usually means using shared (or global) state, and since that means using specific ownership mechanisms, those spots are fairly obvious in the code.
In the light of multithreading, some programmers do not understand that they MUST NOT access memory from two threads at once. That leads to horrible forms of spaghetti code when
How is const not a good stateless modifier?
Of course, it's up to you to decide what your object should allow when constant. It's up to you to maintain the right invariants and semantics, which are what modeling resources and values as objects is for.
The good practices of C++ are to *not* use pointers, only perform resource reclamation in destructors (which means setting the pointer to null after freeing is useless, since the pointer doesn't exist any more), and not use useless "empty" states when it doesn't make sense, because they're usually dangerous states with limited possibilities (it mostly makes sense only for dynamically-sized collections).
So you're mostly recommending the worse practices ever.
To not have stateful objects in C++, simply design them to be immutable or to act as views, which are quite the recommended designs these days.
It basically makes sense for values to be stateless, but entities should be stateful.
As usual, people are talking of "C/C++".
However there is no such thing. There is C, and then there is C++. They are very different languages.
C++ suffers from a rather poor reputation because most people don't really know it, and because most code that has been written in it is really C-ish (C with classes) or worse, Java-ish (as if C++ was about OOP...).
Anyway, my point is that it's a language that needs to be learnt separately from C altogether.
It's both as low-level and as high-level as you want, bringing you the best (or worse, depending on how you use it) of both worlds.
If the cost of making the extension yourself is far lower than that of buying the extension, then obviously it's the price of the extension that is much too high.
And that's what the problem with that kind of things is in practice, extensions are priced much more than their real value to amortize the cost of the main product.
The solution is simple: just price the extensions correctly. If that means your extensions become super cheap, then why not make extensions that are actually valuable?
Not gonna happen, RenderMan is CPU-only.
Ubuntu loses on any disk intensive operation, especially when it is required to perform synchronisation (with sqlite, for example).
That's not surprising at all, given how the default ext3 Ubuntu partition is set up.
Data cannot be illegal.
It is distributing data which may be illegal or not, depending on the rights you hold upon the data. It is also illegal to receive data from an illegal distributer, since that makes you an accomplice.
Depending on your country, you may also be able to distribute data in a limited way without acquiring distribution rights from the copyright holder. This is known as fair use.
All systems that want to check whether someone is distributing some data illegally are necessarily doomed to have false positives, because you cannot check if the person is sending the data to his family, for example, which is within fair use in most countries.
If you have acquired distribution rights, the system may also not know of it.
So that kind of system will always be a bother since it will turn in a lot of false positives, even if it actually worked and was well-designed to actually care about people's rights.