C/C++ Programming Questions Not Worth Their Own Thread

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > C/C++ Programming Questions Not Worth Their Own Thread

«‹›640 »

Jose Cuervo: Aug 25, 2004

That Turkey Story posted:

If you know that in your particular case size() won't ever exceed the max unsigned value, you can do
code:
for( unsigned i = 0; i != myVector.size(); ++i )
or, more safely
code:
for( your_vector_type::size_type i = 0; i != myVector.size(); ++i )
or
code:
for( std::size_t i = 0; i != myVector.size(); ++i )
Or you can use iterators to avoid problems like this completely.

I will use iterators. I asked earlier in this thread (a couple of pages back) on how to use them, so I should be able to make that work, but the warning also appears for the line

code:

while (counter < myVector.size())

where counter is an int, and I am not sure how to take care of this problem. I know that the value of size() will never be more than 100, so should I declare:

code:

unsigned int counter= 0;

# ? Sep 7, 2010 18:29

Adbot: ADBOT LOVES YOU

# ? May 12, 2024 19:26

csammis: Aug 26, 2003; Mental Institution

Jose Cuervo posted:

so should I declare:
code:
unsigned int counter= 0;

Just use the same datatype as that which you're comparing to: std::size_t counter = 0;

# ? Sep 7, 2010 19:18

giogadi: Oct 27, 2009

Alright, I'm about to go batshit-insane here. I'm trying to build a very, very easy example application using FLTK and OpenGL.

I start by making my own subclass of FLTK's "Fl_Gl_Window" class, basically just specifying a draw() method and a constructor (which calls the baseclass's constructor). Below is what's in MyGlWindow.h (minus includes and such):

code:

class MyGlWindow : public Fl_Gl_Window
{
    void draw();

public:
    MyGlWindow(int w, int h, char*l)
        : FL_Gl_Window(w, h, l) {}
};

If it seems simple, it's because it is. draw() is implemented in the .cpp file, and for my constructor I simply call the baseclass's constructor explicitly using argument specifying the window's width, height, and title.

Now, I'm getting two errors when I try to compile this:

C2512 - 'Fl_Gl_Window' - no appropriate default constructor available
C2614 - 'MyGlWindow' - illegal member initialization - 'Fl_Gl_Window' is not a base or member.

So wtf. The default constructor error shouldn't be happening because in my main function, the ONLY time any window is constructed, it's with those parameters (I never try to make a MyGlWindow without specifying constructor parameters). As for the second error, IT SAYS RIGHT THERE IN THE CLASS DEF that Fl_Gl_Window is a base class of MyGlWindow.

I've been looking up and down and backwards and forwards and even delved into FLTK's source to see if there was anything I could do, but alas I've been beaten. Hell, just for sanity's sake, here's the code from my main() function:

code:

int main(int argc, char** argv)
{
    MyGlWindow* window = new MyGlWindow(320, 320, "FLTK OpenGL Test");
    window->end();
    window->show();
    return Fl::run();
}

Simple, really. I've come to the conclusion that I'm literally retarded and simply can't see what I'm doing wrong here. Can anyone see what I may be doing wrong? If it helps anything, I'm using VC++2008.

Thanks for your time, everyone.

# ? Sep 9, 2010 04:25

OddObserver: Apr 3, 2009

code:

Fl_Gl_Window
FL_Gl_Window

l != L

# ? Sep 9, 2010 04:27

giogadi: Oct 27, 2009

OddObserver posted:

wisdom

# ? Sep 9, 2010 04:41

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

Hah I use FLTK a lot and I think I've been through that a few times. I feel better that their naming convention nailed more than just me.

# ? Sep 9, 2010 23:41

Mr VacBob: Aug 27, 2003; Was yea ra chs hymmnos mea

slovach posted:

What is with MSVC and SSE intrinsics? MS recommends their usage over inline asm, but the stuff it seems to generate is beyond earthly logic at times.

Ok, _mm_set stuff... why would it honestly make 4 movss instructions over one movaps and a constant? Occasionally it seems to come up with some shuffling black magic out of nowhere... and isn't instruction pairing a good idea with MMX / SSE? Even if the intrinsics are paired, it seems to do it's own thing and break that.

Maybe it knows best, but it seems to generate some strange code sometimes...

The people who recommend MMX/SSE intrinsics over asm usually don't read their output asm.

Of course, inline asm is kind of hard if you want MSVC/GCC compatibility, or even x86-32/x86-64 compatibility across the same compiler.

"Instruction pairing" hasn't applied to anything since the first Pentium. Out-of-order x86 cores don't care what order your instructions are in (well...), so just to minimize instructions and register spills and don't worry about that.

Mr VacBob fucked around with this message at 00:28 on Sep 10, 2010

