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 »

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

Avenging Dentist posted:

One alternative is to use the Visitor pattern, lame though it is. The real solution is probably to just design things so as to avoid that entirely.

The code is already using the visitor pattern. Even if you ignore the explicit isColliding implementations, you can tell because in fact all of these methods are named differently and therefore cannot possibly be overrides.

Contero, if you've got a small number of implementations and you're really worried about performance and you can't avoid collision detection of arbitrary shapes, you could always index an array of bool (*)(Geometry&,Geometry&) using small-integer type codes held on the Geometry class; that would bring a double-dispatch problem down to the necessary single dispatch.

# ? May 1, 2009 05:19

Adbot: ADBOT LOVES YOU

# ? Jun 1, 2024 12:05

Avenging Dentist: Oct 1, 2005; oh my god is that a circular saw that does not go in my mouth aaaaagh

rjmccall posted:

The code is already using the visitor pattern.

Oops. It's been a long day.

A more concerning thing is this:

Contero posted:

I'm not that worried about it since my game won't have a lot of collisions per frame, but I have a suspicion that there's a better way to handle it.

It's not the number of collisions, it's the number of potential collisions you should be concerned about, i.e. worst-case O(n²) per frame. Aside from the fact that you probably just need a bounding box type and a polygon type and that they only need to collide with objects of the same type, you should be concentrating your optimization efforts on broad-phase collision culling. You'll get a much greater performance boost by eliminating pairs of objects that can't possibly collide than you ever will by optimizing the actual collision tests.

# ? May 1, 2009 05:52

Contero: Mar 28, 2004

Avenging Dentist posted:

Now for the real problem: that won't work because the arguments (const Foo &other) are checked at compile-time, not runtime. Virtual functions only allow single dispatch, and C++ does not natively support multiple dispatch (see Wikipedia).

http://pastebin.com/m2367f1f1 :confused:

Avenging Dentist posted:

do you actually need to test arbitrary pairs of geometry at runtime? Probably not. (e.g. you should only ever need to compare an AABB with another AABB.)

No, probably not, but I'm not sure how I'd do AABB-AABB collision between say, a character and a non-axis aligned wall/floor.

# ? May 1, 2009 06:11

Avenging Dentist: Oct 1, 2005; oh my god is that a circular saw that does not go in my mouth aaaaagh

Contero posted:

No, probably not, but I'm not sure how I'd do AABB-AABB collision between say, a character and a non-axis aligned wall/floor.

You adjust the dimensions of the AABB when an object is rotated. It's an intermediary step between broad-phase and narrow-phase collision detection and isn't meant to be 100% accurate. It's just another culling method. Then you perform polygon-polygon intersection tests for the final, authoritative check on only the pairs that haven't already been culled.

# ? May 1, 2009 06:17

Fecotourist: Nov 1, 2008

Avenging Dentist posted:

One alternative is to use the Visitor pattern, lame though it is. The real solution is probably to just design things so as to avoid that entirely.

Do you have an opinion of boost.variant's implementation of visitation?

Fecotourist fucked around with this message at 06:54 on May 1, 2009

# ? May 1, 2009 06:33

Avenging Dentist: Oct 1, 2005; oh my god is that a circular saw that does not go in my mouth aaaaagh

Yeah let's all quote the one time I wasn't paying attention and said something wrong. :mad:

I kinda hate Boost.Variant, honestly. It's about as good as you can get, implementation-wise in C++03 though. At least C++0x resolves the issues with non-trivially constructible members of unions, making variants way less horrific.

# ? May 1, 2009 06:42

Contero: Mar 28, 2004

Avenging Dentist posted:

You adjust the dimensions of the AABB when an object is rotated. It's an intermediary step between broad-phase and narrow-phase collision detection and isn't meant to be 100% accurate. It's just another culling method. Then you perform polygon-polygon intersection tests for the final, authoritative check on only the pairs that haven't already been culled.

I'm already getting back a fairly small number of objects to test from my bsp tree. My level isn't exactly dense with static objects.

I will do explicit AABB-AABB testing between moving objects though because I can't use the bsp tree. Actually, it seems I can have my cake and eat it too. I can just use the inline testAABB_AABB call when I know I'm using them, and use the visitor method when I want arbitrary collisions. Thanks for nothin CoC :smug:

