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

Steampunk Mario: Aug 12, 2004; DIAGNOSIS ACQUIRED

FatCow posted:

I'm using a stl set to hold multiple instances of a class. Is it considered poor form to make things 'mutable' that aren't used in the comparison operator to get around the implicit cast to const?

I'd probably have to see a specific example of where you'd need to modify data in a comparison operator, but only modifying builtins or calling non-const methods on the class or any nonmutable member classes would cause this issue. So, if you have a lot of data in a class and only some of it needs to be changed in a const function, then you only need to make that specific data mutable.

...But yeah, it's kind of bad form because mutable usually designates pretty specific functionality like access statistics and caching. The general rule is that the (visible) state of the object should never change in a const method.

# ¿ Mar 13, 2008 03:49

Adbot: ADBOT LOVES YOU

# ¿ May 4, 2024 01:56

Steampunk Mario: Aug 12, 2004; DIAGNOSIS ACQUIRED

graffin posted:

Is there a way to test if an Object element variable is an integer, string, or char string?

Are you talking about C# or something? C++ is too strongly typed to cleanly support a standard Object type, but Java and C# do.

# ¿ Mar 20, 2008 19:53

Steampunk Mario: Aug 12, 2004; DIAGNOSIS ACQUIRED

elevatordeadline posted:

Teach me about 64-bit integers in C.

In Java, int is four bytes and long is eight bytes. That's not the case in C, where, if I understand correctly, sizeof(long) only has to be at least equal to sizeof(int). So what should I do when I need a 64-bit integer?

I'm not 100% about the standardization of these, but I'm pretty sure 'long long' and 'int64_t' are 64-bit.

# ¿ Mar 20, 2008 22:08

Steampunk Mario: Aug 12, 2004; DIAGNOSIS ACQUIRED

elevatordeadline posted:

uint64_t and unsigned long long both work as long as I'm using gcc -std=c99. Hooray. Evidently, though, I don't understand what to do next.

For example,
code:
typedef unsigned long long ulong;

ulong x, y, z;
printf("%llu bytes.\n", (ulong) sizeof(ulong));
scanf("%llu %llu %llu", &x, &y, &z);
printf("x = %llu,\ny = %llu,\nz = %llu.\n", x, y, z);
If the input is 314, 31415926535897, and 6469693230, then the output is
code:
8 bytes.
x = 314,
y = 2147303424,
z = 2535732953.
Those numbers are not the same numbers at all.

I don't recognize those format characters, so I'm assuming you have some extension of printf that does. Are you sure it's reading/writing 8 bytes?

# ¿ Mar 20, 2008 23:00

Steampunk Mario: Aug 12, 2004; DIAGNOSIS ACQUIRED

GuyGizmo posted:

I've got a programming bug that's about to make me start pulling out my hair:

I'm writing a plugin in C++ for both the 32-bit and 64-bit Windows versions of Maya. When I compile and test the plugin in a 32-bit environment, it works great. In 64-bit Maya, it causes the whole program to crash, and I have no idea why. It's exactly the same code, and none of it *should* be sensitive to a platform change like that.

Furthermore, when trying to poke around or removing bits and pieces of my code to see if I can figure out what part is causing the crash, I start finding out that re-arranging trivial lines of code, or worse yet, changing the names of local variables can either cause the crash to happen at different places or not at all. Results are totally inconsistent. It makes no sense!

I loving hate errors like this. Does anyone know what the hell could cause a completely inconsistent crash like this?

Unfortunately, plenty of things could be wrong: invalid assumptions about the size of ints/pointers, different alignment on structs or other memory, API calls that work slightly differently (in both windows AND maya)... the list goes on.

If you have a debugger and stack dumps though, it shouldn't be too significant a problem to track down the actual culprit.

# ¿ Mar 27, 2008 00:05

Steampunk Mario: Aug 12, 2004; DIAGNOSIS ACQUIRED

ColdPie posted:

This sounds sane to me, and it's something I always wondered about. But I never follow that rule for the following reason: how do you include types that are defined in other headers, in your header?
code:
//One.h

class One {
  int aMember;
};
code:
//Two.h

#include "One.h"

class Two {
  One anotherMember;
};
How can this situation be arranged so that Two.h does not include One.h, but the class Two still contains a member of type One?

Edit: #ifdefs truncated, but pretend they're there

It can't. The compiler MUST know the size of One in order to compile Two. It can be done with a level of indirection, though:

code:

class One;

class Two
{
  One* one;
};

This works because pointers to any type are always the same size, and the compiler just needs reassurance that 'One' isn't a typo.

# ¿ Mar 27, 2008 01:06

Steampunk Mario: Aug 12, 2004; DIAGNOSIS ACQUIRED

notMordecai posted:

