Yamoto42

It is harder to debug code than it is to write it. Therefore if you right the smartest code you are capable of writing, you are not capable of debugging it. To quote "The Zen of Python":

Where I went to college, they combined it and a few other topics with a combined CS/EE design/practicum 2 semester sequence. They would assign group projects projects, and have a few presentations throughout the 2 semester sequence. The lectures though, started with basic design procedures (ie business cases and design docs), after a few weeks of that the lectures went into other rarely covered topics like ethics, patents and legal stuff, etc.

As far as pointers and references...yes. A pointer is just an address and a reference is negligibly different from a const pointer. But again, the original question isn't about a reference or a pointer...it's about an explicitly declared instance. What you're saying doesn't necessarily disagree with what I said. The question is, in memory, what exactly are an 'Entity' and a 'Hero'. Polymorphism is achieved via what are called vtables. The spec doesn't exactly say where they have to be, but where they are located actually doesn't matter so much as how they work. Essentially, a vtable is a table of function pointers. Lets take the following methods: virtual void Entity::spam() { does something; } void void Hero::spam() override { eggs(); } virtual void Hero::eggs() { does something else; } When you create an Entity, the resulting data structure's vtable will have a single entry: Entity.spam() The thing is, the vtable for a Hero also only has a single entry: Hero::eggs(). You see, the actual layout of a Hero has 2 vtables: one for Entity, and one for Hero. Hero::spam() is not an addendum, it is a replacement. It overwrites the Entity::spam() entry in the Hero instance's Entity vtable. Therefore, a raw memory copy of the Entity portion would leave you with a pointer to Hero::spam(), which when called would (correctly, mind you) receive a 'this' pointer of type Hero...meaning it would think it had a valid Hero vtable and thereby a pointer to Hero::eggs()... So, the answer is a copy constructor. They have default implementations that just copy all data members, or you can explicitly declare one. They take a reference to an object of their own type. But being a constructor, they also implicitly contain the logic to properly set up the vtable based on the class. Since the declared variable is an Entity, even if it's being copied form a hero, the Hero constructor won't run and therefore the Entity vtable won't be modified to point to Hero::spam().

Yeah, in C++ you have to be concerned with where and how memory is allocated. If it is not a pointer, it is allocated where the container is. for a local function variable, that means on the stack. Therefore if you declare a 'Hero', the memory layout of 'Hero' is allocated on the stack. However, if you declare an 'Entity', the stack will only have the memory layout of an 'Entity', so (including the vtable, which is a table of virtual function pointers) it can only contain at most the members of an entity. Now, you can probably see how if you are arbitrarily calling virtual methods of 'Entity' that are override by 'Hero', that might cause some major data errors. Even if we assume 'Entity' is written with proper encapsulation, and therefore cannot be erroneously modified by its subclasses, that doesn't let us off the hook. In fact, that is only the lesser problem. All member variables are stored as offsets to the beginning of the data structure...so what happens when a 'Hero' member method is called on an 'Entity'...the answer is we have no idea. It may edit something in the vtable, ie rewriting executable code, or it may rewrite something outside the owning data structure entirely. We have effectively written to a random memory location. But it's actually slightly worse, because it's not truly random. We know it is actually nearby the data structure...and since the data structure isn't dynamically allocated, that is purely relative to its declared location (as opposed to an arbitrary heap allocation and a pointer reference). That is to say the location we have written to is guaranteed to be nearby or on top of other in-use memory. So...instead of doing all that, there is a safe option that the compiler can take: Just make it an 'Entity' and use Entity's copy constructor.

No, but it's far form unheard of to have said getters and setters defined in a purely virtual class. It is a bit overboard for a PODO class, unless it contains some validation logic or needs to guarantee event callbacks are performed, or something else of that like...but especially in languages like C++ where you can avoid runtime dispatch and therefore let optimizer can cut out any of the additional complexity, its never bad practice to properly encapsulate data.

One of the (few) nice thing in java over C# is you can actually reference constructors as delegates.

the interfaces Comparator<T> (for a delegate) and Comparable<T> (defines this.compareTo(T other)) respectively. @BuckGup There's also (since java 8 ) plenty of static methods defined in the Comparator interface for dynamically building more complex Comparators out of simple ones. One thing to remember is to read the documentation. Sometimes things are said about classes and interfaces that aren't necessarily enforceable by the language. In this case about Comparable<T>: "Note that null is not an instance of any class, and e.compareTo(null) should throw a NullPointerException even though e.equals(null) returns false."

