Watch, Follow, &
Connect with Us

For forums, blogs and more please visit our
Developer Tools Community.


Welcome, Guest
Guest Settings
Help

Thread: XE7 64bit "called object type 'type' is not a function or function pointer"


This question is not answered. Helpful answers available: 0. Correct answers available: 1.


Permlink Replies: 8 - Last Post: Mar 25, 2016 2:54 PM Last Post By: Dennis Jones
Dennis Jones

Posts: 53
Registered: 1/25/98
XE7 64bit "called object type 'type' is not a function or function pointer"  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 24, 2016 10:14 PM
I wrote a bunch of code, tested it using the 32-bit compiler, and it was working beautifully. Then I switched to the 64-bit compiler and got this bizarre error message. I have reduced the code to the minimum required to reproduce the error:

class Object
{
public:
  void operator()() {}
};
 
class Container
{
private:
  Object _Object;
 
public:
  __property Object ContainedObject = { read=_Object };
};
 
int _tmain(int argc, _TCHAR* argv[])
{
  Object o;
  o();  // <== call to operator()() is okay in 32-bit AND 64-bit
 
  Container container;
  container.ContainedObject();  // <== call to operator()() is okay in 32-bit, but produces an error in 64-bit
  return 0;
}


As you can see, ContainedObject is a property which returns the contained object, _Object. Note: the real code actually uses a getter method to return a reference to _Object, but I left that out for simplicity's sake, since it is not necessary to demonstrate the error.

Since the Object class has an operator()() method, I should be able to use ()'s on the object to invoke the function call operator. And, in fact, I can do this successfully with a normal object, as demonstrated at the beginning of the main() function. But, for some reason, when returning an Object via a property, the function call operator is not recognized and I get the error:

"[C++ Error] File5.cpp(35, 27): called object type 'Object' is not a function or function pointer"

Fortunately, there is a fairly simple work-around:

container.ContainedObject.operator()();  // <== explicitly invoke function call operator()(); okay in 32-bit and 64-bit


So my question is, is this a bug in the 64-bit compiler, or is this the result of a language change in the C++11 standard that changes the meaning of the code I have written?

Dennis
Andy Walker

Posts: 72
Registered: 1/20/01
Re: XE7 64bit "called object type 'type' is not a function or function pointer"
Helpful
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 25, 2016 2:50 AM   in response to: Dennis Jones in response to: Dennis Jones
Dennis Jones wrote:

So my question is, is this a bug in the 64-bit compiler, or is this the result of a language change in the C++11 standard that changes the meaning of the code I have written?

Dennis

Not that it helps you but I can confirm that this builds successfully in XE10 Seattle as both 32-bit and 64-bit. So looks like a compiler issue.

Andy
Dennis Jones

Posts: 53
Registered: 1/25/98
Re: XE7 64bit "called object type 'type' is not a function or function pointer"  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 25, 2016 7:19 AM   in response to: Andy Walker in response to: Andy Walker
Andy Walker wrote:

Not that it helps you but I can confirm that this builds successfully in XE10 Seattle as both 32-bit and 64-bit. So looks like a compiler issue.

Andy,

Do you know if they have also addressed the linker issues, particularly the LME and Out of Memory errors that would occur when building large, runtime packages in 64-bit debug mode, due to the very large object files that are produced by the CLANG compiler (w/embedded debug info)? I also wonder, since the 32-bit version is now CLANG, if the object files are now huge in 32-bit mode too.

I'm really gun-shy when it comes to upgrading, as Borland/CodeGear/Embarcadero has a long history (15+ years) of not fixing major bugs in their new releases, and I don't want to spend $1600 only to find out they haven't done squat since XE7.

Dennis

Edited by: Dennis Jones on Mar 25, 2016 7:19 AM
Andy Walker

Posts: 72
Registered: 1/20/01
Re: XE7 64bit "called object type 'type' is not a function or function pointer"  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 25, 2016 12:01 PM   in response to: Dennis Jones in response to: Dennis Jones
Dennis Jones wrote:
Andy Walker wrote:

Not that it helps you but I can confirm that this builds successfully in XE10 Seattle as both 32-bit and 64-bit. So looks like a compiler issue.

Andy,

Do you know if they have also addressed the linker issues, particularly the LME and Out of Memory errors that would occur when building large, runtime packages in 64-bit debug mode, due to the very large object files that are produced by the CLANG compiler (w/embedded debug info)? I also wonder, since the 32-bit version is now CLANG, if the object files are now huge in 32-bit mode too.

I'm really gun-shy when it comes to upgrading, as Borland/CodeGear/Embarcadero has a long history (15+ years) of not fixing major bugs in their new releases, and I don't want to spend $1600 only to find out they haven't done squat since XE7.

