4. I completely disagree. Saying they are the same and then saying one is a subset of the other makes no sense to me. They function differently and provide different, yet closely related, purposes. Thinking they are the same is exactly why most people fail interview questions about the two.
The definition of an abstract class is one that can not be instantiated.
"Interfaces" only exist in languages that prohibit multiple inheritance. They exist explicitly because of the diamond problem. Intro courses don't teach it in these terms usually but the only reason they exist is to get some of the benefits of multiple inheritance while limiting the problems inherent by gimping some of the flexibility in the class (usually all virtual methods & only immutable/static attributes).
If you can come up with an interface example that could not be conceptually replaced by an abstract class in a system with multiple inheritance fire away. In the same way that an abstract class is a subset with restrictions of classes in general, interfaces are a subset of abstract classes.
Oh good lord, you win. I don't even care if someone believes your garbage anymore. Yes, there are many many debates about abstract classes versus interfaces even though they are the same thing. You are correct. I was wrong.
I'll go back to my SAMS: Lurn OOP in 24 Ours book and my JCL programming classes.
Can someone give a clear explanation of the difference between abstract classes and interfaces, and perhaps an example of when you would want to use one and not the other? I'm still shaky on this topic, even after my C# course last semester.
An abstract class is one where an object of said class cannot be created. Going back to the Mammal concept, we can define the characteristics of a Mammal (vertebrate, warm-blooded, gives birth to live young, etc.), but there's no such thing as a pure "Mammal". Instead, there are various kinds of Mammals, like Dogs and Cats and Humans and such.
An interface is a subset of abstract classes that consist only of a list of virtual functions. When a class implements an interface, it guarantees that the functions listed in the interface definition will be implemented. For example, in order to call a foreach loop on an object in C#, the object must implement the IEnumerable interface, which details the specific commands needed for an enumerator.
Properties too AH. Methods and properties (dunno if you include properties when you say "functions").
I dont have VS sitting in front of me: when inheriting from an abstract class (.NET), are you required to provide override implementations of all methods and properties of the abstract class?
4. I completely disagree. Saying they are the same and then saying one is a subset of the other makes no sense to me. They function differently and provide different, yet closely related, purposes. Thinking they are the same is exactly why most people fail interview questions about the two.
The definition of an abstract class is one that can not be instantiated.
"Interfaces" only exist in languages that prohibit multiple inheritance. They exist explicitly because of the diamond problem. Intro courses don't teach it in these terms usually but the only reason they exist is to get some of the benefits of multiple inheritance while limiting the problems inherent by gimping some of the flexibility in the class (usually all virtual methods & only immutable/static attributes).
If you can come up with an interface example that could not be conceptually replaced by an abstract class in a system with multiple inheritance fire away. In the same way that an abstract class is a subset with restrictions of classes in general, interfaces are a subset of abstract classes.
Oh good lord, you win. I don't even care if someone believes your garbage anymore. Yes, there are many many debates about abstract classes versus interfaces even though they are the same thing. You are correct. I was wrong.
I'll go back to my SAMS: Lurn OOP in 24 Ours book and my JCL programming classes.
"Is a subset of" != "Is exactly the same". Someone competent in OOP should recognise this.
Hey guys. I really, REALLY didn't want to post here because I wanted to figure out this project myself, but I'm a retard and can't figure anything out in programming apparently (tell me why I am going for this degree if I'm not even good at it?)
Anyway. I'm working with double linked lists. (working on an insert function, to put the number in a sorted list) but I can't seem to figure out why I am getting an error when I type the following:
This right here runs perfectly, except that node is never actually saved. I did an insert call in my main program, and it completes fine, but when I try to output the node it says the head node is null. But if (right after the if statement) I type: cout<<node->value; It outputs the correct number.
So I try: node->value = newvalue and I get:
Unhandled exception at 0x0041184a in Lab0.exe: 0xC0000005: Access violation writing location 0x00000000.
So I have no idea what to do. I don't think I'm cut out for this stuff like you guys are.
This right here runs perfectly, except that node is never actually saved. I did an insert call in my main program, and it completes fine, but when I try to output the node it says the head node is null.
You're actually very close to it. You've identified what the problem is - i.e. that "head" never changes.
Now look at the insert function. Ask yourself, where does it change the value of "head"?
Then ask yourself, where should it change the value of "head"?
This right here runs perfectly, except that node is never actually saved. I did an insert call in my main program, and it completes fine, but when I try to output the node it says the head node is null.
You're actually very close to it. You've identified what the problem is - i.e. that "head" never changes.
Now look at the insert function. Ask yourself, where does it change the value of "head"?
Then ask yourself, where should it change the value of "head"?
head is a private variable though, so I can't change it right? So shouldn't setting it equal to another node be the same thing as placing a new value in it?
Oh mother of Christ. I'm such an idiot... I completely forgot that I am still in the .cpp file that is attached to the .h file, so I can modify head. Ugh. I'm sorry for wasting your time eeccccoo
head is a private variable though, so I can't change it right?
I feel like smacking my head in the desk
Not quite. If head is a private variable, then it means that it can only be changed by member functions, not by everyone. You can change it, but only inside the member functions (like your insert function).
So shouldn't setting it equal to another node be the same thing as placing a new value in it?
It would be, but what you've done is the opposite. Instead of setting head equal to another node, you've set another node equal to the value of head. i.e. you've copied the value of head into the "node" variable, but "head" itself remains unchanged.
Oh mother of Christ. I'm such an idiot... I completely forgot that I am still in the .cpp file that is attached to the .h file, so I can modify head. Ugh. I'm sorry for wasting your time eeccccoo
Since we're sort of OP mode here, let me add my two cents: If you're at all serious about programming, buy some books.
If nothing else, I am of the opinion that every programmer should own a copy of "Code Complete" by Steve McConnell. This is the kind of book where there are a lot of sections that will be immediately relevant to a novice such as the sections on code formatting and variable use, and sections that you will grow into as you get better (there is oodles of material on being part of and managing real world projects). If you've ever asked yourself questions like, "Should I throw an exception here?" this fucker has the answer.
For the prospective Cocoa programmer, I really recommend "Cocoa Programming For Mac OS X" by Aaron Hillegass. It'll make your life a lot easier and just walk you through all important concepts of building Cocoa apps like a breeze. You can get this information from online tutorials and reading Apple documentation, but this way is so much less painful and quicker - and, dare I say, fun. The book is laid out like one long tutorial and chalk full of screenshots and excellent diagrams and explanations that cover the most important points concisely and in an easy-going comprehensible manner.
Will mention more as I get cash.
I am also taking recommendations on a C++ book for a more experienced programmer. I figure I really ought to get good at this thing, but my comp sci intro class textbook is this super thick piece of crap that's all hung up on explaining the glory of Abstract Data Types to peasants who, presumably, have never known anything other than C and Assembly.
Hey guys. I really, REALLY didn't want to post here because I wanted to figure out this project myself, but I'm a retard and can't figure anything out in programming apparently (tell me why I am going for this degree if I'm not even good at it?)
Your first mistake is you're trying to do it in C++, the language where you can have absolutely nothing wrong with your understanding of the algorithm but still screw up some little bit of syntax and get an incomprehensible error message. :?
Edit: I have a question of my own. I don't yet own the book, and I'm trying to figure something out in my C# / Windows Forms application: Do I need to implement "Dispose()", and, if so, how should I do it? Should I call it on my own objects that are no longer needed? MSDN is, as ever, pretty helpful, but it lacks the ultimatum of "should" or "shouldn't" that I'm looking for. I am currently giving myself a headache trying to figure out if I need to be sure to null member objects that have already been disposed and prevent calling dispose on them again in the containing class' dispose method and really I should probably just sleep on it.
Properties too AH. Methods and properties (dunno if you include properties when you say "functions").
I dont have VS sitting in front of me: when inheriting from an abstract class (.NET), are you required to provide override implementations of all methods and properties of the abstract class?
Properties, no (there's no such thing as a "virtual property"), but yes, classes have to implement the methods in an interface.
Edit: I have a question of my own. I don't yet own the book, and I'm trying to figure something out in my C# / Windows Forms application: Do I need to implement "Dispose()", and, if so, how should I do it? Should I call it on my own objects that are no longer needed? MSDN is, as ever, pretty helpful, but it lacks the ultimatum of "should" or "shouldn't" that I'm looking for. I am currently giving myself a headache trying to figure out if I need to be sure to null member objects that have already been disposed and prevent calling dispose on them again in the containing class' dispose method and really I should probably just sleep on it.
Your first mistake is that you're doing it in C#, the language with a hackish RAII idiom. :P
Properties too AH. Methods and properties (dunno if you include properties when you say "functions").
I dont have VS sitting in front of me: when inheriting from an abstract class (.NET), are you required to provide override implementations of all methods and properties of the abstract class?
Properties, no (there's no such thing as a "virtual property"), but yes, classes have to implement the methods in an interface.
public interface IFoo
{
string Name { get; }
}
public class Bar : IFoo
{
string Name
{
get
{
return "Tom";
}
}
}
Edit: I have a question of my own. I don't yet own the book, and I'm trying to figure something out in my C# / Windows Forms application: Do I need to implement "Dispose()", and, if so, how should I do it? Should I call it on my own objects that are no longer needed? MSDN is, as ever, pretty helpful, but it lacks the ultimatum of "should" or "shouldn't" that I'm looking for. I am currently giving myself a headache trying to figure out if I need to be sure to null member objects that have already been disposed and prevent calling dispose on them again in the containing class' dispose method and really I should probably just sleep on it.
Your first mistake is that you're doing it in C#, the language with a hackish RAII idiom. :P
No shit, it's pissing me off. I like my languages elegant and with one right answer. Edit: Not seeing the RAII thing though. Seems like any other garbage collected language, where every now and then any objects that no variables are pointing to get reclaimed. (Whereas C++ objects are destructed the instant they go out of scope.) Except with the addition that you can dispose of them explicitly, too.
No choice though. Gotta be a Windows database-driven app and fuck if I'm using MFC and C++ or some shit. I'd probably still be trying to get the DataGridView to work if I hadn't done it hack and slash in C#.
Incidentally, the reason I'm asking such a question is I'm currently embroiled in a major re-factoring of the app. What I did first was just get the damn thing working by writing a bunch of code to manage a DataGridView and a MySQL connection for the main window. Then I added some other windows to display other tables in the database and just copied and pasted and modified the code slightly.
Obviously that's a shitty state of affairs, so now I'm writing a "DataGridViewManager" class to encapsulate all the interactions between the DataGridView and the Database so that all windows are using the same code. I figure since these will last the entire life time of the program I don't need to worry about anything besides making sure the MySQL connection gets closed, but I still want to get it right.
I've never used the language, but I hear that D combines the best of both worlds. The Garbage Collector is able to free memory whenever the hell it feels like it, but objects still have destructors which are called deterministically as soon as an object is no longer referenced.
The more I use C# the more I prefer it over C++, but I do love C++'s RAII. And templates, though they're not perfect by any means.
Can't say as I've had any positive experiences with C++ RAII to date. It relies an incredible amount on implicit behavior of the language such that you have to read docs upon docs to fully understand, and even then what I often really need is just some decent reference counting on a shared object, which can get syntactically nightmarish even if you let Boost do it for you.
Still taking book recommendations. C++ FAQ Lite sucks.
Still taking book recommendations. C++ FAQ Lite sucks.
I've found that the two Thinking in C++ books are pretty good. They assume that the reader has basic knowledge of C (or, really, any other similar language...hell, I had no problem following along with most of it, and my 'best' language is PHP), and, from what I can tell, they cover most of Standard C++.
Since we're sort of OP mode here, let me add my two cents: If you're at all serious about programming, buy some books.
I dunno about that. I do programming for my living, but I have never founds them that useful, because typical programming books tend to be so goddamn thick that they can't be browsed quickly. Furthermore, you can't cut-copy-n'-paste stuff from them. But then again, I'm usually working with VB.net and C#, and developer centers for those are very good.
Properties too AH. Methods and properties (dunno if you include properties when you say "functions").
I dont have VS sitting in front of me: when inheriting from an abstract class (.NET), are you required to provide override implementations of all methods and properties of the abstract class?
Properties, no (there's no such thing as a "virtual property"), but yes, classes have to implement the methods in an interface.
See the example Corkiness posted. Properties and methods are included in Interfaces in .NET.
I must have expressed myself badly there. I was talking about two different things really. I was pointing out that methods and properties can both be part of an interface and both will need to be represented in the class implementing the interface. Then I wanted to know if, like an Interface, abstract classes require that all of their methods/properties be implemented in the inheriting class.
[edit] LoneIgadzra: unless your form uses something that won't be cleaned up on it's own, or uses something you need to make sure is cleaned up when your form gets collected then no, you do not need to implement Dispose yourself.
A good example would be if you had a class where you were using a Stream (or something similar: FileStream, StreamWriter, TextWriter, etc). Before your class is disposed of you might want to flush any bytes you've written to the stream and then close the handle that you've got on the file. That would be a good instance to implement Dispose manually. Hope that makes sense...
[edit] LoneIgadzra: unless your form uses something that won't be cleaned up on it's own, or uses something you need to make sure is cleaned up when your form gets collected then no, you do not need to implement Dispose yourself.
A good example would be if you had a class where you were using a Stream (or something similar: FileStream, StreamWriter, TextWriter, etc). Before your class is disposed of you might want to flush any bytes you've written to the stream and then close the handle that you've got on the file. That would be a good instance to implement Dispose manually. Hope that makes sense...
This was my initial assumption, but the MSDN articles on the IDisposable interface are really limited. They seem to sort of imply that I should check if Dispose() was called by the user, in which case it should call Dispose on all member objects, but it doesn't really come right out and say that. (There are comments from other users who are as confused as me!) Also, do I have to explicitly implement IDisposable if I implement Dispose(), and do I then have to instantiate the whole class in a try/finally block as the docs vaguely imply?
Since we're sort of OP mode here, let me add my two cents: If you're at all serious about programming, buy some books.
I dunno about that. I do programming for my living, but I have never founds them that useful, because typical programming books tend to be so goddamn thick that they can't be browsed quickly. Furthermore, you can't cut-copy-n'-paste stuff from them. But then again, I'm usually working with VB.net and C#, and developer centers for those are very good.
I'm not sure I buy the thickness argument. I like my books thick with lots of value, and I find having to type stuff out manually to be a major aid in memorization. Also, MSDN is a lot better than a lot of similar services, especially in how it provides working examples in multiple languages with great consistency. (Though, as mentioned earlier in this post, even MSDN is sometimes lacking.)
The books I recommended, Code Complete and the Cocoa book, I really recommended because they are exactly the kind of resources you can't find on the web. Code Complete, especially, is a really nice book to just pick up every now and then and learn something new. As for Cocoa, I have been trying to learn it for years and made more progress in two hours with the book than in all my time browsing Apple documentation and free online tutorials.
I have, until now, avoided buying books because my class textbooks were so lame and there are loads of free online tutorials for everything, but I'm really glad I finally bit the bullet and bought these two.
Also, flipping through a book is sometimes just a lot nicer than browsing online docs.
This is my insert function. When I insert the numbers: 7, 9, 3, 2, 12 (in that order) I get the following: 2 3 7. This is what my print function looks like:
I assume it has something to do with my while loop, right? Could someone kindly point me in the right direction? I'd like to finish this sometime Thanks guys... Sorry for being a pain.
e: I decided to go with a single linked list, instead of double.
I have, until now, avoided buying books because my class textbooks were so lame and there are loads of free online tutorials for everything, but I'm really glad I finally bit the bullet and bought these two.
Also, flipping through a book is sometimes just a lot nicer than browsing online docs.
I've found that for web development, the vast majority of free tutorials suck. On the other boards I visit, I make it a point to tell newbies to avoid sites like w3schools because they teach only the bare minimum on how to get things done, and never teach good coding practices. I find that if you learn how to do things the 'right' way from the beginning, a lot of confusion can be avoided.
The two languages that immediately spring to mind are JavaScript and PHP. I tend to slum around phpfreaks.com. It quickly becomes obvious who learned from a text or class, and who learned from an online tutorial. There are some epic train wrecks that come through there from time to time, where the best course of action is to scrap the whole thing and start over.
I find that spending $30 - $50 for a good text is well worth the money. There's the comfort factor that you mention, as well as the number of headaches avoided. I'm still looking for a good, up-to-date AJAX book. So far, the ones I've seen/bought have been lacking in one way or another.
The params are float arrays with 4 values in them to represent the homogenous coordinates e.g.
protected float[] lightPosition = new float[]{0.0f, 0.0f, -5.0f, 1.0f};
.
The display code is threaded and run continuously.
public void display(GLAutoDrawable drawable) {
final GL gl = drawable.getGL();
//Toggle lighting
if (!lightingEnabled)
gl.glEnable(GL.GL_LIGHTING);
else
gl.glDisable(GL.GL_LIGHTING);
//Toggle wireframe
if(wireframe)
gl.glPolygonMode(GL.GL_FRONT_AND_BACK, GL.GL_LINE);
else
gl.glPolygonMode(GL.GL_FRONT_AND_BACK, GL.GL_FILL);
//clear the screen and depth buffers
gl.glClear(GL.GL_COLOR_BUFFER_BIT | GL.GL_DEPTH_BUFFER_BIT);
//reset all transformation co-ordinates
gl.glLoadIdentity();
//apply new transformations to the scene
gl.glPushMatrix();
gl.glScalef(modelSX, modelSY, modelSZ);
gl.glTranslatef(modelTX, modelTY, modelTZ);
gl.glRotatef(modelRX, 1.0f, 0.0f, 0.0f);
gl.glRotatef(modelRY, 0.0f, 1.0f, 0.0f);
gl.glRotatef(modelRZ, 0.0f, 0.0f, 1.0f);
//draw the monkey
drawModel(gl);
gl.glPopMatrix();
}
I am using JOGL, in case anyone is wondering about the Java syntax.
Am I push/popping incorrectly?
I found this little snippet, but I can't make head or tail of it. If I'm reading the FAQ correctly, the light position should not move at all unless specified, since I pushed on a 'new' matrix, did some transformations, drew the vertices again, then popped the matrix. Sadly that does not seem to be the case.
Should I set the light's position again in the display code? It's perplexing me for a while now
This was my initial assumption, but the MSDN articles on the IDisposable interface are really limited. They seem to sort of imply that I should check if Dispose() was called by the user, in which case it should call Dispose on all member objects, but it doesn't really come right out and say that. (There are comments from other users who are as confused as me!) Also, do I have to explicitly implement IDisposable if I implement Dispose(), and do I then have to instantiate the whole class in a try/finally block as the docs vaguely imply?
You should just be able to implement Dispose. Because you're already inheriting from Form, and Form inherits (up the chain) from something that implements IDisposable.
I assume it has something to do with my while loop, right? Could someone kindly point me in the right direction? I'd like to finish this sometime Thanks guys... Sorry for being a pain.
You are absolutely correct - it's something to do with your while loop. And a typo.
First, the typo:
if(head->next == NULL)
{
cout<<"Head->next == NULL\n";
head->next == newnode; // TYPO ON THIS LINE - Are you comparing head->next to newnode or setting it equal?
}
Which compiler are you using? If you're using gcc, may I suggest you pass the flag -Wall to turn on all warnings? If you fix just this typo, then your output should be 2, 3, 7, 9.
Next, your while loop. Could you answer this question about your while loop?
If "newvalue" is larger than every value that's already inside your linked list, is there any chance of it running that bit of code that inserts newnode into the linked list?
Before you rush in with a code fix, keep in mind that you'll have to have checked every value in your linked list against newvalue first so it's not just a simple case of sticking an else{} on to the end of that if statement.
1) Thanks for the heads up for the double equals. I can't believe I did that. :P And I do have all warning messages turned on, but I'm just sampling code so I almost always ignore warnings, which will teach me.
2) Hmm. I think I get what you're saying. Right now if it makes it all the way to node->next == Null then it doesn't go into the while loop, and doesn't tack it on at the end. So I have to find a way to add it at the end... Hmm..
This was my initial assumption, but the MSDN articles on the IDisposable interface are really limited. They seem to sort of imply that I should check if Dispose() was called by the user, in which case it should call Dispose on all member objects, but it doesn't really come right out and say that. (There are comments from other users who are as confused as me!) Also, do I have to explicitly implement IDisposable if I implement Dispose(), and do I then have to instantiate the whole class in a try/finally block as the docs vaguely imply?
You should just be able to implement Dispose. Because you're already inheriting from Form, and Form inherits (up the chain) from something that implements IDisposable.
Actually, that's not the case. DataGridViewManager is a "helper" class that a Form in my program can create an instance of. (I figured that was a lot simpler and more re-usable/encapsulated that creating a sub-class of Form that all the Forms in my program inherit from instead of Form itself.)
Quick question for you guys: How do you tell if a double is equal to another double?
Like, I have a variable called newValue and I need to see if it's equal to value, which is also a double... But I know you can't use the == format because doubles aren't exactly what they say they are (a double 2.2, in this case, actually means 2.200000000000002). I'm also using templates if that makes it more complicated. I thought there was a .equals command, but that might be just for java/lists.
e: aha! You just subtract the two and see if they are equal to 0. Thanks anyway guys.
e: aha! You just subtract the two and see if they are equal to 0. Thanks anyway guys.
No, don't do that. It's possible for two values that super-duper look like they should be equal (as in they were even calculated the exact same way) to not be, in which case subtracting won't result in 0.
Subtracting is on the right track though. The most common method is to see if abs(val1-val2) < epsilon, where abs is the absolute value function and epsilon is some really small positive number like .00000001.
Smasher on
0
Options
jackalFuck Yes. That is an orderly anal warehouse.Registered Userregular
I've never used the language, but I hear that D combines the best of both worlds. The Garbage Collector is able to free memory whenever the hell it feels like it, but objects still have destructors which are called deterministically as soon as an object is no longer referenced.
The more I use C# the more I prefer it over C++, but I do love C++'s RAII. And templates, though they're not perfect by any means.
I've never used the language, but I hear that D combines the best of both worlds. The Garbage Collector is able to free memory whenever the hell it feels like it, but objects still have destructors which are called deterministically as soon as an object is no longer referenced.
The more I use C# the more I prefer it over C++, but I do love C++'s RAII. And templates, though they're not perfect by any means.
I've heard that in practice D isn't very good.
Lack of compiler/IDE development + the stuff that makes it more sane than than C++ is old news now.
LoneIgadzra on
0
Options
jackalFuck Yes. That is an orderly anal warehouse.Registered Userregular
e: aha! You just subtract the two and see if they are equal to 0. Thanks anyway guys.
No, don't do that. It's possible for two values that super-duper look like they should be equal (as in they were even calculated the exact same way) to not be, in which case subtracting won't result in 0.
Subtracting is on the right track though. The most common method is to see if abs(val1-val2) < epsilon, where abs is the absolute value function and epsilon is some really small positive number like .00000001.
Two float values calculated in EXACTLY the same way will always be equal. FP math is completely deterministic. There is a situation where that doesn't hold true in the CLR described here, but it is more of a leaky abstraction issue.
e: aha! You just subtract the two and see if they are equal to 0. Thanks anyway guys.
No, don't do that. It's possible for two values that super-duper look like they should be equal (as in they were even calculated the exact same way) to not be, in which case subtracting won't result in 0.
Subtracting is on the right track though. The most common method is to see if abs(val1-val2) < epsilon, where abs is the absolute value function and epsilon is some really small positive number like .00000001.
Two float values calculated in EXACTLY the same way will always be equal. FP math is completely deterministic. There is a situation where that doesn't hold true in the CLR described here, but it is more of a leaky abstraction issue.
Depends on how you define exactly. The same algebra? The same code? The same hardware?
I could run code on one machine that calculates some numbers, stores them in a database, run the same code on different hardware, and theoretically have them be different bit for bit even though they are "the same numbers calculated the same way."
Comparing the difference within a very small tolerable error (epsilon) as posted is the correct method.
e: aha! You just subtract the two and see if they are equal to 0. Thanks anyway guys.
No, don't do that. It's possible for two values that super-duper look like they should be equal (as in they were even calculated the exact same way) to not be, in which case subtracting won't result in 0.
Subtracting is on the right track though. The most common method is to see if abs(val1-val2) < epsilon, where abs is the absolute value function and epsilon is some really small positive number like .00000001.
Two float values calculated in EXACTLY the same way will always be equal. FP math is completely deterministic. There is a situation where that doesn't hold true in the CLR described here, but it is more of a leaky abstraction issue.
That issue is what I was thinking of.
Even if you know it won't happen in a given situation, I'd advise against it simply because that probably won't be clear to other people who might look at your code.
Posts
Oh good lord, you win. I don't even care if someone believes your garbage anymore. Yes, there are many many debates about abstract classes versus interfaces even though they are the same thing. You are correct. I was wrong.
I'll go back to my SAMS: Lurn OOP in 24 Ours book and my JCL programming classes.
An abstract class is one where an object of said class cannot be created. Going back to the Mammal concept, we can define the characteristics of a Mammal (vertebrate, warm-blooded, gives birth to live young, etc.), but there's no such thing as a pure "Mammal". Instead, there are various kinds of Mammals, like Dogs and Cats and Humans and such.
An interface is a subset of abstract classes that consist only of a list of virtual functions. When a class implements an interface, it guarantees that the functions listed in the interface definition will be implemented. For example, in order to call a foreach loop on an object in C#, the object must implement the IEnumerable interface, which details the specific commands needed for an enumerator.
I dont have VS sitting in front of me: when inheriting from an abstract class (.NET), are you required to provide override implementations of all methods and properties of the abstract class?
"Is a subset of" != "Is exactly the same". Someone competent in OOP should recognise this.
Anyway. I'm working with double linked lists. (working on an insert function, to put the number in a sorted list) but I can't seem to figure out why I am getting an error when I type the following:
template <class Elem> bool LinkedSortedList<Elem>::insert(const Elem &newvalue) { Lnode<Elem>* node = head; Lnode<Elem>* newnode = new Lnode<Elem>(newvalue); if(node == NULL) { node = newnode; } return true; }This right here runs perfectly, except that node is never actually saved. I did an insert call in my main program, and it completes fine, but when I try to output the node it says the head node is null. But if (right after the if statement) I type: cout<<node->value; It outputs the correct number.
So I try: node->value = newvalue and I get:
So I have no idea what to do. I don't think I'm cut out for this stuff like you guys are.
You're actually very close to it. You've identified what the problem is - i.e. that "head" never changes.
Now look at the insert function. Ask yourself, where does it change the value of "head"?
Then ask yourself, where should it change the value of "head"?
head is a private variable though, so I can't change it right? So shouldn't setting it equal to another node be the same thing as placing a new value in it?
I feel like smacking my head in the desk
Not quite. If head is a private variable, then it means that it can only be changed by member functions, not by everyone. You can change it, but only inside the member functions (like your insert function).
It would be, but what you've done is the opposite. Instead of setting head equal to another node, you've set another node equal to the value of head. i.e. you've copied the value of head into the "node" variable, but "head" itself remains unchanged.
Been there, done that. =/
Edit:
Also, been there, done that.
If nothing else, I am of the opinion that every programmer should own a copy of "Code Complete" by Steve McConnell. This is the kind of book where there are a lot of sections that will be immediately relevant to a novice such as the sections on code formatting and variable use, and sections that you will grow into as you get better (there is oodles of material on being part of and managing real world projects). If you've ever asked yourself questions like, "Should I throw an exception here?" this fucker has the answer.
For the prospective Cocoa programmer, I really recommend "Cocoa Programming For Mac OS X" by Aaron Hillegass. It'll make your life a lot easier and just walk you through all important concepts of building Cocoa apps like a breeze. You can get this information from online tutorials and reading Apple documentation, but this way is so much less painful and quicker - and, dare I say, fun. The book is laid out like one long tutorial and chalk full of screenshots and excellent diagrams and explanations that cover the most important points concisely and in an easy-going comprehensible manner.
Will mention more as I get cash.
I am also taking recommendations on a C++ book for a more experienced programmer. I figure I really ought to get good at this thing, but my comp sci intro class textbook is this super thick piece of crap that's all hung up on explaining the glory of Abstract Data Types to peasants who, presumably, have never known anything other than C and Assembly.
Your first mistake is you're trying to do it in C++, the language where you can have absolutely nothing wrong with your understanding of the algorithm but still screw up some little bit of syntax and get an incomprehensible error message. :?
Edit: I have a question of my own. I don't yet own the book, and I'm trying to figure something out in my C# / Windows Forms application: Do I need to implement "Dispose()", and, if so, how should I do it? Should I call it on my own objects that are no longer needed? MSDN is, as ever, pretty helpful, but it lacks the ultimatum of "should" or "shouldn't" that I'm looking for. I am currently giving myself a headache trying to figure out if I need to be sure to null member objects that have already been disposed and prevent calling dispose on them again in the containing class' dispose method and really I should probably just sleep on it.
Properties, no (there's no such thing as a "virtual property"), but yes, classes have to implement the methods in an interface.
Your first mistake is that you're doing it in C#, the language with a hackish RAII idiom. :P
public interface IFoo { string Name { get; } } public class Bar : IFoo { string Name { get { return "Tom"; } } }No shit, it's pissing me off. I like my languages elegant and with one right answer. Edit: Not seeing the RAII thing though. Seems like any other garbage collected language, where every now and then any objects that no variables are pointing to get reclaimed. (Whereas C++ objects are destructed the instant they go out of scope.) Except with the addition that you can dispose of them explicitly, too.
No choice though. Gotta be a Windows database-driven app and fuck if I'm using MFC and C++ or some shit. I'd probably still be trying to get the DataGridView to work if I hadn't done it hack and slash in C#.
Incidentally, the reason I'm asking such a question is I'm currently embroiled in a major re-factoring of the app. What I did first was just get the damn thing working by writing a bunch of code to manage a DataGridView and a MySQL connection for the main window. Then I added some other windows to display other tables in the database and just copied and pasted and modified the code slightly.
Obviously that's a shitty state of affairs, so now I'm writing a "DataGridViewManager" class to encapsulate all the interactions between the DataGridView and the Database so that all windows are using the same code. I figure since these will last the entire life time of the program I don't need to worry about anything besides making sure the MySQL connection gets closed, but I still want to get it right.
The more I use C# the more I prefer it over C++, but I do love C++'s RAII. And templates, though they're not perfect by any means.
Still taking book recommendations. C++ FAQ Lite sucks.
I've found that the two Thinking in C++ books are pretty good. They assume that the reader has basic knowledge of C (or, really, any other similar language...hell, I had no problem following along with most of it, and my 'best' language is PHP), and, from what I can tell, they cover most of Standard C++.
PERL :
Camel Book
Llama Book
PERL in a Nutshell
C:
K&R aka the Bible - might not be great for starting out though.
QEDMF xbl: PantsB G+
I dunno about that. I do programming for my living, but I have never founds them that useful, because typical programming books tend to be so goddamn thick that they can't be browsed quickly. Furthermore, you can't cut-copy-n'-paste stuff from them. But then again, I'm usually working with VB.net and C#, and developer centers for those are very good.
I must have expressed myself badly there. I was talking about two different things really. I was pointing out that methods and properties can both be part of an interface and both will need to be represented in the class implementing the interface. Then I wanted to know if, like an Interface, abstract classes require that all of their methods/properties be implemented in the inheriting class.
[edit] LoneIgadzra: unless your form uses something that won't be cleaned up on it's own, or uses something you need to make sure is cleaned up when your form gets collected then no, you do not need to implement Dispose yourself.
A good example would be if you had a class where you were using a Stream (or something similar: FileStream, StreamWriter, TextWriter, etc). Before your class is disposed of you might want to flush any bytes you've written to the stream and then close the handle that you've got on the file. That would be a good instance to implement Dispose manually. Hope that makes sense...
This was my initial assumption, but the MSDN articles on the IDisposable interface are really limited. They seem to sort of imply that I should check if Dispose() was called by the user, in which case it should call Dispose on all member objects, but it doesn't really come right out and say that. (There are comments from other users who are as confused as me!) Also, do I have to explicitly implement IDisposable if I implement Dispose(), and do I then have to instantiate the whole class in a try/finally block as the docs vaguely imply?
I'm not sure I buy the thickness argument. I like my books thick with lots of value, and I find having to type stuff out manually to be a major aid in memorization. Also, MSDN is a lot better than a lot of similar services, especially in how it provides working examples in multiple languages with great consistency. (Though, as mentioned earlier in this post, even MSDN is sometimes lacking.)
The books I recommended, Code Complete and the Cocoa book, I really recommended because they are exactly the kind of resources you can't find on the web. Code Complete, especially, is a really nice book to just pick up every now and then and learn something new. As for Cocoa, I have been trying to learn it for years and made more progress in two hours with the book than in all my time browsing Apple documentation and free online tutorials.
I have, until now, avoided buying books because my class textbooks were so lame and there are loads of free online tutorials for everything, but I'm really glad I finally bit the bullet and bought these two.
Also, flipping through a book is sometimes just a lot nicer than browsing online docs.
template <class Elem> bool Slist<Elem>::insert(Elem newvalue) { Lnode<Elem>* node = head; Lnode<Elem>* newnode = new Lnode<Elem>(newvalue); cout<<"VALUE = "<<newvalue<<endl; if (newnode == NULL) return false; if(head == NULL) { cout<<"Head == NULL\n"; head = newnode; return true; } if(head->value > newvalue) { cout<<"Head->value > newvalue\n"; newnode->next = head; head = newnode; cout<<"head->value is: "<<head->value<<endl; cout<<"head->next->value is: "<<head->next->value<<endl; return true; } if(head->next == NULL) { cout<<"Head->next == NULL\n"; head->next == newnode; } while(node->next != NULL) { cout<<"node->next != NULL\n"; if(node->next->value > newvalue) { newnode->next = node->next; node->next = newnode; } node = node->next; } return true; }This is my insert function. When I insert the numbers: 7, 9, 3, 2, 12 (in that order) I get the following: 2 3 7. This is what my print function looks like:
template <class Elem> void Slist<Elem>::print() { Lnode<Elem>* node = head; cout<<endl<<endl; while(node!= NULL) { cout<<node->value<<" "; node = node->next; } cout<<endl; }I assume it has something to do with my while loop, right? Could someone kindly point me in the right direction? I'd like to finish this sometime
e: I decided to go with a single linked list, instead of double.
I've found that for web development, the vast majority of free tutorials suck. On the other boards I visit, I make it a point to tell newbies to avoid sites like w3schools because they teach only the bare minimum on how to get things done, and never teach good coding practices. I find that if you learn how to do things the 'right' way from the beginning, a lot of confusion can be avoided.
The two languages that immediately spring to mind are JavaScript and PHP. I tend to slum around phpfreaks.com. It quickly becomes obvious who learned from a text or class, and who learned from an online tutorial. There are some epic train wrecks that come through there from time to time, where the best course of action is to scrap the whole thing and start over.
I find that spending $30 - $50 for a good text is well worth the money. There's the comfort factor that you mention, as well as the number of headaches avoided. I'm still looking for a good, up-to-date AJAX book. So far, the ones I've seen/bought have been lacking in one way or another.
I would like to inquire as to why my OpenGL light does not stay fixed. Whenever I rotate my model, the light appears to follow the rotation.
I followed NeHe's tutorial to some extent (only using the lighting parts).
init() { ...other init code... //setup lighting - Light 1 //Ambient gl.glLightfv(GL.GL_LIGHT1, GL.GL_AMBIENT, lightAmbient, 0); //Diffuse gl.glLightfv(GL.GL_LIGHT1, GL.GL_DIFFUSE, lightDiffuse, 0); //Position of Light 1 gl.glLightfv(GL.GL_LIGHT1, GL.GL_POSITION, lightPosition, 0); //Enable Light1 gl.glEnable(GL.GL_LIGHT1); ...other init code... }The params are float arrays with 4 values in them to represent the homogenous coordinates e.g.
protected float[] lightPosition = new float[]{0.0f, 0.0f, -5.0f, 1.0f};.The display code is threaded and run continuously.
public void display(GLAutoDrawable drawable) { final GL gl = drawable.getGL(); //Toggle lighting if (!lightingEnabled) gl.glEnable(GL.GL_LIGHTING); else gl.glDisable(GL.GL_LIGHTING); //Toggle wireframe if(wireframe) gl.glPolygonMode(GL.GL_FRONT_AND_BACK, GL.GL_LINE); else gl.glPolygonMode(GL.GL_FRONT_AND_BACK, GL.GL_FILL); //clear the screen and depth buffers gl.glClear(GL.GL_COLOR_BUFFER_BIT | GL.GL_DEPTH_BUFFER_BIT); //reset all transformation co-ordinates gl.glLoadIdentity(); //apply new transformations to the scene gl.glPushMatrix(); gl.glScalef(modelSX, modelSY, modelSZ); gl.glTranslatef(modelTX, modelTY, modelTZ); gl.glRotatef(modelRX, 1.0f, 0.0f, 0.0f); gl.glRotatef(modelRY, 0.0f, 1.0f, 0.0f); gl.glRotatef(modelRZ, 0.0f, 0.0f, 1.0f); //draw the monkey drawModel(gl); gl.glPopMatrix(); }I am using JOGL, in case anyone is wondering about the Java syntax.
Am I push/popping incorrectly?
I found this little snippet, but I can't make head or tail of it. If I'm reading the FAQ correctly, the light position should not move at all unless specified, since I pushed on a 'new' matrix, did some transformations, drew the vertices again, then popped the matrix. Sadly that does not seem to be the case.
Should I set the light's position again in the display code? It's perplexing me for a while now
You are absolutely correct - it's something to do with your while loop. And a typo.
First, the typo:
if(head->next == NULL) { cout<<"Head->next == NULL\n"; head->next == newnode; // TYPO ON THIS LINE - Are you comparing head->next to newnode or setting it equal? }Which compiler are you using? If you're using gcc, may I suggest you pass the flag -Wall to turn on all warnings? If you fix just this typo, then your output should be 2, 3, 7, 9.
Next, your while loop. Could you answer this question about your while loop?
If "newvalue" is larger than every value that's already inside your linked list, is there any chance of it running that bit of code that inserts newnode into the linked list?
I'll give you a hint:
if(node->next->value > newvalue) { newnode->next = node->next; node->next = newnode; }Before you rush in with a code fix, keep in mind that you'll have to have checked every value in your linked list against newvalue first so it's not just a simple case of sticking an else{} on to the end of that if statement.
2) Hmm. I think I get what you're saying. Right now if it makes it all the way to node->next == Null then it doesn't go into the while loop, and doesn't tack it on at the end. So I have to find a way to add it at the end... Hmm..
Actually, that's not the case. DataGridViewManager is a "helper" class that a Form in my program can create an instance of. (I figured that was a lot simpler and more re-usable/encapsulated that creating a sub-class of Form that all the Forms in my program inherit from instead of Form itself.)
Like, I have a variable called newValue and I need to see if it's equal to value, which is also a double... But I know you can't use the == format because doubles aren't exactly what they say they are (a double 2.2, in this case, actually means 2.200000000000002). I'm also using templates if that makes it more complicated. I thought there was a .equals command, but that might be just for java/lists.
e: aha! You just subtract the two and see if they are equal to 0. Thanks anyway guys.
And I can't figure out how that "changes the semantics of the class" because MSDN sucks.
Edit: Oh wait, there are other articles I didn't read. Joy.
No, don't do that. It's possible for two values that super-duper look like they should be equal (as in they were even calculated the exact same way) to not be, in which case subtracting won't result in 0.
Subtracting is on the right track though. The most common method is to see if abs(val1-val2) < epsilon, where abs is the absolute value function and epsilon is some really small positive number like .00000001.
I've heard that in practice D isn't very good.
Lack of compiler/IDE development + the stuff that makes it more sane than than C++ is old news now.
Two float values calculated in EXACTLY the same way will always be equal. FP math is completely deterministic. There is a situation where that doesn't hold true in the CLR described here, but it is more of a leaky abstraction issue.
Depends on how you define exactly. The same algebra? The same code? The same hardware?
I could run code on one machine that calculates some numbers, stores them in a database, run the same code on different hardware, and theoretically have them be different bit for bit even though they are "the same numbers calculated the same way."
Comparing the difference within a very small tolerable error (epsilon) as posted is the correct method.
// Calculate some double calc ... if(calc == 2.2) { ... }or something like that.
The correct way to do that is
// Calculate some double calc ... if(abs(calc - 2.2) < 0.00001) { ... }So if someone says OMG YOU SHOULD DO IT THIS WAY or USE A DIFFERENT EPSILON you can without changing everywhere in your code.
#define FLOAT_EQUAL(a, b) (abs((a) - (b)) < 0.000001) ... if (FLOAT_EQUAL(num, 5.0)) { ...Makes it a little clearer what exactly you're accomplishing as well.
That issue is what I was thinking of.
Even if you know it won't happen in a given situation, I'd advise against it simply because that probably won't be clear to other people who might look at your code.