| Author |
 Topic  |
|
|
znakeeye
Tomato Guru
379 Posts |
 Posted - Jul 17 2007 : 10:59:24 AM
|
Hi,
Have had problems with this, since early versions. Was too lazy to complain :).
void LoadLibrary() // Parentheses expected on declaration
LoadLibrary() // Parentheses expected on call
pfnLoadLibrary = &LoadLibrary() // Parentheses NOT expected
pfnLoadLibrary = &CMyClass::LoadLibrary() // Parentheses NOT expected
Function pointers are traditionally not used on a regular basis, but if using template libraries such as Boost, they are indeed quite common.
IDE = VS 2005 SP1
VAX = 10.3.1557 |
|
|
feline
Whole Tomato Software
United Kingdom
19014 Posts |
Posted - Jul 17 2007 : 3:05:57 PM
|
At the risk of playing devils advocate, what if you had been trying to write:
pfnLoadLibrary = &LoadLibrary()->nMember;
You do make an interesting point, I am just wondering if there is a valid argument in favour of what VA is currently doing. |
zen is the art of being at one with the two'ness |
 |
|
|
znakeeye
Tomato Guru
379 Posts |
Posted - Jul 18 2007 : 01:37:19 AM
|
Good point indeed. Now I had to think a bit :-)
Anyway, your above code is not always valid. Also, the assignment statement is important.
The parentheses are never wanted if:
1) If the function does not return a referrable object.
I.e. basic types: void, int, char, ... Also (just checked): int*, char*, ...
2) If the function is a non-static class member.
E.g.
struct CFoo { CFoo foo() { return CFoo(); } };
pfnFoo = &CFoo::foo() // invalid, since foo is non-static
3) If the lvalue is a function pointer. Not sure if VAX has support for such type-checking... |
|
|
|
feline
Whole Tomato Software
United Kingdom
19014 Posts |
Posted - Jul 18 2007 : 06:41:30 AM
|
I am very wary of trying to get "clever", by running this many checks. One reason is simply that the behaviour stops being "simple".
While the behaviour, and rules behind it are simple they can be explained, tested, and people know what to expect. But complex behaviour is much harder to explain and support.
VA should know if a given class member function is a function pointer or not, so I am inclined towards an "all or nothing" approach here.
Also what happens when you are calling this function pointer / function? It has been a while since I did much work with function pointers (good old C  ) but my memory was that I spent more time calling them than I did setting them. |
zen is the art of being at one with the two'ness |
|
|
|
znakeeye
Tomato Guru
379 Posts |
Posted - Jul 20 2007 : 03:09:44 AM
|
I see your point. So let's look at the simple approach then.
How often do you find yourself typing this?
&SomeFunction();
I know I haven't done that - ever. There are two reasons:
1) You simply don't write *Foo() or &Foo(). Look through your source code. You won't find many of them ;)
2) If the programmer insists, he will most likely add the prefix after typing 'SomeFunction()'. "Oh, I need a pointer..." |
|
|
|
feline
Whole Tomato Software
United Kingdom
19014 Posts |
Posted - Jul 20 2007 : 07:33:18 AM
|
It took a few moments, but I did think of a case:
std::string &CMyClass::returnsAReference()
{
// body
}
Having said that, this seems a sensible change, and it should cause very few problems, if any, so long as VA can reliably distinguish between these two situations. I have put in a feature request for this:
case=7802 |
zen is the art of being at one with the two'ness |
|
|
|
sean
Whole Tomato Software
USA
2817 Posts |
Posted - Jun 12 2009 : 9:03:05 PM
|
| case=7802 is fixed in build 1727 |
|
|
|
support
Whole Tomato Software
5566 Posts |
Posted - Aug 22 2009 : 7:19:47 PM
|
| There was an additional problem with case=7802 when namespaces were present. This is fixed in build 1731. |
Whole Tomato Software, Inc. |
|
|
| |
Topic |
|
Function pointers generate parentheses
