Multiple types in lists, vectors or arrays.

I learnt to program in python and php, so i'm used to having dynamic and associative lists (php's array, and pythons dictionary). As c++ requires you define the type of each variable, and define the type used when initialising a vector or list, I have been unable to find something which could emulate what I used in php & python.

Is there something within the standard library which allows this kind of data structure? Or is this a drawback I have to work around when coding in c++?

You need a list that can keep any kind of element right?
Like:
char-char-string-int-int-bool

I think you could consider boost::any. That said, C++ is indeed different from PHP and Python, so are you sure you really need such containers in the first place?

You shouldn't change C++, you should change the way you think. While variant types are possible (Boost.Any, Boost.Variant), they're very rarely used - I've never used Variant, although I'm always on the lookout for a chance. But every time, some other option that does not risk type safety comes up as the better choice.

Type safety is not a drawback. It's an advantage.

I'll have a look at boost::any although I was hoping it was possible within the standard library.

The reason I need this is that i'm building an xmlrpc client to communicate with a server. I want a dynamic function that can handle all types which may be sent over the xmlrpc protocol (int, bool, string & array). It must also be able to accept any number of arguments (as different calls require different numbers of arguments). If I was using php or python I would simply pass an array or list of all the arguments to the send function and iterate over them.

There is probably something in c++ which would allow me to do this, preferably within the standard library. However i'm new to c++ and unaware of most of its features.

If I rememebr correctly, boodt::variant is more appropriate for when you know ahead of time which datatypes are allowed. I believe boost::any is better for when it truly coul dbe any datatype.

I found this example of boost variant in a standard C++ container, it might help give you an idea of how to do it:

Code:

---

#pragma warning(disable: 4512)

#include <iostream>
#include <deque>
#include <string>
#include <algorithm>
#include <boost/variant.hpp>


typedef std::deque<boost::variant<double, std::string> > data_row;
typedef std::deque<data_row> data_grid;
void OutputGrid(const data_grid& the_grid);

class column_sorter
{
public:
    column_sorter(data_row::size_type column) : column_(column) { }
    bool operator()(const data_row& left, const data_row& right)
    {
        return left[column_] < right[column_];
    }
private:
    data_row::size_type column_;
};

int main()
{
    // start with 3 empty rows
    data_grid the_grid(3);

    // Fill those rows with two columns, int and string.
    the_grid[0].push_back(37);
    the_grid[0].push_back(std::string("thirty-seven"));
    the_grid[1].push_back(-1);
    the_grid[1].push_back(std::string("negative one"));
    the_grid[2].push_back(88);
    the_grid[2].push_back(std::string("eighty-eight"));

    OutputGrid(the_grid);

    // Add two rows with equal string values.
    data_row new_row;
    new_row.push_back(74);
    new_row.push_back(std::string("seventy-four"));
    the_grid.push_back(new_row);
    new_row[0] = 73;
    the_grid.push_back(new_row);

    // Insert a row.
    new_row[0] = -2;
    new_row[1] = std::string("negative two");
    the_grid.insert(the_grid.begin() + 2, new_row);

    OutputGrid(the_grid);

    // Sort by the second column.
    std::stable_sort(the_grid.begin(), the_grid.end(), column_sorter(1));

    OutputGrid(the_grid);

    // Sort by the first column.
    std::stable_sort(the_grid.begin(), the_grid.end(), column_sorter(0));

    OutputGrid(the_grid);

    // Sort by the second column again (notice the 73 and 74 remained the same).
    std::stable_sort(the_grid.begin(), the_grid.end(), column_sorter(1));

    OutputGrid(the_grid);

    std::cin.get();
}

void OutputGrid(const data_grid& the_grid)
{
    for (data_grid::const_iterator cur_row = the_grid.begin(),
        end_row = the_grid.end();
        cur_row != end_row; ++cur_row)
    {
        for (data_row::const_iterator cur_val = cur_row->begin(),
            end_val = cur_row->end();
            cur_val != end_val; ++cur_val)
        {
            if (cur_val != cur_row->begin())
                std::cout << ", ";
            std::cout << *cur_val;
        }
        std::cout << std::endl;
    }
    std::cout << "\n----------------\n" << std::endl;
}

---

