I want to make a function that takes std::vector as a parameter but without specifying the number of dimensions. Then it will check how many dimensions inside the function and use loops to get all the data out. How would i do this? Do I have to do something like:
Would that even work? is there a better way?Code:public void getData(std::vector *vec)
{
//do work here
}
A std::vector has no such thing as "dimensions." It is always one dimensional. Are you talking about vectors of vectors?
Whoops. Yep, sorry about the confusion. I mean I'd like to be able to do something like:Quote:
Originally Posted by brewbuck
(And this assumes that getData(...) can be used for ANYCode:
//We've got some variables
<std::vector<std::vector<int> > nums;
<std::vector<std::vector<std::vector<int> > > otherNums;
//Put them both into the function
getData( nums );
getData( otherNums );
depth of vectors of vectors, so no overloading of the function would solve it)
You can do that using function templates. Have you learned function templates?
No.Quote:
Originally Posted by CornedBee
EDIT: Oh, wait. I think you mean templates like:
Not sure if that totally solves the problem. Inside the function, how would the code loop through the vectors or vectors? How does it discover how many "levels" there are?Code:template <class T>
T DoSmth (T a, T b)
{
//do code here
}
int main ()
{
int i=5, j=6;
DoSmth<int>(i,j);
return 0;
}
Thanks!
Code:template <typename T>
void getData(const std::vector<T> &data)
{
// This is the final recursion. Do something with the data here.
}
template <typename T>
void getData(const std::vector< std::vector<T> > &data)
{
// This unwraps the vectors.
for(typename std::vector< std::vector<T> >::const_iterator it = data.begin();
it != data.end(); ++it)
{
getData(*it);
}
}
CornedBee, is there a reason for the non-const reference in the second version but the reference to const in the first? Why not make them all const or all not const?
Yeah, there is: confusion. :)
I'll edit the post.
I apologize for taking your time and really appreciate all your help. I'm a little confused.Quote:
Originally Posted by CornedBee
How would that work if it was passed a vector of a vector of a vector of some object? (In other words: <std::vector<std::vector<std::vector<int> > >) Or four levels deep, etc?
I want a function that can handle anywhere from 1..n levels of vectors without knowing beforehand. That's the code that confuses me a bit (I can write it in Java but am having trouble with C++, sorry).
The compiler tries to figure out which of the two should be used for std::vector<std::vector<std::vector<int> > >. It can either make T = std::vector<std::vector<int> > and use the first, or it can make T = std::vector<int> and use the second.
Apparently the rules require that it choose the second because the type used for the argument is closer to the actual parameter type of the second function.
From there, it calls getData for each element in the outer vector. This means a std::vector<std::vector<int> > is being passed to getData. Again, the compiler can choose between T = std::vector<int> (for the first one) or T = int (for the second one). Again, we are passing a std::vector<std::vector<T> > so that is a closer match, so the second version is used.
Each element of that vector is then sent to getData, but those would each have the type std::vector<int>. Since that type doesn't match the second function, the first function is used.
I haven't tried this, but I think it should work for n levels because for:Quote:
Originally Posted by 6tr6tr
T can be anything, including another const std::vector<T>, then that T could be another const std::vector...Code:const std::vector< const std::vector<T> >
When the loop calls getData() it calls the first version if it's the inner-most level, otherwise it calls itself.
HELP! I wrote the code you gave an it won't compile. For some reason it says that "GetData" has already been defined! Why won't it let me overload the function?Quote:
Originally Posted by CornedBee
What are you doing inside getData? If you're changing data you need to de-constify it. This simple example works for me since the data doesn't change:Code:#include <iostream>
#include <vector>
template <typename T>
void getData(const std::vector<T> &data)
{
for(typename std::vector<T>::const_iterator it = data.begin();
it != data.end(); ++it)
{
std::cout << (*it) << ' ';
}
std::cout << '\n';
}
template <typename T>
void getData(const std::vector< std::vector<T> > &data)
{
// This unwraps the vectors.
for(typename std::vector< std::vector<T> >::const_iterator it = data.begin();
it != data.end(); ++it)
{
getData(*it);
}
}
int main()
{
std::vector<std::vector<std::vector<int> > > threeD(2,
std::vector<std::vector<int> >(3,
std::vector<int>(4, 7)));
getData(threeD);
}
Really? it won't compile for me in MS Visual C++. It says:Quote:
Originally Posted by Daved
'error C2995' : 'GetData' : template function has already been defined.
EDIT: And when I compile your code, I get the same error! Help, why isn't this working?
Probably because the compiler sucks.Quote:
Originally Posted by 6tr6tr
I compiled with MS Visual C++ also. I used version 7.1 (.NET 2003). Are you using version 6.0? That's about 10 years old, can you upgrade to a newer version?
Yeah, it appears it's a Visual C++ 6 problem (that was fixed in 7 which I don't have) Any ideas for a good compiler for windows?Quote:
Originally Posted by brewbuck
Visual C++.
Just upgrade. There is an express version of 2005 or 2008 that is free if you don't want to or can't pay for the full version.
Thanks, I'll use the express version if it can actually compile and run programs/dlls. Any idea of what the restrictions are?Quote:
Originally Posted by Daved
I think it doesn't include MFC, but there aren't many restrictions on C++ code. They use the full optimizing compiler and you're allowed to use them on commercial applications.
Thanks. I actually installed MinGW (which uses GNU's compiler, gcc and g++) because I had to install the entire Visual Studio Express if I want MS.Quote:
Originally Posted by Daved
But now I get another problem. If I use printf( *it ); instead of std::cout it throws an exception:
no matching function for call to 'printf(std::basic_string....' (rest elided).
Any idea why and how I get around this?
Quote:
Originally Posted by 6tr6tr
Or in most cases:Code:printf( it->c_str() )
Code:printf( "%s", it->c_str() )
Shouldn't the inner vector be const also?Code:void getData(const std::vector< std::vector<T> > &data)
Why would you want to use printf() in a C++ program?Quote:
But now I get another problem. If I use printf( *it ); instead of std::cout it throws an exception:
No, that's not how vector works.Quote:
Originally Posted by cpjust
Indeed. I have to second this notion.Quote:
Why would you want to use printf() in a C++ program?
I'd want to use it because iostream provides no genuine advantages over stdio, and several disadvantages.Quote:
Originally Posted by CornedBee
Err ... iostream works with std::string. I call that an advantage.
More importantly, it works with generic code in general.
>> Err ... iostream works with std::string
And any other streamable class, many of which do not have c_str() style functions for easy workarounds.
Sure, but it works pretty sloppily.Quote:
Originally Posted by CornedBee
- Try getting a line of input from cin. As we all know from C, scanf() is error-prone and we should be getting whole lines with fgets() and parsing that. So dont use std::cin >> str (it'll trip up if there are any spaces anyway) but std::cin.getline(arr, len) or std::cin.get(arr, len). Mind you, those input to char arrays. If you want std::string you need the obvious std::getline(std::cin, str, len).
- The "new and improved" way to open files is to use ifstream and ofstream. Strangely, to tell them the name of the file -- a particularly stringy kind of thing -- you have to give them an "old and evil" array of char. But anyways, just use std::ofstream logfile(filename)... oh, snap, std::string doesn't define operator const char* so make that std::ofstream logfile(filename.c_str()). Fortunately you wouldn't want to put that file anywhere in particular, otherwise you'd have to pile on the ugly with std::ofstream logfile((dir + "/" + filename).c_str()). And if dir is a C-string... well now we're getting into the deficiencies of other classes, so enough of that.
- Nevertheless iostream works with std::string a lot better than some other classes, like std::map.
Mind you, how much can you expect a foreign class to operate with iostream, when iostream's classes can't even interoperate with themselves. Maybe you have a std::ostringstream you'd like to print out (gotta do something with those). You'll likely try cout << oss which is wrong, you need cout << oss.str(). Neither can you cin to an istringstream. Once again, you need an extraneous std::string object (and God forbid your ostringstream holds a filename to open... good thing you can chain method calls: std::ofstream outfile(oss.str().c_str()).
You listed several trivial issues, the first of which occurs in C as well so is moot, the second of which I agree with but will be fixed in the next standard (and is super trivial), and the third of which doesn't make sense (are you saying streams are worse than printf because they only work with string?).
In addition, you complain about more trivial stuff like the extra effort needed to use some streams in unobvious ways, even though you have to jump through the same (or much more difficult) hoops with the printf style solution.
And yet, you failed to address the reason given for streams being better than C style i/o, which is that they work much better with generic code. (They are also often safer.)
If you are uncomfortable with the look and feel of streams, fine, but your original assertion was wrong.
And do you really think using format specifiers with ellipsis are better?
Code:printf( "%s blah blah %d, %2.3f blah", str, num ); // Oops, forgot the 3rd arg, boom!
"It occurs in C as well so it's moot?" Isn't C++ is supposed to be an improvement over C? Surely there was a point to duplicating the C library functionality beyond keeping the status quo. I'm sure we can hold it to a higher standard than that.Quote:
Originally Posted by Daved
And furthermore this was in response to iostream working with std::string. The gist of it being, it's incomplete, non-orthogonal, and non-obvious in many areas.
Well, we all know how timely and completely compiler vendors are with respect to implementing the C++ standard. And the standard actually has to be published first, so that doesn't change the situation now or in the past.Quote:
the second of which I agree with but will be fixed in the next standard
I guess it is once you've gotten used to it.Quote:
(and is super trivial)
It demonstrates that the writers decided to pick and choose which standard types can be combined with other standard types using the standard operators.Quote:
and the third of which doesn't make sense (are you saying streams are worse than printf because they only work with string?).
It's all right though, since you can create a template operator<< to print out all the maps and vectors and such like as you want. And so can I. But let's not try and integrate our code into one program afterwards.
Printing them out and using them to format stuff. That's unobvious.Quote:
In addition, you complain about more trivial stuff like the extra effort needed to use some streams in unobvious ways
Once again, C++ gets a pass because C does the same thing.Quote:
, even though you have to jump through the same (or much more difficult) hoops with the printf style solution.
C++'s templates are such an unmitigated stream of crap, that it's really irrelevant how well this part of the language works with them compared to that one. And if you're talking about how you can say cout << my_imaginary_number_instance, why can't you write a function that takes a pointer to your object and uses printf.Quote:
And yet, you failed to address the reason given for streams being better than C style i/o, which is that they work much better with generic code.
They're safer. Who cares. First of all, type safety isn't going to give you any performance benefits since I/O tends to be bound by... I/O.Quote:
(They are also often safer.)
And secondly, am I to believe that the compiler will help catch errors? Well why don't you try diagnosing a run-time printf() error, versus a compile-time iostream error (and all the hundreds of overloaded << operators the compiler will spew out).[/quote]
Hahahaha. Okay, you've convinced me. I'll just go out and change all my "evil printf("0x%08x\n", x)" to the equivalent "std::cout << std::hex << std::setfill('0') << std::setw(8) << x << std::dec << std::endl." I think I can almost see the variable I'm trying to print. (and I sure hope cout was in decimal mode before that). Domain-specific languages FTL.Quote:
Originally Posted by cpjust
Also, you might try some translation of your program's messages into another language sometime, particularly one that differs in its SVO order. Pretty easy to change a format string with an external tool[1], not so easy to reorder the linguistic puzzle.
If you would like more information, refer to the C++ FQA Lite and the section "Input/output via <iostream> and <cstdio>"
[1]In fact, that's how Qt, a C++ toolkit, approaches this. And word is there is something similar available if you want to "boost" your programs.
>> Isn't C++ is supposed to be an improvement over C?
You're changing the argument. If neither is better than the other in a specific context, then that is irrelevant to whether your original statement is correct.
>> Once again, C++ gets a pass because C does the same thing.
Yes, because you argued that iostream has no genuine advantages over stdio and has some disadvantages, so only differences are relevant.
>> C++'s templates are such an unmitigated stream of crap, that it's really irrelevant how well
>> this part of the language works with them compared to that one.
Well, that's your opinion. However, many C++ programmers disagree and this very thread (assuming the side discussion isn't separated to its own thread) is discussing a templated solution. If you had said "iostream provides no genuine advantages over stdio in my limited use of C++" that might have been more accurate.
>> They're safer. Who cares.
That would be a genuine advantage.
>> If you would like more information, refer to the C++ FQA Lite and the section "Input/output via <iostream> and <cstdio>"
Thanks for acknowledging the error in your original statement.
Here's that link for others: http://www.parashift.com/c++-faq-lite/input-output.html
BTW, the FQA Lite you referred to has the same illogical arguments as you do.
Yes, and as we all know, all runtime errors are found during QA cycles and never by customers.Quote:
Originally Posted by zx-1
actually the problem is that i always feel that there is something lacking in std implementations of c++.
c++ can make life so easy if used properly. but the stuff does not exist in std namespace.
i use Qt. and it has all std stuff plus a whole lot more. and c++ really shines here.
Well there goes any credibility you had.Quote:
Originally Posted by zx-1
Did you really need to start a programming language flame-war?
There are many people here who know both languages better than you do. You should be getting a feeling for this by the number of people agreeing with you. In case you hadn't noticed, that number is zero.
Now it's about time to make peace, move on, and actually learn something.
I think the idea here is, if C++ is the same as C, why use C? It's at least more type safe, which is a good thing.Quote:
Originally Posted by zx-1
And this is the part where I have to disagree.Quote:
C++'s templates are such an unmitigated stream of crap
Templates are very nice additions to C++. I wish, in fact, they were a little more powerful.
If the compiler complains a thousand lines of errors because it can't call a proper templated function, well, that's the compiler's fault, not the language's.
I agree with you that the standards library and some other things like cout/cin are retarded. It's a pain to output formatted text and the documentation is of no help (it took me ages to find the flags I needed to set to properly format the output, while for sprintf, it's non-trivial).
Yes, it's stupid that std::string doesn't have tolower, toupper and no const char* operator, but unfortunately, I can't change that...
Doesn't make C++ bad, though.
No, it's not. The third is plain dangerous, and the other two are a big can of worms.Quote:
Yes, it's stupid that std::string doesn't have tolower, toupper and no const char* operator,
This is my opinion. It's one of the little things I hate about the standard library. std::string is supposed to be a string, yet does not have tolower/toupper? OK, are we back to the C days now where every function lay in the global namespace (or in the std namespace for C++)?
Actually, one of the design flaws of std::string is that it has too many member functions. Read: GotW #84: Monoliths "Unstrung".Quote:
It's one of the little things I hate about the standard library. std::string is supposed to be a string, yet does not have tolower/toupper? OK, are we back to the C days now where every function lay in the global namespace (or in the std namespace for C++)?
So they say. I don't agree.
Then write a critique of GotW #84 and publish it. If you can definitively show that Meyers, Sutter and Stroustrup are wrong, you will immediately find yourself counted as an expert in C++.Quote:
So they say. I don't agree.
Meyers:
How Non-Member Functions Improve Encapsulation
Minimal and Complete Interfaces
Stroustrup:
Designing Simple Interfaces
Having read those, I still don't agree.
The first is kind of confusing. Why the heck does Nap, for example, need to be a non-member that introduced syntax inconsistencies? It can just as well be a member function!
Sure, classes grow big and can be hard to maintain. But who's going to maintain those non-member functions? Classes can still be maintained by several people.
And if a change makes those 60 member functions go awry, then what's to say those non-members won't be the same? If they do work even with those internal changes, then so too, can the member functions, if designed correctly.
And if you stop deriving classes and implement everything into the base class, you won't get the "can't use function X with object Y" that Bjorne describes.
It cannot be a member function since the assumption is that you are not the author of Wombat, i.e., you cannot change the class itself.Quote:
Why the heck does Nap, for example, need to be a non-member that introduced syntax inconsistencies? It can just as well be a member function!
The point is not to reduce the number of developers, but to separate the core interface from a secondary interface. In fact, doing so allows for a larger development team, since those who develop the secondary interface are insulated from changes to the implementation of the class since they can only use the public interface of the class. This is what Meyers means by increasing encapsulation by preferring non-member non-friends.Quote:
Sure, classes grow big and can be hard to maintain. But who's going to maintain those non-member functions? Classes can still be maintained by several people.
Of course the non-members (assuming they are not friends) will not be affected by a change in the data layout since they never access the data directly. If they are affected, then it is because of a bug in a member function, in which case fixing the member function will also fix them.Quote:
And if a change makes those 60 member functions go awry, then what's to say those non-members won't be the same? If they do work even with those internal chances, then so too, can the member functions, if designed correctly.
That is a non-solution since you cannot provide a member function to solve every conceivable problem, unless your class is intentionally designed such that it cannot be reused.Quote:
And if you stop deriving classes and implement everything into the base class, you won't get the "can't use function X with object Y" that Bjorne describes.
Intriguing. I do see the points. I will have to reflect upon that and finds holes to punch through.
There is a std::tolower function, and with a little work you can make it work with strings instead of characters. Here's mine.Quote:
Originally Posted by Elysia
I imagine, but I want it to be part of std::string, not std. It's a string, so string manipulation routines should be in std::string.
But the problem is, of course, the encapsulation issue. And the maintenance issue.
Besides, I generally use MFC's CString because it's more to my liking, so it's not that bothersome.