GnomeTankWhat the what?Portland, OregonRegistered Userregular
edited June 2010
Back to the stack/heap/memory discussion: In C++, you should be using smart pointers when dealing with heap memory. Boost::shared_ptr and Boost::scoped_ptr are the ones I use the most, though I've been known to use std::auto_ptr.
Back to the stack/heap/memory discussion: In C++, you should be using smart pointers when dealing with heap memory. Boost::shared_ptr and Boost::scoped_ptr are the ones I use the most, though I've been known to use std::auto_ptr.
In a perfect world I would agree. But you should learn manual pointer manipulation if you ever have to work with legacy code.
Back to the stack/heap/memory discussion: In C++, you should be using smart pointers when dealing with heap memory. Boost::shared_ptr and Boost::scoped_ptr are the ones I use the most, though I've been known to use std::auto_ptr.
In a perfect world I would agree. But you should learn manual pointer manipulation if you ever have to work with legacy code.
Learn how to do it without smart pointers, so that you can appreciate them!
Infidel on
0
Options
GnomeTankWhat the what?Portland, OregonRegistered Userregular
edited June 2010
Smart pointers aren't an excuse to not understand C++ memory management, but that doesn't mean you shouldn't use them as soon as you understand why they are important. Get in the habit early, and write better code later.
Smart pointers aren't an excuse to not understand C++ memory management, but that doesn't mean you shouldn't use them as soon as you understand why they are important. Get in the habit early, and write better code later.
Nooooooooo, you're not supposed to actually use things that make C++ development not a pain in the ass! You're supposed to be thankful for language X and how it's not god-forsaken like C++.
Who can give me 1 paragraph how to overview of the following:
I have a very simple scene drawn in OpenGL. It's a camera, boxed inside of a cube with textures painted on the sides of the cube (inward facing the camera).
I want to designate areas on the sides (corresponding to a point on the texture) as "hot spots". Clicking would then determine if the click was over a hotspot.
Who can give me 1 paragraph how to overview of the following:
I have a very simple scene drawn in OpenGL. It's a camera, boxed inside of a cube with textures painted on the sides of the cube (inward facing the camera).
I want to designate areas on the sides (corresponding to a point on the texture) as "hot spots". Clicking would then determine if the click was over a hotspot.
You'll want to look into gluUnProject to convert your mouseclick x/y into worldspace x/y/z, you can define hotspots as some sort of bounding object and test for the point within that.
Infidel on
0
Options
DVGNo. 1 Honor StudentNether Institute, Evil AcademyRegistered Userregular
edited June 2010
Ah, nothing to round out a long weekend like diving into code to figure out where you fucked up your reference count that's crashing your iPhone app.
Smart pointers aren't an excuse to not understand C++ memory management, but that doesn't mean you shouldn't use them as soon as you understand why they are important. Get in the habit early, and write better code later.
Nooooooooo, you're not supposed to actually use things that make C++ development not a pain in the ass! You're supposed to be thankful for language X and how it's not god-forsaken like C++.
Honestly, while smart pointers are nice I don't think they actually reduce the complexity of working with C++.
I've been working a lot with Qt, and I still can't figure out what the semantics of adding something to a QList are. The documentation on the subject makes my head spin, with discussions of "implicit sharing" and the like.
I find the C++ tendency toward copy semantics very confusing and almost never what I want, and while smart pointers implement functionality that I need, they also make the program more confusing.
LoneIgadzra on
0
Options
Monkey Ball WarriorA collection of mediocre hatsSeattle, WARegistered Userregular
edited June 2010
Does the "foo::bar" syntax in c++ mean "bar, which can be found in the library foo"?
I saw it in ruby once and had no idea wtf it was supposed to mean. This was a long time ago, though.
Monkey Ball Warrior on
"I resent the entire notion of a body as an ante and then raise you a generalized dissatisfaction with physicality itself" -- Tycho
Does the "foo::bar" syntax in c++ mean "bar, which can be found in the library foo"?
I saw it in ruby once and had no idea wtf it was supposed to mean. This was a long time ago, though.
Namespace. In that example, "foo" is the namespace, and "bar" is the variable, class or function declared in that namespace.
LoneIgadzra on
0
Options
DVGNo. 1 Honor StudentNether Institute, Evil AcademyRegistered Userregular
edited June 2010
Oh man, this is confusing.
So I've run into my first memory allocation error on iPhone development. I'm getting the dreaded EXC_BAD_ACCESS exception when I'm doing something. So I enabled Zombie-Mode (which is a pretty cool feature) and tracked it down to my predicate (which has pretty much been the bane of my existence for the last week or so).
But it's not an object I really have memory ownership of. It's my fetched results controller, and the _predicate member of it's _fetchrequest member.
So at the end of the method where the fetchedResultsController is built, the _predicate is set to an NSComparisonPredicate. By the time the table asks how many rows to draw, _predicate has been dealloc'd and now lives only as a Zombie, all without any command on my part to kill itself.
Have you considered just making the predicate a class property? Wouldn't hurt as a test.
Jasconius on
0
Options
DVGNo. 1 Honor StudentNether Institute, Evil AcademyRegistered Userregular
edited June 2010
It's super weird. As a test, i sent [fetchedResultsController.fetchRequest.predicate retain]; and suddenly it all works, but I don't think that's what I'm supposed to do.
DVG on
Diablo 3 - DVG#1857
0
Options
DVGNo. 1 Honor StudentNether Institute, Evil AcademyRegistered Userregular
edited June 2010
Heh, like usual it was something simple. When I was building the fetched results controller I was releasing all the variables I created in the process, and neglected to notice that *predicate wasn't created with new, alloc, retain or copy.
Who can give me 1 paragraph how to overview of the following:
I have a very simple scene drawn in OpenGL. It's a camera, boxed inside of a cube with textures painted on the sides of the cube (inward facing the camera).
I want to designate areas on the sides (corresponding to a point on the texture) as "hot spots". Clicking would then determine if the click was over a hotspot.
You'll want to look into gluUnProject to convert your mouseclick x/y into worldspace x/y/z, you can define hotspots as some sort of bounding object and test for the point within that.
Yes, this. Specifically, you'll want this (or an equivalent function in your chosen language) to get the line in world space
//uses gluUnProject to convert a xy pair to an xyz point
//projmat & modelmat can be NULL
//x & y are relative to the topleft client pixel
static void Mouse2Dto3D(int x, int y, const double *projmat, const double *modelmat,
const RECT *viewport, Vector& pt0, Vector& pt1, bool clamp=true)
{
if(!viewport)
return;
double _modl[16], _proj[16];
const double *modl=_modl, *proj=_proj;
//choose the projection matrix
if(projmat)
proj=projmat;
else
glGetDoublev( GL_PROJECTION_MATRIX, _proj );
//choose the modelview matrix
if(modelmat)
modl=modelmat;
else
glGetDoublev( GL_MODELVIEW_MATRIX, _modl );
//clamp to viewport extremes
if(clamp){
if(x<viewport->left) x=viewport->left;
if(x>viewport->right) x=viewport->right;
if(y<viewport->top) y=viewport->top;
if(y>viewport->bottom) y=viewport->bottom;
}
y = viewport->bottom - y; //convert to bottom-up format used by GL
gluUnProject(x, y, 0.0, modl, proj, (const int*)viewport, &pt0.x, &pt0.y, &pt0.z);
gluUnProject(x, y, 1.0, modl, proj, (const int*)viewport, &pt1.x, &pt1.y, &pt1.z);
}
It's been a while since I used this but I'm pretty sure it should work.
Once you have the line just do an intersection test on your targets. The easiest way to do that would probably be a line-plane intersection (where the plane is formed by your hotspot area) and then a simple 2d check to see if the intersection point is inside the area.
Who can give me 1 paragraph how to overview of the following:
I have a very simple scene drawn in OpenGL. It's a camera, boxed inside of a cube with textures painted on the sides of the cube (inward facing the camera).
I want to designate areas on the sides (corresponding to a point on the texture) as "hot spots". Clicking would then determine if the click was over a hotspot.
You'll want to look into gluUnProject to convert your mouseclick x/y into worldspace x/y/z, you can define hotspots as some sort of bounding object and test for the point within that.
Yes, this. Specifically, you'll want this (or an equivalent function in your chosen language) to get the line in world space
//uses gluUnProject to convert a xy pair to an xyz point
//projmat & modelmat can be NULL
//x & y are relative to the topleft client pixel
static void Mouse2Dto3D(int x, int y, const double *projmat, const double *modelmat,
const RECT *viewport, Vector& pt0, Vector& pt1, bool clamp=true)
{
if(!viewport)
return;
double _modl[16], _proj[16];
const double *modl=_modl, *proj=_proj;
//choose the projection matrix
if(projmat)
proj=projmat;
else
glGetDoublev( GL_PROJECTION_MATRIX, _proj );
//choose the modelview matrix
if(modelmat)
modl=modelmat;
else
glGetDoublev( GL_MODELVIEW_MATRIX, _modl );
//clamp to viewport extremes
if(clamp){
if(x<viewport->left) x=viewport->left;
if(x>viewport->right) x=viewport->right;
if(y<viewport->top) y=viewport->top;
if(y>viewport->bottom) y=viewport->bottom;
}
y = viewport->bottom - y; //convert to bottom-up format used by GL
gluUnProject(x, y, 0.0, modl, proj, (const int*)viewport, &pt0.x, &pt0.y, &pt0.z);
gluUnProject(x, y, 1.0, modl, proj, (const int*)viewport, &pt1.x, &pt1.y, &pt1.z);
}
It's been a while since I used this but I'm pretty sure it should work.
Once you have the line just do an intersection test on your targets. The easiest way to do that would probably be a line-plane intersection (where the plane is formed by your hotspot area) and then a simple 2d check to see if the intersection point is inside the area.
There is also the GL_SELECT method, where you basically render the scene (localized around just the mouse click) into a special buffer that basically is "object 1 drawn in color index 1, object 2 in index 2, etc." and you can grab the resultant pixel under the mouse click to determine which object # was clicked on.
I don't really like this method since it ends up being more work and less flexible I find. For example, the hotspots desired by you (Jasconius) wouldn't work with this as-is since you only have one object, and all you could have GL figure out for you is "yes you clicked on the cube" which is a no-brainer in your scenario. It also leaves you unable to tell where you clicked in world space, meaning you can't tell relative to the object and get zero useful info if you don't click on any objects.
The projecting method is the "right" method imo because of this. Picking (as the GL_SELECT method is known as) only works for objects that you define so you'd have to write this projection code anyways if you're doing things like targeting (an RTS style "move here" click order, etc.)
Who can give me 1 paragraph how to overview of the following:
I have a very simple scene drawn in OpenGL. It's a camera, boxed inside of a cube with textures painted on the sides of the cube (inward facing the camera).
I want to designate areas on the sides (corresponding to a point on the texture) as "hot spots". Clicking would then determine if the click was over a hotspot.
You'll want to look into gluUnProject to convert your mouseclick x/y into worldspace x/y/z, you can define hotspots as some sort of bounding object and test for the point within that.
Yes, this. Specifically, you'll want this (or an equivalent function in your chosen language) to get the line in world space
//uses gluUnProject to convert a xy pair to an xyz point
//projmat & modelmat can be NULL
//x & y are relative to the topleft client pixel
static void Mouse2Dto3D(int x, int y, const double *projmat, const double *modelmat,
const RECT *viewport, Vector& pt0, Vector& pt1, bool clamp=true)
{
if(!viewport)
return;
double _modl[16], _proj[16];
const double *modl=_modl, *proj=_proj;
//choose the projection matrix
if(projmat)
proj=projmat;
else
glGetDoublev( GL_PROJECTION_MATRIX, _proj );
//choose the modelview matrix
if(modelmat)
modl=modelmat;
else
glGetDoublev( GL_MODELVIEW_MATRIX, _modl );
//clamp to viewport extremes
if(clamp){
if(x<viewport->left) x=viewport->left;
if(x>viewport->right) x=viewport->right;
if(y<viewport->top) y=viewport->top;
if(y>viewport->bottom) y=viewport->bottom;
}
y = viewport->bottom - y; //convert to bottom-up format used by GL
gluUnProject(x, y, 0.0, modl, proj, (const int*)viewport, &pt0.x, &pt0.y, &pt0.z);
gluUnProject(x, y, 1.0, modl, proj, (const int*)viewport, &pt1.x, &pt1.y, &pt1.z);
}
It's been a while since I used this but I'm pretty sure it should work.
Once you have the line just do an intersection test on your targets. The easiest way to do that would probably be a line-plane intersection (where the plane is formed by your hotspot area) and then a simple 2d check to see if the intersection point is inside the area.
There is also the GL_SELECT method, where you basically render the scene (localized around just the mouse click) into a special buffer that basically is "object 1 drawn in color index 1, object 2 in index 2, etc." and you can grab the resultant pixel under the mouse click to determine which object # was clicked on.
I don't really like this method since it ends up being more work and less flexible I find. For example, the hotspots desired by you (Jasconius) wouldn't work with this as-is since you only have one object, and all you could have GL figure out for you is "yes you clicked on the cube" which is a no-brainer in your scenario. It also leaves you unable to tell where you clicked in world space, meaning you can't tell relative to the object and get zero useful info if you don't click on any objects.
The projecting method is the "right" method imo because of this. Picking (as the GL_SELECT method is known as) only works for objects that you define so you'd have to write this projection code anyways if you're doing things like targeting (an RTS style "move here" click order, etc.)
Yeah, GL_SELECT basically just sucks. It's less useful and quite slow. I suppose the only case where it really would be better is if you had some crazy non-standard transforms that don't translate well to the mathematical intersection methods.
I've always done it this way, through projections (although what I normally set the matrices up to do is generate the line in object space since it takes less math to translate the 2 points of the line for each object than to bring everything into world space)
Smart pointers aren't an excuse to not understand C++ memory management, but that doesn't mean you shouldn't use them as soon as you understand why they are important. Get in the habit early, and write better code later.
Nooooooooo, you're not supposed to actually use things that make C++ development not a pain in the ass! You're supposed to be thankful for language X and how it's not god-forsaken like C++.
Honestly, while smart pointers are nice I don't think they actually reduce the complexity of working with C++.
I've been working a lot with Qt, and I still can't figure out what the semantics of adding something to a QList are. The documentation on the subject makes my head spin, with discussions of "implicit sharing" and the like.
I find the C++ tendency toward copy semantics very confusing and almost never what I want, and while smart pointers implement functionality that I need, they also make the program more confusing.
I have no idea how smart pointers make your code more difficult to understand. They make memory management semantics much easier to understand, in almost all cases.
Smart pointers aren't an excuse to not understand C++ memory management, but that doesn't mean you shouldn't use them as soon as you understand why they are important. Get in the habit early, and write better code later.
Nooooooooo, you're not supposed to actually use things that make C++ development not a pain in the ass! You're supposed to be thankful for language X and how it's not god-forsaken like C++.
Honestly, while smart pointers are nice I don't think they actually reduce the complexity of working with C++.
I've been working a lot with Qt, and I still can't figure out what the semantics of adding something to a QList are. The documentation on the subject makes my head spin, with discussions of "implicit sharing" and the like.
I find the C++ tendency toward copy semantics very confusing and almost never what I want, and while smart pointers implement functionality that I need, they also make the program more confusing.
e.g. it's got push_back(), push_front(), insert()... all sorts.
Which part of QList are you specifically having trouble with?
Implicit sharing, in the context of Qt, is a "only make a copy of the data if I need to, otherwise just point to the original data".
It's a common memory management optimisation:
e.g.
QString szOriginalString = GetRandomString(); // From somewhere
QString szEvenLengthString = MakeEvenLength(szOriginalString);
cout
<< "Original string: " << szOriginalString << endl
<< "Modified string: " << szEvenLengthString << endl;
QString MakeEvenLength(QString szInputString)
{
if(szInputString.size() & 1)
{
// Odd length string - append a space to make it even
szInputString += " ";
}
return szInputString;
}
If there were no implicit sharing involved, then every time QString's copy constructor is called, it would allocate memory for a while new string.
So if the original input string was, say, 2048 characters, then szInputString would also allocate memory for 2048 characters and copy the original input string over, and then szEvenLengthString would also allocate 2048 characters and copy the contents of szInputString over.*
* Depending on the level of optimisation, there may also be a temporary QString created for the return value of MakeEvenLength().
So even if the original input string was even length and would remain unchanged, there would be at least 2 memory allocations/copies made - even though the string contents are unchanged!
Implicit sharing, on the other hand, would go, "Let's not make copies that we don't need."
So when the call to MakeEvenLength() is made, szInputString would *not* allocate memory - it would instead just point to the same memory as szOriginalString.
If the original string was even length, then the return value would set szEvenLengthString to point to the original memory allocated by szOriginalString. This means that szOriginalString is being implicitly shared with szEvenLengthString because they contain the exact same data, so why not share the same memory?
Now, if the original string was odd length, the attempt to change it would cause szInputString to allocate the memory for more characters, because szInputString is now no longer equal to szOriginalString. As a result, szEvenLengthString will point to a different block of memory than szOriginalString.
Basically, only allocate memory when you need to.
Very easy to do once you have reference counted smart pointers!
e.g.
void tSomeClass::FunctionWhichChangesData()
{
if(m_pData->GetReferences() > 1)
{
// At least one other instance is implicitly sharing the same data we are, so we need to make a copy
m_pData = MakeCopyOf(m_pData);
}
else
{
// Can directly write to m_pData since we are the only instance using that data
}
*m_pData = blah blah blah
}
Edit: Of course, it gets more complex if you're multi-threading, but this is the general gist of it.
I have no idea how smart pointers make your code more difficult to understand. They make memory management semantics much easier to understand, in almost all cases.
All the boost pointers are great, and shared_ptr is the bees' knees.
GnomeTankWhat the what?Portland, OregonRegistered Userregular
edited June 2010
shared_ptr is pretty great, but I find scoped_ptr to be a more useful general tool, especially in file I/O situations where you may have to allocate/deallocate a lot of temporary buffers of dynamic size.
Started studying C++ again a few days ago. Im now up to finding substrings. Fodder said that I'm past the hard part, the rest is pretty simple. He has also said that he is a better Dystopia player than me, so who knows if he can be trusted.
I've been studying up on C++ as part of my "learn a couple of new languages this year" goal and so far, it's not so bad. I'm doing the cprogramming.com series first, then I have C++ Primer Plus I'll be going over. The only language I know well enough to say I'm proficient in is AS3, but the syntax in C++ is pretty similar. I got tripped up a bit at binary trees with pointers, but I'm hoping anything that doesn't click right away now will clear up when I go over the book.
My end goal is a bit specific, creating extensions for a specific platform, ESRI ArcObjects. I'm hoping to at least get good at that.
I'm taking notes from all you guys too, so thanks.
Starfuck on
jackfaces
"If you're going to play tiddly winks, play it with man hole covers."
- John McCallum
Pointers aren't hard. Just because a lot of bad programming has been done with them doesn't mean that you're doomed to do the same. Most of the time, if it's tough to keep track of memory and free it at the appropriate time, that's an indication that you need to take a look at the big picture. Memory management is made easiest not by automation, but by well designed and structured code - especially in C++ where you have destructors vs plain old malloc/free.
As far as code readability, pointers are extremely simple. With regards to memory management, they don't do anything by themselves, and there's a well known set of things that are done with them (new, delete, malloc, free, etc.). Anyone who has written C or derivative languages knows the concept. If you use a smart pointer, it has its own special properties regarding the circumstances under which the pointed object will be destroyed, and anyone who reads your code needs to understand those properties. So I would certainly agree that there's an increase in complexity there.
There are exceptions, but in most cases I opt for the interoperability and simplicity of a normal pointer, and use tools like Valgrind to catch any mistakes that slip through the cracks.
I may have asked this before, or maybe I didnt. One of the 2. After learning 1 language, do others tend to be easier to learn?
Nope. Once you understand how things work it's relatively easy depending on the resource you're learning from.
I'm trying to pick up FoxPro ( ) from someone's sourcecode so that I can rewrite it. Which is substantially harder than picking up a book and learning. I don't know what's wrong with me.
The only hard part is concepts that don't transfer well between languages. If you know Java and went to C++, you'd have a hard time understanding memory, pointers, and most of that. At least most people usually do anyways.
But since you started with C++, you should be good for most of the used languages.
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
0
Options
GnomeTankWhat the what?Portland, OregonRegistered Userregular
Pointers aren't hard. Just because a lot of bad programming has been done with them doesn't mean that you're doomed to do the same. Most of the time, if it's tough to keep track of memory and free it at the appropriate time, that's an indication that you need to take a look at the big picture. Memory management is made easiest not by automation, but by well designed and structured code - especially in C++ where you have destructors vs plain old malloc/free.
As far as code readability, pointers are extremely simple. With regards to memory management, they don't do anything by themselves, and there's a well known set of things that are done with them (new, delete, malloc, free, etc.). Anyone who has written C or derivative languages knows the concept. If you use a smart pointer, it has its own special properties regarding the circumstances under which the pointed object will be destroyed, and anyone who reads your code needs to understand those properties. So I would certainly agree that there's an increase in complexity there.
There are exceptions, but in most cases I opt for the interoperability and simplicity of a normal pointer, and use tools like Valgrind to catch any mistakes that slip through the cracks.
Seriously, you think shared_ptr, auto_ptr, and scoped_ptr add that much complexity to your code? Seriously?
With shared_ptr, I don't even care about my destructors. When I allocate a pointer to it, I know for a fact it's going to be de-allocated when that class is torn down, I don't even have to think about it. How is this adding complexity? The complexity of reading less than 50 lines of documentation on the incredibly simple and basic semantics of shared_ptr?
If a C++ programmer can't figure out the kindergarten simple semantics of the Boost and standard lib smart pointers, I don't want them on my team, or maintaining my code, anyway.
I may have asked this before, or maybe I didnt. One of the 2. After learning 1 language, do others tend to be easier to learn?
Nope. Once you understand how things work it's relatively easy depending on the resource you're learning from.
I'm trying to pick up FoxPro ( ) from someone's sourcecode so that I can rewrite it. Which is substantially harder than picking up a book and learning. I don't know what's wrong with me.
The only hard part is concepts that don't transfer well between languages. If you know Java and went to C++, you'd have a hard time understanding memory, pointers, and most of that. At least most people usually do anyways.
But since you started with C++, you should be good for most of the used languages.
To add to this, most languages have a syntax that is similar to C. Some might throw in a few syntactical changes/features, so that's probably where you will spend most of your time learning the new language. Likewise, concepts like OOP will be similar between OO languages. So knowing one OO language will get you 80-90% of the way in any other OO language.
Then, there are languages that use a completely different paradigm, like functional programming. Knowing C or C++ probably won't make it much easier to learn Haskell or Erlang or F#, but once you learn one of those you're close to understanding the rest. I'm sure the reverse is true (going from something like Haskell to C), but I don't know anyone who has actually done this.
Halibut on
0
Options
GnomeTankWhat the what?Portland, OregonRegistered Userregular
edited June 2010
Actually most procedural languages are adding a lot of functional tools these days, so even the functional stuff will make sense if you've used a language like C#, or C++0x. Things like type inference and lambdas are all offshoots from functional programming.
Requires:
variables, data types, and numerical operators
basic input/output
logic (if statements, switch statements)
loops (for, while, do-while)
arrays
Write a program that asks the user to enter the number of pancakes eaten for breakfast by 10 different people (Person 1, Person 2, ..., Person 10)
Once the data has been entered the program must analyze the data and output which person ate the most pancakes for breakfast.
★ Modify the program so that it also outputs which person ate the least number of pancakes for breakfast.
★★★★ Modify the program so that it outputs a list in order of number of pancakes eaten of all 10 people.
i.e.
Person 4: ate 10 pancakes
Person 3: ate 7 pancakes
Person 8: ate 4 pancakes
...
Person 5: ate 0 pancakes
Still working on the basic challenge. So far I had this
#include <iostream>
#include <string>
#include <vector>
using namespace std;
int main()
{
int i;
int contestants;
int pancake;
vector <int> eater(1);
cout<<"How many pancake eaters were there? " <<endl;
cin>>contestants;
do
{
cout<<"How many pancakes did contestant "<< eater.size()<< " eat?" <<endl;
cin>>pancake;
eater.pop_back();
eater.push_back(pancake);
eater.push_back(1);
}
while (eater.size()<=contestants);
return 0;
}
Using that just to populate the vectors. However I'm finding no way to further manipulate/store the data as needed. And looking at the site now, it says I should be using arrays... This book has 0 info on how to do anything other than fill an array. Will a vector work just as well?
This book also only lists the .at() .back() .clear() .empty() .front() .pop_back() .push_back() and .size()
Anyone have a scrub-friendly reference guide? The cplusplus.com site seems horribly unorganized in that it references commands that I cant find an explanation of elsewhere.
CangoFett on
0
Options
GnomeTankWhat the what?Portland, OregonRegistered Userregular
edited June 2010
Why are popping a value off the list before you push one on? Your list will never fill. Also, you are pushing a value twice. You're pushing the entered number, then the number 1, why?
Think of a vector like an array that grows as you add elements (the internal implementation is different, but just think of it this way).
e:
Also, this 'vector<int> eaters(1)' creates a vector with one pre-allocated entry. Why are you doing this?
vectors and arrays are nearly identical in their functionality. It seems the example is trying to identify your ability to sort the data. In which case, an array is fine to use, or a vector, or a linked list.
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
Why are popping a value off the list before you push one on? Your list will never fill. Also, you are pushing a value twice. You're pushing the entered number, then the number 1, why?
Think of a vector like an array that grows as you add elements (the internal implementation is different, but just think of it this way).
e:
Also, this 'vector<int> eaters(1)' creates a vector with one pre-allocated entry. Why are you doing this?
vector<int> eaters(1) is so that it asks "how many pancakes did eater 1 eat" from eater.size. Without it, it'll say 0.
The only method I have of adding in an element is push_back. Im popping off the back which is there just to keep the size right, adding in the pancake number, and then adding in a new one that can be popped off at the end.
It works that way because you started it with an size of "1" and you're just checking how many elements total are in the vector when you call vector.size(). This is actually an issue with while loops not being all that great for iterating through an element like a vector or array.
your better bet is to go:
//ask how many eaters there are, init the vector to that size
for(int i = 0; i < eater.size(); i++) {
cout << "How many pancakes did eater " << i + 1 << " eat?" << endl;
cin >> eater[i];
}
That should work, anyways.
Edit:
Pre-emptive old-guy shutdown: this is not a best practice to assign directly to the data-structure, but you're trying to learn concepts at this point.
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
edit: still having issues with that, but I cant really mess with it now, gotta head to work. Ill fiddle with it from scratch tonight. Thanks for the help though.
Posts
In a perfect world I would agree. But you should learn manual pointer manipulation if you ever have to work with legacy code.
Learn how to do it without smart pointers, so that you can appreciate them!
Nooooooooo, you're not supposed to actually use things that make C++ development not a pain in the ass!
I have a very simple scene drawn in OpenGL. It's a camera, boxed inside of a cube with textures painted on the sides of the cube (inward facing the camera).
I want to designate areas on the sides (corresponding to a point on the texture) as "hot spots". Clicking would then determine if the click was over a hotspot.
You'll want to look into gluUnProject to convert your mouseclick x/y into worldspace x/y/z, you can define hotspots as some sort of bounding object and test for the point within that.
Good times.
Honestly, while smart pointers are nice I don't think they actually reduce the complexity of working with C++.
I've been working a lot with Qt, and I still can't figure out what the semantics of adding something to a QList are. The documentation on the subject makes my head spin, with discussions of "implicit sharing" and the like.
I find the C++ tendency toward copy semantics very confusing and almost never what I want, and while smart pointers implement functionality that I need, they also make the program more confusing.
I saw it in ruby once and had no idea wtf it was supposed to mean. This was a long time ago, though.
Namespace. In that example, "foo" is the namespace, and "bar" is the variable, class or function declared in that namespace.
So I've run into my first memory allocation error on iPhone development. I'm getting the dreaded EXC_BAD_ACCESS exception when I'm doing something. So I enabled Zombie-Mode (which is a pretty cool feature) and tracked it down to my predicate (which has pretty much been the bane of my existence for the last week or so).
But it's not an object I really have memory ownership of. It's my fetched results controller, and the _predicate member of it's _fetchrequest member.
So at the end of the method where the fetchedResultsController is built, the _predicate is set to an NSComparisonPredicate. By the time the table asks how many rows to draw, _predicate has been dealloc'd and now lives only as a Zombie, all without any command on my part to kill itself.
Have you considered just making the predicate a class property? Wouldn't hurt as a test.
Yes, this. Specifically, you'll want this (or an equivalent function in your chosen language) to get the line in world space
//uses gluUnProject to convert a xy pair to an xyz point //projmat & modelmat can be NULL //x & y are relative to the topleft client pixel static void Mouse2Dto3D(int x, int y, const double *projmat, const double *modelmat, const RECT *viewport, Vector& pt0, Vector& pt1, bool clamp=true) { if(!viewport) return; double _modl[16], _proj[16]; const double *modl=_modl, *proj=_proj; //choose the projection matrix if(projmat) proj=projmat; else glGetDoublev( GL_PROJECTION_MATRIX, _proj ); //choose the modelview matrix if(modelmat) modl=modelmat; else glGetDoublev( GL_MODELVIEW_MATRIX, _modl ); //clamp to viewport extremes if(clamp){ if(x<viewport->left) x=viewport->left; if(x>viewport->right) x=viewport->right; if(y<viewport->top) y=viewport->top; if(y>viewport->bottom) y=viewport->bottom; } y = viewport->bottom - y; //convert to bottom-up format used by GL gluUnProject(x, y, 0.0, modl, proj, (const int*)viewport, &pt0.x, &pt0.y, &pt0.z); gluUnProject(x, y, 1.0, modl, proj, (const int*)viewport, &pt1.x, &pt1.y, &pt1.z); }It's been a while since I used this but I'm pretty sure it should work.
Once you have the line just do an intersection test on your targets. The easiest way to do that would probably be a line-plane intersection (where the plane is formed by your hotspot area) and then a simple 2d check to see if the intersection point is inside the area.
There is also the GL_SELECT method, where you basically render the scene (localized around just the mouse click) into a special buffer that basically is "object 1 drawn in color index 1, object 2 in index 2, etc." and you can grab the resultant pixel under the mouse click to determine which object # was clicked on.
I don't really like this method since it ends up being more work and less flexible I find. For example, the hotspots desired by you (Jasconius) wouldn't work with this as-is since you only have one object, and all you could have GL figure out for you is "yes you clicked on the cube" which is a no-brainer in your scenario.
The projecting method is the "right" method imo because of this. Picking (as the GL_SELECT method is known as) only works for objects that you define so you'd have to write this projection code anyways if you're doing things like targeting (an RTS style "move here" click order, etc.)
Yeah, GL_SELECT basically just sucks. It's less useful and quite slow. I suppose the only case where it really would be better is if you had some crazy non-standard transforms that don't translate well to the mathematical intersection methods.
I've always done it this way, through projections (although what I normally set the matrices up to do is generate the line in object space since it takes less math to translate the 2 points of the line for each object than to bring everything into world space)
I have no idea how smart pointers make your code more difficult to understand. They make memory management semantics much easier to understand, in almost all cases.
QList is really similar to std::list.
e.g. it's got push_back(), push_front(), insert()... all sorts.
Which part of QList are you specifically having trouble with?
Implicit sharing, in the context of Qt, is a "only make a copy of the data if I need to, otherwise just point to the original data".
It's a common memory management optimisation:
e.g.
QString szOriginalString = GetRandomString(); // From somewhere QString szEvenLengthString = MakeEvenLength(szOriginalString); cout << "Original string: " << szOriginalString << endl << "Modified string: " << szEvenLengthString << endl; QString MakeEvenLength(QString szInputString) { if(szInputString.size() & 1) { // Odd length string - append a space to make it even szInputString += " "; } return szInputString; }If there were no implicit sharing involved, then every time QString's copy constructor is called, it would allocate memory for a while new string.
So if the original input string was, say, 2048 characters, then szInputString would also allocate memory for 2048 characters and copy the original input string over, and then szEvenLengthString would also allocate 2048 characters and copy the contents of szInputString over.*
* Depending on the level of optimisation, there may also be a temporary QString created for the return value of MakeEvenLength().
So even if the original input string was even length and would remain unchanged, there would be at least 2 memory allocations/copies made - even though the string contents are unchanged!
Implicit sharing, on the other hand, would go, "Let's not make copies that we don't need."
So when the call to MakeEvenLength() is made, szInputString would *not* allocate memory - it would instead just point to the same memory as szOriginalString.
If the original string was even length, then the return value would set szEvenLengthString to point to the original memory allocated by szOriginalString. This means that szOriginalString is being implicitly shared with szEvenLengthString because they contain the exact same data, so why not share the same memory?
Now, if the original string was odd length, the attempt to change it would cause szInputString to allocate the memory for more characters, because szInputString is now no longer equal to szOriginalString. As a result, szEvenLengthString will point to a different block of memory than szOriginalString.
Basically, only allocate memory when you need to.
Very easy to do once you have reference counted smart pointers!
e.g.
void tSomeClass::FunctionWhichChangesData() { if(m_pData->GetReferences() > 1) { // At least one other instance is implicitly sharing the same data we are, so we need to make a copy m_pData = MakeCopyOf(m_pData); } else { // Can directly write to m_pData since we are the only instance using that data } *m_pData = blah blah blah }Edit: Of course, it gets more complex if you're multi-threading, but this is the general gist of it.
All the boost pointers are great, and shared_ptr is the bees' knees.
Is that the hard part of coding?
Cause im good at that too.
My end goal is a bit specific, creating extensions for a specific platform, ESRI ArcObjects. I'm hoping to at least get good at that.
I'm taking notes from all you guys too, so thanks.
"If you're going to play tiddly winks, play it with man hole covers."
- John McCallum
Yeah and you really have to poop/eat but don't want to get up.
As far as code readability, pointers are extremely simple. With regards to memory management, they don't do anything by themselves, and there's a well known set of things that are done with them (new, delete, malloc, free, etc.). Anyone who has written C or derivative languages knows the concept. If you use a smart pointer, it has its own special properties regarding the circumstances under which the pointed object will be destroyed, and anyone who reads your code needs to understand those properties. So I would certainly agree that there's an increase in complexity there.
There are exceptions, but in most cases I opt for the interoperability and simplicity of a normal pointer, and use tools like Valgrind to catch any mistakes that slip through the cracks.
Nope. Once you understand how things work it's relatively easy depending on the resource you're learning from.
I'm trying to pick up FoxPro (
The only hard part is concepts that don't transfer well between languages. If you know Java and went to C++, you'd have a hard time understanding memory, pointers, and most of that. At least most people usually do anyways.
But since you started with C++, you should be good for most of the used languages.
Seriously, you think shared_ptr, auto_ptr, and scoped_ptr add that much complexity to your code? Seriously?
With shared_ptr, I don't even care about my destructors. When I allocate a pointer to it, I know for a fact it's going to be de-allocated when that class is torn down, I don't even have to think about it. How is this adding complexity? The complexity of reading less than 50 lines of documentation on the incredibly simple and basic semantics of shared_ptr?
If a C++ programmer can't figure out the kindergarten simple semantics of the Boost and standard lib smart pointers, I don't want them on my team, or maintaining my code, anyway.
To add to this, most languages have a syntax that is similar to C. Some might throw in a few syntactical changes/features, so that's probably where you will spend most of your time learning the new language. Likewise, concepts like OOP will be similar between OO languages. So knowing one OO language will get you 80-90% of the way in any other OO language.
Then, there are languages that use a completely different paradigm, like functional programming. Knowing C or C++ probably won't make it much easier to learn Haskell or Erlang or F#, but once you learn one of those you're close to understanding the rest. I'm sure the reverse is true (going from something like Haskell to C), but I don't know anyone who has actually done this.
Im trying this exercise
variables, data types, and numerical operators
basic input/output
logic (if statements, switch statements)
loops (for, while, do-while)
arrays
Write a program that asks the user to enter the number of pancakes eaten for breakfast by 10 different people (Person 1, Person 2, ..., Person 10)
Once the data has been entered the program must analyze the data and output which person ate the most pancakes for breakfast.
★ Modify the program so that it also outputs which person ate the least number of pancakes for breakfast.
★★★★ Modify the program so that it outputs a list in order of number of pancakes eaten of all 10 people.
i.e.
Person 4: ate 10 pancakes
Person 3: ate 7 pancakes
Person 8: ate 4 pancakes
...
Person 5: ate 0 pancakes
Still working on the basic challenge. So far I had this
#include <iostream> #include <string> #include <vector> using namespace std; int main() { int i; int contestants; int pancake; vector <int> eater(1); cout<<"How many pancake eaters were there? " <<endl; cin>>contestants; do { cout<<"How many pancakes did contestant "<< eater.size()<< " eat?" <<endl; cin>>pancake; eater.pop_back(); eater.push_back(pancake); eater.push_back(1); } while (eater.size()<=contestants); return 0; }This book also only lists the .at() .back() .clear() .empty() .front() .pop_back() .push_back() and .size()
Anyone have a scrub-friendly reference guide? The cplusplus.com site seems horribly unorganized in that it references commands that I cant find an explanation of elsewhere.
Think of a vector like an array that grows as you add elements (the internal implementation is different, but just think of it this way).
e:
Also, this 'vector<int> eaters(1)' creates a vector with one pre-allocated entry. Why are you doing this?
The only method I have of adding in an element is push_back. Im popping off the back which is there just to keep the size right, adding in the pancake number, and then adding in a new one that can be popped off at the end.
It works as intended, though Im sure theres a better way.
your better bet is to go:
//ask how many eaters there are, init the vector to that size for(int i = 0; i < eater.size(); i++) { cout << "How many pancakes did eater " << i + 1 << " eat?" << endl; cin >> eater[i]; }That should work, anyways.
Edit:
Pre-emptive old-guy shutdown: this is not a best practice to assign directly to the data-structure, but you're trying to learn concepts at this point.
5 *s ramps up the complexity a lot, whilst the first two don't, really, at all.