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 »

Dicky B: Mar 23, 2004

I really like Bartosz Milewski's Win32 tutorials since it's one of the few resources I've found that gives a very concise overview of the api and the basic concepts http://www.relisoft.com/win32/index.htm. As Mr.Radar says, it's useful to have an understanding of what's happening under the hood.

# ? Nov 23, 2010 00:07

Adbot: ADBOT LOVES YOU

# ? Jun 7, 2024 01:37

Adahn the nameless: Jul 12, 2006

I want to start doing some c/c++ programming in a windows environment. Simple gui stuff just using the win32 API. Anyone have suggestions for IDEs' and compilers? So far I've been using g++ on Ubuntu.

I could use Visual Studio, but I've heard it doesn't play nice with Standard C++.

# ? Nov 23, 2010 01:07

w00tz0r: Aug 10, 2006; I'm just so god damn happy.

Adahn the nameless posted:

I want to start doing some c/c++ programming in a windows environment. Simple gui stuff just using the win32 API. Anyone have suggestions for IDEs' and compilers? So far I've been using g++ on Ubuntu.

I could use Visual Studio, but I've heard it doesn't play nice with Standard C++.

If you're using win32, there's no real reason not to use Visual Studio if you can.

# ? Nov 23, 2010 01:13

ToxicFrog: Apr 26, 2008

Visual Studio is fine as long as:
- you're working in C++ or C89 (not C99)
- you're cool with developing and running only on windows (ie, you aren't planning to develop on linux and test on windows, or release windows+linux+OSX versions of your software)

If this is the case, grab VS and have at it.

If not, your best is probably a mingw build of gcc - it comes in both windows-native command line (MSYS) and IDE (Code::Blocks) flavours, and is also available as a linux-host, windows-target cross compiler (check apt-get for "mingw32").

# ? Nov 23, 2010 01:21

Adahn the nameless: Jul 12, 2006

Visual Studio's better than anything I can use even if I'm not using Visual C++ or anything .Net? I guess I'll go with that then. Thanks.

# ? Nov 23, 2010 01:39

Vino: Aug 11, 2010

Old versions of Visual Studio (6.0 and to some degree 7.0/7.1) did not cooperate with other C compilers. The STL implementation was broken and the language had several minor but significant differences that required careful hacking around. These days if you avoid any Windows-based header or Windows-only library dependencies you should be able to write cross-platform code rather effectively, and Visual Studio's a fine choice. Since you're doing Win32 API stuff that's no problem for you and VS Express is free and actually quite good in my opinion.

I wouldn't recommend the Win32 API though if you can avoid it, there's lots of windowing toolkits that will work better for you and are easier to use.

# ? Nov 23, 2010 01:54

Adahn the nameless: Jul 12, 2006

Vino posted:

Old versions of Visual Studio (6.0 and to some degree 7.0/7.1) did not cooperate with other C compilers. The STL implementation was broken and the language had several minor but significant differences that required careful hacking around. These days if you avoid any Windows-based header or Windows-only library dependencies you should be able to write cross-platform code rather effectively, and Visual Studio's a fine choice. Since you're doing Win32 API stuff that's no problem for you and VS Express is free and actually quite good in my opinion.

I wouldn't recommend the Win32 API though if you can avoid it, there's lots of windowing toolkits that will work better for you and are easier to use.

Toolkits like Visual C++? My goal in Win32 is to get a feel for what I'm abstracting away when I use windowing toolkits. I dunno, I like having an idea of what's going on at the lower level.

I'll keep in mind what you said about Windows headers in case I decide to try something that's platform-agnostic.

# ? Nov 23, 2010 02:09

Floor is lava: May 14, 2007; Fallen Rib

Here's a tiny win32 tutorial. Beyond a simple framework there's not much to it really. Just reference msdn and you should be fine.

# ? Nov 23, 2010 03:14

Vino: Aug 11, 2010

Adahn the nameless posted:

Toolkits like Visual C++? My goal in Win32 is to get a feel for what I'm abstracting away when I use windowing toolkits. I dunno, I like having an idea of what's going on at the lower level.