Freshman CS major. I am doing a very, very basic program to represent trees. What it does is the computer says a number from 1 to 20 and depending on the number given (the first number it will always say is "10"). The user enters if that is correct, lower, or higher. It's simple enough but I am getting a really loving annoying syntax error that is not letting progress further.
code:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

struct guess_tree{
                  int node;
                  struct guess_tree* less;
                  struct guess_tree* more;
                  };
                  
struct guess_tree *start, *current_guess;

guess_tree list[21];

int i;

for (i = 1; i <= 20; i++) {
	list[i]->node = i;
}
It's telling me I have a syntax error before "for" in line 17. So help me god I cannot figure out what the gently caress I am doing wrong (unless of course I am having a retard moment).

If that's your entire file, then you're just dumping executable code in no-man's land. It needs to be in an execution path, like your main function for instance.

# ¿ Mar 27, 2008 01:17

Steampunk Mario: Aug 12, 2004; DIAGNOSIS ACQUIRED

"Reduce dependencies by forcing your user to have essentially the same number of includes, only spread across many files and much more difficult to maintain!"

What a great idea.

# ¿ Mar 27, 2008 01:27

Steampunk Mario: Aug 12, 2004; DIAGNOSIS ACQUIRED

I'd like to add that generally if you want a set of unique numbers randomly selected from another set, it's cheaper to simply sort your set of available numbers with a random metric, then just pull your 'rolls' from the front of the randomly sorted array.

