It's a type. The size() member function of strings return a size_t.
Though, it could probably be written as
size_t tempsize = str.size();
The size_t(...) part is a cast.
It's a type. The size() member function of strings return a size_t.
Though, it could probably be written as
size_t tempsize = str.size();
The size_t(...) part is a cast.
Originally Posted by Adak
An unsigned integer type that is the type of the result of the sizeof operator. It is a natural choice for a variable that stores the size of an array. If you use a std::vector then you do not need another variable to store the size of the dynamic array since the vector keeps track of its own size.
Look up a C++ Reference and learn How To Ask Questions The Smart Way
It's a type. If you look at string's copy() function, you'll see why I used it. It's because copy uses it. C++ has a strict type system, so you want to avoid using the wrong type if you can. If you're careless, you're also, by necessity, very comfortable with type promotion rules, which will change the types of certain variables used in expressions that aren't the same type as the result.
For example:
size_t tempsize = size_t(str.size());
Here I elected to use an explicit type conversion because the return value of size() is not size_t, but string::size_type. Perhaps more correct would be static_cast<size_t> (str.size()); but there are a lot of things to explain in that statement. For starters. There's no reason to believe that string::size_type isn't convertible to size_t though...
okay here is a header of one of the functions to that networking engine:
Its using char* because its communicating with another program that only accepts doubles and char*Code:double writestring(char*str, double buffid) { CBuffer*buff = (CBuffer*)buffers.item((int)buffid); if(buff == NULL)return 0; return buff->writestring(str); }
Well to sum up, you could use vector<char> or what I showed you to do this.
If my example or any of the others are confusing, then what you're doing is:
1. Constructing something array like from the string object.
2. Calling your function by passing the address of the first element, which is the same type as char*
3. Cleaning up the array like object if necessary.
From there you continue to use standard strings.
This modularizes the code, so that you're only using lower-level stuff when you call on the networking API.
Now in the interest of full disclosure, laserlight is correct about my example and its lack of exception safety. vector, and just about anything else, would be safe, but writestring() doesn't throw unless buffers.item() throws. Maybe nothing else does either. I'm not clairvoyant.
okay lets put this char* thing on hold. Lets move towards a diffrent function I have been working on.
Is this the most EFFICIENT way to do this?Code:int stringToInt(string paraString) { return atoi (paraString.c_str()); }
I can't say about efficient, but there are several ways to do it. Two are:
Another is:Code:int n = boost::lexical_cast<int>(mystr);
If you're going to make a function, consider passing the string by const reference. Otherwise you'll hurt efficiency by making a copy.Code:int n; std::stringstream sstr(str); sstr >> n;
No, it would likely be more efficient to write:
But then if paraString contains some invalid character, this would also fail to detect it. If that is acceptable, then you're okay, otherwise use a stringstream method or strtol.Code:int stringToInt(const string& paraString) { return atoi(paraString.c_str()); }
Look up a C++ Reference and learn How To Ask Questions The Smart Way
Well atoi is pretty fast. If paraString is not guaranteed to be an integer and an integer in the range of int, you'll have to verify the conversion. Again, string streams will work. Just test the stream state after you extract the int.
Depends on your code flow too, I suppose. boost::lexical_cast will throw an exception if it fails. But don't worry about speed unless you figure out that it's really a bottleneck.
why did you change it to a const?
To make sure the function doesn't modify it.
lol, the function is only 1 line though
Yes, but then again, const correctness is like a chain. Once you begin the chain, you can't break it. A const function cannot call non-const functions. And a function that takes arguments by const reference cannot pass these into functions expecting non-const arguments.
laserlight changed it to a const reference because making a copy is slower than not making a copy. If it was left as a normal reference you wouldn't protect the original data.
