How to pass a vector of strings to execv

I have found that the easiest way to build my program argument list is as a vector of strings. However, execv expect开发者_Go百科s an array of chars for the second argument. What's the easiest way to get it to accept of vector of strings?

execv() accepts only an array of string pointers. There is no way to get it to accept anything else. It is a standard interface, callable from every hosted language, not just C++.

I have tested compiling this:

std::vector<string> vector;
const char *programname = "abc";

const char **argv = new const char* [vector.size()+2];   // extra room for program name and sentinel
argv [0] = programname;         // by convention, argv[0] is program name
for (int j = 0;  j < vector.size()+1;  ++j)     // copy args
        argv [j+1] = vector[j] .c_str();

argv [vector.size()+1] = NULL;  // end of arguments sentinel is NULL

execv (programname, (char **)argv);

The prototype for execv is:

int execv(const char *path, char *const argv[]);

That means the argument list is an array of pointers to null-terminated c strings.

You have vector<string>. Find out the size of that vector and make an array of pointers to char. Then loop through the vector and for each string in the vector set the corresponding element of the array to point to it.

I stumbled over the same problem a while ago.

I ended up building the argument list in a std::basic_string<char const*>. Then I called the c_str() method and did a const_cast<char* const*> on the result to obtain the list in a format that execv accepts.

For composed arguments, I newed strings (ordinary strings made of ordinary chars ;) ), took their c_str() and let them leak.

The const_cast is necessary to remove an additional const as the c_str() method of the given string type returns a char const* const* iirc. Typing this, I think I could have used std::basic_string<char*> but I guess I had a reason...

I am well aware that the const-casting and memory leaking looks a bit rude and is indeed bad practise, but since execv replaces the whole process it won't matter anyway.

Yes, it can be done pretty cleanly by taking advantage of the internal array that vectors use. Best to not use C++ strings in the vector, and const_cast string literals and string.c_str()'s to char*.

This will work, since the standard guarantees its elements are stored contiguously (see https://stackoverflow.com/a/2923290/383983)

#include <unistd.h>
#include <vector>

using std::vector;

int main() {
  vector<const char*> command;

  // do a push_back for the command, then each of the arguments
  command.push_back("echo");
  command.push_back("testing");
  command.push_back("1");
  command.push_back("2");
  command.push_back("3");

  // push NULL to the end of the vector (execvp expects NULL as last element)
  command.push_back(NULL);

  // pass the vector's internal array to execvp
  execvp(command[0], const_cast<char* const*>(command.data()));
  return 1;
}

Code adapted from: How to pass a vector to execvp

Do a const_cast to avoid the "deprecated conversion from string constant to 'char*'". String literals are implemented as const char* in C++. const_cast is the safest form of cast here, as it only removes the const and does not do any other funny business. execvp() will not edit the values anyway.

If you want to avoid all casts, you have to complicate this code by copying all the values to char* types not really worth it.

Although if the number of arguments you want to pass to execv/execl is known, it's easier to write this in C.

You can't change the how execv works (not easily anyway), but you could overload the function name with one that works the way you want it to:

int execv(const string& path, const vector<string>& argv) {
    vector<const char*> av;
    for (const string& a : argv) {
        av.push_back(a.c_str());
    av.push_back(0);
    return execv(path.c_str(), &av[0]);
}

Of course, this may cause some confusion. You would be better off giving it a name other than execv().

NB: I just typed this in off the top of my head. It may not work. It may not even compile ;-)