No, I mean, something like Qt or GTK+ or MFC or the C# stuff or even wxWidgets. The simplest amount of code that gets you with a functional window is like, 100 lines of Win32 API but with GTK+ it's like, 2 lines. There's something to be said about what's going on at the lower level and if you really want to learn then by all means do it, but if you want to get things done then probably you don't care about what's going on down there too much, so long as it works. (And those windowing toolkits work pretty well.)

# ? Nov 23, 2010 03:31

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

TasteMyHouse posted:

Are there any tutorials / resources you recommend for basic framework / api agnostic GUI programming concepts?

I don't know of any. That's not to say that they're not out there, but I haven't ever looked for them. I learned everything I know about GUI programming (which I admit is not that much, I mostly do command-line and web programming) mostly by just trying lots of different frameworks (and tutorials for them).

# ? Nov 23, 2010 03:46

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!

Vino posted:

No, I mean, something like Qt or GTK+ or MFC or the C# stuff or even wxWidgets.

But for god's sake don't go with MFC, because it's basically the same as the Windows API only 1. C++ (intentionally) and 2. loving awful and full of retarded #defined craziness (presumably not intentionally).

MFC is only (maybe) okay, in Visual Studio, if you don't ever look at your own header files and just trust the Wizards to make the code work for you and you don't intend to do anything complicated. Also it tries to trick you into using the horrible new removable menu bars instead of the sane old ones. It's just dreadful. Don't do it.

# ? Nov 23, 2010 03:48

Vino: Aug 11, 2010

Disclaimer: I've never actually used any of the windowing toolkits I just mentioned so I can't vouch for their quality. If you want to use one you should do the appropriate research to find which one sucks least.

# ? Nov 23, 2010 04:50

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

Adahn the nameless posted:

Toolkits like Visual C++? My goal in Win32 is to get a feel for what I'm abstracting away when I use windowing toolkits. I dunno, I like having an idea of what's going on at the lower level.

I'll keep in mind what you said about Windows headers in case I decide to try something that's platform-agnostic.

You're posting like you think Visual C++ is some crazy language or toolkit or something. It's just Microsoft's IDE for Microsoft's implementation of C++ which isn't incompatible with the standard unless you use their language extensions (which are pretty well documented).

# ? Nov 23, 2010 05:40

Null Pointer: May 20, 2004; Oh no!

roomforthetuna posted:

But for god's sake don't go with MFC, because it's basically the same as the Windows API only 1. C++ (intentionally) and 2. loving awful and full of retarded #defined craziness (presumably not intentionally).

MFC dates back to when people were still worried about the costs of dynamic dispatch. MFC is based on such a heavily-restricted subset of C++ that it's not really even C++ anymore. That's also why it's so terrible and (intentionally) full of preprocessor macros: MFC had to re-implement a lot of functionality that the language already provided.

MFC and Win32 API are both terrible whether you're working in Visual Studio or not. Win32 API is pretty much mandatory to learn if you're serious about Windows development, but I'd never even consider writing a new GUI application using it. If you have your heart set on it, though, the gold standard Win32 API tutorial used to be theForger's.

# ? Nov 23, 2010 06:02

ToxicFrog: Apr 26, 2008

Vino posted:

No, I mean, something like Qt or GTK+ or MFC or the C# stuff or even wxWidgets. The simplest amount of code that gets you with a functional window is like, 100 lines of Win32 API but with GTK+ it's like, 2 lines. There's something to be said about what's going on at the lower level and if you really want to learn then by all means do it, but if you want to get things done then probably you don't care about what's going on down there too much, so long as it works. (And those windowing toolkits work pretty well.)

On top of that, using GTK+ or Qt (and possibly some of the others?) makes design tools accessible to you, allowing you to design the GUI in a seperate program and hook it up to the code later, which massively reduces the pain of trying to design a UI that doesn't look like poo poo.

# ? Nov 23, 2010 06:06

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

Please don't use GTK+ if you're ever planning to use the program on anything but linux.

# ? Nov 23, 2010 06:14

ToxicFrog: Apr 26, 2008

Why not? I've never had any problems releasing windows programs using GTK+.

# ? Nov 23, 2010 06:24

Quebec Bagnet: Apr 28, 2009; mess with the honk
you get the bonk; Lipstick Apathy