# ? Sep 10, 2010 00:03

evensevenone: May 12, 2001; Glass is a solid.

if I have a function that expects to get an array, how bad is it to pass it a pointer to an element in a much bigger array? obviously I have to be careful to avoid overflows but is there anything else that could go wrong?

code:


someFunction(&someBigArray[10]);

I'm stuck with C arrays for what I am doing.

# ? Sep 13, 2010 04:50

Mr VacBob: Aug 27, 2003; Was yea ra chs hymmnos mea

Nothing, they're identical. This is what C is for.

Obviously you shouldn't try to free() it or anything.

# ? Sep 13, 2010 05:07

Jabor: Jul 16, 2010; #1 Loser at SpaceChem

If the function expects that it needs to free the array you passed it in some cases, then very bad things can happen.

Otherwise, if it expects a pointer to a section of memory with some values, and you give it a pointer to a section of memory with some values, it shouldn't care that there are other values immediately preceding the one you pointed it to.

# ? Sep 13, 2010 05:07

evensevenone: May 12, 2001; Glass is a solid.

Thanks, that makes sense. I knew there was something.

# ? Sep 13, 2010 05:29

emf: Aug 1, 2002

There are some library function that expect the pointer passed to them has been malloced. I think most of them are string.h functions, and you can always check the function definition to be sure.

# ? Sep 13, 2010 13:44

Mustach: Mar 2, 2003; In this long line, there's been some real strange genes. You've got 'em all, with some extras thrown in.

emf posted:

There are some library function that expect the pointer passed to them has been malloced.

There are only two, and they're in stdlib.h: realloc() and free(). (They accept null pointers, as well.)

# ? Sep 13, 2010 14:43

emf: Aug 1, 2002

Mustach posted:

There are only two, and they're in stdlib.h: realloc() and free(). (They accept null pointers, as well.)

I could swear I've run into a string copy or string read or some such function that would dynamically grow a char array to fit the string, but you had to call it with a pointer compatible with realloc.

# ? Sep 13, 2010 15:34

Mustach: Mar 2, 2003; In this long line, there's been some real strange genes. You've got 'em all, with some extras thrown in.

Those aren't part of the C standard library. If they're in string.h, the implementation is a jerk!

# ? Sep 13, 2010 15:36

emf: Aug 1, 2002

Probably some Gnu crap. Again, I don't remember where I saw it.

# ? Sep 13, 2010 15:39

Dooey: Jun 30, 2009

Is there any way to optimise std::stack? I've determined that stack.top() and stack.pop() are the bottlenecks in my program.

I thought about reimplementing the parts I am going to use myself, since I've already done that in class, but it would be a lot of effort to find out that its less efficient anyway. (The spec for the one we made in class was stupid and I would never actually use it in a project. Required the caller to free the memory and stuff. I wouldn't really be able to reuse any of it.)

# ? Sep 14, 2010 03:17

That Turkey Story: Mar 30, 2003

Dooey posted:

Is there any way to optimise std::stack? I've determined that stack.top() and stack.pop() are the bottlenecks in my program.

I thought about reimplementing the parts I am going to use myself, since I've already done that in class, but it would be a lot of effort to find out that its less efficient anyway. (The spec for the one we made in class was stupid and I would never actually use it in a project. Required the caller to free the memory and stuff. I wouldn't really be able to reuse any of it.)

What exactly makes you think "top" is one of your bottlenecks? I find that extremely hard to believe since all it does is return a reference to the last element. It should be as efficient as your underlying container.

In fact pretty much all operations on a std::stack are just forwarding operations to the underlying container, so if you have any type of issue, your best bet is to just swap out what container type you are passing into it. By default it uses a deque, but you can always try a vector, or some type of container that uses local storage.

# ? Sep 14, 2010 03:27

Vanadium: Jan 8, 2005

If this is a thing for class, any chance the entire code is small enough to post somewhere? I was wondering how you could bottleneck on top too, maybe you are really doing more copying of big objects than you think and accounting the cost wrongly or something.

# ? Sep 14, 2010 03:35

Dooey: Jun 30, 2009

That Turkey Story posted:

What exactly makes you think "top" is one of your bottlenecks? I find that extremely hard to believe since all it does is return a reference to the last element. It should be as efficient as your underlying container.

In fact pretty much all operations on a std::stack are just forwarding operations to the underlying container, so if you have any type of issue, your best bet is to just swap out what container type you are passing into it. By default it uses a deque, but you can always try a vector, or some type of container that uses local storage.

I profiled it :P stack.top() is used extensively in one of my functions, and within that function it takes up 47.1% of the time in that function. No other line in the function takes more than 8.5%. I can change the algorithm slightly, but at a cost of reduced accuracy. I will try a vector though, and see how it compares.

