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

cronio: Feb 15, 2002; Drifter

mracer posted:

Ok, more of a Visual Studio question. Whats the best way to step thru code with many macros. you know #define functions.

for example:
code:
#define COPY_PMV(adst,asrc) {                      \
  Ipp32s nn;                                       \
  for(nn=0; nn<sizeof(adst)/sizeof(Ipp32s); nn++)  \
    ((Ipp32s*)adst)[nn] = ((Ipp32s*)asrc)[nn];     \
}
is there an option for the debugger to show that instead of COPY_PMV(pointer,pointer) ?

No, I'm fairly sure that doesn't exist.

Using sizeof here may be your problem though, if adst is a pointer like you say, sizeof is going to return 4 (or 8 if you're on 64 bit).

# ¿ Feb 17, 2008 03:35

Adbot: ADBOT LOVES YOU

# ¿ May 6, 2024 10:04

cronio: Feb 15, 2002; Drifter

If you want a more generic solution, check out http://nocturnal.insomniacgames.com/index.php/Common#Automation.2FEvent.h

It's part of our new opensource initiative, Nocturnal. You can download the code from http://nocturnal.insomniacgames.com/releases/Common/

Other options include FastDelegate (which ours is based on) -- http://www.codeproject.com/KB/cpp/FastDelegate.aspx, and boost::bind.

[edited for comma in URL]

cronio fucked around with this message at 21:12 on Mar 2, 2008

# ¿ Mar 2, 2008 04:09

cronio: Feb 15, 2002; Drifter

oldkike posted:

If you want a really generic solution, check out libsigc++. It supports multiple args to callbacks all with type-safety.

How is this more generic than FastDelegate? (I don't know much about boost::bind, so I won't ask about it)

The support for Rebinding/Retyping doesn't seem compelling to me, since I prefer callbacks to be single-purpose (if the code needs to happen from multiple execution paths, I'd prefer the callback(s) call another function that does the work, rather than have a single callback that is rebinded/retyped).

Marshalling seems like it could be useful, but I can't think of any time I've actually needed that functionality.

Anyway, I'm not trying to knock libsigc++, I'm genuinely curious.

# ¿ Mar 2, 2008 21:11

cronio: Feb 15, 2002; Drifter

Thug Bonnet posted:

Good point! Is that a reasonable thing to do then? I'm pretty new with file i/o so I honestly don't know.

It's reasonable. If your files aren't going to be large though (if you're on a PC, on the order of tens of megabytes), reading the entire file and doing all the parsing in-memory is actually a better (faster) solution.

I'm used to C++, so this may not be perfectly valid C (variable declarations need to go to the top of the function for example).

code:

fseek( f, 0, SEEK_END );
int fileSize = ftell( f );
fseek( f, 0, SEEK_SET );

char* buf = (char*)malloc(fileSize);
fread( buf, 1, fileSize, f );

... parse ...

free( buf );

[edit] As far as string parsing goes in C, it basically sucks. atoi/atof/etc. are your friends, just make sure your strings are NULL terminated. The sn_ functions (snprintf, snscanf, etc.) are also handy (if your compiler supports them -- I'm not sure if they're standardized or not), since they take the size of the buffer, and so won't ever read off the end.

cronio fucked around with this message at 23:20 on Mar 2, 2008

# ¿ Mar 2, 2008 23:12

cronio: Feb 15, 2002; Drifter

oldkike posted:

atoi, atof, etc are deprecated. Look at strtol, strtod, etc.

Good to know, thanks.

# ¿ Mar 3, 2008 00:12

cronio: Feb 15, 2002; Drifter

Honestly I'm not sure why either would compile. I've always thought that if you want to declare a variable inside a case statement, you need to give it scope:

code:

case is_Stm:
  {
    ...
  }
  break; // can be in or out of the brackets

# ¿ Mar 3, 2008 01:56

cronio: Feb 15, 2002; Drifter

Neslepaks posted:

Don't do these casts when writing C. void pointers are always implicitly castable to other pointers, all you'll achieve is to hide warnings you'd want to see (like if you forgot to include the prototype for malloc, or there's a more serious type mismatch).

Not having the cast there is a compile error in C++ -- is that not true in C?

# ¿ Mar 5, 2008 06:49

cronio: Feb 15, 2002; Drifter

Thug Bonnet posted:

Is it possible to know the size at any given time, though? For example would it be possible to just create a memory dump as a program is running? I'm trying to think of a "hello world" of memory dumps, but I'm not sure where to begin.

