[Issue 846] New: Error 42: Symbol Undefined _D1a7__arrayZ
d-bugmail at puremagic.com
d-bugmail at puremagic.com
Sat Jan 13 09:28:30 PST 2007
http://d.puremagic.com/issues/show_bug.cgi?id=846
Summary: Error 42: Symbol Undefined _D1a7__arrayZ
Product: D
Version: 0.177
Platform: PC
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: bugzilla at digitalmars.com
ReportedBy: sean at f4.ca
This is a variation of the "template library bug," similar to why std.boxer is
incompatible with debug user apps. Support for in/out contracts seems to be
fixed, as they always seem to be generated within the template function body,
but it appears that array bounds and assertion checks are still sometimes
expected to exist in the object containing the declaration of the template
code. Here is an example:
module a;
template ElemTypeOf( T )
{
alias typeof(T[0]) ElemTypeOf;
}
template removeIf_( Elem, Pred )
{
size_t fn( Elem[] buf, Pred pred )
{
void exch( size_t p1, size_t p2 )
{
Elem t = buf[p1];
buf[p1] = buf[p2];
buf[p2] = t;
}
size_t cnt = 0;
for( size_t pos = 0, len = buf.length; pos < len; ++pos )
{
if( pred( buf[pos] ) )
++cnt;
else
exch( pos, pos - cnt );
}
return buf.length - cnt;
}
}
template removeIf( Buf, Pred )
{
size_t removeIf( Buf buf, Pred pred )
{
return removeIf_!(ElemTypeOf!(Buf), Pred).fn( buf, pred );
}
}
----------
import a;
void main()
{
auto num = removeIf( "abcdef".dup, ( char c ) { return c == 'c'; } );
}
C:\code\src\d\test>dmd b
c:\bin\dmd\bin\..\..\dm\bin\link.exe b,,,user32+kernel32/noi;
OPTLINK (R) for Win32 Release 7.50B1
Copyright (C) Digital Mars 1989 - 2001 All Rights Reserved
b.obj(b)
Error 42: Symbol Undefined _D1a7__arrayZ
--- errorlevel 1
It appears that whether this error occurs may somehow be related to the
inlining mechanism, because I have some template functions that exhibit this
behavior and others that do not. This bug is a major obstacle to building
libraries containing template code in D, particularly when the user cannot
manually link a debug library because the library name is selected
automatically (as with phobos.lib). Also, I don't entirely understand why a
separate bound-check and assert function must apparently be generated for every
module, since the contents should be immutable. The easiest fix for std.boxer
(if perhaps not user libraries) would be to link separate standard libraries
for debug and release builds--phobos.lib vs. phobosd.lib, for example. But it
would be far preferable if code generation could be fixed such that this
problem no longer occurs.
--
More information about the Digitalmars-d-bugs
mailing list