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

«‹›641 »

Harokey: Jun 12, 2003; Memory is RAM! Oh dear!

Okay thanks for your inputs. It looks like what I need to do is have the thread that is handling the window events also create the windows. It must be a problem that One thread creates the window, and another is trying to handle the events.

Edit: I got it working. I made it so my windowing thread can accept "messages" from other threads about what windowing commands to run. Its more of a pain, but at least it works. Thanks again!

Harokey fucked around with this message at 18:27 on Jan 17, 2011

# ? Jan 16, 2011 20:08

Adbot: ADBOT LOVES YOU

# ? Jun 8, 2024 00:53

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

I think I got all confused in the discussion of threads and windows here. I think the general rule is to assume the GUI toolkit is a single thread--including the code that gets called out of it (your callbacks). You don't have to set up some kind of hierarchy to maintain some kind of drawing context from a master window. Rather, everything you create has to just get in the line on the GUI thread to be handled.

I spent a lot of the weekend figuring out some more obscure GUI stuff. I guess you really do have to grind through this a little bit to develop an appreciation for some of the oddball crap. I was finding that a group class containing a GL canvas I was creating in FLTK after I had started the FLTK routines would not display correctly, even if I had told them to be shown. Any that were instantiated before I started the FLTK routine (Fl::run()) drew fine. I guess after Fl::run() starts, you have to tell all the children components of your custom class to be shown too, not just yourself. So it was showing my group was technically being shown, but none of its children were being shown by default. :wtf:

At least the FLTK people are generally responsive and don't sneer at you to google until your fingers fall off, so I will try to send them a simple case of this.

I was also hoping to do drag and drop with it. I actually got that working after much gnashing of teeth. However I see it's doing a system-wide drag and drop so my message can get dumped on the desktop even if I don't want it. The alternative is to write your own kind of drag and drop feature, but I found out only the highlighted window handles events. So I can't readily have the target area start accepting mouse events that would suggest something it being sent to it.

GUI's really are a pain in the butt.

# ? Jan 17, 2011 18:47

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

code:

class Foo {
    Contained contained;
public:
    Contained & get_contained();
};

void somewhere_else(Foo & foo) {
    function_that_needs_a_pointer_to_a_contained(&(foo.get_contained()));
}

Will this fly? It seems like it should but I don't like making assumptions about this sort of thing.

# ? Jan 19, 2011 03:01

Flobbster: Feb 17, 2005; "Cadet Kirk, after the way you cheated on the Kobayashi Maru test I oughta punch you in tha face!"

GrumpyDoctor posted:

code:
class Foo {
    Contained contained;
public:
    Contained & get_contained();
};

void somewhere_else(Foo & foo) {
    function_that_needs_a_pointer_to_a_contained(&(foo.get_contained()));
}
Will this fly? It seems like it should but I don't like making assumptions about this sort of thing.

Assuming get_contained returns the field contained, that should be fine. It'll return a pointer to the field inside foo, which will exist as long as foo exists. Just make sure that function_that_needs_a_pointer_to_a_contained doesn't store the pointer for longer than the lifetime of the foo you're passing in and try to use it later.

# ? Jan 19, 2011 03:10

floWenoL: Oct 23, 2002

pr0metheus posted:

I was having issues with boost's dynamic_bitset. In my program I have a tree data structure where each node is an instance of a class which has one dynamic bitset as a member variable. I allocate my tree on heap, and clean it up when my program is done. The issue I am running into is apparent memory leaking from dynamic_bitset's = operator. Valgrind is reporting that new operator that is called as result of calling = operator on dynamic_bitset at some point in course of my program never has an associated delete. I am quite positive that I am cleaning up my entire tree properly, and valgrind doesn't bitch about any node allocation which makes me think I did my job right.

Does anybody else run into this issue? Is it possible I am doing something wrong and forget to delete some nodes? If I did forget to delete nodes then why doesn't valgrind show callstack for allocating that node ( I use --leak-check=full )?

Here are callstacks from valgrind:

Smells like a leak in your DFA's copy constructor.

As a rule of thumb, if Valgrind reports a leak from a standard library class, the real leak is at the boundary between your code and the standard library.

# ? Jan 19, 2011 13:10

Theseus: Jan 15, 2008; All I know is if there is a God, he's laughin' his ass off.

I hope this is a good place to ask this question. There isn't an assembly or SIMD thread I can find.

