Preferred conversion from char (not char*) to std::string

I have a char, a plain old character, that I would like to turn into an std::string. std::string(char) doesn't exist of course. I could create a char array and copy it in, I could go through string streams, or many other little roundabout routes. Currently, I prefer boost::lexical_cast, but even that seems too verbose for this simple task. So what's the preferred way?

std::string has a constructor that takes a number and a character. The character will repeat for the given number of times. Thus, you should use:

std::string str(1, ch);

To add to the answer, you can simply use initializer list

std::string str = {ch};

just use the overload that takes a char?

i.e. string(1, 'A')

You still can use the string constructor taking two iterators:

char c = 'x';
std::string(&c, &c + 1);

Update:

Good question James and GMan. Just searched freely downloadable "The New C Standard" by Derek M. Jones for "pointer past" and my first hit was:

> If the expression P points to an > element of an array object and the > expression Q points to the last > element of the same array object, the > pointer expression Q+1 compares > greater than P... even though Q+1 does > not point to an element of the array > object... > > On segmented architectures > incrementing a pointer past the end of > a segment causes the address to wrap > segmented architecture around to the > beginning of that segment (usually > address zero). If an array is > allocated within such a segment, > either the implementation must ensure > that there is room after the array for > there to be a one past the end > address, or it uses some other > implementation technique to handle > this case (e.g., if the segment used > is part of a pointer’s representation, > a special one past the end segment > value might be assigned)... > > The C relational operator model enables > pointers to objects to be treated in > the same way as indexes into array > objects. Relational comparisons > between indexes into two different > array objects (that are not both > subobjects of a larger object) rarely > have any meaning and the standard does > not define such support for pointers. > Some applications do need to make use > of information on the relative > locations of different objects in > storage. However, this usage was not > considered to be of sufficient general > utility for the Committee to specify a > model defining the behavior... > > Most implementations perform no checks > prior to any operation on values > having pointer type. Most processors > use the same instructions for > performing relational comparisons > involving pointer types as they use > for arithmetic types. For processors > that use a segmented memory > architecture, a pointer value is often > represented using two components, a > segment number and an offset within > that segment. A consequence of this > representation is that there are many > benefits in allocating storage for > objects such that it fits within a > single segment (i.e., storage for an > object does not span a segment > boundary). One benefit is an > optimization involving the generated > machine code for some of the > relational operators, which only needs > to check the segment offset component. > This can lead to the situation where > p >= q is false but p > q is true, > when p and q point to different objects.

This works on gcc C++ 4.9.2 (http://ideone.com/f3qhTe)

#include <iostream>
using namespace std;

int main() {
	// your code goes here
	std::string test;
	
	test = (char) 76;
	test += (char) 77;
	test += (char) 78;
	test += (char) 79;
	
	std::cout << "test contains: " << test << std::endl;
	return 0;
}