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?
Basically, it's like operator overloading, but allows you to define the "()" operation.
Wiki has a decent article on it.
..I've already read that article//...it only says how it is done in various languages...not the various utilities of it..
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.
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
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; }
...which could be used, like so:
Code:dynchalloc keywords(keywordslen + 1); commsock.readData(keywords(), keywordslen); keywords()[keywordslen] = 0;
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.
Originally Posted by Adak
You are aware that not all compilers follow the standard as well as they could, right? Be safe, not sorry.
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.
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.
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.
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.
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.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 whiteflags; 05-25-2011 at 04:17 AM.
Sorry, I missed a "not" in there. Fixed now.
Yes, you have a point 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 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.
No further arguments.
Actually, no, I didn't know this. Thank you for informing me. My being more familiar with C often bleeds into my C++
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.