Yeah, the big problem with generics in Java is type erasure. Simply put, type parameters are effectively lost at runtime...and it can really messes with overloading and reflection. What you actually get from the compiler is something like: // This is your code public class GenericExample<T> { private T myVar; public T getVar() { return myVar; } public void setVar(T var) { myVar = var; } static main(String ... args) { GenericExample<MyOtherClass> tmp = new GenericExample<>(); MyOtherClass var = 1; tmp.setVar(var); var = tmp.getBar(); } } // This is what the compiler actually compiles public class GenericExample { private Object myVar; public Object getVar() { return myVar; } public void setVar(Object var) { myVar = var; } static main(String ... args) { GenericExample tmp = new GenericExample(); MyOtherClass var = 1; tmp.setVar(var); // Because of compile time checking, there may not be a hard type check here. var = (MyOtherClass)tmp.getBar(); } } You will notice that the compiled class looses its reference to T. Type restrictions are also solved by inserting casts. // Example classes public interface Customer { boolean likesSpam(); } public class GrahamChapman implements Customer { public boolean likesSpam() { return false; } } // What you wrote public class Server<T extends Customer> { private T myCustomer; public Server(T customer) { myCustomer = customer; } public String getBreakfast() { if (!myCustomer.likesSpam()) return "Spam"; else return "Eggs"; } public static main() { Server<GrahamChapman> eric = new Server<>(new GrahamChapman()); String meal = eric.getBreakfast(); } } // What gets compiled public class Server { private Object myCustomer; public Server(Object customer) { myCustomer = customer; } public String getBreakfast() { Customer tmp = (Customer)myCustomer; if (!tmp.likesSpam()) return "Spam"; else return "Eggs"; } public static main() { Server eric = new Server(new GrahamChapman()); String meal = eric.getBreakfast(); } } You'll see again, the type itself looses the actual type information, and the compiler just inserts cases where needed. Without getting into too much detail about dynamic dispatch, a good example of a side effect are the types Collection<Double> and Collection<Integer>: Or more specifically the singular type Collection. public class TypeErasureExample { public double sum(Collection<Double> values) { ... } public int sum(Collection<Integer> values { ... } } Because generics are implement as type Object, then cast to T, the original type T is not stored as part of the type. Ergo, if the above were allowed to compile the runtime would see: public class CompiledTypeErasure { public double sum(Collection values) { ... } public int sum(Collection values) { ... } } And (as return types are not part of a method signature in Java) not know what method to actually call.

I wont necessarily tell you how to do it, but think about how you might be able to store the type information alongside each pointer. Edit: As a minor aside since it's a data structures class, RPN is processed in a stack, not a queue.

Implementation. Interpretation requires a minimum of two operations in the interpreter per instruction of its input. The first operation is interpretation, the second is execution. Let P represent Python and C represent..well..C... the default implementation of the python interpreter is written in C. therefore the speed of a python program must be P >= 2C. BUT, python and C are both Turing complete, so the converse is also possible: writing a C interpreter in python. Therefore the speed of C must be expressible as C >= 2P. It is a paradox. The only thing that has a speed is how much time it takes to execute an instruction on the processor. It's the implementation of the language, the compiler or interpreter, not the language itself that possesses this attribute. And again, because of Turing completeness, implementations are 100% interchangeable.

Speed is not a property of a language to begin with...anyone with half a brain can prove that.

While good practice, it's not the problem. That does nothing to make it run, it only makes it NOT execute if the module is imported as opposed to being the initial entry point....hence good practice. @riklaunim got it with the missing closing parenthesis.

Similar situation I mentioned...actually at AMD's fault. But yes, it has as just as much factual basis as: I can't convert a true believer, so don't expect further responses. But I do hope for all of our sakes you're right and there's nothing shady going on...but even if you are, because you allowed lack of transparency it's inherently impossible to ever know.

Good to know how much credence you give every 12 year old who claims to have 5 FPS less than <insert reviewer here> playing...what do kids play these days? Or perhaps I should word it differently: If this is as harmless as you believe, then anyone worth listening too should have already signed it, thereby And "friendly advice" on selling Intel stock from a board member a few weeks ago in no way can be construed as insider trading...no particular reason for selling...just a hunch. That is to say it doesn't take a law degree to make an argument for intentional testing based on, and with intent to lead to exposure of, confidential data. Because if they lack the integrity to decline the initial agreement...surely we can count on them to leak it when it reaches some (as of yet undefined) goalpost. Because actor A provides evidence that they lack trait B, we can depend on them them performing action C that requires trait B. Your argument is inherently self contradictory. Yes. you must not have read anything I put in parenthesis. I use them rather liberally to ensure I am being as specific as possible.

Actually...there is precedence for this. I honestly forget the details, but I believe it was AMD, actually, a couple of years ago asked its reviewers to use specific settings to avoid their cards'...shall we say weaker points. So, even if they were not to acquiesce to said request, we would effectively be disallowed from knowing the request was made in the first place. But this NDA is not for a "said product". Even if it were, it 'technically' does allow them to disclose known flaws in confidence, and therefore (due to the first sentence of [the first] item 3) bar the flaw form being publicly disclosed (at least by any reviewer) for the effective product lifespan. See also: Xanatos Gambit. That is to say, bringing up the first example...they might actually not be able to share a card's known weak point, since that is confidential information that is not beneficial to Nvidia. What is even more, because again, this is NOT PRODUCT SPECIFIC, it allows Nvidia to approach signers about other..propositions...under its terms. For example...the GPP. But remember, the GPP was made under terms that they knew might become public...and if they're willing to do that publicly...just imagine what they might be willing to try in private.