Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[MagmaMcFry]

I have an idea for a program/game/sim that no one has done before as far as I can tell. No amount of googling has shown even a single prior reference for something even remotely like it. As this may be my very first truly original idea that I can capitalize on... i wont be sharing it until it can be demo'd.

You evil, evil bastard, leaving the rest of this thread to intently wonder what the hell you could have thought about.

[olemars]

Since he's not telling I'm just going to assume it's a fantasy MMO with guild banks.

[Mego]

Well, I didn't know that there's an issue with templated functions/classes having separate definitions and declarations. Moved the definitions into the header for the Member class, and the problems disappeared (with some more magic).

[Skyrunner]

Related to optimizing my A* algorithm

Can someone link me to a good algorithm for hashing std::pair<int,int>? I've searched around but haven't found anything that jumps out to me as drop-and-use code . It's weird that strings and vectors have automatic hashes but pair<> doesn't.

Reason I'm using unordered_map is because 30% of exclusive function call time is in map::find() now, and hashmaps probably have faster access time than maps.

[MadocComadrin]

This may just be my current migraine talking, but what about hashing a string made by concatenating the two integers?  Eg. if your pair contains 45 and -67, hash "45-67"?

[Rose]

how about long Pair = int1 * MAX_INT + int2?

[MagmaMcFry]

This may just be my current migraine talking, but what about hashing a string made by concatenating the two integers?  Eg. if your pair contains 45 and -67, hash "45-67"?

That's kinda expensive, since that would take two decimal conversions, some string allocations and concatenations and a string hashing. A better choice would be Japa's, but you could make it even faster if you omit the multiplication and simply define the coordinate datatype as union{struct{int x, y}; long i} instead of pair<int,int>.

[Mephisto]

Just finished my biggest refactor yet. We went from a mess of Ajax and Bootstrap modals (yes, we're THOSE kinds of developers. I'm sorry) to something a bit more... normal, pleasing, and usable. Making this thing degrade gracefully when Javascript is absent was probably much more enjoyable to me than it should have been.

Git informs me that my total changes add up to 1034 additions and 1518 deletions (split over two pull requests, one for each of the large modules I was working on). My pull request reviewers love me.

[Mego]

This may just be my current migraine talking, but what about hashing a string made by concatenating the two integers?  Eg. if your pair contains 45 and -67, hash "45-67"?

If you use the sign of the second number as the separator between the first and the second, I'm having a hard time finding a reason why this wouldn't result in a suitable hash.

how about long Pair = int1 * MAX_INT + int2?

{int1=1, int2=MAX_INT} would produce the same value as {int1=2, int2=0}.

[dreadmullet]

C++, why must you be so inconsistent?

I like C++ because it doesn't hold your hand. What's that saying... something like, "Other languages have measures in place to prevent shooting yourself in the foot; C++ has a gun aimed at your foot at all times." But it can be a little annoying sometimes.

For anyone wondering about the difference, let me (try to) explain. globalInstance is a constant value always in memory that is loaded from the .exe file. The compiler is nice and gives the values in the executable default values; integers default at 0. However, variables declared in functions are different. At runtime, to make room for local variables, such as instance, the stack is expanded by the size of all the local variables, and then any variables that you assign values to in C++ land have their values assigned by the running program. So the unassigned values in instance are just garbage.

[Telgin]

Global values probably just shouldn't be initialized to anything.  It would help avoid that inconsistency and would also help avoid the problem of objects being constructed in an undefined order if you have global objects.

Though, if you didn't initialize global objects, I guess you'd have to resolve how global objects would work.  Forbidding them is probably extreme and wouldn't really work, though there's always the option of allowing only pointers to them that are initialized at runtime.

There's really no way to define what order such objects should be constructed either, so I guess the standard just did the easiest thing by still allowing global variables but not defining construction order.  Atomic types might could get away without being initialized though.

[MorleyDev]

In theory, the compiler could allocate the stack ones to a default value too. It's called "undefined behaviour" for a reason. It just doesn't, and really you should never assume that the globals you've created are always going to have that default value. Even if it works, it's still bad practice.

That's the cracks where C++ will bite you, the specification allows for "undefined behaviour" and woe betide the fool who integrates against a specific definition of that undefined behaviour.

[Mego]

At runtime, to make room for local variables, such as instance, the stack is expanded by the size of all the local variables, and then any variables that you assign values to in C++ land have their values assigned by the running program. So the unassigned values in instance are just garbage.

That's actually inherited from C, which is the way it is because of how assembly works.

In theory, the compiler could allocate the stack ones to a default value too. It's called "undefined behaviour" for a reason. It just doesn't, and really you should never assume that the globals you've created are always going to have that default value. Even if it works, it's still bad practice.

That's the cracks where C++ will bite you, the specification allows for "undefined behaviour" and woe betide the fool who integrates against a specific definition of that undefined behaviour.

Don't blame the tool if you don't use it right.

[Telgin]

Yep, it's just a case of the compiler not doing extra work for you and assigning values to stack variables after reserving space for them.  It just kind of calls into question why it makes provisions for default values for global variables, which could be confusing to new programmers.  From what I recall, global variables have space and their initial values reserved as a section of the executable, which seems unnecessary (at least on some platforms, are globals initialized to 0 part of the standard?).  I admit it's been a while since I looked at x86 assembly and how C was typically translated to it, but at the very least it seems like globals could just be treated like stack allocated variables and pushed onto a stack frame before main was called.

That doesn't help with the indeterminate initialization order problem with C++ of course...

[Skyrunner]

how about long Pair = int1 * MAX_INT + int2?

uint_64 might work o_O?
If Japa's idea won't work for some reason, someone tell me!

edit: perhaps uint64_t hash = (uint64_t)n1 << 32 + n2?