Hmm ... still not a good idea, I think. XML-RPC follows a pre-defined schema. In other words, it should be possible to know, at the time of writing the code, what types are expected. You would typically write a tool that generates a wrapper class for the web service. This class then presents a fully type-safe interface to the outside.
The core library, on the other hand, has no need for variants either: it has to convert the values it gets passed in to XML at some point, so why not do it the moment you get the value? This way, you just have a setParameter template (or overloaded) function which takes any datatype, converts it to its wire representation, and stores the resulting string in a homogeneous string container. For the response, you again store the XML representation, until the library user queries the value. Then you require him to specify the suspected type, and try to convert the representation you have into that type. On failing, you could throw an exception, or return an empty Boost.Optional.

The point is this: at some point, the type decision has to be made, and using variants or any only delays it, transfers it from the interface of the library to the user code, where it does not belong.

Quote:

---

Originally Posted by CornedBee

Hmm ... still not a good idea, I think. XML-RPC follows a pre-defined schema. In other words, it should be possible to know, at the time of writing the code, what types are expected. You would typically write a tool that generates a wrapper class for the web service. This class then presents a fully type-safe interface to the outside.
The core library, on the other hand, has no need for variants either: it has to convert the values it gets passed in to XML at some point, so why not do it the moment you get the value? This way, you just have a setParameter template (or overloaded) function which takes any datatype, converts it to its wire representation, and stores the resulting string in a homogeneous string container. For the response, you again store the XML representation, until the library user queries the value. Then you require him to specify the suspected type, and try to convert the representation you have into that type. On failing, you could throw an exception, or return an empty Boost.Optional.

The point is this: at some point, the type decision has to be made, and using variants or any only delays it, transfers it from the interface of the library to the user code, where it does not belong.

---

I've just read up on overloaded template functions and I think i'll do it this way. The only problem is I need a way to tell what type i'm handling when the the argument is processed, so it can be passed to the right function for serialization into an xml-useable string.

Just to clarify, would the following code give me what i'm after (the server could take up to 5 params of different types per call)..

Code:

---

template <typename T1>
string sendCall(T1 param1) {
//code which checks param types and processes to xml string..
}

template <typename T1, typename T2>
string sendCall(T1 param1, T2 param2) {
//code which checks param types and processes to xml string..
}

template <typename T1, typename T2, typename T3>
string sendCall(T1 param1, T2 param2, T3 param3) {
//code which checks param types and processes to xml string..
}

template <typename T1, typename T2, typename T3, typename T4>
string sendCall(T1 param1, T2 param2, T3 param3, T4 param4) {
//code which checks param types and processes to xml string..
}

template <typename T1, typename T2, typename T3, typename T4, typename T5>
string sendCall(T1 param1, T2 param2, T3 param3, T4 param4, T5 param5) {
//code which checks param types and processes to xml string..
}

---

Yes, it would work, but . . . why don't you use default template arguments?

Code:

---

template <typename T1, typename T2 = T1, typename T3 = T2, typename T4 = T3, typename T5 = T4>
string sendCall(T1 param1, T2 param2, T3 param3, T4 param4, T5 param5) {
//code which checks param types and processes to xml string..
}

---

or

Code:

---

template <typename T1, typename T2 = int, typename T3 = int, typename T4 = int, typename T5 = int>
string sendCall(T1 param1, T2 param2, T3 param3, T4 param4, T5 param5) {
//code which checks param types and processes to xml string..
}

---

Quote:

---

Originally Posted by dwks

Yes, it would work, but . . . why don't you use default template arguments?

Code:

---

template <typename T1, typename T2 = T1, typename T3 = T2, typename T4 = T3, typename T5 = T4>
string sendCall(T1 param1, T2 param2, T3 param3, T4 param4, T5 param5) {
//code which checks param types and processes to xml string..
}

---

or

Code:

---

template <typename T1, typename T2 = int, typename T3 = int, typename T4 = int, typename T5 = int>
string sendCall(T1 param1, T2 param2, T3 param3, T4 param4, T5 param5) {
//code which checks param types and processes to xml string..
}

---

---

Because there are many possible combinations of types used and the order they will be in (the order is important). So i'm not sure what your code does but if it does the same thing then I may use it. Also, is there a way of just writing one function with 5 param's, 4 of which are non-essential and can be NULL when the function is called? Maintaining 5 seperate functions which essentially do the same thing could get tiresome (and buggy).

Yes, that's what default arguments are for. If you leave out that particular parameter to the function, it gets a default value.

Code:

---

int add(int x, int y = 0) {
    return x + y;
}

add(5,6);
add(5); /* same as above */

---

