Though implementation problem

This is a discussion on Though implementation problem within the C++ Programming forums, part of the General Programming Boards category; Originally Posted by laserlight It would be better to state your reasoning than to state your support since this is ...

  1. #91
    Banned
    Join Date
    Nov 2007
    Posts
    678
    Quote Originally Posted by laserlight View Post
    It would be better to state your reasoning than to state your support since this is not a popularity contest.
    I find it way more convenient and logical also, besides, there are generic solutions available for me, i can always use the *g-e-n-e-r-i-c* if, else, while, for . . .

    Of course they are not always possible, or at least not possible while remaining efficient. I cited the case of std::sort versus std::list::sort as an example. As such, so what if they are not always possible within the given constraints?
    See i am not against for_each, but you may not realize, since you seem so used to it, (honestly i am very impressed by your C++ knowledge), but although, for_each seems so easy, but to run it you need to know a dozens of background details, which you will forget almost after you have used it, it happens to me

    for_each is not part of the C++ core language but it is part of the C++ standard library. The only benefit of for_each is in abstracting away the loop - if feasible the more appropriate generic algorithms should be used to better describe what is happening.
    The more understandable would be this, and not your silly for_each:
    Code:
    processLedgerEntries(ledgerEntries);

  2. #92
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,794
    I find it way more convenient and logical also, besides, there are generic solutions available for me, i can always use the *g-e-n-e-r-i-c* if, else, while, for . . .
    Note that part of the argument involves member functions versus non-member non-friend functions. I suggest that you read:
    Designing Simple Interfaces

    See i am not against for_each, but you may not realize, since you seem so used to it
    Actually, I have almost never actually used for_each. It is simply not descriptive enough in my opinion, and thus not worth the effort of also having an appropriate function object. Consequently, I either find a better generic algorithm to use, or use a loop instead.

    The more understandable would be this, and not your silly for_each:
    That's fine. processLedgerEntries() might be implemented using a generic algorithm. Read Elysia's statement again:
    Quote Originally Posted by Elysia
    The good thing is that we can write user-friendly interface functions to those generic functions. This allows for easy programming (though it may take a bit extra work to write those, but I'm fine with that) and if those functions does not do the trick, you can implement another function from the generic algorithm.
    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

  3. #93
    Banned
    Join Date
    Nov 2007
    Posts
    678
    Quote Originally Posted by Elysia View Post
    I'm going to have to side with everyone else here. The main reason I have this class and indeed, all my functions and libraries in general is due to code use.
    No doubt, that is why you are a C++ programmer! =_=

    The more generic functions I can write, the better because it means less code to rewrite. The good thing is that we can write user-friendly interface functions to those generic functions. This allows for easy programming (though it may take a bit extra work to write those, but I'm fine with that) and if those functions does not do the trick, you can implement another function from the generic algorithm.
    I just hope you are right, good luck

    It's also good learning to implement generic functions, I think.
    Don't worry. The generic functions won't make the class hard to use.
    They will distract the user of your class.
    I came to your class looking for a simple function to change my string to upper case, and, all i can see is, a big grand pile of generic functions, that claim, they can change the case of everything on earth, from a pin to a plane!!!

  4. #94
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,663
    Quote Originally Posted by manav View Post
    They will distract the user of your class.
    I came to your class looking for a simple function to change my string to upper case, and, all i can see is, a big grand pile of generic functions, that claim, they can change the case of everything on earth, from a pin to a plane!!!
    The interface isn't done yet, of course, but I assure you there will be member functions for toupper/tolower.
    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.

  5. #95
    Banned
    Join Date
    Nov 2007
    Posts
    678
    Quote Originally Posted by laserlight View Post
    Note that part of the argument involves member functions versus non-member non-friend functions.
    I know you were all able to brain wash Elysia. Now Elysia will be literally re-inventing the evil wheel of STL style, but, only this time, the names will be what Elysia think are better! *_*

    The generic stuff becomes really ugly when I do:
    Code:
    std::vector <  MyGenericClass <  SpecifiType > >  poorVector;
    We are trying to imitate Python like VHLL here, while this is so ugly, and Python would have it so neat and clean:
    myVector = [ whatever ]

  6. #96
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,663
    Quote Originally Posted by manav View Post
    I know you were all able to brain wash Elysia. Now Elysia will be literally re-inventing the evil wheel of STL style, but, only this time, the names will be what Elysia think are better! *_*
    No, I won't. STL is evil. Therefore we must provide new, better interfaces. Easy interfaces to interface with STL.
    I assure you that this will be better than other string classes you've seen!
    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. #97
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,794
    I know you were all able to brain wash Elysia. Now Elysia will be literally re-inventing the evil wheel of STL style, but, only this time, the names will be what Elysia think are better! *_*
    Start your own thread and state what do you mean by "evil wheel of STL style", elaborating on how it is evil, and what you propose as an alternative.

    The generic stuff becomes really ugly when I do:
    Use an appropriate typedef if you think it will help.

    We are trying to imitate Python like VHLL here, while this is so ugly, and Python would have it so neat and clean:
    I do not think that there is any attempt to imitate Python here. What is your point?
    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

  8. #98
    Banned
    Join Date
    Nov 2007
    Posts
    678
    Quote Originally Posted by laserlight View Post
    Start your own thread and state what do you mean by "evil wheel of STL style", elaborating on how it is evil, and what you propose as an alternative.
    lol!
    You want me to do that, the whole committee of C++ could not do that!
    And as an alternative, i will suggest read Java's collection framework.
    (You asked for an alternative, alternative - alternate way of doing the same. I am not claiming the best way or anything like that)

    Use an appropriate typedef if you think it will help.
    Code:
    void Func(float) {}
    void Func(int) {}
    
    Func(5);
    Do I need a typedef here? Then why with templates? I am just pointing out the ugliness of syntax. Would be better if compiler could infer the types based on what was passed in

    I do not think that there is any attempt to imitate Python here. What is your point?
    That was an implementation that is free of type declaration.
    Type less stuff is in domain of Python like languages!
    Last edited by manav; 05-13-2008 at 03:55 AM.

  9. #99
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,794
    lol!
    You want me to do that, the whole committee of C++ could not do that!
    And as an alternative, i will suggest read Java's collection framework.
    (You asked for an alternative, alternative - alternate way of doing the same. I am not claiming the best way or anything like that)
    lol! indeed. Clearly, you know nothing about what you are talking about, since you cannot justify your assertions. This is underscored by the fact that you try and escape by not citing or providing an alternative that you dare claim is better. So, you have not pointed what is wrong and why it is wrong, and you have not pointed what is right and why it is right, thus you know nothing at all.

    Do I need a typedef here? Then why with templates? I am just pointing out the ugliness of syntax.
    You are being inconsistent. Since you want to use function overloading as an example, then the corresponding template example is a function template:
    Code:
    template<typename T>
    void Func(T x) {}
    // ...
    Func(5);
    Would be better if compiler could infer the types based on what was passed in
    That's not possible for class templates since it is not known what is to be passed in until run time.

    That was an implementation that is free of type declaration.
    Type less stuff is in domain of Python like languages!
    If you prefer (run time) duck typing, then use a programming language that supports duck typing.
    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. #100
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,663
    Quote Originally Posted by manav View Post
    Code:
    void Func(float) {}
    void Func(int) {}
    
    Func(5);
    Do I need a typedef here? Then why with templates? I am just pointing out the ugliness of syntax. Would be better if compiler could infer the types based on what was passed in
    But it does deduce type. However, because C++ is a type-safe language, you must explicitly define that you want a variable type (it not limited to one). The template type declaration will allow you to refer to that type at a later stage.
    The syntax is very good because it allows us to explicitly use the type you passed in at a later stage.
    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. #101
    Banned
    Join Date
    Nov 2007
    Posts
    678
    Quote Originally Posted by laserlight View Post
    lol! indeed. Clearly, you know nothing about what you are talking about, since you cannot justify your assertions. This is underscored by the fact that you try and escape by not citing or providing an alternative that you dare claim is better. So, you have not pointed what is wrong and why it is wrong, and you have not pointed what is right and why it is right, thus you know nothing at all.
    I never heard you laughing before! I am glad that I made you happy!

    Boy! STL is huge!! I can not explain it in all terms, suffice is to say that it is the least convenient lib that I ever used!

    You are being inconsistent. Since you want to use function overloading as an example, then the corresponding template example is a function template:
    Code:
    template<typename T>
    void Func(T x) {}
    // ...
    Func(5);
    That's not possible for class templates since it is not known what is to be passed in until run time.
    I have said that already, your C++ knowledge is very impressive! I do not want to go that deep! It is suffocating in there!

    If you prefer (run time) duck typing, then use a programming language that supports duck typing.
    Actually I am very happy with the way Qt has used C++, I never need to use any STL stuff! Qt people understand C++ more than I do, (more than Bjarne too?)
    ...

    Nothing wrong with dUcK typing also, i love python, it's just that while writing GUI or Graphics stuff, i gain nothing from Python! Only useful for text processing or similar stuff!

  12. #102
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,794
    Boy! STL is huge!! I can not explain it in all terms, suffice is to say that it is the least convenient lib that I ever used!
    Ah, in that case you should say something like: "it lacks convenience functions". Then provide some examples (in your new thread), and what you might do differently.

    Nothing wrong with dUcK typing also, i love python, it's just that while writing GUI or Graphics stuff, i gain nothing from Python!
    Look into wxPython, but now we are veering completely off even the topic of this forum
    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

  13. #103
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Quote Originally Posted by manav View Post
    Now for the for_each, it is generalized,
    for_each is not a generalization of the built-in for-loop. It cannot be, since it is implemented using a for loop, and it is logically impossible to implement something generic using less generic components.

    On one hand, for_each is a generalization of the other algorithms. See, you have all these algorithms in the STL that do things, like std::accumulate(). for_each is a generalization of these. accumulate iterates over a range and "adds" (but the add operation need not be an actual plus) each element to a running total. for_each iterates over a range and does something with each element. Adding them to a running total is a possibility. You can implement accumulate in terms of for_each.

    On the other hand, for_each is a specialization of the for loop. It is optimized for iterating exactly once over each element in a range. Especially combined with lambdas (C++0x built-ins or Boost.Lambda), this makes for some syntax reduction. For example, let's print every element in a vector and a list of ints, followed by some string.
    Using for loops:
    Code:
    for(std::vector<int>::iterator it = v.begin(); it != v.end(); ++it) {
      std::cout << *it << " bottles of beer.\n";
    }
    for(std::list<int>::iterator it = l.begin(); it != l.end(); ++it) {
      std::cout << *it << " red balloons.\n";
    }
    Using for_each:
    Code:
    std::for_each(v.begin(), v.end(), std::cout << lambda::_1 << " bottles of beer.\n");
    std::for_each(l.begin(), l.end(), std::cout << lambda::_1 << " red balloons.\n");
    Of course, it's even nicer if you get yet more specialized, using Boost's Range and (candidate) RangeEx libraries:
    Code:
    rex::for_each(v, std::cout << lambda::_1 << " bottles of beer.\n");
    rex::for_each(l, std::cout << lambda::_1 << " red balloons.\n");
    (On a side note, std::copy to an ostream_iterator would be yet more specialized. But because the lambda syntax is more concise than creating an ostream_iterator, it wouldn't actually be shorter.)

    This is a case of getting more specialized, not of getting more generic. You seem to be under the impression that all we want is getting more generic. That's wrong. What we want is building blocks, that we can stack upon each other. Some building blocks are so useful that we want to use them again and again. Others are useful only for the specific case.

    For example, rex::for_each could be implemented like this: (Note: I have no idea how the RangeEx library looks exactly.)
    Code:
    namespace boost {
      namespace range {
        template <typename Container> inline
        typename Container::iterator begin(Container &c)
        {
          return c.begin();
        }
        template <typename Container> inline
        typename Container::iterator end(Container &c)
        {
          return c.end();
        }
    
        template <typename InputRange, typename Fn> inline
        Fn for_each(Range &r, Fn fn)
        {
          return std::for_each(begin(r), end(r), fn);
        }
      }
    }
    
    namespace rex = boost::range;
    And std::for_each could be (and very likely is) implemented like this:
    Code:
    namespace std {
    
      template <typename InputIterator, typename Fn> inline
      Fn for_each(InputIterator first, InputIterator last, Fn fn)
      {
        for( ; first != last; ++first) {
          fn(*first);
        }
        return fn;
      }
    
    }
    Why the weird free functions in the rex part, you may ask? Genericity. Adaptability. Did you know that a std:air<Iterator, Iterator> is a range?
    Code:
    namespace boost { namespace range {
      template <typename InputIterator> inline
      InputIterator begin(const std::pair<InputIterator, InputIterator> &p)
      {
        return p.first;
      }
      template <typename InputIterator> inline
      InputIterator end(const std::pair<InputIterator, InputIterator> &p)
      {
        return p.end;
      }
    }}
    That's interesting, because that's what std::equal_range (and rex::equal_range) return. Suppose you have a sorted vector<int>: [ 1, 3, 4, 4, 4, 6, 6, 7, 9 ]
    And you want to print all occurrences of 4 to stdout. (For whatever deranged reason.) Then you can pass the return value of equal_range directly to copy:
    Code:
    rex::copy(rex::equal_range(v, 4), std::ostream_iterator<int>(std::cout, " "));
    It's all about building blocks.
    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

  14. #104
    Banned
    Join Date
    Nov 2007
    Posts
    678
    Quote Originally Posted by laserlight View Post
    Ah, in that case you should say something like: "it lacks convenience functions". Then provide some examples (in your new thread), and what you might do differently.
    I have already posted or mentioned the examples, no need to start a thread!
    Except one thing that it is possible (thank Lord!), the basic stuff is so convoluted!

    toUpper(). toLower(). split(). replace(). equalsIgnoreCase().

    Look into wxPython, but now we are veering completely off even the topic of this forum
    The thread topic is "Though implementation problem"
    which means STL may be powerful for some, "Though implementation problem" is there! Elysia is very kind hearted, and will not mind me hijacking the thread

  15. #105
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Please leave out all case conversion issues out of this discussion. Case conversion is very complicated. Proper international character handling is a known weakness of the standard library, because its design predates many of the more complicated issues involved in this. If you need character handling, use ICU.
    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

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. WS_POPUP, continuation of old problem
    By blurrymadness in forum Windows Programming
    Replies: 1
    Last Post: 04-20-2007, 06:54 PM
  2. Laptop Problem
    By Boomba in forum Tech Board
    Replies: 1
    Last Post: 03-07-2006, 05:24 PM
  3. implementation file
    By bejiz in forum C++ Programming
    Replies: 5
    Last Post: 11-28-2005, 12:59 AM
  4. Replies: 5
    Last Post: 11-07-2005, 10:34 PM
  5. Memory Problem - I think...
    By Unregistered in forum C Programming
    Replies: 4
    Last Post: 10-24-2001, 12:14 PM

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