I would assume to help with the whole inheritance nightmare in C++.
It's been a while though. I would assume if it's virtual, once you do two shapes into one shape, the "Shape" data members become one logical unit instead of it going "Do I use Circle->Shape->poopyButt() or Square->Shape->poopyButt()?"
bowen on
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
it is a direct work around for diamond inheritance. It basically fusses Circle and Square together into a single inherited class type that you inherit from.
it is a direct work around for diamond inheritance. It basically fusses Circle and Square together into a single inherited class type that you inherit from.
That seems to be more specific wording than what I was trying to say!
I bet you have free shit I don't have too.
Ass.
:rotate:
bowen on
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
I would assume to help with the whole inheritance nightmare in C++.
It's been a while though. I would assume if it's virtual, once you do two shapes into one shape, the "Shape" data members become one logical unit instead of it going "Do I use Circle->Shape->poopyButt() or Square->Shape->poopyButt()?"
Ding! It's to make sure there is only ever one instance of Shape
Fun fact: it also affects construction/destruction order and object layout
More explicitly: If a class has at least one pure virtual function (that is, a function signature without an implementation), it's considered an abstract class, and cannot be instantiated.
Man, I feel like using "virtual" in the context of cleaning up multiple inheritance is very non-intuitive and non-obvious.
I think I've just written the most inefficient algorithm ever
Still remember guy in school implementing a random sort operation for laughs. Randomly pick two elements in a list and swap them. Check if the list is sorted. Repeat till its sorted.
That's actually a de facto sort algo. I think bubblesort?
No, randomly pick. That's bogosort! Bubblesort picks two that are out of order
I was curious, so I looked this up.
bogosort is when you randomize the entire list.
bozosort is when you swap two random elements.
This was in 97-98 so before it had a semi-official name.
Edit: Guess that was incorrect because wikipedia references bogo-sort from 1996.
The use of "virtual" I just complained about reminded me of the "const" keyword in C++, which has enough uses that the following function signature (a member function of a class) is legal and, furthermore, actually makes sense:
No non-mutable member variables will be modified
The param will not be modified
The dereferenced param will not be modified
The return value may not be modified
The dereferenced return value may not be modified
No non-mutable member variables will be modified
The param will not be modified
The dereferenced param will not be modified The return value may not be modified
The dereferenced return value may not be modified
Actually, that one automagically gets cast away. * I think
Probably needs a slight modification to the original question to be useful:
Anyone have any opinions on irrlicht? I'm using it for a game I want to make, keeping the "Maybe move this to other platforms" as my guide. Plus not having to pay extraordinary licensing fees if I ever finish it.
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
No non-mutable member variables will be modified
The param will not be modified
The dereferenced param will not be modified The return value may not be modified
The dereferenced return value may not be modified
Actually, that one automagically gets cast away. * I think
Probably needs a slight modification to the original question to be useful:
Anyone have any opinions on irrlicht? I'm using it for a game I want to make, keeping the "Maybe move this to other platforms" as my guide. Plus not having to pay extraordinary licensing fees if I ever finish it.
I've heard it's decent and I've played around with it a bit, no real problems
I should have specified that Phyphor is disqualified from the running because he obviously knows C++ better than anyone in this thread. For example, I didn't know about const_cast.
What's cool about C++ is that it's not just a kitchen sink language, it's like a meta-kitchen-sink language. It's a kitchen sink made of kitchen sinks, but also nega-kitchen sinks, forever. Kitchen sinks all the way down. If you don't like one of their kitchen sinks, they have another kitchen sink that fills the negative space around the kitchen sink you don't like.
Plus it has the templating metaprogramming language hidden inside of it, Magic Eye-style.
(Note: When I say "cool", I mean "sometimes 'cool' but also sometimes 'god why won't the pain stop'".)
No non-mutable member variables will be modified
The param will not be modified
The dereferenced param will not be modified The return value may not be modified
The dereferenced return value may not be modified
Actually, that one automagically gets cast away. * I think
Probably needs a slight modification to the original question to be useful:
Yeah, it's not a thing that you do for basic non-pointer types because it's just redundant.
e.g. const int someFunction() vs int anotherFunction();
If you look at its usage:
const int newInt = someFunction();
const int newInt = anotherFunction(); // Made a const copy of the non-const
int newInt = someFunction(); // Just made a non-const copy of the return value
int newInt = anotherFunction();
Only finds real use for returning references ("No, you can't modify the contents of this reference"), and even then, only if the return value goes into another reference.
No non-mutable member variables will be modified
The param will not be modified
The dereferenced param will not be modified The return value may not be modified
The dereferenced return value may not be modified
Actually, that one automagically gets cast away. * I think
Probably needs a slight modification to the original question to be useful:
Of course "immutability" in the presence of const_cast, specifically added to get around const, immutability is not
=P
Yeah - C++ helpfully loads the shotgun for you, but that doesn't mean you have to point it at your feet with the safety off.
const int* const
That should be valid, I read it to mean that you have a const pointer to a const int. Other than int being a poor example, using a class would make
more sense as that would restrict you to only using const methods.
I really want restrict to be introduced into c++ so that we can finally have:
No non-mutable member variables will be modified
The param will not be modified
The dereferenced param will not be modified The return value may not be modified
The dereferenced return value may not be modified
Actually, that one automagically gets cast away. * I think
Probably needs a slight modification to the original question to be useful:
Of course "immutability" in the presence of const_cast, specifically added to get around const, immutability is not
=P
Yeah - C++ helpfully loads the shotgun for you, but that doesn't mean you have to point it at your feet with the safety off.
const int* const
That should be valid, I read it to mean that you have a const pointer to a const int. Other than int being a poor example, using a class would make
more sense as that would restrict you to only using const methods.
Ah - I am explaining poorly. It is syntactically valid, but the extra const doesn't really add any anything unless it's attached to a reference.
What is the point of having it, if you can just:
const int * const someFunction();
const int * someFunction2();
// All compiles without warnings
const int * const pTest = someFunction();
const int * const pTest2 = someFunction2();
const int * pTest3 = someFunction();
const int * pTest4 = someFunction2();
But, if you are to add a reference into the mix:
const int * const & someFunction3();
const int * & someFunction4();
const int * const & rpTest = someFunction3(); // Ok - no change
const int * const & rpTest2 = someFunction4(); // Ok - creates a const reference from a non-const reference
const int * & rpTest3 = someFunction3(); // Error - cannot change const& to just &
const int * & rpTest4 = someFunction4(); // Ok - no change
Edit 3:
Actually, now that I think about C++11, maybe it would make a difference with auto?
I was having the same discussion the other day at work - the general feeling was that 95%+ of our functions are implicitly restricted already, because that's when we pass data around with pointer, we usually imply two separate and non-overlapping memory areas (in our environment, at least).
Oh right I forgot to check clang. Is the Intel compiler widely used though?
Dunno - I have a feeling Ethea has access to internal charts and stats showing compiler usage, though. =P
Having said that, anecdotal: We have a client who uses ICC for production software. I remember because we ended up adding checks for the level of C++11 support on various versions of ICC.
Oh right I forgot to check clang. Is the Intel compiler widely used though?
I wouldn't say widely used, but it is required for xeon phi work. IBM's and portland compiler are also used on BlueGene P/Q/... and Cray HPC machines and both of those support the restrict keyword in some form.
Not that I actually use the keyword in any production code yet...
Oh right I forgot to check clang. Is the Intel compiler widely used though?
It is, relatively speaking. The landscape of C++ compilers are:
(1) VC++ if you operate on Windows.
(2) GCC if you operate on Linux.
(3) Clang (soon) if you operate on OSX.
(4) Intel if you want (allegedly) better performance, in particular, wrt parallelized code.
Kambing on
@TwitchTV, @Youtube: master-level zerg ladder/customs, commentary, and random miscellany.
0
Options
mightyjongyoSour CrrmEast Bay, CaliforniaRegistered Userregular
Oh right I forgot to check clang. Is the Intel compiler widely used though?
It is, relatively speaking. The landscape of C++ compilers are:
(1) VC++ if you operate on Windows.
(2) GCC if you operate on Linux.
(3) Clang (soon) if you operate on OSX.
(4) Intel if you want (allegedly) better performance, in particular, wrt parallelized code.
For HPC.
(5) Intel if you target Xeon Phi Coproccessor or on modern SGI machines
(6) IBM XL C++ if you target Blue Gene machines
(7) PGI if you are on a cray machine
Restrict lets the compiler make assumptions that two pointers don't point to the same data, it basically lets it more aggressively optimize memory access, register allocations load/store.
I'm not familiar with restrict really, anyone care to explain why I'd want it?
One way to think of pointers (and references) is that they provide an alias for a particular memory location. This level of indirection can be problematic because it can hide the fact that two pointers may point to the same location in memory, known as the pointer aliasing problem. A concrete example in C++ is the standard implementation of the copy assignment operator:
T& operator=(const T &other) {
// 1. Check for self-assignment
if (this != &other) {
// 2. Clean up own resources
// 3. Copy over other's resources
}
return *this;
}
The check for self-assignment is necessary because this (a pointer-to-a-T) and other (a reference-to-a-T) may point to the same object. This is only possible because this and other are pointers/references to objects rather than actual memory locations (and thus distinct by definition).
In the context of compiler optimizations, pointer aliasing restricts how code can be moved. Conservatively if two statements write to the same pointer that may alias the same memory, then those two statements' order cannot be changed which restricts a number of fundamental optimizations (e.g., common sub-expression elimination, constant propagation). In general, static pointer aliasing analysis is undecidable, so we must rely on conservative approximations in practice.
The restrict modifier (available in C99 or as an extension to virtually all major compilers) says the following:
T *restrict x is a pointer to T that uniquely references its underlying memory. That is, for the lifetime of the variable x, x (or pointers derived from it) are the only way to reference its own underlying memory.
This is precisely the information that the compiler needs to resolve pointer aliasing issues for variables (in particular, function parameters). The downside is that this is not enforced (i.e., type-checked) by the compiler at all; it is a merely an annotation that the compiler uses to optimize code. In the event that such an annotation is wrong (another pointer referencing the same memory that a pointer variable declared as restrict is referencing), the resulting optimized code may be incorrect.
(Third! ^_^)
Kambing on
@TwitchTV, @Youtube: master-level zerg ladder/customs, commentary, and random miscellany.
Posts
class Shape {}; class Circle : public virtual Shape {}; class Square : public virtual Shape {}; class CirSquare : public Circle, public Square {};Bonus points to anyone who knows what those virtual keywords mean, and why they might be there, without looking it up
It's been a while though. I would assume if it's virtual, once you do two shapes into one shape, the "Shape" data members become one logical unit instead of it going "Do I use Circle->Shape->poopyButt() or Square->Shape->poopyButt()?"
That seems to be more specific wording than what I was trying to say!
I bet you have free shit I don't have too.
Ass.
Ding! It's to make sure there is only ever one instance of Shape
Fun fact: it also affects construction/destruction order and object layout
That's pure virtual functions: virtual void poopyButt() = 0;
Like methods, that you can overlap cause you make them virtual, and there are problems if you don't.
(Virtual means you only get one.)
Man, I feel like using "virtual" in the context of cleaning up multiple inheritance is very non-intuitive and non-obvious.
Go with quantum bogosort.
Check to see if the list is sorted. If it is not, then destroy the current universe. In all existing universes, the list is now sorted.
This was in 97-98 so before it had a semi-official name.
Edit: Guess that was incorrect because wikipedia references bogo-sort from 1996.
Nintendo ID: Incindium
PSN: IncindiumX
const int* const SomeFunction(const int* const&) const;
Can you list the five promises of immutability that that function signature makes? If you can, my condolences.
The param will not be modified
The dereferenced param will not be modified
The return value may not be modified
The dereferenced return value may not be modified
Actually, that one automagically gets cast away. * I think
Probably needs a slight modification to the original question to be useful:
Edit2:
=P
Yeah - C++ helpfully loads the shotgun for you, but that doesn't mean you have to point it at your feet with the safety off.
I've never actually tried returning a const
I've heard it's decent and I've played around with it a bit, no real problems
What's cool about C++ is that it's not just a kitchen sink language, it's like a meta-kitchen-sink language. It's a kitchen sink made of kitchen sinks, but also nega-kitchen sinks, forever. Kitchen sinks all the way down. If you don't like one of their kitchen sinks, they have another kitchen sink that fills the negative space around the kitchen sink you don't like.
Plus it has the templating metaprogramming language hidden inside of it, Magic Eye-style.
(Note: When I say "cool", I mean "sometimes 'cool' but also sometimes 'god why won't the pain stop'".)
Yeah, it's not a thing that you do for basic non-pointer types because it's just redundant.
e.g. const int someFunction() vs int anotherFunction();
If you look at its usage:
Only finds real use for returning references ("No, you can't modify the contents of this reference"), and even then, only if the return value goes into another reference.
more sense as that would restrict you to only using const methods.
I really want restrict to be introduced into c++ so that we can finally have:
Of course restrict just confuses people
Ah - I am explaining poorly. It is syntactically valid, but the extra const doesn't really add any anything unless it's attached to a reference.
What is the point of having it, if you can just:
But, if you are to add a reference into the mix:
Edit 3:
Actually, now that I think about C++11, maybe it would make a difference with auto?
Hmmmmmmm....
Interesting
Yeesssssssss
I was having the same discussion the other day at work - the general feeling was that 95%+ of our functions are implicitly restricted already, because that's when we pass data around with pointer, we usually imply two separate and non-overlapping memory areas (in our environment, at least).
So does intel and clang so really people can use it.
Dunno - I have a feeling Ethea has access to internal charts and stats showing compiler usage, though. =P
Having said that, anecdotal: We have a client who uses ICC for production software. I remember because we ended up adding checks for the level of C++11 support on various versions of ICC.
I wouldn't say widely used, but it is required for xeon phi work. IBM's and portland compiler are also used on BlueGene P/Q/... and Cray HPC machines and both of those support the restrict keyword in some form.
Not that I actually use the keyword in any production code yet...
It is, relatively speaking. The landscape of C++ compilers are:
(1) VC++ if you operate on Windows.
(2) GCC if you operate on Linux.
(3) Clang (soon) if you operate on OSX.
(4) Intel if you want (allegedly) better performance, in particular, wrt parallelized code.
learn something new every day.
For HPC.
(5) Intel if you target Xeon Phi Coproccessor or on modern SGI machines
(6) IBM XL C++ if you target Blue Gene machines
(7) PGI if you are on a cray machine
http://cellperformance.beyond3d.com/articles/2006/05/demystifying-the-restrict-keyword.html is a good overview
Haha, Geth agrees.
The problem it solves is aliasing - and one of the main consequencing being optimisations.
The restrict keyword basically says, "You may assume that this pointer does not point to any other variable in the function being analysed".
Edit: Darn it Phyphor!
You win again! =P
One way to think of pointers (and references) is that they provide an alias for a particular memory location. This level of indirection can be problematic because it can hide the fact that two pointers may point to the same location in memory, known as the pointer aliasing problem. A concrete example in C++ is the standard implementation of the copy assignment operator:
T& operator=(const T &other) { // 1. Check for self-assignment if (this != &other) { // 2. Clean up own resources // 3. Copy over other's resources } return *this; }The check for self-assignment is necessary because this (a pointer-to-a-T) and other (a reference-to-a-T) may point to the same object. This is only possible because this and other are pointers/references to objects rather than actual memory locations (and thus distinct by definition).
In the context of compiler optimizations, pointer aliasing restricts how code can be moved. Conservatively if two statements write to the same pointer that may alias the same memory, then those two statements' order cannot be changed which restricts a number of fundamental optimizations (e.g., common sub-expression elimination, constant propagation). In general, static pointer aliasing analysis is undecidable, so we must rely on conservative approximations in practice.
The restrict modifier (available in C99 or as an extension to virtually all major compilers) says the following:
T *restrict x is a pointer to T that uniquely references its underlying memory. That is, for the lifetime of the variable x, x (or pointers derived from it) are the only way to reference its own underlying memory.
This is precisely the information that the compiler needs to resolve pointer aliasing issues for variables (in particular, function parameters). The downside is that this is not enforced (i.e., type-checked) by the compiler at all; it is a merely an annotation that the compiler uses to optimize code. In the event that such an annotation is wrong (another pointer referencing the same memory that a pointer variable declared as restrict is referencing), the resulting optimized code may be incorrect.
(Third! ^_^)