Re: object.d: Error: module object is in file 'object.d' which cannot be read
On 2011-03-27 23:05, Jonathan M Davis wrote: On 2011-03-27 13:20, Jacob Carlborg wrote: On 2011-03-27 21:24, Ishan Thilina wrote: @Jacob: An error comes when the ./dvm install dvm command is given. ./dvm: error while loading shared libraries: libz.so.1: cannot open shared object file: No such file or directory You don't have libz installed? Oh, you're running 64bit, you need to install 32bit libraries. I also forgot to mention that DVM currently only installs the 32bit version of DMD. The 64bit version is quite new, don't know if it's experimental, alpha or beta. Probably alpha. I believe that it mostly works, but there are still plenty of bugs to find, I'm sure. However, depending on what you mean by installing the compiler, there is no 32-bit vs 64-bit version. Only the libraries differ. There is only a 32-bit binary for the compiler, and you pass it -m64 if you want it to compile 64-bit binaries. So, if your tool deals with the compiler only, then 32-bit vs 64-bit is currently a moot point. On the other hand, if it deals with the standard libraries too (as it probably does), then 32-bit vs 64-bit _is_ an issue, but it isn't an issue for the compiler itself. And unless you're not using the standard dmd.conf as part of switching compilers, there would already be a difference in the library layout once 64-bit compilation was introduced, since the 32-bit Phobos was moved from dmd2/linux/lib to dmd2/linux/lib32 (with the 64-bit version in dmd2/linux/lib64). And if you made the lib32 change, then having it work with 64-bit is likely trivial. And if you didn't make such a change, you're going to have to eventually. Personally, I don't see tha alpha quality of the 64-bit code generation to be a reason not to support it. It's been released. But then again, I don't use your tool at all and find no need for it, so it's not like I'm one of your users. - Jonathan M Davis What I meant with installing is that he shouldn't expect to be able to produce 64bit binaries with a DMD installed with my tool. I have changed the tool to handle the lib - lib32/lib64 change. It is a trivial change to make the 64bit installation possible. The reason I have made that change yet is a couple of reasons: * I was planning to refactor the whole tool into a library and a tool using that library. I was planning to wait with all the new functionality until after the refactoring was done. * I'm not 100% how I want the default behavior to be. When the 64bit is mature enough that will probably be the default when running on a 64bit machine and otherwise 32bit. I will also provide an option to installed the non-native library as well. The question is, what should be the default behavior now on a 64bit machine, 32bit or 64bit? Yes, I do have a custom dmd.conf. No reason to put the bin folder in an extra folder just because that's the layout in the zip file. I guess you're right, that I shouldn't blame the current status of the 64bit code generation as a reason not to support installing it. Just thought it was easier to explain it that way the more complete explanation I gave here. I do know that the compiler can produce both 32 and 64bit binaries and the only difference is the standard library. -- /Jacob Carlborg
Re: null Vs [] return arrays
bearophile Wrote: Kagamin: [] is not null, it's an array of 0 elements, what is done exactly. edx points to the allocated array. I don't understand what you say. I think the caller of foo() and bar() receive the same thing, two empty registers. I think that cast(int[])null and cast(int[])[] are the same thing for D. That's a mistake. Well, if there's no differnce for you, you can use either of them. What's the problem?
Re: Sample source code for D
On 03/28/2011 05:43 AM, Ishan Thilina wrote: @ David: I'm looking for example code that explains specific pieces of functionality :) @Lutger: Those two links were really helpful :). Thank you :) There are tutorial examples of D code at DSource; they were initially D1, but many of them are compatible or translated to D2; rather good place to start: http://www.dsource.org/projects/tutorials On the official D wiki, you'll find some useful material and links (tutorial, example, howto); unfortunatly, some of those materials are rather light: http://prowiki.org/wiki4d/wiki.cgi?DevelopmentWithD http://prowiki.org/wiki4d/wiki.cgi?D__Tutorial http://prowiki.org/wiki4d/wiki.cgi?HowTo http://prowiki.org/wiki4d/wiki.cgi?ExamplesRoadmap Also useful comparisons: http://prowiki.org/wiki4d/wiki.cgi?LanguagesVersusD http://en.wikibooks.org/wiki/D_Transition_Guide Denis -- _ vita es estrany spir.wikidot.com
How do you use BinaryHeap with Array (or just make a growable heap)?
I need a (growable) binary heap, and I'm trying to avoid writing one myself (which isn't too hard, of course :) ... but for some reason I can't figure out how to use Phobos to do it. I've seen stated (e.g., by Andrei and in the docs) that the standard way is combining BinaryHeap with an Array. Which is fine with me. Except I can't make it work. E.g., I try: Array!uint A; auto Q = heapify(A); The error is /path/to/phobos/std/container.d(2658): Error: template instance BinaryHeap!(Array!(uint)) does not match template declaration BinaryHeap(Store,alias less = a b) if (isRandomAccessRange!(Store) || isRandomAccessRange!(typeof(Store.init[]))) /path/to/phobos/std/container.d(2658): Error: BinaryHeap!(Array!(uint)) is used as a type When I check it out, it seems that isRandomAccessRange!(Array!uint) returns false (and it doesn't, AFAIK, have an init), which means that the error makes sense. Does this mean... 1. That Array isn't, and shouldn't be, a random access range? 2. That Array can't, and shouldn't be (despite official statements to the contrary) be used with BinaryHeap? (I suspect the answer to both is you're doing it wrong ;) And, of course, my main question: 3. How do you (canonically) make a growable heap using Phobos? -- Magnus Lie Hetland http://hetland.org
Re: inline functions
On Fri, 25 Mar 2011 22:04:20 -0400, Caligo iteronve...@gmail.com wrote:
T[3] data;
T dot(const ref Vector o){
return data[0] * o.data[0] + data[1] * o.data[1] + data[2] *
o.data[2];
}
T LengthSquared_Fast(){ return data[0] * data[0] + data[1] * data[1] +
data[2] * data[2]; }
T LengthSquared_Slow(){ return dot(this); }
The faster LengthSquared() is twice as fast, and I've test with GDC
and DMD. Is it because the compilers don't inline-expand the dot()
function call? I need the performance, but the faster version is too
verbose.
ref parameters used to make functions not be inlined, but apparently that
was fixed: http://d.puremagic.com/issues/show_bug.cgi?id=2008
The best thing to do is check the disassembly to see if the call is being
inlined.
Also, if you want more help besides guessing, a complete working program
is good to have.
-Steve
Re: null Vs [] return arrays
On Sun, 27 Mar 2011 09:37:47 -0400, bearophile bearophileh...@lycos.com
wrote:
I have compiled this little D2 program:
int[] foo() {
return [];
}
int[] bar() {
return null;
}
void main() {}
Using DMD 2.052, dmd -O -release -inline test2.d
This is the asm of the two functions:
_D5test23fooFZAicomdat
L0: pushEAX
mov EAX,offset FLAT:_D11TypeInfo_Ai6__initZ
push0
pushEAX
callnear ptr __d_arrayliteralT
mov EDX,EAX
add ESP,8
pop ECX
xor EAX,EAX
ret
_D5test23barFZAicomdat
xor EAX,EAX
xor EDX,EDX
ret
Is this expected and desired? Isn't it better to compile the foo() as
bar()?
Probably. The runtime that allocates an array looks like this (irrelevant
parts collapsed):
extern (C) void* _d_arrayliteralT(TypeInfo ti, size_t length, ...)
{
auto sizeelem = ti.next.tsize();// array element size
void* result;
...
if (length == 0 || sizeelem == 0)
result = null;
else
{
...
}
return result;
}
So essentially, you are getting the same thing, but using [] is slower.
-Steve
Container access in std.container
I know that D has some Containers implemented by default( such as a a List,
Red-black tree, Array). In C++ these data structures can be used as follows.
#include vector
int main(){
std::vectorint myVector;
std::vectorint::iterator myIterator;
}
Then I can use myIterator to manipulate myVector.
But in D the containers are embedded in the std.container( as far as I
understood it) and I can't do import std.container too. So how can I access
the built in containers?
Thank you..!
Re: Sample source code for D
@Denis: The tutorials in the dsource were very helpful. I have read most of those articles that are in the prowiki( the ones you have given links to). As you have stated they are more suited for beginners :-/ . Thank you for the help :)
unit testing
I see that almost all of the phobos library files have unittests. Were these unit tests were created using some framework? If so, then what is it? Thank you...!
Re: unit testing
On 3/28/11 4:23 PM, Ishan Thilina wrote: I see that almost all of the phobos library files have unittests. Were these unit tests were created using some framework? If so, then what is it? Thank you...! No, these unit test were just written by hand while writing the corresponding pieces of code, and extended after a bug was fixed which they previously missed. Or was your question related to actually running them? David
Re: Container access in std.container
On 3/28/11 4:17 PM, Ishan Thilina wrote:
I know that D has some Containers implemented by default( such as a a List,
Red-black tree, Array). In C++ these data structures can be used as follows.
#includevector
int main(){
std::vectorint myVector;
std::vectorint::iterator myIterator;
}
Then I can use myIterator to manipulate myVector.
But in D the containers are embedded in the std.container( as far as I
understood it) and I can't do import std.container too. So how can I access
the built in containers?
Hi Ishan,
First, to avoid confusion in further discussions, the term »built-in« is
usually used when referring to the types which are part of the D
language itself (e.g. the built-in arrays and associative arrays, i.e.
int[] and int[string]). The types std.container, on the other hand,
could be in any other library as well, so I wouldn't call them built-in,
but rather just Phobos containers.
What exactly do you mean by »I can't do import std.container«?
Assuming you have a working D2 environment, you should be able to use
them like this:
---
import std.container;
import std.stdio;
void main() {
auto rb = redBlackTree(4, 1, 2, 3);
foreach (e; rb) {
writeln(e);
}
}
---
To get a range over all elements (in an container-defined order), use
the slicing operator [], e.g. rb[] – if I remember correctly, the
std.container ddoc page has more information on commonly supported
operations.
David
Re: object.d: Error: module object is in file 'object.d' which cannot be read
@Jonathan:
Yeah I checked. It's there :s. I dont know what has gone wrong, but I'm using
the
default settings . I have GDC installed too. Can this have any connection with
this problem( just a wild guess ) ?
@Jacob:
I wasn't sure about which libraries you were talking about. The only lib set I
left out was ia32-libs. So I installed it too.That didn't solve the problem. So
I
tried to install the deb file by force.
sudo dpkg -i --force-architecture dmd***.dmd
now I get a whole lot more errors :s.
ishan@ishan-Ubu-I1464:~/Geany Projects$ dmd untitle.d
/usr/include/d/dmd/phobos/object.d(51): C-style function pointer and pointer to
array syntax is deprecated. Use 'function' to declare function pointers
/usr/include/d/dmd/phobos/std/format.d(672): no identifier for declarator
inout(fakevalue)
/usr/include/d/dmd/phobos/std/c/stdlib.d(43): C-style function pointer and
pointer
to array syntax is deprecated. Use 'function' to declare function pointers
/usr/include/d/dmd/phobos/std/c/stdlib.d(59): C-style function pointer and
pointer
to array syntax is deprecated. Use 'function' to declare function pointers
/usr/include/d/dmd/phobos/std/c/linux/linux.d(558): C-style function pointer and
pointer to array syntax is deprecated. Use 'function' to declare function
pointers
/usr/include/d/dmd/phobos/std/c/linux/linux.d(574): C-style function pointer and
pointer to array syntax is deprecated. Use 'function' to declare function
pointers
I'm trying to compile the following simple code. As you can see it should work
without any problem.
import std.stdio;
int main()
{
writefln(Hello world);
return 0;
}
Where does the template parameter E come from?
When running compose with two arguments, the implementation uses the
template parameter E. I don't understand what's going on here as E isn't
submitted to the template - what type is E?
I've also seen this in unary/binaryFun using ElementType.
template compose(fun...) { alias composeImpl!(fun).doIt compose; }
// Implementation of compose
template composeImpl(fun...)
{
static if (fun.length == 1)
{
static if (is(typeof(fun[0]) : string))
alias unaryFun!(fun[0]) doIt;
else
alias fun[0] doIt;
}
else static if (fun.length == 2)
{
// starch
static if (is(typeof(fun[0]) : string))
alias unaryFun!(fun[0]) fun0;
else
alias fun[0] fun0;
static if (is(typeof(fun[1]) : string))
alias unaryFun!(fun[1]) fun1;
else
alias fun[1] fun1;
// protein: the core composition operation
typeof({ E a; return fun0(fun1(a)); }()) doIt(E)(E a)
{
return fun0(fun1(a));
}
}
else
{
// protein: assembling operations
alias composeImpl!(fun[0], composeImpl!(fun[1 .. $]).doIt).doIt
doIt;
}
}
Re: clear()
On 03/25/2011 01:10 PM, Dr.Smith wrote: To empty many arrays of various types, rather than: clear(arr1); clear(arr2); ... clear(arrN); is there something like: clear(ALL); No, but perhaps you can do a: foreach(a; ALL) a.clear() But that would require you having an iterable sequence that contains all of your arrays, which may or may not be worth your time to explore. Also, after clear(arr), will arr ~= value assign starting from element 0? Yes
Re: Little quiz
On 03/24/2011 06:50 PM, bearophile wrote:
A little quiz for people here: guess the output of this little D2 program (it
compiles correctly and doesn't crash at run time, so it's a fair question):
import std.typecons: tuple;
import std.c.stdio: printf;
auto foo() {
printf(foo\n);
return tuple(1, 2);
}
void main() {
foreach (x; foo().tupleof)
printf(%d\n, x);
}
Bye,
bearophile
That's pretty cool :) Seems like we should be able to expect the same
behavior in all of these, but that doesn't appear to be the case at all.
import std.typecons: tuple;
import std.c.stdio: printf;
auto foo() {
printf(foo\n);
return tuple(1, 2);
}
void main() {
printf(-\n);
foreach (x; foo().tupleof)
printf(%d\n, x);
printf(-\n);
auto f = foo();
printf(-\n);
foreach (x; f.tupleof)
printf(%d\n, x);
printf(-\n);
auto f2 = foo().tupleof;
printf(-\n);
foreach (x; f2)
printf(%d\n, x);
printf(-\n);
}
Re: Where does the template parameter E come from?
On 28.03.2011 16:54, simendsjo wrote:
When running compose with two arguments, the implementation uses the
template parameter E. I don't understand what's going on here as E isn't
submitted to the template - what type is E?
I've also seen this in unary/binaryFun using ElementType.
template compose(fun...) { alias composeImpl!(fun).doIt compose; }
// Implementation of compose
template composeImpl(fun...)
{
static if (fun.length == 1)
{
static if (is(typeof(fun[0]) : string))
alias unaryFun!(fun[0]) doIt;
else
alias fun[0] doIt;
}
else static if (fun.length == 2)
{
// starch
static if (is(typeof(fun[0]) : string))
alias unaryFun!(fun[0]) fun0;
else
alias fun[0] fun0;
static if (is(typeof(fun[1]) : string))
alias unaryFun!(fun[1]) fun1;
else
alias fun[1] fun1;
// protein: the core composition operation
typeof({ E a; return fun0(fun1(a)); }()) doIt(E)(E a)
{
return fun0(fun1(a));
}
}
else
{
// protein: assembling operations
alias composeImpl!(fun[0], composeImpl!(fun[1 .. $]).doIt).doIt doIt;
}
}
I think I get it.
doIt becomes the function being called. So E is the type of the
parameter being used when calling compose.
Re: Where does the template parameter E come from?
On 3/28/11 4:54 PM, simendsjo wrote:
When running compose with two arguments, the implementation uses the
template parameter E. I don't understand what's going on here as E isn't
submitted to the template - what type is E?
[…]
typeof({ E a; return fun0(fun1(a)); }()) doIt(E)(E a)
{ […] }
doIt is a function template, so E will be deduced to be whatever type
the passed argument is – you won't notice the extra »template layer« as
E is automatically inferred from the argument.
For better understanding, you might want to look at the definition like
this:
---
template composeImpl(fun...) {
[…]
template doIt(E) {
typeof({ E a; return fun0(fun1(a)); }()) doIt(E a) {
[…]
}
}
}
---
David
Re: Where does the template parameter E come from?
On 3/28/11 5:14 PM, simendsjo wrote:
On 28.03.2011 17:07, David Nadlinger wrote:
On 3/28/11 4:54 PM, simendsjo wrote:
When running compose with two arguments, the implementation uses the
template parameter E. I don't understand what's going on here as E isn't
submitted to the template - what type is E?
[…]
typeof({ E a; return fun0(fun1(a)); }()) doIt(E)(E a)
{ […] }
doIt is a function template, so E will be deduced to be whatever type
the passed argument is – you won't notice the extra »template layer« as
E is automatically inferred from the argument.
For better understanding, you might want to look at the definition like
this:
---
template composeImpl(fun...) {
[…]
template doIt(E) {
typeof({ E a; return fun0(fun1(a)); }()) doIt(E a) {
[…]
}
}
}
---
David
Thanks. That seems like a good way of mentally mapping template usage
until it comes more naturally.
Even more, due to the eponymous template »trick«, there is almost no
difference between the forms – with the important exception being that
function templates enjoy IFTI (implicit function template
instantiation), the feature which allows you to omit the type
parameter(s) if it can be deduced from the arguments.
David
Re: Where does the template parameter E come from?
On 28.03.2011 17:07, David Nadlinger wrote:
On 3/28/11 4:54 PM, simendsjo wrote:
When running compose with two arguments, the implementation uses the
template parameter E. I don't understand what's going on here as E isn't
submitted to the template - what type is E?
[…]
typeof({ E a; return fun0(fun1(a)); }()) doIt(E)(E a)
{ […] }
doIt is a function template, so E will be deduced to be whatever type
the passed argument is – you won't notice the extra »template layer« as
E is automatically inferred from the argument.
For better understanding, you might want to look at the definition like
this:
---
template composeImpl(fun...) {
[…]
template doIt(E) {
typeof({ E a; return fun0(fun1(a)); }()) doIt(E a) {
[…]
}
}
}
---
David
Thanks. That seems like a good way of mentally mapping template usage
until it comes more naturally.
Re: unit testing
On 3/28/11 5:55 PM, Caligo wrote: and how does one do unit testing with GDC? It works fine with DMD, but GDC doesn't do unit testing when -unittest is supplied. -funittest, IIRC. David
Re: std.conv.to can't convert to bool?
Andrej Mitrovic Wrote: Wow not a minute later and I get bitten by my own solution. A C function returned 1 for a supported feature, and -1 otherwise. And of course -1 got converted to true, so then I had a bug in my code. Damn silly C functions which return -1 when they should return 0. Or damn me for not RTFM'ing. Yeah, so the reason it doesn't do that conversion is because it will bite you. Actually D already uses non-zero as true. Why do you need to cast it?
Re: object.d: Error: module object is in file 'object.d' which cannot be read
On 03/28/2011 04:49 PM, Ishan Thilina wrote:
now I get a whole lot more errors :s.
ishan@ishan-Ubu-I1464:~/Geany Projects$ dmd untitle.d
/usr/include/d/dmd/phobos/object.d(51): C-style function pointer and pointer to
array syntax is deprecated. Use 'function' to declare function pointers
/usr/include/d/dmd/phobos/std/format.d(672): no identifier for declarator
inout(fakevalue)
/usr/include/d/dmd/phobos/std/c/stdlib.d(43): C-style function pointer and
pointer
to array syntax is deprecated. Use 'function' to declare function pointers
/usr/include/d/dmd/phobos/std/c/stdlib.d(59): C-style function pointer and
pointer
to array syntax is deprecated. Use 'function' to declare function pointers
/usr/include/d/dmd/phobos/std/c/linux/linux.d(558): C-style function pointer and
pointer to array syntax is deprecated. Use 'function' to declare function
pointers
/usr/include/d/dmd/phobos/std/c/linux/linux.d(574): C-style function pointer and
pointer to array syntax is deprecated. Use 'function' to declare function
pointers
I'm trying to compile the following simple code. As you can see it should work
without any problem.
import std.stdio;
int main()
{
writefln(Hello world);
return 0;
}
I have no idea why and where your issues in using D with dmd come from. AFAIK,
it just works out of the box if you use release versions.
Just 2 notes about the piece of code:
First, you often do not need in D a program result code (int).
Second, writefln, as opposed to writeln, expects a format string as first
argument.
void main () {
writeln(Hello, world!);
auto userName = Otto;
writefln(Hello, %s!, userName);
}
Denis
--
_
vita es estrany
spir.wikidot.com
Re: Little quiz
Kai Meyer: auto f2 = foo().tupleof; Thank you. From the output of this line of code the problem seems not caused by the static foreach. Bye, bearophile
Re: null Vs [] return arrays
Steven Schveighoffer: So essentially, you are getting the same thing, but using [] is slower. It seems I was right then, thank you and Kagamin for the answers. Bye, bearophile
Re: Container access in std.container
I am using DGC due to the problems I'm witnessing with DMD. I tried a similar approach. But the following error comes. structures.d:4: Error: module container cannot read file 'std/container.d' import path[0] = /usr/lib/gcc/x86_64-linux-gnu/4.3.5/../../../../include/d/4.3.5/x86_64-linux-gnu import path[1] = /usr/lib/gcc/x86_64-linux-gnu/4.3.5/../../../../include/d/4.3.5 I dont know what is wrong. I'll try to compile in Windows and let you know. @David : Thanks for the clarifications :)
Re: unit testing
@David: No, my question was not about running them,but on how that code was generated. I thought they were auto generated using a unitest framework :). Your answer clarifies everything. Thank you..! :-)
Re: How do you use BinaryHeap with Array (or just make a growable heap)?
On 2011-03-28 20:24:55 +0200, Jonathan M Davis said: Well, Array definitely shouldn't be a random access range. The range for it (which you'd typically get by slicing it) would be random access, but the container itself isn't a range of any kind. Containers aren't ranges (barring the oddities of dynamic arrays). I've never used BinaryHeap, but glancing at it, my guess would be that the correct solution (if you want to use Array with it) is to create an Array and then pass its range to heapify: Array!uint a; //... put stuff in a. auto heap = heapify(a[]); I'm not sure if that's growable or not though. Hm. I can't even get the slicing to work: /path/to/phobos/std/container.d(2436): Error: function std.container.Array!(uint).Array.Range.opSlice (uint a, uint b) is not callable using argument types () Glancing at BinaryHeap, it'll work with arrays though, so you don't need to use Array. Hm. The docs say If Store is a range, the BinaryHeap cannot grow beyond the size of that range. If Store is a container that supports insertBack, the BinaryHeap may grow by adding elements to the container. So it seems that a container (such as Array, which has insertBack) should be usable, according to the docs. And an array/slice would not be growable. (At least, it isn't growable in practice.) See also: http://www.digitalmars.com/d/archives/digitalmars/D/std.algorithm.BinaryHeap_88811.html What I'm looking for is a completely standard priority queue, where I can add and remove objects, and not have to know the maximum size beforehand. I'd also like to have tuple entries, but it seems that BinaryHeap has trouble with that as well... I don't know what the ideal container to use with a BinaryHeap is though. Also, in my experience, Array is pretty buggy at this point, so I'm not sure how far you'll get with it. Yeah, it seems to be. At the moment, I've just reimplemented BinaryHeap myself (with a subset of the Phobos API), so that it can handle arrays of tuples (which I couldn't get std.container.BinaryHeap to accept). I then wrapped it in a PriorityQueue class, which takes care of resizing the array (and having BinaryHeap switch to the possibly reallocated new one). Not an ideal solution, but at least it works. -- Magnus Lie Hetland http://hetland.org
Re: unit testing
On 2011-03-28 11:29, Ishan Thilina wrote: @David: No, my question was not about running them,but on how that code was generated. I thought they were auto generated using a unitest framework :). Your answer clarifies everything. Thank you..! :-) LOL. Goodness no. They're done by hand. I'm currently reworking std.datetime's unit tests, and it's very time consuming (since it's a large module with lots of tests). I don't know how you'd get a framework to generate what I want anyway. The fact that D has unit testing built in like it does is fantastic, but it is fairly simplistic. - Jonathan M Davis
Re: Assertion failure: '!vthis-csym' on line 703 in file 'glue.c'
nrgyzer wrote: Hey guys, I got Assertion failure: '!vthis-csym' on line 703 in file 'glue.c' after I add LinkList!(uint) myList; to my source file. I figured out that the same bug was already reported on http://lists.puremagic.com/ pipermail/digitalmars-d-bugs/2010-October/019237.html Ticket 4129 describes a bug in glue.c but for DMD 1.x and I'm using DMD 2.052. It's still the same bug. The source code for the backend is the same for all versions of DMD. The reported line number might change slightly (eg, might be line 691 on an old DMD version).
Re: Container access in std.container
I am using GDC due to the problems I'm witnessing with DMD. I tried a similar approach. But the following error comes. structures.d:4: Error: module container cannot read file 'std/container.d' import path[0] = /usr/lib/gcc/x86_64-linux-gnu/4.3.5/../../../../include/d/4.3.5/x86_64-linux-gnu import path[1] = /usr/lib/gcc/x86_64-linux-gnu/4.3.5/../../../../include/d/4.3.5 I dont know what is wrong. I'll try to compile in Windows and let you know. A module std.container cannot be found error comes in windows too. I'm using GDC to compile in linux and DMD to compile in windows. I'm really confused about this :s
Re: clear()
On Mon, 28 Mar 2011 16:57:17 +0200, Kai Meyer k...@unixlords.com wrote: On 03/25/2011 01:10 PM, Dr.Smith wrote: To empty many arrays of various types, rather than: clear(arr1); clear(arr2); ... clear(arrN); is there something like: clear(ALL); No, but perhaps you can do a: foreach(a; ALL) a.clear() That should probably be foreach ( a; ALL ) clear( a ); -- Simen
