www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - Wrong method called.

reply Dave <Dave_member pathlink.com> writes:
I saw this elsewhere, but can't find the original and don't know if it was ever
reported in digitalmars.D.bugs or not.

Summary: Changing the order of class methods in an import file can result in the
wrong method called when the executable is built with the corresponding object
file. This happens on both Linux and Windows. On windows, the equivalent C++
code doesn't exhibit the same bug with DMC.

Build and run the following with:

\> dmd main.d c.d -ofmain
\> dmd main.d c.obj -version=_OBJ_ -ofmain_obj

\> main
method1()
method2()

\> main_obj
method2()
method1()

main.d:
-------
import c;

void main()
{
C c = new C;
c.method1();
c.method2();
}

c.d:
----
class C
{
version(_OBJ_)
{
void method2() { printf("method2()\n"); }
void method1() { printf("method1()\n"); }
}
else
{
void method1() { printf("method1()\n"); }
void method2() { printf("method2()\n"); }
}
}

C++ code:

\> dmc main.cpp c.cpp -omain_cpp
\> dmc main.cpp c.obj -D_OBJ_ -omain_cpp_obj

main.cpp:
---------
#include "c.h"

int main()
{
C *c = new C();
c->method1();
c->method2();

return 0;
}

c.cpp:
------
#include "c.h"
#include <stdio.h>

void C::method1() { printf("method1()\n"); }
void C::method2() { printf("method2()\n"); }

c.h:
----
class C
{
public:
#ifdef _OBJ_
virtual void method2();
virtual void method1();
#else
virtual void method1();
virtual void method2();
#endif
};
Jan 15 2006
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Dave" <Dave_member pathlink.com> wrote in message 
news:dqef6s$2ovu$1 digitaldaemon.com...
I saw this elsewhere, but can't find the original and don't know if it was 
ever
 reported in digitalmars.D.bugs or not.

 Summary: Changing the order of class methods in an import file can result 
 in the
 wrong method called when the executable is built with the corresponding 
 object
 file.
It's not a bug. The order in the import file *must* match the order in the import's compiled object file. In the example presented, the order in the import file is changed (via a command line switch) to be different from what it was in the object file.
Mar 04 2006
parent reply alan <alan_member pathlink.com> writes:
In article <ducnmk$rv$4 digitaldaemon.com>, Walter Bright says...
It's not a bug. The order in the import file *must* match the order in the 
import's compiled object file. In the example presented, the order in the 
import file is changed (via a command line switch) to be different from what 
it was in the object file. 
dmd b.d a.d -c dmd main.d a.obj b.obj Error: AssertError Failure a.d(5) dmd main.d b.obj a.obj Error: AssertError Failure a.d(5) ============================================ dmd a.d b.d -c dmd main.d a.obj b.obj Bar.bar() dmd main.d b.obj a.obj Bar.bar() ============================================ dmd main.d a.d b.d Bar.bar() dmd main.d b.d a.d Bar.bar() OK, it's not a bug, it's a feature! I believe we now know why compiling object modules seperately causes problems. Walter, I think you have a big problem here.
Mar 04 2006
parent reply Brad Roberts <braddr puremagic.com> writes:
On Sat, 4 Mar 2006, alan wrote:

 In article <ducnmk$rv$4 digitaldaemon.com>, Walter Bright says...
It's not a bug. The order in the import file *must* match the order in the 
import's compiled object file. In the example presented, the order in the 
import file is changed (via a command line switch) to be different from what 
it was in the object file. 
dmd b.d a.d -c dmd main.d a.obj b.obj Error: AssertError Failure a.d(5) dmd main.d b.obj a.obj Error: AssertError Failure a.d(5) ============================================ dmd a.d b.d -c dmd main.d a.obj b.obj Bar.bar() dmd main.d b.obj a.obj Bar.bar() ============================================ dmd main.d a.d b.d Bar.bar() dmd main.d b.d a.d Bar.bar() OK, it's not a bug, it's a feature! I believe we now know why compiling object modules seperately causes problems. Walter, I think you have a big problem here.
Careful.. don't confuse the original topic here with a different topic. The start of this is changing a module such that it doesn't match the .obj/.o being linked in. Your example is order of linking. If you lie to the compiler about the contents of the compiled code by changing the header, you're out of luck in general. Later, Brad
Mar 04 2006
parent Dave <Dave_member pathlink.com> writes:
In article <Pine.LNX.4.64.0603041438430.30259 bellevue.puremagic.com>, Brad
Roberts says...
On Sat, 4 Mar 2006, alan wrote:

 In article <ducnmk$rv$4 digitaldaemon.com>, Walter Bright says...
It's not a bug. The order in the import file *must* match the order in the 
import's compiled object file. In the example presented, the order in the 
import file is changed (via a command line switch) to be different from what 
it was in the object file. 
dmd b.d a.d -c dmd main.d a.obj b.obj Error: AssertError Failure a.d(5) dmd main.d b.obj a.obj Error: AssertError Failure a.d(5) ============================================ dmd a.d b.d -c dmd main.d a.obj b.obj Bar.bar() dmd main.d b.obj a.obj Bar.bar() ============================================ dmd main.d a.d b.d Bar.bar() dmd main.d b.d a.d Bar.bar() OK, it's not a bug, it's a feature! I believe we now know why compiling object modules seperately causes problems. Walter, I think you have a big problem here.
Careful.. don't confuse the original topic here with a different topic. The start of this is changing a module such that it doesn't match the .obj/.o being linked in. Your example is order of linking. If you lie to the compiler about the contents of the compiled code by changing the header, you're out of luck in general.
The OP was demonstrating a problem that can manifest itself in many ways with versioning, making bugs caused by this hard to find and fix (because the program might not crash). For example: module a; import b, std.stdio; void main() { B b = new B; writefln(b.foo(10)); } module b; class B { version(bar) int bar(int x) { return x + x; } int foo(int x) { return x * x; } } 20 Like the OP, DMC and also VC++ will call the correct function with equivalent code. I'm sure this will become a problem with library users not building their apps. with the same compiler conditionals that were used to build the library. So if it is something that wouldn't greatly complicate D compilers (or drastically effect performance in calling virtual methods) then it would be a nice to have change. - Dave
Mar 05 2006