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

«‹›639 »

jonus: Jun 7, 2008; by mons all madden

#ifdef _MSC_VER
// We'll also define this to stop MSVC complaining about sprintf().
#define _CRT_SECURE_NO_WARNINGS
#pragma comment(lib, "Irrlicht.lib")
#endif

#include <irrlicht.h>
#include <iostream>
#include <fstream>
#include <iomanip>
#include <string>

using namespace irr;
using std::string;

I know I said I was using iostream.h, but in truth I was using iostream. I had been able to figure out the h was depreciated by myself. Strangely enough I do have to use it for irrlicht.

Originally I was able to get the irrlicht tutorials to work, except when I used std::cout, or std::cin. I eventually realized I needed to click the box under Build options, Compiler Flag,
'single-threaded run time library' [/Ml]
or
'single-threaded debug runtime library' [Mld]

If I'm already using namespace for irr, can I also do 'using namespace std;' so I don't have to put a std:: in front of every cout and cin?

About being able to open and edit a textfile in MSVC, what tutorial would you guys recommend?

# ? Aug 16, 2009 15:13

Adbot: ADBOT LOVES YOU

# ? Apr 29, 2024 15:55

Sweeper: Nov 29, 2007; The Joe Buck of Posting; Dinosaur Gum

Avenging Dentist posted:

Hahahahahahahahaha no. These two headers have nothing to do with one another. (string.h is cstring in C++)

I thought it string was a "replacement" for CStrings?

What are the differences between a CString and a string usage wise? Is one better then the other?

Like I know you do things differently with CStrings and strings, but are they two means to the same end?

# ? Aug 16, 2009 16:44

Vanadium: Jan 8, 2005

There is no thing named CString in the standard library. :geno:

Edit: The <cstring> header repackages the C89 string.h functionality within the std namespace, so it is basically C strings, it does not actually introduce anything like a CString type. The <string> header gives you the std::string type.

Vanadium fucked around with this message at 16:52 on Aug 16, 2009

# ? Aug 16, 2009 16:48

Sweeper: Nov 29, 2007; The Joe Buck of Posting; Dinosaur Gum

Vanadium posted:

There is no thing named CString in the standard library.

I thought it was apart of the C Standard Library?

Edit: ah I see

# ? Aug 16, 2009 16:55

Standish: May 21, 2001

There are three completely different string datatypes being talked about here:

The CString class, this is part of the Microsoft Foundation Classes and is not part of either the C or C++ standards
The std::string class, this is part of the C++ standard and is in the <string> header file
a "C string", this refers to a plain old zero-terminated array of bytes, from the original C language. It's built-in to the language so you don't need to include any header files to use it, but there are some related C standard library utility functions in the <string.h>/<cstring> header file

# ? Aug 16, 2009 17:34

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

I've got a bit of a debugging question here.

My program compiles fine, and at first seems to run well. However, whenever I try and close it I get an unhandled exception error. This isn't unusual. What's unusual is that I've gone through using breakpoints, and the error doesn't occur until AFTER my main() function returns. Is this from a deconstructor being called? How do I locate a problem like this?

I also get another error after the first; "No symbols are loaded for any call stack frame. The source code cannot be displayed."

# ? Aug 16, 2009 19:39

floWenoL: Oct 23, 2002

Standish posted:

There are three completely different string datatypes being talked about here:
The CString class, this is part of the Microsoft Foundation Classes and is not part of either the C or C++ standards
The std::string class, this is part of the C++ standard and is in the <string> header file
a "C string", this refers to a plain old zero-terminated array of bytes, from the original C language. It's built-in to the language so you don't need to include any header files to use it, but there are some related C standard library utility functions in the <string.h>/<cstring> header file

Also, this CString.

# ? Aug 16, 2009 20:09

That Turkey Story: Mar 30, 2003

floWenoL posted:

Also, this CString.

I just concatenated in my pants.

# ? Aug 16, 2009 20:47

HondaCivet: Oct 16, 2005; And then it falls
And then I fall
And then I know

Avenging Dentist posted:

What are some of the other errors?

You could also try putting #include <windows.h> before any other #includes. You might want to put #define NOMINMAX before that since Windows is retarded.

