Printable View
Why would the following give an error as shown?
Until I added the ' + "test" ' everything worked fine.Code:std::string messageOut = "header 1: " + "test";
error: invalid operands of types `const char[11]' and `const char[5]' to binary `operator+'
Thanks
Just a wild guess.... ;)
Check the string operators:
http://www.cppreference.com/cppstrin...operators.html
See any that for operator+ that takes in two const char *'s? ;)
The examples for C++ (unlike those for c stings) hide the use of pointers which lead me to above usage (even at the link given).
But clearly the link you gave shows that the arguments (even if hidden) are pointers.
Thanks
Of course, there's no reason to do that when you can just do:In the rare case that you want to add two string literals, you can just create a temporary string out of one of them so that you are always adding to a string:Code:std::string messageOut = "header 1: test";
Code:std::string messageOut = "header 1: " + std::string("test");
On a related note:
I am converting a number to a string and would like to code...
And for the last hour I've been discovering that whenever and however I invoke DecToBin(num)...Code:std::string DecToBin(int num);
...
messageOut = "header 1: " + DecToBin(num);
e.g.
...that the executable returns "segmentation fault". I step through the code and find that a normally solid function (elsewhere and upstream in the method) returns negative.Code:test1 = DecToBin(num);
messageOut = "header1: " + test1;
What I'm wondering is that because I've defined DecToBin(int num) as an outside function to the class method that calls it, is it possible that some of its internal char* methods are conflicting with the class methods memory allocations?
Mystery...
There shouldn't be a conflict if you are doing it right.
Is this related to your itoa thread? Why are you using char*'s at all?
Dave++:
If you're returning a local string object, that could be why you're seg faulting. I don't think you should return local objects. Someone correct me if I'm wrong....
...Quote:
Originally Posted by Daved
Because string literals are char *'s when you get down to it. That's how you create string objects.
>> I don't think you should return local objects.
It's fine if it is a string object, which is what that function returns.
>> Because string literals are char *'s when you get down to it.
I'm not referring to string literals. I'm referring to actual usage and manipulation of the string itself. It sounds as if Dave++ is using char*'s as variables, when all that does is lead to greater potential for errors like segmentation faults. The C++ string class should be used instead.
The only char*'s you might want are const char*'s to point at the string literals, but even those are probably not necessary.
MacGyver,
Can you expand on your previous comment?
More testing...
In gdb I can comment out the call to the function, with a simple default value in its place, and then reset the DAQ hardware and everything works fine, but then as soon as I uncomment the line...everything fails. AND then when I comment the line out again errors persist until I reset the hardware.
Interestingly, the function itself works alright (set var=newval, and step though an if) but its inclusion alone seems to cause the code to fault ahead of itself and then behind as well.
So, if I get you right, I need to create a global pointer for the string?
Dave
Can you post the code inside the function?
>> So, if I get you right, I need to create a global pointer for the string?
No. If you are returning a string, you don't have to worry about that (Macgyver was mistaken). But it really depends on the code, its hard to tell just by your description.
It's the code from Mike
http://cboard.cprogramming.com/showthread.php?t=90911
I modified to return std::string
fyi - clocking out for the dayCode:std::string strOut = std::string(str); // using Daved approach as shown above
return(strOut);
The problem is likely that you didn't allocate space for the char* when you moved it inside the function. You could declare str as char str[100] if you are using mike_g's version, but I would use a bitset as I mentioned in that thread:The ugliness of the to_string method will be fixed in later C++ standard.Code:std::string getbinary(int num)
{
return std::bitset<32>(num).to_string<char, std::char_traits<char>, std::allocator<char> >();
}
For fun, I welcome people to comment on this "super" version, which is probably more than you need:Code:#include <iostream>
#include <bitset>
#include <string>
#include <climits>
#include <limits>
template<bool truncate_zeroes, size_t bits>
std::string get_binary_impl(unsigned long val)
{
std::string s(std::bitset<bits>(val).to_string<char, std::char_traits<char>, std::allocator<char> >());
return truncate_zeroes ? (val == 0 ? "0" : s.substr(s.find_first_not_of('0'))) : s;
}
template<size_t bits>
std::string get_binary(unsigned long val)
{
return get_binary_impl<false, bits>(val);
}
std::string get_binary(unsigned long val)
{
return get_binary_impl<true, sizeof(unsigned long)*CHAR_BIT>(val);
}
int main()
{
std::cout << get_binary(0) << '\n';
std::cout << get_binary(5) << '\n';
std::cout << get_binary<8>(0) << '\n';
std::cout << get_binary<8>(5) << '\n';
std::cout << get_binary(1431655765) << '\n';
std::cout << get_binary(std::numeric_limits<unsigned long>::max()) << '\n';
}
fun, but if you wanted to be super-anally-runtime efficient you could specialise get_binary_impl for true and false values of truncate_zeroes instead of a runtime ?:
but that would be ridiculous :D
>> you could specialise get_binary_impl for true and false values
Sounds good. Feel free to give it a go. I just spent five minutes trying and decided it's not a simple switch.
Also, the preprocessor automatically concatenates adjacent string literals, so thisQuote:
Originally Posted by Daved
is the same asCode:"hello"
"world" "nice to"
"meet you"
It's useful for really long string constants. It lets you stick to an 80 character limit more easily. :)Code:"hello world nice to meet you"
Alright, thanks for the code examples above.
I will be studying them and will use them once I know and test them better.
Below is the hardway in that it demonstrates the math and could be extended to other bases.
As always your comments are welcome.
Dave++
____________Code:#include <iostream>
#include <stdio.h>
#include <string>
#include <cmath>
#include <cstdlib>
std::string DecToBin(float num)
{
std::string str = "";
int i, expmax;
double top;
const double lg2 = log(2.0);
if(num == 0) return("0");
expmax = floor(log(num)/lg2);
// std::cout <<"expmax " << expmax << std::endl;
for(i=expmax; i>=0; i--){
top = num - pow(2.0,i); // subtract the binary basis
// std::cout << num << " " << top << std::endl;
if (top < 0){
str = str + "0";
}
else {
str = str + "1";
num = top;
}
}
return(str);
}
int main()
{
int num;
printf("Enter a whole number: ");
scanf("%i", &num);
std::cout << DecToBin(num) << std::endl;
// std::cout << log(2.0) << std::endl;
}
If there are no spoons, then where did all the ice cream come from? ("7")
just a thought Dave++, here is another way to work it. Not as good as Daved but it does work.
Code:#include <iostream>
#include <string>
#include <algorithm>
#include <sstream>
using namespace std;
int main()
{
unsigned long long Dec;
std::stringstream ss;
cout << "Number:";
while ( cin >> Dec )
{
while ( Dec > 0 )
{
ss << (Dec%2);
Dec /= 2;
}
std::string binary = ss.str();
reverse(binary.begin(), binary.end());
cout << "Binary: " << binary << endl;
cout << "New Number: ";
}
}
To Dave++:
<stdio.h> is a C header file. Usually one uses <cstdio>, which puts the functions in <stdio.h> into the namespace std. I see you've included <cmath> instead of <math.h>, but you're using just plain pow() and log() etc. Use either <math.h> and pow() or <cmath> and std::pow.
Also,
is the same asCode:str = str + "0";
which means, of course, that you can use either. But the latter requires less typing and is less error-prone.Code:str += "0";
DWKS, Raigne,
Thanks for the updates. I'll be using them.
Dave
a = a + b and a += b may be semantically equivalent, but they might very well differ in efficiency. Typically, += is considerably more efficient.
For appending a single character, an alternative would be:
Code:str.push_back('0');
You shouldn't return REFERENCES to local objects. Returning objects themselves is fine.Quote:
Originally Posted by MacGyver
You shouldn't return pointers to local objects, either. Returning objects by value is okay (assuming that the object has a proper copy constructor!) because the calling function gets a copy of the object.