On Windows you probably want to look at VirtualQuery: http://msdn2.microsoft.com/en-us/library/aa366902(VS.85).aspx

# ¿ Mar 11, 2008 08:21

cronio: Feb 15, 2002; Drifter

It's called a forward declaration. It's used all over the place -- it's the standard way of removing the include file mess.

Note that it only works on pointers or references, where the compiler doesn't need to know the full definition of the object.

So:

code:

class SomeClass;

SomeClass* asdf;

works, but:

code:

class SomeClass;

SomeClass asdf;

does not

[edit]
FYI forward declaring classes/structs in headers saves a huge amount of compile time in large code bases. Seeing code that includes unnecessary headers in other headers makes me seethe with rage.

Also, if what you're trying to forward declare is inside a namespace, you can do:

code:

namespace A
{
  class B;
}

A::B* asdf;

cronio fucked around with this message at 05:16 on Jun 12, 2008

# ¿ Jun 12, 2008 05:12

cronio: Feb 15, 2002; Drifter

StringX is uninitialized... you don't actually want an LPSTR (unless you allocate memory for it), you want an array of characters: char StringX[25].

# ¿ Sep 15, 2008 08:01

cronio: Feb 15, 2002; Drifter

Character strings (char*/char[]) are essentially just arrays of bytes, ending in a NULL terminator (which you seem to understand).

Your confusion is more a question of pointers/memory management than strings themselves. Forget about it being a string for a second, and think about it this way: GetWindowText takes a pointer to a *block of memory* to put the string into, and the size of that block of memory. So if you just have an LPSTR (char*) and haven't allocated space for it you have a pointer that doesn't actually point to anything yet. If you really wanted to use an LPSTR, you'd have to allocate some space for it with new (or malloc, depending on if this is C or C++):

code:

StringX = new char[25];
GetWindowText(...)
...
delete [] StringX;

If you're in C++, a string class like std::string will take care of the details for you, but unfortunately the windows API is all C-based.

# ¿ Sep 15, 2008 10:23

cronio: Feb 15, 2002; Drifter

Avenging Dentist posted:

Assuming you're using a static function, it's because this is the typedef:
code:
typedef DWORD (__stdcall *LPTHREAD_START_ROUTINE) (
        LPVOID lpThreadParameter
);
i.e. you need a function whose signature is DWORD __stdcall butts(void*)

EDIT: also the scope-resolution operator in C++ is "::", not "."

Unless it's a static function, you can't do it anyway. You need to do something like:

code:

DWORD wrapperFunc( LPVOID param )
{
  ((MyObject*)param)->myFunction();
}

And pass your object as the parameter in CreateThread.

# ¿ Sep 26, 2008 05:29

cronio: Feb 15, 2002; Drifter

Avenging Dentist posted:

Yes, hence the "Assuming you're using a static function" at the beginning of my post

gently caress. I actually specifically looked because I assumed you would've mentioned it. Apparently I can't read :eng101:

# ¿ Sep 26, 2008 06:28

cronio: Feb 15, 2002; Drifter

Since you're storing T in your queue, and not T*, what's happening is that you're actually storing a *copy* of the object you're adding. And because the queue is actually of type Point, it's using the copy constructor to create a new Point object, not a derived one, and copy just the Point data from the derived object you're adding.

You need to store pointers inside your queue, and allocate the objects on the heap:

code:

template <class T> 
void declare(Queue<T> *q){ 
  Derivd* newball = new Derivd(amb, mir, trans, azi, elev, roll, diff, centr, .25); 
  q->add(newball); 
}

And of course don't forget to delete them when they are removed from the queue.

cronio fucked around with this message at 05:31 on Sep 29, 2008

# ¿ Sep 29, 2008 04:07

cronio: Feb 15, 2002; Drifter

Whoops, noticed I had a slight typo... I didn't mean to have Queue<T*> in there.

What you really want to do is keep the queue holding T, but instantiate it with Shape* instead of Shape:

code:

Queue<Shape*> my_queue;

This lets it work for any kind of object instead of just pointers.

# ¿ Sep 29, 2008 05:34

cronio: Feb 15, 2002; Drifter

The first result to a google search for "C file output":

http://www.cs.bu.edu/teaching/c/file-io/intro/

# ¿ Oct 3, 2008 04:23

cronio: Feb 15, 2002; Drifter

The Red Baron posted:

Could/should shared_ptrs be passed/returned (but not stored, obviously) by reference to avoid the overhead of an atomic refcount update? Or are there issues with this that makes it a bad idea?