Dennis

Edited by: Dennis Jones on Mar 25, 2016 7:19 AM

Sorry, I don't know the answers to those questions. Why don't you download the trial version and have a play?

Andy
Dennis Jones

Posts: 53
Registered: 1/25/98
Re: XE7 64bit "called object type 'type' is not a function or function pointer"  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 25, 2016 1:53 PM   in response to: Andy Walker in response to: Andy Walker
Andy Walker wrote:
Dennis Jones wrote:
Do you know if they have also addressed the linker issues, particularly the LME and Out of Memory errors that would occur when building large, runtime packages in 64-bit debug mode, due to the very large object files that are produced by the CLANG compiler (w/embedded debug info)? I also wonder, since the 32-bit version is now CLANG, if the object files are now huge in 32-bit mode too.

Sorry, I don't know the answers to those questions. Why don't you download the trial version and have a play?

I found the answer. They have NOT fixed the linker errors, and they have no plans to do so any time soon (basically, it would require a complete rewrite of the linker, and they aren't willing to do that at this time). (ref: https://quality.embarcadero.com/browse/RSP-13247?focusedCommentId=25845&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-25845) Which means, we have little to no chance of getting a product that can be used for anything but small, toy 64-bit applications until some time in the far out, unspecified future (if ever). Large, industrial-strength apps just aren't going to happen with this tool chain unless/until the linker issues are addressed. It's a shame too, because C++ Builder has been a decent product for a long time, but because they have refused to address critical bugs, we can't depend on it for serious work. Of course, we can continue to use the old 32-bit compiler, but that defeats the purpose of even having a 64-bit tool chain. Not to mention the fact that the XE7 compiler is lousy w.r.t. C++11 compliance. I'm not sure the CLANG-based 32-bit compiler is ready for prime time either -- apparently it has issues too. Oh well.

Dennis
david hoke

Posts: 616
Registered: 2/9/07
Re: XE7 64bit "called object type 'type' is not a function or function pointer"
Helpful
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 25, 2016 5:43 AM   in response to: Dennis Jones in response to: Dennis Jones
Dennis Jones wrote:

<many various snips>

demonstrated at the beginning of the main() function. But, for some
reason, when returning an Object via a property, the function call

So my question is, is this a bug in the 64-bit compiler, or is this
the result of a language change in the C++11 standard that changes
the meaning of the code I have written?

As 'properties', AFAIK, are a 'borland' extension that have not made it
into the standard, it is unlikely to be a change in the standard at
play here...
Dennis Jones

Posts: 53
Registered: 1/25/98
Re: XE7 64bit "called object type 'type' is not a function or function pointer"  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 25, 2016 6:58 AM   in response to: david hoke in response to: david hoke
david hoke wrote:
Dennis Jones wrote:

<many various snips>

demonstrated at the beginning of the main() function. But, for some
reason, when returning an Object via a property, the function call

So my question is, is this a bug in the 64-bit compiler, or is this
the result of a language change in the C++11 standard that changes
the meaning of the code I have written?

As 'properties', AFAIK, are a 'borland' extension that have not made it
into the standard, it is unlikely to be a change in the standard at
play here...

Good point, David. Thanks.

Dennis
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: XE7 64bit "called object type 'type' is not a function or functionpointer"  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 25, 2016 2:19 PM   in response to: Dennis Jones in response to: Dennis Jones
Dennis wrote:

Fortunately, there is a fairly simple work-around:

Or use a variable to receive the object:

Container container;
Object o = container.ContainedObject;
// or: Object &o = ...
o();


So my question is, is this a bug in the 64-bit compiler, or is this
the result of a language change in the C++11 standard that
changes the meaning of the code I have written?

No. The 32bit compiler is the old Borland compiler, the 64bit compiler is
based on CLang. Borland's compiler extensions, like __property, had to be
added to CLang, so there is bound to be some subtle differences in how they
operate between the two compilers.

--
Remy Lebeau (TeamB)
Dennis Jones

Posts: 53
Registered: 1/25/98
Re: XE7 64bit "called object type 'type' is not a function or functionpointer"  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 25, 2016 2:42 PM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
Remy Lebeau (TeamB) wrote:
Dennis wrote:

Fortunately, there is a fairly simple work-around:

Or use a variable to receive the object:

Container container;
Object o = container.ContainedObject;
// or: Object &o = ...
o();

Yes, Remy, a reference would be optimal, but I don't need the intermediate object for anything else. All the code that uses this construct is generated from a T4 template, so it was just a matter of changing the template to use operator()() and re-generating the code.

Dennis
Legend
Helpful Answer (5 pts)
Correct Answer (10 pts)

Server Response from: ETNAJIVE02