(pseudocode, may not compile as it's a mix of C99, C++, and garbage)

code:

int availableNums[20];
for( unsigned i = 0; i < 20; ++i )
  availableNums[i] = i + 1;

int RandPred( int num1, int num2 )
{
  return rand()%3 - 1;
}

std::sort( availableNums, availableNums + 20, RandPred );

int rolls[NUM_PLAYERS];
for( unsigned i = 0; i < NUM_PLAYERS; ++i )
  rolls[i] = availableNums[i];

# ¿ Mar 31, 2008 23:43

Steampunk Mario: Aug 12, 2004; DIAGNOSIS ACQUIRED

ShoulderDaemon posted:

Sorting with a random metric is O(n ln₂ n) and potentially has problems if your sorting algorithm is stable, but you can shuffle an array in linear time with, for example, the Fisher-Yates shuffle:
code:
int nums[20];
int j;
int temp;

for ( int i = 0; i < 20; ++i ) {
  j = random( ) % (i + 1);
  temp = nums[i];
  nums[i] = nums[j];
  nums[j] = temp;
};

I think the complexity of sorting an array of 20 numbers is pretty insignificant, and I only gave the pseudocode as an example. The person writing the program would probably prioritize good random numbers over a fast shuffle. Besides, I would probably just use random_shuffle anyway.

# ¿ Apr 1, 2008 00:36

Steampunk Mario: Aug 12, 2004; DIAGNOSIS ACQUIRED

floWenoL posted:

I think the person writing the program would probably prioritize "having my program not crash" over anything else, which sorting with a random metric would do. To fix that, you'd have to make sure that your predicate returns consistent results if you pass it the same pair twice, at which point your level of complexity is way beyond just doing the shuffle.

Hey, I didn't even guarantee that it would compile, so getting far enough to crash is pretty ambitious for my pseudocode! v:)v

# ¿ Apr 1, 2008 01:46

Steampunk Mario: Aug 12, 2004; DIAGNOSIS ACQUIRED

Also, operand is uninitialized and therefore this snippet won't do anything useful (and may possibly have undefined behavior).

# ¿ Apr 15, 2008 21:38

Steampunk Mario: Aug 12, 2004; DIAGNOSIS ACQUIRED

Citizen Erased posted:

Does anyone know of a faster alternative to the standard library vector container? A year or so ago I made a 3D application which relied very heavily on the stl vector and since, a friend has told me how slow vectors are. I'd like to re-work some of the old code and replace the vectors with something similar but more efficient if it means I can eek a few more frames per second out of it. Is there anything faster and more suited for real time 3D applications?

http://code.google.com/p/rdestl/

This is a library developed by a guy who worked on The Witcher (and has a pretty decent development blog). I would imagine there's something in here you can cannibalize if optimization's important.

# ¿ Apr 24, 2008 20:38

Steampunk Mario: Aug 12, 2004; DIAGNOSIS ACQUIRED

That Turkey Story posted:

Oh my lord... I hope that isn't what he was using std::vector for!

How else would you implement a 3-Vector? :raise:

It's called std::vector for a reason, you know!

If you really needed .x, .y, and .z syntax you could instead inherit from std::vector, I guess.

If you weren't supposed to use it like that, then why would the STL provide an inner_product function? :rolleyes:

# ¿ Apr 24, 2008 23:00

Steampunk Mario: Aug 12, 2004; DIAGNOSIS ACQUIRED

HB posted:

Probably with something that doesn't have a ton of baggage related to dynamic resizing.

Well it wouldn't be doing any resizing after init since it's a 3-vector, not an n-vector!

# ¿ Apr 24, 2008 23:08

Steampunk Mario: Aug 12, 2004; DIAGNOSIS ACQUIRED

Andrei Alexandrescu posted:

Indeed, where there are ellipses, there's not much C++ left.

# ¿ May 2, 2008 16:17

Steampunk Mario: Aug 12, 2004; DIAGNOSIS ACQUIRED

What's an easy way to determine if an arbitrary program will halt? Is there a library for it?

# ¿ Jul 13, 2008 20:45

Steampunk Mario: Aug 12, 2004; DIAGNOSIS ACQUIRED

KaeseEs posted:

I think a lot of people who would use hash_map would in fact want it for its implementation...?

Just because people expect O(1) doesn't mean they should assume a hash table (or any combination of guarantees and predictable implementation).

# ¿ Aug 17, 2008 11:13

Steampunk Mario: Aug 12, 2004; DIAGNOSIS ACQUIRED

KaeseEs posted:

Indeed, it is foolish for users to expect implementations of common data structures and algorithms in the standard libra
source

You misunderstand me. I just mean that although they should include a data structure that has all the guarantees that they expect, there's no reason for them to bind their hands needlessly by making it a hash table underneath, particularly if there are better options on different platforms or whatever. Giving the users a O(1) data structure that improves in performance with more memory thrown at it is important, but if someone figures out a better way to do it than a hash table it's silly to make a new container for that since it meets all the old requirements.

# ¿ Aug 17, 2008 22:20

Steampunk Mario: Aug 12, 2004; DIAGNOSIS ACQUIRED

Avenging Dentist posted:

The template arguments for unordered_map expect a hashing function. It's not like you can just slot in a new implementation without changing the template arguments.

Ok, bad example, but I was just trying to say that expecting a specific implementation underneath an interface doesn't make sense. The guarantees and interface should be enough.

# ¿ Aug 17, 2008 22:52

Steampunk Mario: Aug 12, 2004; DIAGNOSIS ACQUIRED

Avenging Dentist posted:

They're both intellisense related. C++ intellisense is crap because the C++ grammar is complicated*. This isn't really rocket science here.

* And because Microsoft is full of lovely programmers who couldn't template metaprogram their way out of a paper bag.

Come on, TMP is a great tool at solving certain problems, but you seem to have an unwarranted fascination with it. Sometimes the most straightforward and effective solution is naive and readable and doesn't involve TMP at all. Not all problems can be solved at compile-time and you're suggesting that TMP is the biggest hammer of all time, when most problems aren't nails.

# ¿ Oct 27, 2008 04:46

Steampunk Mario: Aug 12, 2004; DIAGNOSIS ACQUIRED

Avenging Dentist posted:

If you don't want to use Boost, you're probably an idiot.

This is extremely naive fyi and I'm not certain if you're a professional programmer why you can't imagine situations in which certain libraries and language features aren't available, but you're making yourself look like either a pompous moron or a troll. C++ was designed to be a multiparadigm language, and part of the reason that it's still so widely used is that it supports many features in many different ways, and there's often no One True Solution to a particular problem.

# ¿ Nov 24, 2008 12:44

Adbot: ADBOT LOVES YOU

# ¿ May 4, 2024 01:56

Steampunk Mario: Aug 12, 2004; DIAGNOSIS ACQUIRED

theg sprank posted:

I have a question for C++ language nazis.

Clearly it's unacceptable to call a virtual method on a NULL pointer. Is it acceptable to call a non-virtual method on a NULL pointer, from the standpoint of the language definition? It happens to work on g++, but I want to know whether it is required by the standard to work.

many thanks

I'm not sure about the standard, but in all the implementations that I've seen, it's safe if and only if the function doesn't access any member data (as in, use the this pointer). This basically makes it a static function though, so you would probably just refactor it that way. I'm sure the standard says it's undefined in general though, since it's a NULL deref technically.

# ¿ Dec 15, 2008 04:07

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

FatCow posted:

graffin posted:

elevatordeadline posted:

elevatordeadline posted:

code:

code:

GuyGizmo posted:

ColdPie posted:

code:

code:

code:

notMordecai posted:

code:

code:

ShoulderDaemon posted:

code:

floWenoL posted:

Citizen Erased posted:

That Turkey Story posted:

HB posted:

more falafel please posted:

Andrei Alexandrescu posted:

KaeseEs posted:

KaeseEs posted:

Avenging Dentist posted:

Avenging Dentist posted:

Avenging Dentist posted:

theg sprank posted: