Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 24 Apr 2010
Offline Last Active Today, 04:02 AM

#5286938 c++ list iterator not dereferencable when using switch statement

Posted by on 14 April 2016 - 05:03 PM

list<Vertex>::iterator rotate_current = rotated.begin();

can be

auto rotate_current = rotated.begin();

Which is easier on you and also makes it easier to change the container type.


Which raises the question: Why are you using a list rather than a vector? vector is superior in the overwhelming majority of cases, most especially for iteration, which I see you doing plenty of here.


Also, I mentioned DRY and switches in your other thread. You've got some of that going on here. You're doing the same thing in both cases, but with different containers. Why not make that process a function:

void doStuff(std::list<Vertex>& container);

and then just

switch(select) {
  case 1: doStuff(vertices); break;
  case 2: doStuff(rotated);  break;

You can also take advantage of the new for-each syntax, except in the case where you're using the 'previous' iterator (though you could just retain a pointer to the element there):

for(auto shape : shapes) {

#5286936 c++ should nested switch statements be avoided?

Posted by on 14 April 2016 - 04:44 PM

It looks quite messy and difficult to read


Therefore avoid it when you can reasonably do so. Depending on the situation there's a decent chance that the nested switches could be within function calls, which is easier to read and probably supports DRY in many cases.

#5286895 Simple code for reading and writing file in UTF-16 mode

Posted by on 14 April 2016 - 12:22 PM

I have no idea why std::endl would behave in this way

Because endl is a turd that only causes problems. You don't need to flush the stream at that point either (whoops! endl does that too) because all it will do is harm performance. Just use your LINE_END instead or just use L"\n", which is less typing.

#5286757 Creating Box RigidBody From AABB

Posted by on 13 April 2016 - 03:35 PM

You really need your coordinate systems to share the same origin if they're supposed to correspond. The typical solution to this is to employ an offset, which can be metadata with your model (just marking the position of the barycenter/CoM in model space) or you can calculate it at load time if it's just barycenter. It would be easier in the short-run to center the pivot, but if that's restrictive for you then building that offset system is a one-shot solution that will remove the restriction and let you do your thing (not counting bugs, etc).


The basic idea is to transform the CoM along with the object and then use the resulting position as the offset for aligning the spaces.


For example, in the picture you showed we can say that the bottom-center of the model is at 0,0,0 and the barycenter is at 0,1,0. So just add 0,1,0 to to the object position for bullet and the AABB should align correctly.

#5286591 Template-related compiler bug or... ?

Posted by on 12 April 2016 - 11:02 PM

The behavior is standard. The relevant section is §14.8.3, paragraph 1.

#5286577 Template-related compiler bug or... ?

Posted by on 12 April 2016 - 10:13 PM

C++ template type deduction rules are spelled out in the standard in excruciating detail

Okay, so are you going to cite a relevant passage so the question is answered?

and compilers implement it exactly as specified

Except for when they don't.

While bugs are possible, you would need to be well versed in the C++ standard to differentiate between compiler bugs and C++ limitations.

There are people here that are extremely well-versed, so I'm asking those people.

#5286553 Creating Box RigidBody From AABB

Posted by on 12 April 2016 - 08:02 PM

Okay, so you know about debuggers already. Fantastic. Let me just make sure that we're on the same page here.


You've already got bullet debug view on - so clearly we're not talking about that. Let's cross that off the list.


You didn't post shader code because it sure doesn't seem like a shader issue, so digging up pix from the depths of history probably isn't what we're after. Let's go ahead and cross that off the list too.


You did post application code, because that's where the issue probably is.

The code you posted is relatively short and not very complex.

Your issue is an IPO (input-process-output) problem where the process is the prime suspect.


So of our remaining option, what tool can generally identify and isolate that kind of problem in about 30 seconds?


#5286547 Creating Box RigidBody From AABB

Posted by on 12 April 2016 - 06:48 PM

Okay, we're not in For Beginners (I scrolled up) so it's time to learn how debugging works. This is more or less a perfectly ideal case.

Are you using Visual Studio, or something "fun"?

#5286544 Creating Box RigidBody From AABB

Posted by on 12 April 2016 - 06:42 PM

Run the debugger?

#5285962 Why learn STL library

Posted by on 09 April 2016 - 12:52 AM

I swear there's a conspiracy to very slowly wind me up going on here...

...And I love it.

#5285961 Is it good practice for game development to learn multiple languages?

Posted by on 09 April 2016 - 12:46 AM

When you first start out the important thing is to get your feet under you. If you can do small projects comfortably in SFML then you're on the right track. The danger is in using alternatives as a means of running away from things you don't understand. Ideally you want to reach a point where you feel good about the language you're using and then take up another language just to see what it is and what you can do with it. If you fall into the habit of running away any time you find a difficult problem then you're only going to become incompetent in many different languages. Beat the problems to get stronger and branch out from that position of strength.

Incidentally, there are a lot of people who can't do what you've done so far, so keep going.

#5285960 Should getters and setters be avoided?

Posted by on 09 April 2016 - 12:30 AM

Simple setters are generally pointless. If outside logic should be able to directly set an object's members, those members should generally be public,

The guidelines are actually opposed to both (avoid trivial get/set and avoid public class members), which is a bit of a sore point for me, but even the discussion around the guidelines was peppered with people saying, "It's a guideline, not a rule."

Honestly, it's nice to have a super well-formed system, but you can spend years on every trivial item and still have issues. I think it's really down to experience and learning what things save time in the long run and what things don't, and what's true for you and yours may not be the same for other people.

#5285940 Typing skills

Posted by on 08 April 2016 - 07:32 PM

I think 30 mistakes per minute is good.

30? With the right tools we could easily double that.

#5285921 Should getters and setters be avoided?

Posted by on 08 April 2016 - 04:13 PM

As usual, you should not take everything too seriously.


Skyrocketing toward 'most upvoted post ever'. Well done.

#5285919 Why learn STL library

Posted by on 08 April 2016 - 04:11 PM

At the very least you should learn it because other people use it and you want to be able to understand what the hell is going on when you see their code.


I'm more interested to know why you think that knowing about a small fraction of language features means that you can't benefit from learning other things as well.