The same applies for templates, except instead of default values you use default types.

Code:

---

template <typename T = char>
size_t size(T x) {
    return sizeof(x);
}

size<int>();
size(); /* same as size<char>(); */

---

Quote:

---

Originally Posted by dwks

Yes, that's what default arguments are for. If you leave out that particular parameter to the function, it gets a default value.

Code:

---

int add(int x, int y = 0) {
    return x + y;
}

add(5,6);
add(5); /* same as above */

---

The same applies for templates, except instead of default values you use default types.

Code:

---

template <typename T = char>
size_t size(T x) {
    return sizeof(x);
}

size<int>();
size(); /* same as size<char>(); */

---

---

Ah, that helps a lot. Thanks! :)

EDIT: How do I check if the parameter has been left out. Say if I use the int method, what if an int value is passed to that param. If it is an un-used param i'm guessing it defaults to 0. What if I want to pass an int of value 0?

EDIT2: When I try to compile I get the following...

Code:

---

error: default template arguments may not be used in function templates

---

Quote:

---

EDIT: How do I check if the parameter has been left out. Say if I use the int method, what if an int value is passed to that param. If it is an un-used param i'm guessing it defaults to 0. What if I want to pass an int of value 0?

---

No, it wouldn't have a default value of 0 or anything else, just a default type. To put a default value in, add default values to the function.

The idea is that you don't need to check if a parameter has been left out. (If you do need to, you use overloading.) It's like getline(); the default separator is '\n'. It doesn't need to know whether you actually passed '\n' or if the '\n' comes from the default value.

Quote:

---

EDIT2: When I try to compile I get the following...

Code:

---

error: default template arguments may not be used in function templates

---

---

Hmm, maybe you can only use them in classes. Sorry, I guess that won't work.

Indeed that won't work.

And no, I didn't mean it that way. I meant a core engine that looks like this:

Code:

---

Call Rpc::createCall(string functionName);
template<typename T> void Call::setArgument(string argName /*or perhaps an index */, T argValue);
void Call::submit();

---

Calling is rather complicated, but allows for ANY number of arguments. (Your engine won't be generic if it doesn't do that.)

Code:

---

Call call = rpc.createCall("greetWorld");
call.setArgument("myname", "CornedBee");
call.setArgument("times", 10);
call.submit();

---

The ease-of-use would come from a tool similar to Axis' wsdl2java that takes a WSDL file and generates a C++ wrapper class from it.

You should definitely create some wrapper classes that can handle these objects. Derive them from a common base and place common operations that both objects do in the base. Then you can get more specific in the derived classes.

With this method of using a common base you can then declare an STL container of the base type and yet be able to add both objects since they are derived from the base. This also is a type-safe implementation of doing exactly what you need.

I would not use variant or any b/c although the functionality is there it cannot be completely safe no matter who wrote it. In essence, C++ provides a much better answer to the problem.

Quote:

---

Originally Posted by CornedBee

Indeed that won't work.

And no, I didn't mean it that way. I meant a core engine that looks like this:

Code:

---

Call Rpc::createCall(string functionName);
template<typename T> void Call::setArgument(string argName /*or perhaps an index */, T argValue);
void Call::submit();

---

Calling is rather complicated, but allows for ANY number of arguments. (Your engine won't be generic if it doesn't do that.)

Code:

---

Call call = rpc.createCall("greetWorld");
call.setArgument("myname", "CornedBee");
call.setArgument("times", 10);
call.submit();

---

The ease-of-use would come from a tool similar to Axis' wsdl2java that takes a WSDL file and generates a C++ wrapper class from it.

---

This is a nice solution. However I will probably stick to the template function. The engine doesnt need to be entirely generic as I know exactly what kind of calls I can expect. It is not designed to be a replacement for existing xmlrpc libraries out there, but an engine that my main program will run on. I am basically porting the program from python so I know what the xmlrpc 'engine' can expect.

Thanks for the help :)

Okay, i've tried writing a function template to take arguments of varying numbers and types. It didnt go so well. Here is what it looks like..

Code:

---

std::string XmlGbx::parseString(std::string pstr){
    std::string outstr = "<value><string>";
    outstr = outstr + pstr;
    outstr = outstr + "</string></value>\n";
    return outstr;
}

std::string XmlGbx::parseInt(int pint) {
    std::string istr = intostr(pint);
    std::string outstr = "<value><i4>";
    outstr = outstr + istr;
    outstr = outstr + "</i4></value>\n";
    return outstr;
}

