Quote:Original post by RinusMaximus Thanks for the explanation jflanglois and Fruny, I see what the difference is. And now that you tell me that the new allocates memory on the heap and returns me a pointer it makes sense to me as well. This is actually really close to what Java does.
Is it save for me to assume that the first form
Cat Frisky(5);
is shown because we haven't discussed pointers yet and that
Cat* Frisky = new Cat(5);
will be the way I will use it in my future programs?
Ignoring that "in your future programs" you won't be messing around with toy examples like Cat ;)
In C++, there are lots of rules of thumb of the form "Use X when you can; use pointers when you have to." With good reason :) You have to do your own memory management, and raw pointers don't "know" anything that could help with this task. For example, if you wanted to write a function that accepted a pointer and deallocated the pointed-at stuff (very bad idea), you'd be stuck, because there is no way to find out whether the pointer points at a single element or at an array allocation, and you *must* use delete[] for the array allocation rather than delete. (Even if the array size is 1, even if it's an array of a primitive type, even if anything-else-you-can-think-of-that-might-make-a-difference.)
So yeah, pay attention to the other replies, and think carefully - sometimes you will need a pointer, and you can't do this stuff on autopilot.
Quote:Original post by RinusMaximus Thanks for the explanation jflanglois and Fruny, I see what the difference is. And now that you tell me that the new allocates memory on the heap and returns me a pointer it makes sense to me as well. This is actually really close to what Java does.
Is it save for me to assume that the first form
Cat Frisky(5);
is shown because we haven't discussed pointers yet and that
Cat* Frisky = new Cat(5);
will be the way I will use it in my future programs?
In general, allocating objects with pointers is only used if you want polymorphic behaviour (which can also be achieved using "references") or if an object is large so placing it on the stack may not be a good idea. It is preferable to use stack objects as much as possible if you can, as they are automatically cleaned up at the end of their scope.
Ironically, you forgot the single most common scenario: You simply want the object to stick around after the current scope has exited. It doesn't matter how simple the object is, or whether you're using it polymorphically; if you want it to exist 'independently' of the code that creates it, then you need to put it on the heap (or make it a global variable, but there are other issues inherent in doing that). An example would be creating nodes in a linked list structure - they're small objects and not polymorphic, but you need them to exist independently of any AddNode() function.
Using stack objects instead of heap objects is often a sensible practice, but don't go crazy.
Richard "Superpig" Fine - saving pigs from untimely fates - Microsoft DirectX MVP 2006/2007/2008/2009
"Shaders are not meant to do everything. Of course you can try to use it for everything, but it's like playing football using cabbage." - MickeyMouse
Quote:Original post by superpig: It doesn't matter how simple the object is, or whether you're using it polymorphically; if you want it to exist 'independently' of the code that creates it, then you need to put it on the stack
This is probably a missprint, or perhaps I'm missunderstanding him. If you want your data to exist independant of the call stack, then you need to create it on the heap, not the stack. If its created on the stack then it's local data which will be destroyed upon returning from the current location.
Also, I will be posting a quiz for this week tomorrow. I would do it today, but I'm still catching up on my reading. You will, however, find that I posted a quiz for Week 4.
Quote:Original post by superpig: It doesn't matter how simple the object is, or whether you're using it polymorphically; if you want it to exist 'independently' of the code that creates it, then you need to put it on the stack
This is probably a missprint, or perhaps I'm missunderstanding him. If you want your data to exist independant of the call stack, then you need to create it on the heap, not the stack. If its created on the stack then it's local data which will be destroyed upon returning from the current location.
Also, I will be posting a quiz for this week tomorrow. I would do it today, but I'm still catching up on my reading. You will, however, find that I posted a quiz for Week 4.
Whoops, yes. Sorry, I'll edit my original post...
Richard "Superpig" Fine - saving pigs from untimely fates - Microsoft DirectX MVP 2006/2007/2008/2009
"Shaders are not meant to do everything. Of course you can try to use it for everything, but it's like playing football using cabbage." - MickeyMouse
It's once again QUIZ TIME!!! That's right, listed below are a set of quiz questions to help you test your knowledge and understanding of the material contained in chapters 6. I will post a follow-up quiz for chapter 11 tomorrow.
In addition to the questions and exercises below, make sure that as you're reading the book you enter the examples into your compiler, build the program, and run the executable. I know this is a time consuming process, but the repeat use of keywords, syntax, and semantics will help ingrain the information into your long-term memory. My advice is to create a simple "driver" project with a function main. As you read, enter the examples into function main, test it, and then erase it for use again in the next example.
PLEASE DO NOT POST THE ANSWERS TO THESE QUESTIONS OR EXERCISES. If you are unable to answer these questions, please ask for assistance, but DO NOT POST THE ANSWERS. Any question which is not marked with [Extra Credit] can be answered by reading your textbook. Questions which are marked [Extra Credit] either have been answered in the thread previously, or can be answered by doing a bit of research.
I will create an answer thread for these questions immediately, so that people will have a chance to get the answers more quickly.
Chapter 6 Quiz
1. What was the ‘C’ capability which allowed you to combine related variables? Did this solve the problem of connecting data with behaviors? 2. How do you make a new type in C++? 3. What is a class? 4. What is another name for variables within a class? What is another name for the member functions? 5. What are the requisite parts of a class declaration? Show an example. 6. What are the two things a class declaration tells your compiler? 7. When discussing naming conventions, what’s the most important point to remember? 8. What is an object? 9. How do you declare an object? Show an example. 10. What operator is used to access members and methods of a class for objects created on the stack. 11. What is the difference between public and private members/methods within a class? Which is the default? 12. In general, should methods or members be private? Why? 13. What is the primary way you initialize the member data of a class? 14. How can you identify a constructor for a class? 15. What is a default constructor? How is it called. 16. What does “declaring a method of a class const” mean? What is the syntax for such a declaration? 17. In the context of classes and objects, what is a client? 18. Where do class declarations go? Where do the member function definitions go? 19. When one class has a member variable which is an object of a different class they are said to form a ___ relationship? 20. What is the only difference between C++ classes and C++ structs?
Chapter 6 Exercises
I will post exercises tomorrow for both chapter 6 and 11.
It's been a hard week! I'm comfortable with the principles in the chapters but have been very confused by Listings 6.8 and 6.9 which demonstrate the use of Classes within Classes. There are so many methods and data members there and a lot of them have similar names. Does anyone have a more simple example that they could post with, maybe, 2 or 3 methods and 4 or 5 data members?
I realise that this is a core element of C++ and I MUST get my head around it, otherwise I'll stay at the "Hello World!" phase!
I must say I have to agree! That rectangle program is pretty crazy, although I've been kinda hoping Mr. Walsh's workshop will create other, simpler examples for us to work with in the coming weeks. Perhaps someone else could post a simpler program illustrating subclasses for us to examine here? I would find it very helpful as well.
Well, if you don't ask, we can't guess what you're having problems with. Please, people, if you have a question, if something is unclear, say so. Even if it seems a minor point, ask.
If nobody ever asks questions, the tutors are going to believe that noone is actually participating in the tutorial, and lose interest.
Watch this space for an explanation of nested classes, coming up when I'm done typing it.
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." — Brian W. Kernighan
Please note that it's probably going to take a while to finish typing that explanation. While nested classes are simple, they open the door to some relatively advanced techniques which are omnipresent in the standard C++ library. In fact, template metaprogramming, which is possibly the most advanced C++ programming technique could not exist without nested classes.
And rating++ to CondorMan, for giving me back hope that we're not just wasting our time.
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." — Brian W. Kernighan