# ? Sep 14, 2010 03:51

That Turkey Story: Mar 30, 2003

Dooey posted:

I profiled it :P stack.top() is used extensively in one of my functions, and within that function it takes up 47.1% of the time in that function. No other line in the function takes more than 8.5%. I can change the algorithm slightly, but at a cost of reduced accuracy. I will try a vector though, and see how it compares.

How are you profiling, and also, post your code. Again, I doubt stack.top is an issue.

# ? Sep 14, 2010 03:56

roomforthetuna: Mar 22, 2005; I don't need to know anything about virii! My CUSTOM PROGRAM keeps me protected! It's not like they'll try to come in through the Internet or something!

Dooey posted:

I profiled it :P stack.top() is used extensively in one of my functions, and within that function it takes up 47.1% of the time in that function. No other line in the function takes more than 8.5%. I can change the algorithm slightly, but at a cost of reduced accuracy. I will try a vector though, and see how it compares.

Perhaps that function is actually taking very little of your program's time? 47.1% of next to nothing is still next to nothing. Or perhaps it is just a really not-doing-very-much function that's called many many times? With a short enough function called enough times you can make even
__asm mov ax,bx
look like a bottleneck, after all.

# ? Sep 14, 2010 04:07

Dooey: Jun 30, 2009

I'm profiling using visual studio 2010s performance wizard.

The code: http://codepad.org/1uORJxCO

I think everything is pretty clear, except maybe how I have an operator> for Rgbs. It returns true if every component of the first Rgb is greater than that component in the second.

(Yes I've posted this code in the thread before. Not much has changed since then, except that I've done proper profiling now.)

Also, the function is called once per frame.

# ? Sep 14, 2010 04:16

raminasi: Jan 25, 2005; a last drink with no ice

Dooey posted:

I profiled it :P stack.top() is used extensively in one of my functions, and within that function it takes up 47.1% of the time in that function. No other line in the function takes more than 8.5%. I can change the algorithm slightly, but at a cost of reduced accuracy. I will try a vector though, and see how it compares.

If your profiler is just giving you information about lines, what makes you think that top() is the bottleneck and not the Point construction you do on the same line?

# ? Sep 14, 2010 05:47

Dooey: Jun 30, 2009

Good point, that might be the problem.

Does that mean I should create a copy constructor and do this:

Point<int> curPoint(pointStack.top());

or just replace each usage of curPoint with pointStack.top()?

or something else? I'm not completely familiar with with constructors work, although I do have a general idea.

edit: or use pointers to Point<int>s? That wouldn't require any allocation since the points are already in the pointStack, and no construction either? Right?

edit2: actually stepping through the code in the debugger shows that it takes way more time to go through stack.top than the constructor. The debugger never even actually entered the constructor, so maybe it got optimized away. Or I am misunderstanding something, which seems to happen to me a lot with C++.

Dooey fucked around with this message at 06:09 on Sep 14, 2010

# ? Sep 14, 2010 06:00

That Turkey Story: Mar 30, 2003

Dooey posted:

Good point, that might be the problem.

Does that mean I should create a copy constructor and do this:

Point<int> curPoint(pointStack.top());

The copy constructor is already being called, you don't need to use special syntax to call it. If you don't define a copy constructor a default one is generated.

Dooey posted:

or just replace each usage of curPoint with pointStack.top()?

You can't do that without rewriting the rest of your code because after you push or pop the top element will change.

Dooey posted:

edit: or use pointers to Point<int>s? That wouldn't require any allocation since the points are already in the pointStack, and no construction either? Right?

Same as above. Once you pop, it is no longer valid to reference that object.

Dooey posted:

edit2: actually stepping through the code in the debugger shows that it takes way more time to go through stack.top than the constructor.

Don't assume that stepping through code in debug mode tells you how your function will perform in an optimized build.

Dooey posted:

The debugger never even actually entered the constructor, so maybe it got optimized away. Or I am misunderstanding something, which seems to happen to me a lot with C++.

Yes, you are misunderstanding something -- the copy constructor is called. You didn't explicitly define one so one that does member-wise copy-constructions was used automatically, and since it was generated automatically there is no written C++ code to step through. If the automatically generated copy constructor isn't what your point's copy construction needs to do then you have a bug.

Looking at your code there are plenty of things that could potentially be inefficient if not optimized away, and the call to "top" is not one of those things.

# ? Sep 14, 2010 06:38

Dooey: Jun 30, 2009

That Turkey Story posted:

You can't do that without rewriting the rest of your code because after you push or pop the top element will change.

Same as above. Once you pop, it is no longer valid to reference that object.

It should be fine if I pop at the end of the while loop though?

quote:

Looking at your code there are plenty of things that could potentially be inefficient if not optimized away, and the call to "top" is not one of those things.

Well, I just finished a very basic stack class of my own, so we will see once I get VS to stop telling me that it can't find C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe even though it is most definitely there.

# ? Sep 14, 2010 07:02

That Turkey Story: Mar 30, 2003

Dooey posted:

It should be fine if I pop at the end of the while loop though?

No. Think about it, if you're pushing things inside loop then when you call pop at the end of an iteration you'll just be popping one of those. It's a stack.

# ? Sep 14, 2010 07:05

Dooey: Jun 30, 2009

Silly me. Thats what I get for trying to think when its past midnight.

# ? Sep 14, 2010 07:11

MutantBlue: Jun 8, 2001

Dooey posted:

The code: http://codepad.org/1uORJxCO

I see you specified a vector as the stack's underlying container. Why did you choose that instead of the default deque?

# ? Sep 14, 2010 07:24

Jan: Feb 27, 2008; The disruptive powers of excessive national fecundity may have played a greater part in bursting the bonds of convention than either the power of ideas or the errors of autocracy.

^^^^^^^^^^^^^^^
Because of this:

That Turkey Story posted:

In fact pretty much all operations on a std::stack are just forwarding operations to the underlying container, so if you have any type of issue, your best bet is to just swap out what container type you are passing into it. By default it uses a deque, but you can always try a vector, or some type of container that uses local storage.

vvvvvvvvvvvvvvvv
Without anything to base yourself upon other than what he said without the code, it's as valid a crapshoot as any other.

Jan fucked around with this message at 17:11 on Sep 14, 2010

# ? Sep 14, 2010 14:21

pseudorandom name: May 6, 2007

Well, that's terrible advice.

# ? Sep 14, 2010 16:59

That Turkey Story: Mar 30, 2003

pseudorandom name posted:

Well, that's terrible advice.

No, it's really not, but thanks. That's the whole reason why the option to change internal containers is there. A vector type with the max stack size reserved or a local dynamic array type with max size being the max size of the stack will both likely outperform a deque implementation. As for why "top" specifically is slow, the answer is that it's not as we have said repeatedly, but we are trying to not be douches about it.

# ? Sep 14, 2010 18:07

OddObserver: Apr 3, 2009

I hope the profile was at least done with a fully optimized build?

# ? Sep 14, 2010 19:49

pseudorandom name: May 6, 2007

Won't a stack wrapping a vector push/pop from the front of the vector? And require the equivalent of big memmove() for every operation?

edit: Nope, it uses push_back(). You learn something new every day.

pseudorandom name fucked around with this message at 19:57 on Sep 14, 2010

# ? Sep 14, 2010 19:53

kes: Jan 4, 2006

GrumpyDoctor posted:

If your profiler is just giving you information about lines, what makes you think that top() is the bottleneck and not the Point construction you do on the same line?

likewise, pop() would not be the bottleneck but rather the implicit call to the destructor

post your code for Point

# ? Sep 15, 2010 05:28

Dooey: Jun 30, 2009

The constructors and destructors for Point:

code:

template<typename T> Point<T>::Point() {
}

template<typename T> Point<T>::Point(T newX, T newY) {
    x = newX;
    y = newY;
}

template<typename T> Point<T>::~Point() {
}

and the whole thing: http://codepad.org/a9Gvyb8s

Also I'm trying not to fall into any bad practices with this project, so if you see anything stupid or smelly that I'm doing, please tell me

# ? Sep 16, 2010 01:01

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

It shouldn't be causing your performance problems, but you don't need to declare the destructor like that; in fact, doing so makes it non-trivial (when it otherwise is probably trivial) and means that points have to be passed to and from functions less efficiently.

# ? Sep 16, 2010 01:31

Dooey: Jun 30, 2009

Removing the dustructor doesn't change my performance problems

Does having an empty destructor like that actually change anything relative to leaving out the destructor?

# ? Sep 16, 2010 02:18

Adbot: ADBOT LOVES YOU

# ? May 12, 2024 19:26

Jan: Feb 27, 2008; The disruptive powers of excessive national fecundity may have played a greater part in bursting the bonds of convention than either the power of ideas or the errors of autocracy.

Dooey posted:

Removing the dustructor doesn't change my performance problems

Does having an empty destructor like that actually change anything relative to leaving out the destructor?

The compiler most likely optimises the empty constructor call anyway. You're mostly losing terseness and clarity for... no advantage at all.

Now if the destructor was virtual, you'd have a bit more reason to leave an empty base one, but this is not the case.

# ? Sep 16, 2010 02:22

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > C/C++ Programming Questions Not Worth Their Own Thread

«‹›640 »