Utility of Function Objects

This is a discussion on Utility of Function Objects within the Tech Board forums, part of the Community Boards category; I've recently read about function objects, in more detail than I'd previously done.... But I'm falling short in imagining circumstances(the ...

  1. #1
    Registered User manasij7479's Avatar
    Join Date
    Feb 2011
    Location
    Kolkata@India
    Posts
    2,498

    Utility of Function Objects

    I've recently read about function objects, in more detail than I'd previously done....
    But I'm falling short in imagining circumstances(the examples I found are not very conclusive ) in which it'll be absolutely necessary....and can not be done with ...say...functions and static variables..etc..
    Any illuminating answer?
    Manasij Mukherjee | gcc-4.8.2 @Arch Linux
    Slow and Steady wins the race... if and only if :
    1.None of the other participants are fast and steady.
    2.The fast and unsteady suddenly falls asleep while running !



  2. #2
    Unregistered User Yarin's Avatar
    Join Date
    Jul 2007
    Posts
    1,627
    Basically, it's like operator overloading, but allows you to define the "()" operation.

    Wiki has a decent article on it.

  3. #3
    Registered User manasij7479's Avatar
    Join Date
    Feb 2011
    Location
    Kolkata@India
    Posts
    2,498
    ..I've already read that article//...it only says how it is done in various languages...not the various utilities of it..
    Manasij Mukherjee | gcc-4.8.2 @Arch Linux
    Slow and Steady wins the race... if and only if :
    1.None of the other participants are fast and steady.
    2.The fast and unsteady suddenly falls asleep while running !



  4. #4
    &TH of undefined behavior Fordy's Avatar
    Join Date
    Aug 2001
    Posts
    5,789
    You can do the same with functions and static variables as you suggest, but a function object allows you to treat an action as an object as well as store its state between calls.

    Image you have a list of actions to do, one after another, with the need to store the state between calls. Creating a function object for each and storing them in a container is one simple way that you could do this. Each time you need to process your actions, call each of them using an iterator on the container.

  5. #5
    Registered User manasij7479's Avatar
    Join Date
    Feb 2011
    Location
    Kolkata@India
    Posts
    2,498
    That returns the pointer to the original problem (which, as I was suggested ) could be very elegantly solved by function objects..but I'm hopelessly lost about how to apply them..

    ..the problem..if you're interested is here
    Manasij Mukherjee | gcc-4.8.2 @Arch Linux
    Slow and Steady wins the race... if and only if :
    1.None of the other participants are fast and steady.
    2.The fast and unsteady suddenly falls asleep while running !



  6. #6
    Unregistered User Yarin's Avatar
    Join Date
    Jul 2007
    Posts
    1,627
    Alright, here's an example:

    Code:
    dynchalloc::dynchalloc(long memlen)
    {
       buff = new char[memlen];
       if(!buff)
          throw std::bad_alloc();
    }
    
    dynchalloc::~dynchalloc()
    {
       delete [] buff;
    }
    
    char* dynchalloc::operator()()
    {
       return buff;
    }

  7. #7
    Unregistered User Yarin's Avatar
    Join Date
    Jul 2007
    Posts
    1,627
    ...which could be used, like so:
    Code:
                dynchalloc keywords(keywordslen + 1);
                commsock.readData(keywords(), keywordslen);
                keywords()[keywordslen] = 0;

  8. #8
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,604
    Yarin, you are aware that, by default, new throws std::bad_alloc if it fails to allocate memory, right? It will not return a nullptr_t.
    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. #9
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,703
    You are aware that not all compilers follow the standard as well as they could, right? Be safe, not sorry.

  10. #10
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,604
    I don't think it's a good idea to assume that everyone is working with such an old compiler. In that case, we'd have to compromise a lot, such as not templates, etc, etc, etc.
    Anyway, it doesn't matter. I was simply checking if Yarin knew this or not.
    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. #11
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,703
    Even if he didn't know it, regardless of what assumptions I may actually be making, in your own words it amounts to something that "doesn't matter" and you're encouraging him to delete code that makes absolutely sure an exception is thrown when new fails, rather than trusting invisible code.

  12. #12
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,604
    OK, first, I am encouraging people to not write legacy code in order to support old compilers. If we wrote code for the lowest common denominator, we'd be making sure works for Turbo C/C++, which is ridiculous. I don't encourage people to write code for Visual C++ 6 either, it being so old and all. If there are special situations requiring the use of such old software, then adjust your code accordingly. But if not, then let's write standard compliant code which is not burned by legacy compilers.

    And so, secondly, I am not encouraging Yarin to delete the code. I was merely asking if Yarin was aware that an exception will be thrown or not. It's, how shall we put it ... dead code. Code that is unnecessary. Might it be sometimes that we add unnecessary code due to lack of sufficient knowledge? Of course it is. So did Yarin add it because Yarin didn't know new would throw, or did Yarin add it as a fallback? I don't know. It doesn't matter. All I wanted to do was to inform Yarin that modern compilers will throw an exception. I mean, there's nothing wrong in imparting knowledge to others, is there?
    Last edited by Elysia; 05-25-2011 at 04:16 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. #13
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,703
    Quote Originally Posted by Elysia View Post
    OK, first, I am encouraging people to write legacy code in order to support old compilers. If we wrote code for the lowest common denominator, we'd be making sure works for Turbo C/C++, which is ridiculous.
    You're getting a bit worked up. You say you encourage people to write legacy code, but in the same sentence you mention it's ridiculous.

    I don't encourage people to write code for Visual C++ 6 either, it being so old and all. If there are special situations requiring the use of such old software, then adjust your code accordingly. But if not, then let's write standard compliant code which is not burned by legacy compilers.

    And so, secondly, I am not encouraging Yarin to delete the code. I was merely asking if Yarin was aware that an exception will be thrown or not. It's, how shall we put it ... dead code. Code that is unnecessary. Might it be sometimes that we add unnecessary code due to lack of sufficient knowledge? Of course it is. So did Yarin add it because Yarin didn't know new would throw, or did Yarin add it as a fallback? I don't know. It doesn't matter. All I wanted to do was to inform Yarin that modern compilers will throw an exception. I mean, there's nothing wrong in imparting knowledge to others, is there?
    You can't talk about dead code and not encourage people to do something about it. Think about what you do with code that, you learn, supposedly never executes. It's also nice of you to want to impart knowledge but I don't think you're in the right. new certainly can return null pointers -- it just won't most of the time, depending on compiler and linker, and other standard options, of course. I think we can share the blame. I admit my post is a quip towards you. But this is apparently not just a VS6 problem; it also happens in not so recent 2003, 2005 versions if you link a certain way. So how dead is the code really? I mean, if you decide to turn on nothrow, it won't be so dead. It still comes down to trusting that new indeed does throw, instead of just writing it and making sure that it does.
    Last edited by whiteflags; 05-25-2011 at 04:17 AM.

  14. #14
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,604
    Quote Originally Posted by whiteflags View Post
    You're getting a bit worked up. You say you encourage people to write legacy code, but in the same sentence you mention it's ridiculous.
    Sorry, I missed a "not" in there. Fixed now.

    You can't talk about dead code and not encourage people to do something about it. Think about what you do with code that supposedly never executes. It's also nice of you to want to impart knowledge but I don't think you're in the right. new certainly can return null pointers -- it just won't most of the time, depending on compiler and linker, and other standard options, of course. I think we can share the blame. I admit my post is a quip towards you. But this is apparently not just a VS6 problem; it also happens in not so recent 2003, 2005 versions if you link a certain way. So how dead is the code really? I mean, if you decide to turn on nothrow, it won't be so dead. It still comes down to trusting that new indeed does throw, instead of just writing it and making sure that it does.
    Yes, you have a point there.
    No further arguments.
    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. #15
    Unregistered User Yarin's Avatar
    Join Date
    Jul 2007
    Posts
    1,627
    Quote Originally Posted by Elysia View Post
    Yarin, you are aware that, by default, new throws std::bad_alloc if it fails to allocate memory, right? It will not return a nullptr_t.
    Actually, no, I didn't know this. Thank you for informing me. My being more familiar with C often bleeds into my C++

    Quote Originally Posted by whiteflags View Post
    You can't talk about dead code and not encourage people to do something about it. Think about what you do with code that, you learn, supposedly never executes. It's also nice of you to want to impart knowledge but I don't think you're in the right. new certainly can return null pointers -- it just won't most of the time, depending on compiler and linker, and other standard options, of course. I think we can share the blame. I admit my post is a quip towards you. But this is apparently not just a VS6 problem; it also happens in not so recent 2003, 2005 versions if you link a certain way. So how dead is the code really? I mean, if you decide to turn on nothrow, it won't be so dead. It still comes down to trusting that new indeed does throw, instead of just writing it and making sure that it does.
    Also good to know, thanks.

    Am I correct in assuming that GCC's optimizer will catch this, and forgo my check if new does indeed automatically throw? If so, the check would definitely be good practice.

Page 1 of 2 12 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 14
    Last Post: 12-04-2009, 04:24 PM
  2. vector of function objects
    By idleman in forum C++ Programming
    Replies: 6
    Last Post: 09-11-2009, 11:59 AM
  3. Replies: 11
    Last Post: 09-22-2006, 05:21 PM
  4. Replies: 4
    Last Post: 10-16-2003, 11:26 AM
  5. Can objects contain/return values like a function?
    By Panopticon in forum C++ Programming
    Replies: 3
    Last Post: 01-22-2003, 06:44 PM

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