And for the second problem I think I am going to use a global, but it's going to be a wrapper class around the Game class that provides a cleaner interface to the random objects inside it. I'm fairly comfortable that I'm not going to need to run two of the same Game class at the same time. It also stops me from needing to change a bunch of my code every time I decide to rearrange my Game data structures.

# ? May 1, 2009 08:01

shinmai: Oct 9, 2007; CHK Instruction

slovach posted:

How about this?

*snip*

Was this what you were trying to do?

Compiled / linked to 1kb after merging sections.

Perhaps I should've further stressed, that the code I'm working on, used to function fine, before I ran the Dev-C++-update. The only changes done to the code have been the removal of window creation and OpenGL initalization. I could post the whole original source, but doubt it'd shed any more light on my actual problem.

The whole reason I even run Windows is win32 ogl development, so I might just go ahead and scrap my windows installation and try to get my original development enviroment back.

e: Declaring int WinMainCRTStartup(); before other functions fixes the problem, but I'm still distressed, as I haven't got a clue what caused this whole mess.

shinmai fucked around with this message at 08:28 on May 1, 2009

# ? May 1, 2009 08:01

newsomnuke: Feb 25, 2007

It's been a while since I've worked with gcc, and I'm getting an error porting some (working) code from MSVC:

code:

class exDataUnion
{
	friend std::ostream &operator << (std::ostream &a_stream, const exDataUnion &a_data);
	union
	{
		int m_int;
		float m_float;
		void *m_ref;
	} m_data;

	...
};

std::ostream &operator << (std::ostream &a_stream, const exDataUnion &a_data)
{
	switch (a_data.m_type)
	{
	case EX_Null:
		a_stream << "Null";
	case EX_Int:
		a_stream << a_data.m_data.m_int;
		break;
	case EX_Float:
		a_stream << a_data.m_data.m_float;
		break;
	case EX_String:
		a_stream << (const char *) a_data.m_data.m_ref;
		break;
	default:
		a_stream << "Unknown type";
		break;
	}

	return a_stream;
}

Gives a bunch of no match for 'operator<<' in 'a_stream << "Null"' errors, one for each of the switch cases. Seems like it's saying a_stream's << operator doesn't know how to handle the operands?

# ? May 1, 2009 18:34

Avenging Dentist: Oct 1, 2005; oh my god is that a circular saw that does not go in my mouth aaaaagh

It compiles just fine (codepad uses GCC):
http://codepad.org/SyBogf9r

Though you probably want a break after printing "Null".

# ? May 1, 2009 18: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.

Your code explicitly include <iostream>; maybe ultra-inquisitor's doesn't.

# ? May 1, 2009 19:05

newsomnuke: Feb 25, 2007

Mustach posted:

Your code explicitly include <iostream>; maybe ultra-inquisitor's doesn't.

This was it, thanks. Pretty much all of the porting was adding in extra #includes. Dunno why ostream needs <iostream> in Linux, but meh.

# ? May 1, 2009 19:15

Fecotourist: Nov 1, 2008

Contero posted:

And for the second problem I think I am going to use a global, but it's going to be a wrapper class around the Game class that provides a cleaner interface to the random objects inside it. I'm fairly comfortable that I'm not going to need to run two of the same Game class at the same time. It also stops me from needing to change a bunch of my code every time I decide to rearrange my Game data structures.

This isn't a terribly general solution, but if these objects that need the "global" data are always accessed through a tree traversal, a tree iterator that contains the data and code needed for the traversal itself can also carry along other stuff that might be useful deep in the tree. The brittleness comes from the first use-case where you really need just a naked pointer to a Monster (and thus no traversal context), possibly worked around by storing a struct {Monster*, GlobalData*}. At least nothing's truly global then.
I'm doing something like this in a purely hobby project (so time wasted is weighted very low). There are some fun puzzles to solve, like finding a given same-depth neighbor (e.g. how many levels do you have to pop to find the common ancestor). Straightforward in a binary tree, interesting in 3-ary and higher.

# ? May 1, 2009 19:49

slovach: Oct 6, 2005; Lennie Fuckin' Briscoe

shinmai posted:

Perhaps I should've further stressed, that the code I'm working on, used to function fine, before I ran the Dev-C++-update. The only changes done to the code have been the removal of window creation and OpenGL initalization. I could post the whole original source, but doubt it'd shed any more light on my actual problem.

