Alternative to #define VARNAME "text".....

This topic is 3527 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

(in VS2005/C++/std) Alternative to #define VARNAME "text"..... i am reading in some strings and mapping them onto unique ids. example: #define BOX1 "box1" #define BOX2 "box2" i want to use an alternative to #define.... i am thinking writing a function that passes in a string, compares this with a list of const strings and returns the integer id. std::map<std::string,int> stringList; int FindID(std::string& findThis) { return ( stringList[findThis] ); } Anyone know any simpler/better ideas or something i am missing?

Share on other sites
I don't really know what your problem is, but in C++ we try to use const variables instead of #defines.

const std::string BOX1 = "box1";const std::string BOX2 = "box2";

Share on other sites
What you posted;

std::map<std::string,int> stringList;int FindID(std::string& findThis){  return ( stringList[findThis] );}

won't work as you expect.

If the string 'findThis' doesn't exist then a new entry will be created and a default constructed int will be returned.

What you should do is use std::map::find() and check the returned iterator to make sure the entry exists and then retrive it (via deferencing the iterator to get at the value).

Share on other sites
I want to link the value of a const integer to the value of a string.
so where ever i use the string it substitutes it for the value of the const integer.

const int objectOneId = 5;

// This is what i want help with...
// the string is checked against a std::map<std::string,int> stringList;
int id = GetIDFromString(string);
someObject->SetID(id);

if(someObject->GetID() == objectOneId)
{
// this is object one
}

Share on other sites
thanks, saved me some debugging time :), my original question would be is that an efficient way of doing what i want?

Share on other sites
If I understand what you want, you should use a pointer. Technically, it's an integer that can be set to constant that can be substituted for the value of a string.

string x = "qwerty";const string* xPtr = &x; // xPtr equals the address/value of x.                         // The & prefixed to a variable is the address extractor.if( *xPtr == "qwerty" ) // If the pointer points to a value equal to qwerty...// The *prefixed to a pointer de-references, or allows you to see what the pointer points to.

This should in no way be a substitute for a tutorial on pointers if you really don't know what they are. They can be quite a hassle to work with, but once you understand them, the list of things you can do shoots up exponentially.

Share on other sites
Quote:
 Original post by Splinter of Chaosa pointer. Technically, it's an integer

What?

Share on other sites
Technically, it is a whole number, or integer that represents a place in memory. Might be good to clarify positive whole number, or unsigned integer.

But if you disagree, I'd be happy to read WHY? (Wikipedia, by the way, has no entry for "whole number", it redirects you to integer.)

Share on other sites
Quote:
 Original post by Splinter of ChaosIf I understand what you want, you should use a pointer. Technically, it's an integer that can be set to constant that can be substituted for the value of a string.

Ah, where's Zahlman when you need him to explain the deep doctrine of the difference between integers and pointers? C++ makes far fewer guarantees about pointers than integers (e.g. theint++ is always defined while theptr++ may not be defined, as after the end of an array).

Share on other sites
I was (a) using the word integer because s/he asked specifically about using an integer that works as the specific string and (b), either way, trying to suggest s/he use pointers. (Or at least learn to use them.)

Share on other sites
Quote:
Original post by BeanDog
Quote:
 Original post by Splinter of ChaosIf I understand what you want, you should use a pointer. Technically, it's an integer that can be set to constant that can be substituted for the value of a string.

Ah, where's Zahlman when you need him to explain the deep doctrine of the difference between integers and pointers?

Technically, I'm the minion in charge of that doctrine [wink]

Splinter of Chaos: there are two ways to look at the "pointers are integers" statement. The first way is to notice that pointers and integers behave differently: pointer arithmetic and comparison is based on a buffer-offset definition, which means it's unsafe to compare the order of pointers to objects that are not within the same buffer, or to add random offsets to pointers. Sure, pointers can be converted to and from integers, but it's not a morphism (the various operations on integers don't match the operations on their associated pointers). In that perspective, pointers and integers are not the same.

The other way is to notice that pointers are represented, at the machine level, as a sequence of bits. On many platforms, this sequence has the same size and storage locations as an integers (though this is not necessarily the case). And so, like 99% of any data inside a computer, pointers are actually integers. This is, of course, not really useful because of the generality of that statement.

Share on other sites
Quote:
 Original post by Splinter of ChaosTechnically, it is a whole number, or integer that represents a place in memory.

If you want to make that argument, then technically an address is, at some level, an integer. That is, it is a whole number.

A pointer T* is a data type which represents an address, and is not synonymous to the data type int.

Share on other sites
Quote:
 Original post by Driv3MeFarIf you want to make that argument, then technically an address is, at some level, an integer. That is, it is a whole number.

Even that isn't accurate. An address may have more complicated structure than that. For example, on x86 processors an address is actually two numbers: a segment and and offset into that segment. In the old days of DOS, the memory model worked with 20 address lines and the segment was 16 bits and the offset was also 16 bits. This meant that a far pointer, a pointer that contained both segment and offset, was 32 bits, but multiple pointer values could be used to refer to the same memory block. Pointers are an abstraction that may or may not be mappable to simple integer operations, which is one reason why various programming standard have limitations of valid pointer operations. Ex: the limitation on pointers pointing to one past the end of an allocated memory block. In a flat memory model this may seem like a pretty stupid restriction. However, in the DOS segment:offset memory model, pointing two past an allocated memory block may actually wrap around and end up pointing to the beginning of the memory block.

More to the point, using a pointer to a string literal as a unique identifier for that string is pretty useless since dynamically allocated strings with the same string value will not share the same pointer value for the string. Even two string literals from different parts of the program with the same value may have different pointer values. If you want to map a string value to an integer, use a hash function.

Share on other sites
/whistles innocently :)

Share on other sites
Quote:
 Original post by Zahlman/whistles innocently :)

I think I'm going to take that position.

• 9
• 11
• 21
• 10
• 14