I've been writing a raytracer in C++, and recently discovered SIMD and SSE. I've successfully gotten great dividends from vectorizing rays, though I left (currently only) sphere intersection code in normal C++. I recently decided that using a structure of arrays and processing ray packets would be faster than vectorizing single calculations on every ray. I've written a RayPacket class that passes all the unit tests I throw at it, but there's an issue with vectorizing the intersect code in my Sphere class. ~~Specifically, it appears that SQRTPS doesn't yield NaN's of any variety if it's handed negative numbers.~~ What I was hoping to do was to get a QNaN out of the whole deal if no root was found and the smallest root otherwise. How can I go about getting this behavior? My first thought was to copy the register holding the discriminants to another register before the square root, then ANDPS a QNaN bit pattern with the result of a CMPLTPS (with zero of course) and ADDPS that with the result of the square root. I'm assuming that adding a QNaN to any number will give me another QNaN. Is that a correct assumption, and is there a better way of doing this?

Edit: It appears that SQRTPS does actually behave as I expected, and generates QNaNs appropriately. I had an ADDPS instruction when determining the discriminant instead of a MULPS instruction. There's still a very strange issue happening with the target test sphere being the color of the background and the background being the color of the sphere, but at least now there's a coherent image.

Theseus fucked around with this message at 22:46 on Jan 20, 2011

# ? Jan 20, 2011 00:34

Risible: Jun 1, 2009

This has got me puzzled in C.

I'm opening, and reading, through a file on a machine with fread(). This read works perfectly fine, but I wanted it to be able to handle an error should one arise.

I have something like this:

code:

buffer = malloc(512);

bytesRead = fread(buffer, 1, 512, file);
if(ferror(file))
{
   printf("\nEncountered an error, let's get out of here.");
   free(buffer);
   fclose(file);
   return ErrorOpeningFile;
}

In that 'ferror' condition, the program will crash on free(buffer) when ferror throws the number 32 (I think the error is unimportant, but just in case it represents a sharing violation--another program was opening and writing to a file while this one was reading it). It looks as if after fread() returns with the error, it also frees what memory was allocated to buffer. Since it frees the memory, my call to free(buffer) causes the program to crash. Is this right? Is fread() suppposed to free memory when it encounters an error like this? I haven't encountered another condition yet where this comes up, and I haven't seen any documentation yet on this behavior.

# ? Jan 21, 2011 16:30

Standish: May 21, 2001

Risible posted:

It looks as if after fread() returns with the error, it also frees what memory was allocated to buffer. Since it frees the memory, my call to free(buffer) causes the program to crash. Is this right? Is fread() suppposed to free memory when it encounters an error like this?

fread() doesn't free the buffer (if it did, what would happen if you passed it a buffer which is on the stack?) . You probably have heap corruption going on,

# ? Jan 21, 2011 20:22

Nalin: Sep 29, 2007; Hair Elf

I'm having some issues compiling a unicode string class I wrote in GCC 4.5. It used to work fine, but I recently re-programmed the iterator to work in STL algorithms and everything broke horribly. It works just fine in Visual Studio 2010, but it generates a lot of errors in GCC 4.5.

Here is a zip file containing the class (irrUString.h), an extremely simple test program, and a couple headers required for irrUString.h to compile (it was developed to be integrated with the Irrlicht engine, so a couple Irrlicht-specific headers are required.)
http://irrlicht.suckerfreegames.com/test/ustring.zip

Just compile it like this:
g++ main.cpp -std=c++0x

Can anyone tell me why it is failing to see the typedefs defined in std::iterator? Do I really have to throw in a typename everywhere I use a typedef'ed name in order to get this thing to work? If anyone could tell me what I am doing wrong, I would much appreciate it.

# ? Jan 24, 2011 08:26

OddObserver: Apr 3, 2009

http://www.parashift.com/c++-faq-lite/templates.html#faq-35.18

# ? Jan 24, 2011 13:42

Nalin: Sep 29, 2007; Hair Elf

OddObserver posted:

http://www.parashift.com/c++-faq-lite/templates.html#faq-35.18

Thanks, that was exactly what I needed. I got everything working after reading that.

# ? Jan 24, 2011 15:02

CapnBry: Jul 15, 2002; I got this goin'; Grimey Drawer

Here is something to test your pedantic C knowledge:

code:

char buffer[10];
size_t x = sizeof(buffer-1);

What does this code do? The intent was to get sizeof(buffer)-1 but I have known C for 20 years and have no idea what you're actually getting the sizeof.

# ? Jan 25, 2011 19:43

Scaevolus: Apr 16, 2007

CapnBry posted:

Here is something to test your pedantic C knowledge:
code:
char buffer[10];
size_t x = sizeof(buffer-1);
What does this code do? The intent was to get sizeof(buffer)-1 but I have known C for 20 years and have no idea what you're actually getting the sizeof.