Always.

# ¿ Oct 3, 2008 17:10

cronio: Feb 15, 2002; Drifter

How about just cin.get(), getc()... ?

# ¿ Oct 14, 2008 06:27

cronio: Feb 15, 2002; Drifter

Avenging Dentist posted:

I think pretty much anything trying to force a pause in a console app is kinda dumb. If you're just learning how to program, you shouldn't really be worried about usability, just about learning the concepts. If you're an experienced programmer writing a console app, you should be using command line arguments anyway. I mean, at the end of the day, do whatever you want, but I think stuff like that is kinda hacky, and really a lot less useful than people make it out to be.

Hard to learn the concepts if you can't see what your program is outputting though. While there are other ways around this, grabbing a character from input is fine if you want to just hit F5 in VS. Worrying about details like breakpoints when you're writing your first application is just silly.

I wasn't really paying attention to the thread, I see he already was using cin.get(). I agree that system("pause") is a horrible thing to do.

# ¿ Oct 14, 2008 17:45

cronio: Feb 15, 2002; Drifter

Avenging Dentist posted:

I don't see why you'd run in debug mode unless you have breakpoints set. Running without debug (Ctrl+F5) will keep the command prompt open, and if you compiled in debug mode, the JIT debugger will load up if something goes haywire anyway.

Because most people who have never programmed before don't know the difference? After all, it's the exact problem the person who asked the question was having.

Anyway, Ctrl+F5 works here as well, but if you're writing an *interactive* console app a cin.get() to pause the app is not exactly verboten.

# ¿ Oct 15, 2008 07:59

cronio: Feb 15, 2002; Drifter

wwqd1123 posted:

Can't you adjust the level of objects for garbage collections? ie higher level objects won't be collected before lower level objects? I think Microsoft has poured millions into it's GC so it wouldn't surprise me if you couldn't customize it for games.

In addition to what's already been said, very few people develop games just for Windows -- and C# is not cross-platform (even on the 360 only the XNA games are allowed to use C#, and XNA is a *lot* slower than direct access to the graphics card).

# ¿ Apr 10, 2010 07:29

cronio: Feb 15, 2002; Drifter

digibawb posted:

citation required.

Seriously, of all the things for XNA to be slow at on the 360, I really can't see why it would be the rendering. Do you have evidence for this? (Same applies for on Windows tbh)

Looks like I was partially wrong -- the Direct3D implementation on the 360 is much lower-level than on Windows. In the native API you do get direct access to the hardware though, i.e. you can bypass the Direct3D API or even write directly to the command buffer (and many do). I can't cite anything but this is directly from people who work on the 360.

Direct3D on the 360 is at least a lot better than OpenGL on the PS3 though, which virtually no one uses (that's direct from experience).

The same does not apply on Windows because you don't have the same level of hardware access.

# ¿ Apr 11, 2010 04:28

cronio: Feb 15, 2002; Drifter

digibawb posted:

Yeah, unless you are writing your own command buffers, which you don't have access to in XNA, then it's going to be pretty much identical.

No VMX support seems like a much bigger deal, to me anyway.

EDIT: And the limited control of memory...

Yeah, I was assuming the difference was more along the lines of OpenGL vs. libgcm on the PS3. Since that's not the case the differences for the average coder are less, but game developers still do a lot of asm-level optimization (even if they're not writing assembly, analyzing the assembly generated by the compiler).

Also, game developers are dinosaurs, and don't like to change

. They also don't like anything unexpected, which managed languages sometimes provide.

Oh, and they already have millions of lines of asm/C/C++ code. I wouldn't be surprised if a lot of things go the way of Unity (C# as a scripting language -- a lot of developers use Lua now), with the engine still in C/C++.

# ¿ Apr 11, 2010 04:39

Adbot: ADBOT LOVES YOU

# ¿ May 6, 2024 10:04

cronio: Feb 15, 2002; Drifter

digibawb posted:

I'd like to think I'm quite open to change, thank you very much :P

That was meant more as a joke, but didn't come out that way

. It's somewhat true, but it's also often true for good reasons. When you need to lock at 30/60hz, any unexpected performance overhead (especially if it's variable between frames) causes problems. It's easy enough to write badly performing C or C++ code, it can be much easier in a managed or dynamic language.

digibawb posted:

We might be getting a little off topic here though

Yes, I'll stop the derail here, just wanted to clarify that last bit.

# ¿ Apr 12, 2010 06:14

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