The only time the piece of code you gave me seems to do anything is when I put it right after #include stdafx.h but right before the other #includes. When I do this, it gives me like 200 errors that mostly read "error C4430: missing type specifier - int assumed. Note: C++ does not support default-int."

I tried the windows.h thing and that gives me an error that says " fatal error C1189: #error : WinSock.h has already been included."

Bleh. :\

# ? Aug 17, 2009 20:34

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

HondaCivet posted:

The only time the piece of code you gave me seems to do anything is when I put it right after #include stdafx.h but right before the other #includes. When I do this, it gives me like 200 errors that mostly read "error C4430: missing type specifier - int assumed. Note: C++ does not support default-int."

Did you create this project yourself or are you working with someone else's stuff? MSVC's precompiled headers (that's what stdafx.h is for) are just a gigantic clusterfuck and almost always make your life worse. I've never been able to get them to work sensibly, though to be fair I haven't tried especially hard.

If I'm using MSVC, I always create a blank project and do everything from scratch. Believe me, it's easier.

_{It would probably be faster if I just took a look at it in person though.}

Avenging Dentist fucked around with this message at 20:49 on Aug 17, 2009

# ? Aug 17, 2009 20:43

HondaCivet: Oct 16, 2005; And then it falls
And then I fall
And then I know

Avenging Dentist posted:

Did you create this project yourself or are you working with someone else's stuff? MSVC's precompiled headers (that's what stdafx.h is for) are just a gigantic clusterfuck and almost always make your life worse. I've never been able to get them to work sensibly, though to be fair I haven't tried especially hard.

If I'm using MSVC, I always create a blank project and do everything from scratch. Believe me, it's easier.

_{It would probably be faster if I just took a look at it in person though.}

It's something the company made but they might be lazy and are using the default.

Look out for a PM.

# ? Aug 17, 2009 21:15

Thug Bonnet: Sep 22, 2004; anime tits ftw

Is there a common means of generating a public interface header for a library from multiple headers? For example my library has multiple source files, and multiple headers, and ultimately I'd like to have a single header to include that describes the interface rather than the handful of separate headers.

# ? Aug 18, 2009 19:28

Adhemar: Jan 21, 2004; Kellner, da ist ein scheussliches Biest in meiner Suppe.

Thug Bonnet posted:

Is there a common means of generating a public interface header for a library from multiple headers? For example my library has multiple source files, and multiple headers, and ultimately I'd like to have a single header to include that describes the interface rather than the handful of separate headers.

Make a header that includes the other headers?

# ? Aug 18, 2009 19:32

Thug Bonnet: Sep 22, 2004; anime tits ftw

Adhemar posted:

Make a header that includes the other headers?

That's one solution, but it's not very pleasant. I know there are utilities to do this, I just don't know what they are.

# ? Aug 18, 2009 19:34

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

Thug Bonnet posted:

That's one solution, but it's not very pleasant. I know there are utilities to do this, I just don't know what they are.

Why is that not pleasant? That's what you do.

Or, if you're some kind of obsessive weirdo, you could just make said header file and run gcc -E on it.

# ? Aug 18, 2009 19:45

Thug Bonnet: Sep 22, 2004; anime tits ftw

Avenging Dentist posted:

Or, if you're some kind of obsessive weirdo, you could just make said header file and run gcc -E on it.

I am, and that's exactly what I was looking for. Thanks

# ? Aug 18, 2009 19:53

Adhemar: Jan 21, 2004; Kellner, da ist ein scheussliches Biest in meiner Suppe.

Thug Bonnet posted:

I am, and that's exactly what I was looking for. Thanks

What's the advantage of doing it this way? It would have to outweigh the fact the you're duplicating code.

# ? Aug 18, 2009 20:42

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.

Thug Bonnet posted:

That's one solution, but it's not very pleasant. I know there are utilities to do this, I just don't know what they are.

Pleasant for who? If the library's big enough, users will want the option of multiple headers so that they can include just what they need and reduce compile times.

If you're worried about remembering to add the includes, it's easy enough to write a script that generates the mondo-header & add it to your build process:

code:

#!/bin/bash
echo "#ifndef MY_MEGA_HEADER" > libsex.h
echo "#define MY_MEGA_HEADER" >> libsex.h
for h in *.h; do echo '#include "$h"' >> libsex.h; done
echo "#endif" >> libsex.h

Or something like that, I'm sure it has errors/could be better.

# ? Aug 18, 2009 21:39

Joe Kickass: Feb 19, 2008; FUCK OFF WE'RE FULL

I've got a possibly stupid question for you c geniuses.

I've written a small program which loads data from a file into a linked list etc etc, standard uni assignment stuff. The program compiles and runs fine on my home linux computer, but when running it on the schools computer (Solaris), the program shits its pants with a bus error when trying to traverse the list. According to GDB it doesn't like:

code:

listptr = list[j]->head;

if(listptr == NULL)
{
   /*do something*/
}
else
{
   while(listptr->next != NULL) ********
      listptr = listptr->next;
}

The bus error occurs on the the line with the asterisks. I can't see how this could happen because it specifically checks that a node exists before trying to reach the next one.

The program compiles fine on both systems with -ansi -pedantic -Wall flags, and like I said, it works fine on Linux.

Any help would be appreciated.

# ? Aug 19, 2009 03:21

Dijkstracula: Mar 18, 2003; You can't spell 'vector field' without me, Professor!

does it throw the bus error immediately (ie. the first time through the loop) or does it get part way through the traversal before it crashes? Either way, it sounds like your routine for building your list is maybe stomping on memory somewhere, or something's misalligned, or something like that. (I would venture it's an x86 vs sparc issure as opposed to a Linux vs Solaris one.)

edit: Do me a favour and set a breakpoint and inspect what listptr points to. If it's an invalid region of memory, it should say.

Dijkstracula fucked around with this message at 03:47 on Aug 19, 2009

# ? Aug 19, 2009 03:44

Joe Kickass: Feb 19, 2008; FUCK OFF WE'RE FULL

Solved it. Turns out I wasn't initializing the head pointer to null. loving dumb thing to waste a whole morning on. Thanks for your help Dijkstracula.

# ? Aug 19, 2009 04:50

baquerd: Jul 2, 2007; by FactsAreUseless

So I'm going for a fresh build of the newest GCC:

gmp-4.2.4
mpfr-2.4.1
gcc-4.4.1

"make check" and "make install" on gmp and mpfr go fine, libraries are present and everything seems to be working.

Running ./configure in GCC fails however, and complains the mpfr isn't the right version. When I tell it where to find the .h file just created via the make install, it complains the gmp is the wrong version (which it doesn't do when I don't specify mpfr).

quote:

checking for correct version of gmp.h... yes
checking for correct version of mpfr.h... no
configure: error: Building GCC requires GMP 4.1+ and MPFR 2.3.2+.

Any thoughts on how to proceed?

# ? Aug 19, 2009 09:51

Slurps Mad Rips: Jan 25, 2009; Bwaltow!

quadreb posted:

So I'm going for a fresh build of the newest GCC:

gmp-4.2.4
mpfr-2.4.1
gcc-4.4.1

"make check" and "make install" on gmp and mpfr go fine, libraries are present and everything seems to be working.

Running ./configure in GCC fails however, and complains the mpfr isn't the right version. When I tell it where to find the .h file just created via the make install, it complains the gmp is the wrong version (which it doesn't do when I don't specify mpfr).

Any thoughts on how to proceed?

run ldconfig as root?

# ? Aug 19, 2009 14:37

6174: Dec 4, 2004

C99 Question:

I've got the following union:

code:

union
{
    uint8_t u8buff[512];
    uint16_t u16buff[256];
    uint32_t u32buff[128];
    uint64_t u64buff[64];
    float fbuff[128];
    double dbuff[64];
} record_t;

It is being used to read a binary file that is made up of many records that are all 512 bytes long. When I currently compile my program, sizeof() of the union is 512 as I expect it to be. I know the ISO spec specifies it to be implementation specific, but is there a reasonable implementation that would not make that union exactly 512 bytes? The reason I ask is because my program verifies it to be 512, and gives an error if it is not. I just want to be sure that is a reasonable expectation on my part.

edit: For reference, I am using the __STDC_IEC_559__ macro that AD mentioned on the previous page to verify that the float and double aren't crazy.

edit2: I know it sounds like I'm being paranoid, so let me give a few more details to explain why I'm being so cautious. The data files this program reads are scientific instrument recordings spanning about 4-5 years in the early 90s. I'm in the process of packaging that data up to put into a long term storage computer. In addition this program I'm writing will be sitting next to the data. What will most likely occur is no one will use this program for a decade or more (if ever). I'm trying to make it as likely as I can that this program will still function then, or give enough information so that a researcher, who will almost certainly have minimal programming experience, can still access the data or hand the program off to someone to update it so they can access the data.

6174 fucked around with this message at 19:33 on Aug 19, 2009

# ? Aug 19, 2009 19:02

Dijkstracula: Mar 18, 2003; You can't spell 'vector field' without me, Professor!

In general, it's not a reasonable expectation, but in your case, it should be okay. On certain architectures, alignment requirements would pad out the array if sizeof(yourtype) wasn't a multiple of the alignment stride. However, since all those datatypes will be naturally 4-byte aligned (which is the only alignment that I've seen in use these days), that shouldn't pose a problem for you.

If you know something about the compiler that will be used, you can use a directive like __attribute__ ((__packed__)) on a union, but I've never actually needed this, so I can't tell you how the behaviour would play on different architectures.

Also scientific code :rolleye:

# ? Aug 19, 2009 21:03

BigRedDot: Mar 6, 2008

Dijkstracula posted:

If you know something about the compiler that will be used, you can use a directive like __attribute__ ((__packed__)) on a union, but I've never actually needed this, so I can't tell you how the behaviour would play on different architectures.

Have had to use packed structs to interface -malign-double code with -mno-align-double libraries.

quote:

Also scientific code

OH you don't even know. I mean, unless you do.

# ? Aug 19, 2009 21:14

Dijkstracula: Mar 18, 2003; You can't spell 'vector field' without me, Professor!

BigRedDot posted:

OH you don't even know. I mean, unless you do.

Oh I know. My favourite was a fluid dynamics app that, as part of the build process, had to build its own copy of gcc. Getting that one to comiple with Intel compilers was a comically huge amount of work.

# ? Aug 19, 2009 21:26

6174: Dec 4, 2004

Dijkstracula posted:

In general, it's not a reasonable expectation, but in your case, it should be okay.

Yeah, certainly alignment in general can't be assumed, but for the types in this particular union it seemed like a reasonable expectation.

Dijkstracula posted:

If you know something about the compiler that will be used, you can use a directive like __attribute__ ((__packed__)) on a union, but I've never actually needed this, so I can't tell you how the behaviour would play on different architectures.

Unfortunately I've got no clue what compilers will be common in the future. For now I'm using gcc, and trying to keep from using any odd extensions and attempting to make explicit the various assumptions I'm making.

Dijkstracula posted:

Also scientific code

This will be at least the 3rd or 4th generation of this program (others not written by me, and don't completely work with modern compilers if they ever worked), but it will be the first to have any comments or error checking.

# ? Aug 19, 2009 22:11

Dijkstracula: Mar 18, 2003; You can't spell 'vector field' without me, Professor!

6174 posted:

Yeah, certainly alignment in general can't be assumed, but for the types in this particular union it seemed like a reasonable expectation.

Unfortunately I've got no clue what compilers will be common in the future. For now I'm using gcc, and trying to keep from using any odd extensions and attempting to make explicit the various assumptions I'm making.

Yeah, what I was trying to say was, by virtue of your types in that particular union, you should be okay, but you shouldn't extrapolate that to an arbitrary union was what I was getting at.

Honestly, if you test this with, say, gcc and icc, in 32-bit x86 and amd64/x86_64 envionments, I would say it's highly likely that it will work for the forseeable future.

# ? Aug 19, 2009 22:23

Vanadium: Jan 8, 2005

Okay I never wrote anything where alignment or padding or whatever mattered but would it not be safer and more intuitive to just stuff everything into a char[512] instead of hoping that your unions are not going crazy on you

# ? Aug 19, 2009 23:14

BigRedDot: Mar 6, 2008

Dijkstracula posted:

Oh I know. My favourite was a fluid dynamics app that, as part of the build process, had to build its own copy of gcc. Getting that one to comiple with Intel compilers was a comically huge amount of work.

LOL that's awesome, I hope that was 10 years ago. Building gcc 2.x was a blast in the 90's

Edit: I still think it would be amusing to start with the latest gcc release, compile the immediately previous release, and repeat this process for as long as it works. I wonder what the absolute oldest version of gcc you could get to build today is.

BigRedDot fucked around with this message at 23:19 on Aug 19, 2009

# ? Aug 19, 2009 23:17

Dijkstracula: Mar 18, 2003; You can't spell 'vector field' without me, Professor!

BigRedDot posted:

LOL that's awesome, I hope that was 10 years ago.

Last fall

# ? Aug 19, 2009 23:40

floWenoL: Oct 23, 2002

6174 posted:

The reason I ask is because my program verifies it to be 512, and gives an error if it is not. I just want to be sure that is a reasonable expectation on my part.

Are you checking at compile-time or at run-time? If you're compiling it now to be used 10 years from now, then if you do a compile-time check you'll know that whenever you run it it'll still work.

# ? Aug 20, 2009 00:56

6174: Dec 4, 2004

floWenoL posted:

Are you checking at compile-time or at run-time? If you're compiling it now to be used 10 years from now, then if you do a compile-time check you'll know that whenever you run it it'll still work.

It is currently run-time because sizeof won't work as part of a pre-processor command, and I don't know of an alternative means to check the size of the union at compile-time. Also, it won't be the binary that is distributed, but the source.

Vanadium posted:

Okay I never wrote anything where alignment or padding or whatever mattered but would it not be safer and more intuitive to just stuff everything into a char[512] instead of hoping that your unions are not going crazy on you

Most of the reading of the block I am simply using the uint8_t type, so I guess in retrospect just reading into an array and dealing with it from there should be simplest way to proceed. I am already basically dealing with it byte by byte because of endianness issues.

6174 fucked around with this message at 01:35 on Aug 20, 2009

# ? Aug 20, 2009 01:18

floWenoL: Oct 23, 2002

6174 posted:

It is currently run-time because sizeof won't work as part of a pre-processor command, and I don't know of an alternative means to check the size of the union at compile-time. Also, it won't be the binary that is distributed, but the source.

I didn't mean checking it with the preprocessor but a static assertion, which is something like (untested):

code:

#define STATIC_ASSERT(x, msg) enum { static_assert_##msg = 1/(x) }

code:

#define STATIC_ASSERT(x, msg) char static_assert_##msg[x ? 1 : -1]

which will cause a compile error iff x is false. If you google around you can find more info, although most of the stuff you'll find will be for C++.

You should probably do it anyway, even if you're distributing the source, so that if it does break, you'll know it early.

Edit:
Source: http://pera-software.com/articles/compile-time-assertions.pdf

floWenoL fucked around with this message at 01:32 on Aug 20, 2009

# ? Aug 20, 2009 01:30

6174: Dec 4, 2004

floWenoL posted:

You should probably do it anyway, even if you're distributing the source, so that if it does break, you'll know it early.

I haven't seen static asserts like that in C before. I'll definitely be adding those checks.

# ? Aug 20, 2009 01:38

IdealFlaws: Aug 23, 2005

Can anyone tell me how to edit a string of numbers?
I have so far

int string[7];

scanf("%s", string);
a = string [0];
printf("a is %i\n", a);

But all I get is random numbers for a. Assuming I have all the correct syntax, it should display element 0 of my string array right?

# ? Aug 22, 2009 23:23

Vanadium: Jan 8, 2005

%s is for strings, not for int arrays. I am pretty sure there is no format specifier that lets you read multiple integers at once.

# ? Aug 22, 2009 23:37

Dijkstracula: Mar 18, 2003; You can't spell 'vector field' without me, Professor!

Vanadium posted:

%s is for strings, not for int arrays. I am pretty sure there is no format specifier that lets you read multiple integers at once.

code:

        int a[3];
        scanf("%d %d %d", &a[0], &a[1], &a[2]);
        printf("%d %d %d", a[0], a[1], a[2]);

code:

$ ./a.out
1 3 4
1 3 4

# ? Aug 23, 2009 00:35

Adbot: ADBOT LOVES YOU

# ? Apr 29, 2024 15:55

Vanadium: Jan 8, 2005

I meant something that is to %d as %s is to %c

# ? Aug 23, 2009 00:41

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

«‹›639 »