boost crowd.
Alexey Veselovsky
alexey.veselovsky at gmail.com
Mon Nov 28 04:00:50 PST 2011
ok. I just removed from test.di all non public entities.
// D import file generated from 'test.d'
module test;
public
{
void foo();
struct Boo
{
public
{
void boo();
}
}
}
Now, let's build it:
$ dmd test.di test.d main.d
test.d: Error: module test from file test.d conflicts with another
module test from file test.di
di file not specification, but just another version of implementation?
ok. let's separate build.
$ dmd -c test.d
$ dmd main.d test.di
main.d(7): Error: no property 'S' for type 'Boo'
main.d(7): Error: Boo.S is used as a type
main.d(8): Error: undefined identifier HelperStruct
It seem like ok. Expected error. We fix it, and everybody happy. But
after years, someone changes test.d:
module test;
public {
void foo() {foo_helper();}
struct Boo
{
public:
void booBar() {S ss; foo_helper();} // <---- method was renamed
private:
struct S {};
}
}
private {
struct HelperStruct {};
void foo_helper() {HelperStruct s;}
}
He rename method, but forgot to change test.di. Let's build it:
$ dmd -c test.d
$ dmd main.d test.di
Undefined symbols for architecture i386:
"_D4test3Boo3booMFZv", referenced from:
__Dmain in main.o
"_D4test3fooFZv", referenced from:
__Dmain in main.o
ld: symbol(s) not found for architecture i386
collect2: ld returned 1 exit status
Oops. No compilation error. Only linker error. Welcome back to C!
Compiler doesn't know anything about "specification" files. So, he
did't check specification&implementation conformance.
More information about the Digitalmars-d
mailing list