3

I have more than one char arrays to copy into one string or void * or int *. For example,

char c1[] = "Hello";
char c2[] = "World";
char c3[] = "!!!!";

I want to copy into one int* (void*) or string.

cindywmiao
  • 937
  • 2
  • 11
  • 26
  • 4
    Can you please elaborate? Why do you want to copy strings into integers (the `int *`)? – Some programmer dude Nov 07 '14 at 15:47
  • As for [`std::string`](http://en.cppreference.com/w/cpp/string/basic_string), that's very simple if you just read a little. – Some programmer dude Nov 07 '14 at 15:48
  • here is how to copy it into string http://stackoverflow.com/questions/8960087/how-to-convert-a-char-array-to-a-string – neo Nov 07 '14 at 15:48
  • @JoachimPileborg Hello, I am a c++ beginner. I receive the message from one udp connection. They send me the byte[], I receive the char[]. I tried, if I print into int[], it will be correct. So I think is there someway copy char[] into int* directly without a loop. – cindywmiao Nov 07 '14 at 16:06

3 Answers3

2

In C++ you can simply use + operator to append strings

string a = "abc";
string b = "dfg";
string c = a + b;
cout << c << endl;
dynamic
  • 46,985
  • 55
  • 154
  • 231
1

This would be much easier using the std::string and std::stringstream namespace class of C++:

#include <sstream>
#include <string>

std::string c1("Hello");
std::string c2("World");
std::string c3("!!!!");

std::stringstream ss;
ss << c1 << c2 << c3;

std::string finalString = ss.str();

You cannot copy these into an int* or void* because those are completely different types.

Lawrence Aiello
  • 4,560
  • 5
  • 21
  • 35
  • Of course, there's no need for `stringstream` if you're just playing with strings, `c1 + c2 + c3` will do the job. Use a stream if you also want to format numbers, user-defined types, etc. – Mike Seymour Nov 07 '14 at 16:04
  • Thank you for point out I could not copy into void * or int *, it's helpful – cindywmiao Nov 07 '14 at 16:22
1

In my opinion the simplest way is the following

#include <iostream>
#include <string>
#include <cstring>

int main() 
{
    char c1[] = "Hello";
    char c2[] = "World";
    char c3[] = "!!!!"; 

    size_t n = 0;

    for ( char *t : { c1, c2, c3 } ) n += strlen( t );

    std::string s;
    s.reserve( n );

    for ( char *t : { c1, c2, c3 } ) s += t;

    std::cout << s << std::endl;


    return 0;
}

The output is

HelloWorld!!!!
Vlad from Moscow
  • 301,070
  • 26
  • 186
  • 335
  • 1
    That's hardly the simplest way. It might (or might not) be faster than `s = string(c1)+c2+c3`, but it's certainly not simpler. – Mike Seymour Nov 07 '14 at 16:06
  • @Mike Seymour It is a simple and very clear code. And moreover it is efficient enough. At least it is the best solution among suggested here. – Vlad from Moscow Nov 07 '14 at 16:15
  • OK, but you can remove half of it, leaving the rest unchanged, and have the same result (maybe more efficiently, maybe less). That would be unarguably simpler. There's no need to measure and reserve the size unless you've proven that that gives a necessary performance improvement. – Mike Seymour Nov 07 '14 at 16:21
  • @Mike Seymour No problem. If you are sure that reserving memory will not increase the efficiency you may remove the first half of the code:) – Vlad from Moscow Nov 07 '14 at 16:25
  • @Mike Seymour This approach is good because it is a general approach. For exanple instead of the initializer list there can be a vector or other container of strings or character arrays. – Vlad from Moscow Nov 07 '14 at 16:27
  • Indeed, the loop that actually does the work is nice and general, I'm not complaining about that. My point was that you can't claim this is the "simplest way" when half the code is unnecessary (except, perhaps, as an optimisation - if you've determined that it really is an optimisation (since calling `strlen` has a cost), and that it's worth sacrificing simplicity for). – Mike Seymour Nov 07 '14 at 16:45
  • @Mike Seymour However strlen has less cost than operator new with following coping of existent data. – Vlad from Moscow Nov 07 '14 at 16:53
  • Maybe, maybe not; you'd have to measure to be sure. But my point is that this isn't the **simplest** way, as you claim it is. It can be made considerably simpler without changing its result. Whether or not it's the most **efficient** way, and whether or not efficiency is worth the sacrifice of simplicity, doesn't change that fact. (Sorry to keep arguing, I seem to be having difficulty getting my point across.) – Mike Seymour Nov 07 '14 at 16:58