It's doing pointer arithmetic. The type of (buffer - 1) is char*, so it's equivalent to sizeof(char*).

# ? Jan 25, 2011 19:53

CapnBry: Jul 15, 2002; I got this goin'; Grimey Drawer

Scaevolus posted:

It's doing pointer arithmetic. The type of (buffer - 1) is char*, so it's equivalent to sizeof(char*).

I got the pointer math part, but how is the type of buffer[-1]/buffer-1 a char*?

# ? Jan 25, 2011 20:31

pseudorandom name: May 6, 2007

Woo! Wrong on all counts.

I'm going to go caffeinate myself.

pseudorandom name fucked around with this message at 20:49 on Jan 25, 2011

# ? Jan 25, 2011 20:33

Sneftel: Jan 28, 2009

CapnBry posted:

I got the pointer math part, but how is the type of buffer[-1]/buffer-1 a char*?

Better you should ask "how is the type of buffer not a pointer"? The answer is, arrays "decay" (automatically convert into) pointers when used in almost any context. buffer[0] converts to a pointer, then applies the subscripting operator. buffer-1 converts to a pointer, then applies subtraction. One of the few operators which doesn't cause array arguments to decay to pointers is sizeof(). sizeof(buffer) would be 10, because no decay occurs. sizeof(buffer-1) is the size of a pointer, because the subtraction forces the decay. The 1 is meaningless.

# ? Jan 25, 2011 20:43

CapnBry: Jul 15, 2002; I got this goin'; Grimey Drawer

Sneftel posted:

Better you should ask "how is the type of buffer not a pointer"? The answer is, arrays "decay" (automatically convert into) pointers when used in almost any context. buffer[0] converts to a pointer, then applies the subscripting operator. buffer-1 converts to a pointer, then applies subtraction.

Oh snap. Well that explains everything now doesn't it. I've always considered arrays to be sorta like a fancy const pointer in practice, but I didn't consider decay. Oh man look at that, this is even in the C FAQ, guess I need more coffee or scotch. One of the two.

CapnBry fucked around with this message at 21:20 on Jan 25, 2011

# ? Jan 25, 2011 21:02

6174: Dec 4, 2004

I'm writing a C++ program and I've come to a design aspect that I don't know how to nicely solve.

My program plays a board game. I will be writing several decision algorithms on how to play (basically variations of one another). Each of these algorithms will use a heuristic to evaluate how good a board position is at various points. How the evaluation heuristic is calculated is totally separate from the specific decision algorithm used.

I would like to be able to easily mix and match decision algorithms with heuristics.

One obvious solution is multiple inheritance with separate abstract base classes for the decision algorithms and the heuristics. Then a full strategy is formed by inheriting a decision algorithm and a heuristic. I'm not particularly enthusiastic about this option because the number of classes I'd have to write is the product of the number of decision algorithms and evaluation heuristics which grows quickly when trying variations of heuristics, even if the classes are essentially trivial.

Is there a better way to do this than multiple inheritance?

# ? Jan 26, 2011 07:08

Titan Coeus: Jul 30, 2007; check out my horn

6174 posted:

I'm writing a C++ program and I've come to a design aspect that I don't know how to nicely solve.

My program plays a board game. I will be writing several decision algorithms on how to play (basically variations of one another). Each of these algorithms will use a heuristic to evaluate how good a board position is at various points. How the evaluation heuristic is calculated is totally separate from the specific decision algorithm used.

I would like to be able to easily mix and match decision algorithms with heuristics.

One obvious solution is multiple inheritance with separate abstract base classes for the decision algorithms and the heuristics. Then a full strategy is formed by inheriting a decision algorithm and a heuristic. I'm not particularly enthusiastic about this option because the number of classes I'd have to write is the product of the number of decision algorithms and evaluation heuristics which grows quickly when trying variations of heuristics, even if the classes are essentially trivial.

Is there a better way to do this than multiple inheritance?

I like templates a lot with this type of thing.

# ? Jan 26, 2011 07:13

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

Well, you can solve the problem of having to write M x N classes by using a template which subclasses two classes given by its template parameters, but I think the better solution is to repeatedly electrocute the part of your brain that's convinced itself that these two things absolutely have to be allocated as part of the same object until it sees the error of its ways.

# ? Jan 26, 2011 07:15

6174: Dec 4, 2004

TheBoogeyMan posted:

I like templates a lot with this type of thing.

That sounds like a nice solution, but I'm not sure how to make templates do this. Do you have any examples or search terms which would reveal some examples?

# ? Jan 26, 2011 07:15

Duke of Straylight: Oct 22, 2008; by Y Kant Ozma Post

As rjmccall said, you absolutely positively want to have your evaluation function over here and the decision algorithm over there. Most likely the former should (in functional terms) simply be passed in to the latter as an argument.

# ? Jan 26, 2011 08:17

The1ManMoshPit: Apr 17, 2005

Make an algorithm and a heuristic interface (pure abstract class) and write all your code conforming to the interfaces, with both as separate objects. Make factories that can construct the classes by name. Create the two things using the factories. Easily change your algorithm/heuristic at run-time by just swapping the two things out as desired by name.

Decide for yourself whether you want to have the caller store both algorithm and heuristic and pass the heuristic to the algorithm when necessary or whether you just want to create an algorithm and pass it the name of the heuristic on creation and it can then store and manage the heuristic object itself.

# ? Jan 26, 2011 15:31

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!

Do it C-style, and just have the object take two function pointers, one "Heuristic" and one "Decision". The functions will take as a parameter a pointer to the object.

Or you can make it member function pointers so you don't have to work with an explicit 'this', but member function pointers are horrible and should be shot in the face.

# ? Jan 26, 2011 17:18

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

I am losing a fight with the preprocessor.

A third-party header file has a section that looks like this:

code:

#if CGAL_LEDA_VERSION < 500
#include <LEDA/real.h>
#include <LEDA/interval.h>
#else
#include <LEDA/numbers/real.h>
#endif

I want the third file, not the first two, but I can't figure out how to get the #if skipped. CGAL_LEDA_VERSION should be 630. I tried putting CGAL_LEDA_VERSION 630 in the Visual Studio "preprocessor defines" section of the project settings and it didn't work. I tried #define CGAL_LEDA_VERSION 630 right before I included that file, and even undefing it before redefining it. No matter what I do, the #if is always true. This is the first third-party header I include (so I can't see how anything else could be futzing with it). I can't just patch this one file, because the version checking is all over the library.

I feel like there's something fundamental I don't know about preprocessor defines, but obviously I don't know what it is. How can I fix this or at least figure out what the problem is?

# ? Jan 27, 2011 01:18

That Turkey Story: Mar 30, 2003

GrumpyDoctor posted:

I feel like there's something fundamental I don't know about preprocessor defines, but obviously I don't know what it is.

It doesn't look like you're doing anything wrong -- is this the exact snippet of code that's exhibiting the behavior you are describing? Also, forgive my asking, but are you absolutely sure it's not taking the 2nd path? Maybe the third file includes the first two anyway which is why you are thinking that the first path is taken. Have you tried putting a #error immediately after the #if or the #else to see where you get?

Edit: Just out of curiosity, have you tried explicitly defining the value to be less than 500?

# ? Jan 27, 2011 01:31

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

I got it working somehow. I'm not sure how, but I did! The #errors helped with debugging, thanks for the tip.

raminasi fucked around with this message at 03:56 on Jan 27, 2011

# ? Jan 27, 2011 03:31

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!

GrumpyDoctor posted:

I tried putting CGAL_LEDA_VERSION 630 in the Visual Studio "preprocessor defines" section of the project settings and it didn't work.

In the preprocessor defines section it'd go in as CGAL_LEDA_VERSION=630 if I recall correctly.

# ? Jan 27, 2011 16:41

Oxyclean: Sep 23, 2007

I'm working with ANSI C for a class assignment to make a buffer:

code:

Buffer * b_create ( int init_capacity, char inc_factor,char o_mode );

Is the function prototype I'm currently expanding; the problem I've run into, or am misunderstanding is that "inc_factor" can be in the range 1-255; yet attempting to do this comparison results in the error to the degree of "result will always be positive because value is out of range"

But I'm not allowed to change the function prototype, and can't make it unsigned so that it will accept values greater then 127. Am I missing something obvious?

# ? Jan 29, 2011 03:52

litghost: May 26, 2004; Builder

Oxyclean posted:

I'm working with ANSI C for a class assignment to make a buffer:
code:
Buffer * b_create ( int init_capacity, char inc_factor,char o_mode );
Is the function prototype I'm currently expanding; the problem I've run into, or am misunderstanding is that "inc_factor" can be in the range 1-255; yet attempting to do this comparison results in the error to the degree of "result will always be positive because value is out of range"

But I'm not allowed to change the function prototype, and can't make it unsigned so that it will accept values greater then 127. Am I missing something obvious?

Compiler flags?

# ? Jan 29, 2011 04:07

Mr.Radar: Nov 5, 2005; You guys aren't going to believe this, but that guy is our games teacher.

Oxyclean posted:

I'm working with ANSI C for a class assignment to make a buffer:
code:
Buffer * b_create ( int init_capacity, char inc_factor,char o_mode );
Is the function prototype I'm currently expanding; the problem I've run into, or am misunderstanding is that "inc_factor" can be in the range 1-255; yet attempting to do this comparison results in the error to the degree of "result will always be positive because value is out of range"

But I'm not allowed to change the function prototype, and can't make it unsigned so that it will accept values greater then 127. Am I missing something obvious?

Cast the parameter to an unsigned char (example).

# ? Jan 29, 2011 04:23

Oxyclean: Sep 23, 2007

Mr.Radar posted:

Cast the parameter to an unsigned char (example).

Would this matter though? Can't the value being sent into the function not be greater then 127 because its a char?

# ? Jan 29, 2011 04:25

oldkike: Jan 10, 2003; hey

www.pleasegimmeadollar.com

True ANSI C shouldn't assume the signedness of char, so if the caller expects you to use a number between 1 and 255, they should have specified "unsigned char" in the function prototype.

# ? Jan 29, 2011 04:25

Mr.Radar: Nov 5, 2005; You guys aren't going to believe this, but that guy is our games teacher.

Oxyclean posted:

Would this matter though? Can't the value being sent into the function not be greater then 127 because its a char?

Look at my example. I passed the value 224 and recovered it with the cast. It works because the types char and unsigned char both use the same number of bytes/bits which means the cast only impacts how the compiler interprets those bits (i.e. as a signed number in the range -128..127 or an unsigned number in the range 0..255).

# ? Jan 29, 2011 04:32

Paniolo: Oct 9, 2007; Heads will roll.

I've got a question about const. I've got a class that does some mathematical work. It's got several Set functions to set the inputs, and several Get functions to get the outputs. It's set up to use lazy evaluation, so any time a Set, it's marked as dirty, and any time a Get function is called, it recalculates the values only if it's marked as dirty.

This has the problem of making the Get functions not const, because they need to modify the data members when updating. I'm currently using const_cast to get around this:

code:

uint MyClass::GetValue() const
{
   const_cast<MyClass*>(this)->Update();
   return mValue;
}

I'm wondering if this is considered an appropriate use of const_cast, or if the "right" thing to do in this case would be to simply not mark the getters as const (which potentially breaks a lot of const correctness throughout the code.)

# ? Jan 29, 2011 17:50

Brain Candy: May 18, 2006

Paniolo posted:

I'm wondering if this is considered an appropriate use of const_cast, or if the "right" thing to do in this case would be to simply not mark the getters as const (which potentially breaks a lot of const correctness throughout the code.)

What you are looking for is the 'mutable' key word. It purpose is for lazy evaluation/caching calculations.

# ? Jan 29, 2011 18:00

Paniolo: Oct 9, 2007; Heads will roll.

Brain Candy posted:

What you are looking for is the 'mutable' key word. It purpose is for lazy evaluation/caching calculations.

Can't believe I didn't know about that. Thanks a lot.

# ? Jan 29, 2011 18:09

Nutsack Rangoon: Mar 30, 2010; EVERYTHING IS NUMBERED HERE. THE MONSTER IS ZERO.

Let me preface by saying I'm terrible:

quote:

int summation(){
int lo;
int hi;
int x;
int y;
x = 0;
for (y == x+lo; lo=<hi; lo++){
cout<<y;

}
}

This isn't compiling. Can someone tell me why? The compiler is telling me something about not expecting "<" before the for loop?

# ? Jan 30, 2011 03:17

A MIRACLE: Sep 17, 2007; All right. It's Saturday night; I have no date, a two-liter bottle of Shasta and my all-Rush mix-tape... Let's rock.

Nutsack Rangoon posted:

Let me preface by saying I'm terrible:

This isn't compiling. Can someone tell me why? The compiler is telling me something about not expecting "<" before the for loop?

Indentation is your friend.

code:

int summation()
{
  int lo, hi, x = 0, y;
  for (y = x + lo; lo <= hi; lo++)
  {
    cout << y;
  }
}

A MIRACLE fucked around with this message at 03:29 on Jan 30, 2011

# ? Jan 30, 2011 03:22

Adbot: ADBOT LOVES YOU

# ? Jun 8, 2024 00:53

Dransparency: Jul 19, 2006

Nutsack Rangoon posted:

Let me preface by saying I'm terrible:

This isn't compiling. Can someone tell me why? The compiler is telling me something about not expecting "<" before the for loop?

You've mistyped "<=" as "=<".

# ? Jan 30, 2011 03:32

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

«‹›641 »