The whole reason I even run Windows is win32 ogl development, so I might just go ahead and scrap my windows installation and try to get my original development enviroment back.

e: Declaring int WinMainCRTStartup(); before other functions fixes the problem, but I'm still distressed, as I haven't got a clue what caused this whole mess.

Why are you trying to use WinMainCRTStartup anyway? You should just be using WinMain() unless you're really trying to avoid the CRT or something. You could also use the ENTRY: setting in the linker, but this is probably the easiest way.

You can just define your entry like:

code:

void __cdecl WinMainCRTStartup(){
	ExitProcess(WinMain(GetModuleHandle(NULL), NULL, NULL, SW_NORMAL));
}

Also DevC++ is ancient as poo poo.

# ? May 1, 2009 22:40

Avenging Dentist: Oct 1, 2005; oh my god is that a circular saw that does not go in my mouth aaaaagh

slovach posted:

Also DevC++ is ~~ancient as~~ poo poo.

Fixed. I'll never understand why people use Dev-C++ when Visual Studio is free. People who use Dev-C++ on Linux (does such a person even exist?) boggle my mind even more.

# ? May 1, 2009 23:12

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

Avenging Dentist posted:

People who use Dev-C++ on Linux (does such a person even exist?) boggle my mind even more.

I don't think so, but somehow Anjuta has users

# ? May 1, 2009 23:46

awesmoe: Nov 30, 2005; Pillbug

I've got a design question - I've got a couple of choices, all of which will work, but I'm looking for insight that I've missed into the pros and cons.
I've got abstract classes FrameworkInterface and PluginInterface.
An instance of fwkIf is created shortly after startup, and it's destroyed during program shutdown (it's not static or global). It holds a list of plugins, each of which needs to call methods on its owning fwkIf.
The plugins are dynamically loaded, based on config.

The plugins are required to be created after and destroyed before the framework - the plugin's frameworkIf will always exist.

My options as I see them are:

Create the plugins on the heap and pass them a reference to *this, which they store as a reference.
As above but create them on the stack instead. Use pimpl if the plugins get big.
Create the plugins and have them use a singleton to get a pointer (or shared_ptr) to the owning framework.

What I'm asking is, what's the idiomatic way of doing this (if there is one)?

# ? May 3, 2009 00:54

Staggy: Mar 20, 2008; Said little bitch, you can't fuck with me if you wanted to
These expensive
These is red bottoms
These is bloody shoes

Does anyone have any experience with NCurses? Or, the variant I'm using, PDCurses? I need a good documentation - all I can find so far is either over my head or a giant list of functions with no explanations.

Really I just need a list that explains what each function does.

# ? May 3, 2009 22:36

Marsol0: Jun 6, 2004; No avatar. I just saved you some load time. You're welcome.

Staggy posted:

Does anyone have any experience with NCurses? Or, the variant I'm using, PDCurses? I need a good documentation - all I can find so far is either over my head or a giant list of functions with no explanations.

Really I just need a list that explains what each function does.

This is what I've been using.

Edit: I use PDCurses and that documentation works.

# ? May 3, 2009 22:59

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.

awesmoe posted:

Create the plugins on the heap

This is your only convenient choice since you'll be interacting with them all exclusively through the abstract class's interface and will be creating them dynamically.

quote:

Create the plugins and have them use a singleton to get a pointer (or shared_ptr) to the owning framework.

Opt for passing a FrameworkInterface& to the plugins' constructors instead; exposing a singleton to a plugin (assuming it's defined in a DLL) would be too much trouble for virtually 0 space savings. You'd have to load thousands of plugins before the references noticeably add up, and they'd be dwarfed by the plugin's code (again, assuming they're defined in DLLs).

You wouldn't want to pass them shared_ptrs, since you've designed your program such that the framework owns the plugins and won't be destroyed until after the plugins. Using shared_ptrs wouldn't give you anything.

# ? May 4, 2009 17:22

awesmoe: Nov 30, 2005; Pillbug

Mustach posted:

This is your only convenient choice since you'll be interacting with them all exclusively through the abstract class's interface and will be creating them dynamically.

Opt for passing a FrameworkInterface& to the plugins' constructors instead; exposing a singleton to a plugin (assuming it's defined in a DLL) would be too much trouble for virtually 0 space savings. You'd have to load thousands of plugins before the references noticeably add up, and they'd be dwarfed by the plugin's code (again, assuming they're defined in DLLs).

