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

This is a discussion on How make function that can take std::vector's of varying dimensions? within the C++ Programming forums, part of the General Programming Boards category; Originally Posted by Daved You listed several trivial issues, the first of which occurs in C as well so is ...

  1. #31
    Registered User
    Join Date
    Oct 2004
    Posts
    151
    Quote Originally Posted by Daved View Post
    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.

    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.

    (and is super trivial)
    I guess it is once you've gotten used to it.


    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.

    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.

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

    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.

    (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 View Post
    And do you really think using format specifiers with ellipsis are better?
    Code:
    printf( "&#37;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.
    Last edited by zx-1; 04-01-2008 at 09:55 PM.
    System: Debian Sid and FreeBSD 7.0. Both with GCC 4.3.

    Useful resources:
    comp.lang.c FAQ | C++ FQA Lite

  2. #32
    Registered User
    Join Date
    Jan 2005
    Posts
    7,317
    >> 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.
    Last edited by Daved; 04-01-2008 at 10:18 PM.

  3. #33
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    Quote Originally Posted by zx-1 View Post
    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.

  4. #34
    Banned
    Join Date
    Nov 2007
    Posts
    678
    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.

  5. #35
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,292

    Red face

    Quote Originally Posted by zx-1 View Post
    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.
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

  6. #36
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,420
    Quote Originally Posted by zx-1 View Post
    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.

    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 Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  7. #37
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    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.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  8. #38
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,420
    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 Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  9. #39
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,397
    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".
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  10. #40
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,420
    So they say. I don't agree.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  11. #41
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,397
    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
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  12. #42
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,420
    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.
    Last edited by Elysia; 04-02-2008 at 05:13 AM.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  13. #43
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,397
    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.

    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.

    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.

    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.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  14. #44
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,420
    Intriguing. I do see the points. I will have to reflect upon that and finds holes to punch through.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  15. #45
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    Quote Originally Posted by Elysia View Post
    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.
    Attached Files Attached Files

Page 3 of 4 FirstFirst 1234 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. In over my head
    By Shelnutt2 in forum C Programming
    Replies: 1
    Last Post: 07-08-2008, 06:54 PM
  2. Undefined Reference Compiling Error
    By AlakaAlaki in forum C++ Programming
    Replies: 1
    Last Post: 06-27-2008, 11:45 AM
  3. We Got _DEBUG Errors
    By Tonto in forum Windows Programming
    Replies: 5
    Last Post: 12-22-2006, 04:45 PM
  4. <Gulp>
    By kryptkat in forum Windows Programming
    Replies: 7
    Last Post: 01-14-2006, 12:03 PM
  5. C++ compilation issues
    By Rupan in forum C++ Programming
    Replies: 1
    Last Post: 08-22-2005, 05:45 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21