How make function that can take std::vector's of varying dimensions?

Quote:

---

Originally Posted by Daved

You listed several trivial issues, the first of which occurs in C as well so is moot

---

"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.

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.

Quote:

---

the second of which I agree with but will be fixed in the next standard

---

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:

---

(and is super trivial)

---

I guess it is once you've gotten used to it.

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 demonstrates that the writers decided to pick and choose which standard types can be combined with other standard types using the standard operators.
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.

Quote:

---

In addition, you complain about more trivial stuff like the extra effort needed to use some streams in unobvious ways

---

Printing them out and using them to format stuff. That's unobvious.

Quote:

---

, even though you have to jump through the same (or much more difficult) hoops with the printf style solution.

---

Once again, C++ gets a pass because C does the same thing.

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.

---

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:

---

(They are also often safer.)

---

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.
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]

Quote:

---

Originally Posted by cpjust

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!

---

---

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.

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.

Quote:

---

Originally Posted by zx-1

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).

---

Yes, and as we all know, all runtime errors are found during QA cycles and never by customers.

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.

Quote:

---

Originally Posted by zx-1

C++'s templates are such an unmitigated stream of crap

---

Well there goes any credibility you had.

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.

Quote:

---

Originally Posted by zx-1

Once again, C++ gets a pass because C does the same thing.

---

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:

---

C++'s templates are such an unmitigated stream of crap

---

And this is the part where I have to disagree.
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.

Quote:

---

Yes, it's stupid that std::string doesn't have tolower, toupper and no const char* operator,

---

No, it's not. The third is plain dangerous, and the other two are a big can of worms.

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++)?

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++)?

---

Actually, one of the design flaws of std::string is that it has too many member functions. Read: GotW #84: Monoliths "Unstrung".

So they say. I don't agree.

Quote:

---

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++.

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.

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!

---

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:

---

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.

---

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:

---

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.

---

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 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.

---

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.

Intriguing. I do see the points. I will have to reflect upon that and finds holes to punch through.

Quote:

---

Originally Posted by Elysia

Yes, it's stupid that std::string doesn't have tolower, toupper ...

---

There is a std::tolower function, and with a little work you can make it work with strings instead of characters. Here's mine.