You wouldn't want to pass them shared_ptrs, since you've designed your program such that the framework owns the plugins and won't be destroyed until after the plugins. Using shared_ptrs wouldn't give you anything.

Thanks, this is exactly what I had done (and for those reasons, even!). I appreciate the comments.

# ? May 4, 2009 21:13

Sabotaged: Jul 6, 2004

I have a DLL that links against some static libs -- the problem is that after upgrading the project to VS2008, and building in release mode, it seems that any static std::wstring (declared in a class, defined outside it.. and the definition definitely is being compiled) used in my DLL results in an unresolved external symbol.

However it does work in debug mode, so it's got to be something stupid I'm missing. Anyone have any ideas? std::string's are OK.

# ? May 5, 2009 04:56

DoctorTristan: Mar 11, 2006; I would look up into your lifeless eyes and wave, like this. Can you and your associates arrange that for me, Mr. Morden?

Dumb question - am I right in thinking that pow(double, int ) is defined in <math>? So I can call pow(x, 3) to cube a double x without having to pay the cost of a pow(double, double) call?

# ? May 5, 2009 17:32

Zakalwe

May 12, 2002

Wanted For:

Terrorism
Kidnapping
Poor Taste
Unlawful Carnal Gopher Knowledge

DoctorTristan posted:

Dumb question - am I right in thinking that pow(double, int ) is defined in <math>? So I can call pow(x, 3) to cube a double x without having to pay the cost of a pow(double, double) call?

Nope. It will be promoted to a double.

x * x * x;

edit: apt-get install manpages-dev if you're on Debian or a derived system (Ubuntu etc). man pow

# ? May 5, 2009 17:44

Avenging Dentist: Oct 1, 2005; oh my god is that a circular saw that does not go in my mouth aaaaagh

Zakalwe posted:

Nope. It will be promoted to a double.

x * x * x;

Correct for C, incorrect for C++. Given that <math> is not a header for either language, I'm not sure which he wants (assuming C++ since people should know that C doesn't support function overloading).

# ? May 5, 2009 17:47

DoctorTristan: Mar 11, 2006; I would look up into your lifeless eyes and wave, like this. Can you and your associates arrange that for me, Mr. Morden?

Sorry, meant <cmath>. Yes, I'm working in C++.

# ? May 5, 2009 17:59

Zakalwe

May 12, 2002

Wanted For:

Terrorism
Kidnapping
Poor Taste
Unlawful Carnal Gopher Knowledge

Avenging Dentist posted:

Correct for C, incorrect for C++. Given that <math> is not a header for either language, I'm not sure which he wants (assuming C++ since people should know that C doesn't support function overloading).

True. Missed the lack of the .h . I have the c prefix beaten into me for c standard library includes in C++ that I assumed C.

# ? May 5, 2009 18:00

Zakalwe

May 12, 2002

Wanted For:

Terrorism
Kidnapping
Poor Taste
Unlawful Carnal Gopher Knowledge

In the case of C++ pow(double, int) No promotion.

# ? May 5, 2009 18:01

DoctorTristan: Mar 11, 2006; I would look up into your lifeless eyes and wave, like this. Can you and your associates arrange that for me, Mr. Morden?

Thanks. Stupid question round 2 is about for() loop scoping. If I write

code:

f(int i=1; i!=10; ++i) {
  int p = 1
  
  //do stuff with p

}

then p is local to the loop, but will each iteration of the loop see a different p?

# ? May 5, 2009 19:45

Vanadium: Jan 8, 2005

yes

# ? May 5, 2009 19:48

POKEMAN SAM: Jul 8, 2004

DoctorTristan posted:

Thanks. Stupid question round 2 is about for() loop scoping. If I write
code:
f(int i=1; i!=10; ++i) {
  int p = 1
  
  //do stuff with p

}
then p is local to the loop, but will each iteration of the loop see a different p?

Does this answer your question?

http://codepad.org/dpjuX7f2

E:F;B.

# ? May 5, 2009 19:50

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.

See this.

e: jesus mutherfucking christ people
editit: Mine's the best though

Mustach fucked around with this message at 20:03 on May 5, 2009

# ? May 5, 2009 19:50