The Win32 API isn't that bad as GUIs go. The API is itself very much a product of the 80s and 90s but there's something to be said for the minimalism.

# ? Nov 23, 2010 06:37

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

Derpes Simplex posted:

The Win32 API isn't that bad as GUIs go. The API is itself very much a product of the 80s and 90s but there's something to be said for the minimalism.

Exactly. Win32 is actually refreshingly simple once you get down a few concepts (the message loop, window classes, GDI drawing). It's not hard or necessarily bad, just tedious: the simplicity of the library comes at the cost of complexity in your app. Now, raw Xlib... that's the stuff of nightmares (or at least that's the reputation its built up over the years; I've (thankfully?) never had to work with it).

# ? Nov 23, 2010 07:11

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

I have no idea why you wouldn't just learn C# and .NET if you were dying to program for Windows now.

# ? Nov 23, 2010 07:31

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

ToxicFrog posted:

Why not? I've never had any problems releasing windows programs using GTK+.

Other than that they're hideous and probably ignore a lot of platform conventions?

# ? Nov 23, 2010 07:34

OddObserver: Apr 3, 2009

Actually Xlib is pretty simple (and similar, to Win32, really) for most of the basic things, too --- creating windows, drawing things, etc (though it's somewhat complicated by having both modern and obsoleted ways of doing things). There are some things, however, that are indeed pretty complex --- basically anything that involves interaction between different clients, in particular clipboard and drag-and-drop, requires implementing protocols from some lower-level primitives, and can get pretty messy.

Oh, and X11/Xlib doesn't actually provide any actual widgets itself, which is sort of a big deal for actual applications (but not so much if you just want to play around and see the basics of how things work).

# ? Nov 23, 2010 07:34

Null Pointer: May 20, 2004; Oh no!

Derpes Simplex posted:

The Win32 API isn't that bad as GUIs go. The API is itself very much a product of the 80s and 90s but there's something to be said for the minimalism.

Sorry, but I completely disagree. Win32 API is 'refreshingly simple' up to the point where you're trying to do some non-trivial layout, or anything that behaves well with user settings (DPI, custom fonts, custom colors.) You'll have implemented a significant portion of wxWidgets by the time you've written enough boilerplate to be productive.

# ? Nov 23, 2010 07:42

Sagacity: May 2, 2003; Hopefully my epitaph will be funnier than my custom title.

If you want to do any sort of GUI programming and you REALLY want to use C++ instead of C#, just go with Qt. It's complex, but usually for the right reasons. And it just works without being completely insane.

# ? Nov 23, 2010 10:01

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.

Plorkyeran posted:

Other than that they're hideous and probably ignore a lot of platform conventions?

Oh it definitely is missing things. #1 on my list is that Pidgin doesn't accept the Windows keyboard codes for non-ASCII characters.

# ? Nov 23, 2010 14:17

csammis: Aug 26, 2003; Mental Institution

Mustach posted:

Oh it definitely is missing things. #1 on my list is that Pidgin doesn't accept the Windows keyboard codes for non-ASCII characters.

This drives me loving nuts, and if I ever got my Pidgin development environment back up and running I'd take a crack at it...but knowing GTK it's probably deep in the actual GText internals and not something I could capture in the client program :sigh:

# ? Nov 23, 2010 15:53

Zaxxon: Feb 14, 2004; Wir Tanzen Mekanik

hey guys I have a weird bug I'm encountering.

I have a class called Cpokey, which is an atari POKEY chip sound emulator, it's ripped out of the MAME source and edited to be more nice and object oriented. I have another class which just makes new pokeys sticks them in a vector and routs control messages to them.

the pokey maker has a function called "make pokey" which looks like this:

code:

void Cpokey_maker::make_pokey(const char* name)
{
	//make a new pokey
	Cpokey* newguy = new Cpokey(name,this->node_depth + 1);

	//stick it in this makers messaging tree
	this->add_child(newguy);

	//stick it on the signal chain
	the_pokeys.push_back(newguy);
}

if I call this function once it works fine. If I call this function more than once the whole vector of Cpokey pointers gets corrupted and they all become pointers to garbage.

I don't know STL too well so I'm wondering if I need to set up the vector in the pokey maker class differently. Right now I'm just declaring it as a member, calling it's default constructor and then using it.

# ? Nov 23, 2010 18:44

Dicky B: Mar 23, 2004

A vector may increase the size of its internal memory to make room for new insertions and in doing so copies its contents to a different block of memory and invalidates the old one.

You could get around this by calling reserve() to reserve the space you need, preventing reallocations as long as you don't insert more than you have space for.

# ? Nov 23, 2010 19:34

Zhentar: Sep 28, 2003; Brilliant Master Genius

Dicky B posted:

A vector may increase the size of its internal memory to make room for new insertions and in doing so copies its contents to a different block of memory and invalidates the old one.

You could get around this by calling reserve() to reserve the space you need, preventing reallocations as long as you don't insert more than you have space for.

If the internal implementation of resizing a vector matters, you're doing something horribly wrong. The solution in such a case is not to call reserve(), it's to stop using vectors like that.

Zaxxon: that's not enough code to know what you're doing wrong. You're going to have to post more of it.

# ? Nov 23, 2010 20:04

Vanadium: Jan 8, 2005

Dicky B posted:

A vector may increase the size of its internal memory to make room for new insertions and in doing so copies its contents to a different block of memory and invalidates the old one.

You could get around this by calling reserve() to reserve the space you need, preventing reallocations as long as you don't insert more than you have space for.

The vector might move the pointer around but the pointer is still going to point to the same object.

# ? Nov 23, 2010 20:13

Dicky B: Mar 23, 2004

I'm assuming he's try to access the contents of the vector via some other reference since that's the only reason I can think of why push_back would cause a pointer to become invalidated (without seeing more of the code).

# ? Nov 23, 2010 20:16

Zaxxon: Feb 14, 2004; Wir Tanzen Mekanik

Dicky B posted:

I'm assuming he's try to access the contents of the vector via some other reference since that's the only reason I can think of why push_back would cause a pointer to become invalidated (without seeing more of the code).

well Here is the rest of the pokey_maker class

code:


Cpokey_maker.h:
class Cpokey_maker : public Cosc_container
{
	protected:

		std::vector<Cpokey*> the_pokeys;
		void execute_osc_method(const osc::ReceivedMessage& message);

	public:
		Cpokey_maker(const char* name, int depth);

		int get_pokey_count();
		Cpokey* operator[](int index);

		void make_pokey(const char* name);

};

Cpokey_maker.c:

#include "Cpokey_maker.h"
#include "Cpokey.h"
#include <iostream>
#include <cstring>
#include <vector>

Cpokey_maker::Cpokey_maker(const char *name, int depth):
Cosc_container(name,depth),
the_pokeys()
{


}

int Cpokey_maker::get_pokey_count()
{
	int sz = the_pokeys.size();
	return sz;
}
		
Cpokey* Cpokey_maker::operator[](int index)
{
	return the_pokeys[index];
}

void Cpokey_maker::execute_osc_method(const osc::ReceivedMessage &message)
{
	const char* our_addr = get_subaddr_at_depth(message.AddressPattern(),node_depth);
	osc::ReceivedMessage::const_iterator arg = message.ArgumentsBegin();

	//NEW_POKEY
	if(match_start(our_addr,"new_pokey"))
	{
		const char* pokey_name = arg->AsString();
		
		Cpokey* newguy = new Cpokey(pokey_name,this->node_depth + 1);
		this->add_child(newguy);
		the_pokeys.push_back(newguy);
	}
}

void Cpokey_maker::make_pokey(const char* name)
{
	//make a new pokey
	Cpokey* newguy = new Cpokey(name,this->node_depth + 1);

	//stick it in this makers messaging tree
	this->add_child(newguy);

	//stick it on the signal chain
	the_pokeys.push_back(newguy);
}

the only relevant things I can think of are that Cosc_containers maintain a vector of pointers to other Cosc_containers, add_child calls push_back() on a vector of Cosc_containers.

The only way I do anything with pokeys are through messages routed through the Cosc_container structure, or asking them to process audio by using the [] operator.

# ? Nov 24, 2010 00:36

Dicky B: Mar 23, 2004

What worries me is code such as

code:

Cpokey_maker cpm;
...
...
Cpokey* p = cpm[0];
cpm.make_pokey("foo");
p->DoSomething(); // p may now point to invalid memory.

If you're not doing anything like this then I would check what is happening to newguy after it is passed to the base class via add_child.

# ? Nov 24, 2010 02:27

Zhentar: Sep 28, 2003; Brilliant Master Genius

Uh, no, that's not how it works. cpm[0] reads the value stored in the first element of the array, which is a Cpokey pointer, which is what gets assigned to p. The validity of this pointer has absolutely no relationship to the current memory location of the vector's storage, or its existence at all.

What you think is happening would look like this:

code:

Cpokey** p = &cpm[0];

# ? Nov 24, 2010 04:36

Brecht: Nov 7, 2009

Definitely looks like the problem is something to do with

code:

this->add_child(newguy);

Also, why is the execute_osc_method doing copypasta when it gets "new_pokey" instead of calling make_pokey?

# ? Nov 24, 2010 08:33

Dicky B: Mar 23, 2004

Zhentar posted:

What you think is happening would look like this:
code:
Cpokey** p = &cpm[0];

oh hur

Just ignore me folks. I leapt on this question because I had to fix a similar bug recently, except I was dealing vectors of actual objects which is a different case altogether.

# ? Nov 24, 2010 15:14

Zaxxon: Feb 14, 2004; Wir Tanzen Mekanik

Brecht posted:

Definitely looks like the problem is something to do with
code:
this->add_child(newguy);
Also, why is the execute_osc_method doing copypasta when it gets "new_pokey" instead of calling make_pokey?

Originally I was only using OSC to make new pokeys. I added make_pokey to help debug this issue. It's a pain in the rear end to have to load up the osc client each and every time I need to debug this stuff.

add_child does almost the exact same thing as make_pokey, it takes the pointer supplied to it and pushes it onto a vector of Cosc_container pointers.

I tried reserving space for the new pokey pointers and that stops the error, so the pointers are definitely getting lost when the vector re allocates.

# ? Nov 25, 2010 02:04

NecroBob: Jul 29, 2003

Would the following code be moderately safe to use? I'm trying to make it so that I can pass an arbitrary element from an array of little-endian bytes (from a file) and have it make an unsigned integer from that and the next three bytes.

I guess something about it just feels wrong, like it'd screw up in a heartbeat. It works in the two instances I've used it already, but I just wanted to see if anyone else saw any red flags.

code:

~
typedef unsigned char byte;
~
header[8] = { stuff };
~
magicnumber = UIntFromChar(&header[4]);

unsigned int UIntFromChar(char* buffer){
	unsigned int lol = 0;
	// go three elements up
	buffer += 3;
	// work our way back to the original index because this is little-endian
	for (int i = offset; i >= 0; i--){
		lol = (lol << 8) + byte(*buffer);
		buffer--;
	}
	return lol;
}

# ? Nov 25, 2010 08:37

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

It should work unless you're one some platform where uint is 16 bits. Or the platform is little-endian in the first place and you don't need to convert. If you don't need to worry about those situations, then you can do it a whole lot simpler:

code:

uint32_t SwapEndianness(uint32_t src) {
  return ((src & 0xFF) << 24) | ((src & 0xFF00) << 8) | 
         ((src & 0xFF0000) >> 8) | ((src & 0xFF000000) >> 24); 
}

And then I guess you could implement UIntFromChar as

code:

uint32_t UIntFromChar(char *buf) {
  return SwapEndianness(*(uint32_t *)buf);
}

Maybe even stick a few #ifdefs in there to handle the platform-endianness issue.

Jabor fucked around with this message at 10:33 on Nov 25, 2010

# ? Nov 25, 2010 10:30

Adbot: ADBOT LOVES YOU

# ? Jun 7, 2024 01:37

pseudorandom name: May 6, 2007

And on little endian platforms that can do unaligned loads (i.e. x86), you can just cast the arbitrary char* to an int* and read it like normal.

# ? Nov 25, 2010 10:34

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

«‹›641 »