std::string XmlGbx::parseBool(bool pbool) {
    std::string outstr = "<value><boolean>";
    if (pbool == true) {
      outstr = outstr + "true";
    } else {
      outstr = outstr + "false";
    }
    outstr = outstr + "</boolean></value>\n";
    return outstr;
}
   

template <typename P>
std::string XmlGbx::parseParam(P param) {
    if (typeid(param).name == "int"){
        return parseInt(param);
    }
    if (typeid(param).name == "string"){
      return parseString(param);
    }
    if (typeid(param).name == "bool") {
      return parseBool(param);
    }
    std::cout << "could not match type" << std::endl;
    return "failed";
}
     

std::string XmlGbx::endCall(){
    std::string eCall = eCall + "</params>";
    eCall = eCall + "</methodCall>";
    return eCall;
}
   

template <typename T1, typename T2, typename T3, typename T4, typename T5>
std::string XmlGbx::sendCall(std::string meName,T1 param1, T2 param2, T3 param3, T4 param4, T5 param5) {
      //build first part of call..
      std::string call = "<?xml version=\"1.0\" ?>\n";
      call = call + "<methodCall>\n";
      call = call + "<methodName>" + meName + "</methodName>\n";
      call = call + "<params>\n";
      if (param1 == "£$"){
          call = call + this->endCall();
          //int handle = this->SockW.sendout(call);
          return call;
      } else {
          call = call + parseParam(param1);
      }
      if (param2 == "£$"){
          call = call + this->endCall();
          //int handle = this->SockW.sendout(call);
          return call;
      } else {
          call = call + parseParam(param2);
      }
      if (param3 == "£$"){
          call = call + this->endCall();
          //int handle = this->SockW.sendout(call);
          return call;
      } else {
          call = call + parseParam(param3);
      }
      if (param4 == "£$"){
          call = call + this->endCall();
          //int handle = this->SockW.sendout(call);
          return call;
      } else {
          call = call + parseParam(param4);
      }
      if (param5 == "£$"){
          call = call + this->endCall();
          //int handle = this->SockW.sendout(call);
          return call;
      } else {
          call = call + parseParam(param5);
          call = call + this->endCall();
          //int handle = this->SockW.sendout(call);
          return call;
      }
      return call;
}

---

Unfortunately the compiler doesnt like me using typeid on a variable cast as a template. It gives me the following error..

Code:

---

64 C:\xmlgbx\gbx\gbxlib.cpp insufficient contextual information to determine type

---

I have decided a cleaner solution would be the following suggested by CornedBee...

Code:

---

Call call = rpc.createCall("greetWorld");
call.setArgument("myname", "CornedBee");
call.setArgument("times", 10);
call.submit();

---

...however the setArgument method will still need to know what type it is processing so it can be properly converted to an xml string. How exactly can I figure out the type that is passed at run-time?

Quote:

---

Originally Posted by Bubba

You should definitely create some wrapper classes that can handle these objects. Derive them from a common base and place common operations that both objects do in the base. Then you can get more specific in the derived classes.

With this method of using a common base you can then declare an STL container of the base type and yet be able to add both objects since they are derived from the base. This also is a type-safe implementation of doing exactly what you need.

I would not use variant or any b/c although the functionality is there it cannot be completely safe no matter who wrote it. In essence, C++ provides a much better answer to the problem.

---

I like this idea, however it would mean a lot of work initialising a class for each argument and then initialising a container, then adding each one to the container. Since a lot of these calls will be needed in the final app, I want things to be as un-cluttered as possible. I should probably re-phrase my orginal question to "How do I pass multiple arguments of different types to a single class or function and then process accordingly?"

>> however the setArgument method will still need to know what type it is processing so it can be properly converted to an xml string. How exactly can I figure out the type that is passed at run-time?

Have different setArgument overloads, one for each type?

Quote:

---

Originally Posted by Daved

>> however the setArgument method will still need to know what type it is processing so it can be properly converted to an xml string. How exactly can I figure out the type that is passed at run-time?

Have different setArgument overloads, one for each type?

---

Just found out what that means. Good idea thanks - sorry i'm a newbie to this ;)

You figure it out at compile time, not run time.

Quote:

---

Originally Posted by CornedBee

You figure it out at compile time, not run time.

---

Yeah its a tricky concept to grasp after coding scripted languages for all this time. I'm starting to get the hang of it now however ;)