DoctorTristan: Mar 11, 2006; I would look up into your lifeless eyes and wave, like this. Can you and your associates arrange that for me, Mr. Morden?

Point taken. Thanks again.

# ? May 5, 2009 20:15

Avenging Dentist: Oct 1, 2005; oh my god is that a circular saw that does not go in my mouth aaaaagh

Keep in mind that most (all?) C++ compilers will use the same memory location for that variable: http://codepad.org/9iiI707Q

# ? May 5, 2009 20:15

POKEMAN SAM: Jul 8, 2004

Avenging Dentist posted:

Keep in mind that most (all?) C++ compilers will use the same memory location for that variable: http://codepad.org/9iiI707Q

Wouldn't it be stupid if it did it any other way, though?

# ? May 5, 2009 20:28

Avenging Dentist: Oct 1, 2005; oh my god is that a circular saw that does not go in my mouth aaaaagh

Ugg boots posted:

Wouldn't it be stupid if it did it any other way, though?

Yes. But it's less obvious that these take up the same location in memory, for the same reason: http://codepad.org/nC33c7UK

# ? May 5, 2009 20:52

Cosmopolitan: Apr 20, 2007; Rard sele this wai -->

What is a good Windows alternative to Valgrind? The only things I've been able to find are Insure++ and Purify, both of which aren't free.

# ? May 6, 2009 02:22

ctz: Feb 6, 2003

Anunnaki posted:

What is a good Windows alternative to Valgrind? The only things I've been able to find are Insure++ and Purify, both of which aren't free.

I have never come across any. Purify is not only not free; it's expensive, and has massive overhead (a test which takes 30 minutes under valgrind takes 5.5 hours under purify with comparable hardware).

Generally speaking there are far fewer quality free development tools for Windows. It's the nature of the platform.

I suggest making your program portable or perhaps using valgrind under wine.

ctz fucked around with this message at 09:31 on May 6, 2009

# ? May 6, 2009 09:28

digibawb: Dec 15, 2004; got moo?

I have used Memory Validator ( http://softwareverify.com/cpp/memory/index.html ) many times with great success. It isn't free, but there's a 30 day trial iirc. The interface is rather clunky, but if you can get past that, it has a lot of good features.

# ? May 6, 2009 19:45

Adbot: ADBOT LOVES YOU

# ? Jun 1, 2024 12:05

brian: Sep 11, 2001; I obtained this title through beard tax.

I'm having trouble using a really old fixed point library in VC++ 2008, any time I use the following two ASM based functions I get linking errors and I have no idea to fix it, is it a compiler flag I have to enable? I really need the fixed multiplication and division to be as fast as possible, it's for music generation on the GP2X which doesn't have an FPU.

code:

fp14
fpDiv(fp14 d1, fp14 d2);
#pragma aux fpDiv = \
    "xor    edx, edx" \
    "shld   edx, eax, 14" \
    "sal    eax,14" \
    "idiv   ebx" \
    parm [eax] [ebx]\
    modify [edx] \
    value [eax];

fp14
fpMul(fp14 m1, fp14 m2);
#pragma aux fpMul = \
    "imul   ebx" \
    "shrd   eax, edx, 14" \
    parm [eax] [ebx]\
    modify [edx]\
    value [eax];

It's throwing unresolved externals even though I think i'm including everything correctly.

edit:
Here's the linking errors:

code:

Error	84	error LNK2019: unresolved external symbol "long __cdecl fpMul(long,long)" (?fpMul@@YAJJJ@Z) referenced in function "public: short * __thiscall SongSection::GetBuffer(unsigned int const &,int const &)" (?GetBuffer@SongSection@@QAEPAFABIABH@Z)	Song.obj	Terrain
Error	85	error LNK2019: unresolved external symbol "long __cdecl fpDiv(long,long)" (?fpDiv@@YAJJJ@Z) referenced in function "public: short * __thiscall SongSection::GetBuffer(unsigned int const &,int const &)" (?GetBuffer@SongSection@@QAEPAFABIABH@Z)	Song.obj	Terrain
Error	86	error LNK2001: unresolved external symbol "long __cdecl fpDiv(long,long)" (?fpDiv@@YAJJJ@Z)	FIXED.obj	Terrain

brian fucked around with this message at 16:06 on May 8, 2009

# ? May 8, 2009 16:02

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

«‹›640 »