Re: Print a PDF
John schrieb: BCS Wrote: Reply to John, Hello! I'm wanting to use D to send a PDF to a printer. Is there an easy way to do this? Also, I may need to set which tray to go to and whether it should duplex or not. Could someone help me out? THANKS! You would do it the same way that it would be done in C. IIRC D has no special support for that. (If you need help hunting down windows bindings, there are s few people here who work on that kind of thing) Thanks! Is there anyone here familiar with the Windows bindings? The are bindings for the libharu pdf Have a look at dsource.org project AKI / hth, Bjoern
CTFE - filling an array
Hi,
I would like to pre-create a double array, each element is calculated by
a function.
//-
import std.stdio;
import std.conv;
import std.string;
template f(int N)
{
bool fn(double[] tb)
{
for (int i = 1; i < N; i++)
tb[i] = 1.0/i;
return true;
}
}
void main(string[] args)
{
const int N = 200;
static double[N] dd = void;
static auto tmp = f!(N).fn(dd);
int n = toInt(args[1]);
writefln("test array[%d] = %f", n, dd[n]);
}
//--
dmd.2021 says: cannot evaluate "static auto tmp = f!(N).fn(dd);" at
compile-time.
How can i fix it?
Thanks.
Re: Cyclic Dependencies
On Tue, 09 Dec 2008 01:26:29 -0600, Ellery Newcomer wrote:
>
> wchar[] w = (true)? "true":"false";
>
> --> Error: cannot implicitly convert expression ("true") of type char[]
> to wchar[]
>
> or should it be reported as a bug?
It is not a bug. A string literal such as "true" is a char[] type (UTF8),
and the compiler will not implicitly convert UTF8 to UTF16 (wchar[]).
You can tell the compiler that the string literal is meant to be UTF16 by
added the suffix 'w' to the literal ... "true"w, and in that way no
conversion is required.
If for some reason you did want a run-time conversion then this should work
...
wchar[] w = std.utf.toUTF16((true)? "true":"false");
--
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
Re: Cyclic Dependencies
Ellery Newcomer wrote: When I first started learning D I decided that a good way to learn it would be by porting a popular java api (mind, I didn't say intelligent), which came complete with a few cyclic dependencies. At the moment, I'm using GDC, and it refuses to swallow cyclic dependencies. The compiler doesn't complain, but it throws a runtime exception. I can break the dependency loops and GDC will work just fine, but what I'm wondering is whether it is standard that the dependency hierarchy be acyclic, or is this some quirk of GDC, or is it more likely that there is something weird going on in my java-to-D translation. You can't use module constructors (static this) in modules that import each other.
Re: Cyclic Dependencies
Ellery Newcomer wrote: > Hello all, > > I began learning D a few months ago, and now I have a question about > cyclic dependencies (and some random whining). > > I come from a java background and have had no serious exposure to C++. > In java, cyclic dependencies are legit to the best of my knowledge. Legit in the way that they usually work - something that IMO cause a lot of Java code to be badly designed (causing too tight coupling and difficulties with extending code). > I > don't know about C++, thus I don't know about D. > > When I first started learning D I decided that a good way to learn it > would be by porting a popular java api (mind, I didn't say intelligent), > which came complete with a few cyclic dependencies. At the moment, I'm > using GDC, and it refuses to swallow cyclic dependencies. The compiler > doesn't complain, but it throws a runtime exception. I can break the > dependency loops and GDC will work just fine, but what I'm wondering is > whether it is standard that the dependency hierarchy be acyclic, or is > this some quirk of GDC, or is it more likely that there is something > weird going on in my java-to-D translation. No quirk, just good design sense. There are also some real cyclic issues in chicken-egg situations. > Also, I would be trying to compile with DMD, but I have evidently > managed to crash the compiler, and I don't know if it's DMD's fault or > mine. It reports an Internal Error in e2ir.c at line 3904. (not being a > C++ guru, the line "assert(n2->Enumbytes);" doesn't mean much to me) > That was with DMD 1.037, Tango 0.997, and using dsss to build. Tango 0.99.7 doesn't support DMD 1.037 - either use DMD 1.033 or check out Tango trunk. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Re: Cyclic Dependencies
On Tue, 09 Dec 2008 10:26:29 +0300, Ellery Newcomer <[EMAIL PROTECTED]> wrote:
Also, I would be trying to compile with DMD, but I have evidently
managed to crash the compiler, and I don't know if it's DMD's fault or
mine. It reports an Internal Error in e2ir.c at line 3904. (not being a
C++ guru, the line "assert(n2->Enumbytes);" doesn't mean much to me)
That was with DMD 1.037, Tango 0.997, and using dsss to build.
This is a bug for sure. Could you please post a code sample that causes this
behavior (a small one, if possible)?
On an unrelated note, is this code supposed to be incorrect?
wchar[] w = (true)? "true":"false";
--> Error: cannot implicitly convert expression ("true") of type char[]
to wchar[]
or should it be reported as a bug?
Yes it is correct. You need to specify return type explicitly by making at
least one of the arguments wide:
wchar[] w = true ? "true"w : "false";
wchar[] w = true ? "true" : "false"w;
wchar[] w = true ? "true"w : "false"w;
Re: Print a PDF
BLS Wrote: > John schrieb: > > BCS Wrote: > > > >> Reply to John, > >> > >>> Hello! > >>> > >>> I'm wanting to use D to send a PDF to a printer. Is there an easy way > >>> to do this? Also, I may need to set which tray to go to and whether it > >>> should duplex or not. > >>> > >>> Could someone help me out? > >>> > >>> THANKS! > >>> > >> You would do it the same way that it would be done in C. IIRC D has no > >> special > >> support for that. (If you need help hunting down windows bindings, there > >> are s few people here who work on that kind of thing) > >> > >> > > > > Thanks! > > > > Is there anyone here familiar with the Windows bindings? > > The are bindings for the libharu pdf Have a look at dsource.org project > AKI / > > hth, > Bjoern Aki seems to be a PDF generation library. What does this have to do with printing? Thanks!
Re: Inline Assembler: Getting the offset of a label. How?
poly Wrote:
> asm
> {
> call Label1;
> Label1: pop ECX;
> mov EAX, Label1; //error reported on this line
> }
I tried several tricks, seems like compiler doesn't support this.
Re: Freeing of memory (garbage collection)
Dan W: > 1: Even though D has an automatic garbage collector, is one still > allowed to free the memory of a malloced array manually (using free > () ), to avoid pauses in the program? Other people here will just answer your question. But remember that in D manual memory management is done only in special situations, most code of most programs just use the GC. Bye, bearophile
Re: Freeing of memory (garbage collection)
Thanks for that reply. I wonder if extending automatic garbage collection for malloced memory would be a good idea... > Only stuff like dynamic > arrays, AAs and new'ed stuff gets cleaned up by the GC. For the above types of allocating memory, is there a way to 'lock' a variable and say to D, "don't free this memory until I allow you to", and also for it to allow you to free it manually when/if need be?
Re: Cyclic Dependencies
"Ellery Newcomer" wrote
> Hello all,
>
> I began learning D a few months ago, and now I have a question about
> cyclic dependencies (and some random whining).
>
> I come from a java background and have had no serious exposure to C++. In
> java, cyclic dependencies are legit to the best of my knowledge. I don't
> know about C++, thus I don't know about D.
>
> When I first started learning D I decided that a good way to learn it
> would be by porting a popular java api (mind, I didn't say intelligent),
> which came complete with a few cyclic dependencies. At the moment, I'm
> using GDC, and it refuses to swallow cyclic dependencies. The compiler
> doesn't complain, but it throws a runtime exception. I can break the
> dependency loops and GDC will work just fine, but what I'm wondering is
> whether it is standard that the dependency hierarchy be acyclic, or is
> this some quirk of GDC, or is it more likely that there is something weird
> going on in my java-to-D translation.
I'm not sure about this problem. I've not encountered it, but it sounds
weird that it would cause a runtime error...
>
> Also, I would be trying to compile with DMD, but I have evidently managed
> to crash the compiler, and I don't know if it's DMD's fault or mine. It
> reports an Internal Error in e2ir.c at line 3904.
This is a bug in the compiler. Try to figure out what causes the bug
(smallest example possible), and post it to digitalmars' bugzilla. These
are very weird, sometimes hard to narrow down issues, but it helps the
compiler writers to have a small test case to reproduce it.
> (not being a C++ guru, the line "assert(n2->Enumbytes);" doesn't mean much
> to me)
It's saying n2->Enumbytes should not be null, if it is, then throw throw an
error.
> That was with DMD 1.037, Tango 0.997, and using dsss to build.
Hm... as far as I know, DMD 1.037 doesn't work with Tango 0.99.7. Did you
recompile Tango? Or are you using precompiled libraries? If you are, you
should match the compiler to what the libraries were built with. If you
need to use 1.037, download the latest svn Tango trunk and compile it, or
wait for the next release. There are many corrected issues due to compiler
changes in the Tango source tree.
>
> On an unrelated note, is this code supposed to be incorrect?
>
> wchar[] w = (true)? "true":"false";
>
> --> Error: cannot implicitly convert expression ("true") of type char[] to
> wchar[]
A string literal such as "true" is typed as char[]. You cannot assign a
char[] to a wchar[] without a cast. Like Zarathustra said, a wchar[] string
literal is written as "true"w.
-Steve
Re: CTFE - filling an array
The Anh Tran wrote: static double[N] dd = void; dd is not a compile-time constant. static auto tmp = f!(N).fn(dd); The initializer of tmp must be a compile-time constant, but since dd is not a compile-time constant, you can't use CTFE on fn.
Re: Freeing of memory (garbage collection)
"Daniel White" wrote
> Thanks for that reply. I wonder if extending automatic garbage
> collection for malloced memory would be a good idea...
>
>> Only stuff like dynamic
>> arrays, AAs and new'ed stuff gets cleaned up by the GC.
>
> For the above types of allocating memory, is there a way to 'lock' a
> variable and say to D, "don't free this memory until I allow you to",
> and also for it to allow you to free it manually when/if need be?
One thing you can do, that nobody has mentioned yet, is delete memory that
you have allocated using the GC.
Deleting a block of memory that the GC has allocated allows you to reuse
that memory without going through a full GC collect cycle, and so most
likely your performance will be better. Using delete in key spots can be
good.
But using manual memory mangement prevents lots of good designs, so use with
caution.
Lastly, if you are allocating lots of temporary classes, try declaring them
as scope. This allocates the class on the stack if possible. Note that any
memory allocated by the constructor will still go through the GC. Also note
that you can't use a scoped class once its scope is finished. e.g.:
class C
{ ... }
...
while(x > 0)
{
scope c = new C(x--); // c is allocated on the stack. scope keyword
implies the type.
c.doSomething();
// c is deleted from stack at end of loop iteration. No heap activity.
}
-Steve
Re: Freeing of memory (garbage collection)
On Tue, Dec 9, 2008 at 9:16 AM, Daniel White <[EMAIL PROTECTED]> wrote: > Thanks for that reply. I wonder if extending automatic garbage > collection for malloced memory would be a good idea... That would be a bad idea. Then how would you do manual memory management in the few cases that absolutely require it? >> Only stuff like dynamic >> arrays, AAs and new'ed stuff gets cleaned up by the GC. > > For the above types of allocating memory, is there a way to 'lock' a > variable and say to D, "don't free this memory until I allow you to", > and also for it to allow you to free it manually when/if need be? Yes, you can use std.gc.addRoot in Phobos (in D1), and GC.addRoot if you're using Tango (import tango.core.Memory) or D2 (import core.memory).
Re: Freeing of memory (garbage collection)
On Tue, Dec 9, 2008 at 9:42 AM, Jarrett Billingsley <[EMAIL PROTECTED]> wrote: > On Tue, Dec 9, 2008 at 9:16 AM, Daniel White <[EMAIL PROTECTED]> wrote: >> Thanks for that reply. I wonder if extending automatic garbage >> collection for malloced memory would be a good idea... > > That would be a bad idea. Then how would you do manual memory > management in the few cases that absolutely require it? > >>> Only stuff like dynamic >>> arrays, AAs and new'ed stuff gets cleaned up by the GC. >> >> For the above types of allocating memory, is there a way to 'lock' a >> variable and say to D, "don't free this memory until I allow you to", >> and also for it to allow you to free it manually when/if need be? > > Yes, you can use std.gc.addRoot in Phobos (in D1), and GC.addRoot if > you're using Tango (import tango.core.Memory) or D2 (import > core.memory). Oh yeah, and you can use 'delete' on arrays, classes, and structs allocated on the heap, but oddly not with AAs.
Re: Cyclic Dependencies
On Tue, Dec 9, 2008 at 9:52 AM, Steven Schveighoffer
<[EMAIL PROTECTED]> wrote:
> I'm not sure about this problem. I've not encountered it, but it sounds
> weird that it would cause a runtime error...
It is weird.
[a.d]
module a;
import b;
static this(){}
void main(){}
[b.d]
module b;
import a;
static this(){}
[Command line]
$ rebuild a
$ ./a
object.Exception: Cyclic dependency in module a
$
If two modules circularly import each other and they both have static
ctors - regardless of whether or not those ctors really are circularly
dependent - you get an error at runtime. Why it can't determine this
at compile time, I don't know. Why it's an error when there's
obviously no cyclic dependency, I don't know.
http://d.puremagic.com/issues/show_bug.cgi?id=2457
Re: Freeing of memory (garbage collection)
> That would be a bad idea. Then how would you do manual memory > management in the few cases that absolutely require it? Two ways. Either: a: being able to lock the variable so that the garbage collector can't touch it until you unlock it. b: Using a slightly different version of malloc (say 'mallocl') which again, makes it shielded against the garbage collector's wrath.
Re: Cyclic Dependencies
torhu wrote: You can't use module constructors (static this) in modules that import each other. So THAT'S why I couldn't replicate it :)
Re: Cyclic Dependencies
Derek Parnell wrote: > It is not a bug. A string literal such as "true" is a char[] type (UTF8), and the compiler will not implicitly convert UTF8 to UTF16 (wchar[]). Which would then beg the obvious wchar[] w = "true";
Re: Cyclic Dependencies
Lars Ivar Igesund wrote: Tango 0.99.7 doesn't support DMD 1.037 - either use DMD 1.033 or check out Tango trunk. Say what you will, I got it to work :) I also experienced the crash on 1.030, 1.033, and 1.035 variously on linux and windows, so 1.037 was just to see if it had been fixed by then. Just to be thorough.
Re: Freeing of memory (garbage collection)
On Tue, Dec 9, 2008 at 11:08 AM, Daniel White <[EMAIL PROTECTED]> wrote: >> That would be a bad idea. Then how would you do manual memory >> management in the few cases that absolutely require it? > > Two ways. Either: > > a: being able to lock the variable so that the garbage collector > can't touch it until you unlock it. Why not just use GC-allocated memory and use addRoot then? > b: Using a slightly different version of malloc (say 'mallocl') which again, > makes it shielded against the garbage collector's wrath. At which point you're back to the same situation as we have currently.
Re: Cyclic Dependencies
On Tue, Dec 9, 2008 at 12:00 PM, Ellery Newcomer
<[EMAIL PROTECTED]> wrote:
> Derek Parnell wrote:
> > It is not a bug. A string literal such as "true" is a char[] type (UTF8),
>>
>> and the compiler will not implicitly convert UTF8 to UTF16 (wchar[]).
>
> Which would then beg the obvious
>
> wchar[] w = "true";
It's a sort of special case. String literals are, by default, UTF-8.
But if you use a string literal in a situation where it can only be
UTF-16 or UTF-32, it's automatically converted.
However if a string literal is used in a context where it can be
multiple encodings, an error results:
void foo(char[] s) {}
void foo(wchar[] s) {}
foo("hello") fails because string literals are implicitly convertible
to both char[] and wchar[], so you have to append either a c or a w to
the literal.
As for why 'wchar[] s = true ? "true" : "false"' doesn't work, it's
because the initializer expression is semantically analyzed before
looking at the destination type. The type of the initializer is
determined to be char[], which is not implicitly convertible to
wchar[].
It can obviously be argued that since the operands of ?: are constant,
the compiler _could_ figure out that they should be of type wchar[],
but that would make the semantic analysis more complicated, and since
appending 'w' to the strings is far easier, it probably won't change
any time soon.
Re: Cyclic Dependencies
Jarrett Billingsley wrote:
On Tue, Dec 9, 2008 at 12:00 PM, Ellery Newcomer
<[EMAIL PROTECTED]> wrote:
Derek Parnell wrote:
> It is not a bug. A string literal such as "true" is a char[] type (UTF8),
and the compiler will not implicitly convert UTF8 to UTF16 (wchar[]).
Which would then beg the obvious
wchar[] w = "true";
It's a sort of special case. String literals are, by default, UTF-8.
But if you use a string literal in a situation where it can only be
UTF-16 or UTF-32, it's automatically converted.
However if a string literal is used in a context where it can be
multiple encodings, an error results:
void foo(char[] s) {}
void foo(wchar[] s) {}
foo("hello") fails because string literals are implicitly convertible
to both char[] and wchar[], so you have to append either a c or a w to
the literal.
As for why 'wchar[] s = true ? "true" : "false"' doesn't work, it's
because the initializer expression is semantically analyzed before
looking at the destination type. The type of the initializer is
determined to be char[], which is not implicitly convertible to
wchar[].
It can obviously be argued that since the operands of ?: are constant,
the compiler _could_ figure out that they should be of type wchar[],
but that would make the semantic analysis more complicated, and since
appending 'w' to the strings is far easier, it probably won't change
any time soon.
I think the compiler should be smarter. I understand that the compiler
should be simple to allow other implementations to be done easily.
But... I don't think that's true. A D compiler must already instantiate
templates and do compile-time evaluation. Now tell me that's easy! :-P
After all, how many compiler implementors could there be? And how many
users of the language? The language should focus on making it very easy
to program and to avoid this kinds of pitfalls.
Re: Cyclic Dependencies
"Jarrett Billingsley" wrote > It can obviously be argued that since the operands of ?: are constant, > the compiler _could_ figure out that they should be of type wchar[], > but that would make the semantic analysis more complicated, and since > appending 'w' to the strings is far easier, it probably won't change > any time soon. Looks like another job for Captain Polysemy!
Nested Base classes
I'm trying derive a class from a nested base class. The programs' structure is
as follows:
class A
{
class B
{
}
}
class C : A
{
class D : B
{
}
}
I'm using version 2.014 of the dmd compiler, and the above fails. The compiler
error reports that B is nested in class A and not C. Does anyone know a work
around?
Re: Freeing of memory (garbage collection)
Jarrett Billingsley Wrote: > On Tue, Dec 9, 2008 at 11:08 AM, Daniel White <[EMAIL PROTECTED]> wrote: > >> That would be a bad idea. Then how would you do manual memory > >> management in the few cases that absolutely require it? > > > > Two ways. Either: > > > > a: being able to lock the variable so that the garbage collector > > can't touch it until you unlock it. > > Why not just use GC-allocated memory and use addRoot then? Well that question points at the deeper issue of why bother having malloc at all.
Re: Nested Base classes
On Tue, Dec 9, 2008 at 2:08 PM, llee <[EMAIL PROTECTED]> wrote:
> I'm trying derive a class from a nested base class. The programs' structure
> is as follows:
>
> class A
> {
> class B
> {
> }
> }
>
> class C : A
> {
> class D : B
> {
> }
> }
>
> I'm using version 2.014 of the dmd compiler, and the above fails. The
> compiler error reports that B is nested in class A and not C. Does anyone
> know a work around?
>
It's not possible, and I doubt it ever will be.
Re: Freeing of memory (garbage collection)
On Tue, Dec 9, 2008 at 2:53 PM, Daniel White <[EMAIL PROTECTED]> wrote: > Jarrett Billingsley Wrote: > >> On Tue, Dec 9, 2008 at 11:08 AM, Daniel White <[EMAIL PROTECTED]> wrote: >> >> That would be a bad idea. Then how would you do manual memory >> >> management in the few cases that absolutely require it? >> > >> > Two ways. Either: >> > >> > a: being able to lock the variable so that the garbage collector >> > can't touch it until you unlock it. >> >> Why not just use GC-allocated memory and use addRoot then? > > Well that question points at the deeper issue of why bother having malloc at > all. For interaction with some C libraries. Or for implementing your own memory management without having to deal with the GC.
Re: Nested Base classes
Reply to llee,
I'm trying derive a class from a nested base class. The programs'
structure is as follows:
class A
{
class B
{
}
}
class C : A
{
class D : B
{
}
}
I'm using version 2.014 of the dmd compiler, and the above fails. The
compiler error reports that B is nested in class A and not C. Does
anyone know a work around?
That's on the feature request list somewhere.
Re: Freeing of memory (garbage collection)
Daniel White wrote: That would be a bad idea. Then how would you do manual memory management in the few cases that absolutely require it? Two ways. Either: a: being able to lock the variable so that the garbage collector can't touch it until you unlock it. If you have a reference to the memory, the GC won't collect it. Unless you make a habit of hiding pointers inside non-pointer types, that is, which can result in undefined behavior if the hidden pointer points to GC-allocated memory. If you don't have any reference to that memory, then the garbage collector can free it, but in that case, I don't see why it would be an issue, most of the time. If you have a destructor, just be careful -- for instance, if you have an open file in that object and its destructor closes that file. b: Using a slightly different version of malloc (say 'mallocl') which again, makes it shielded against the garbage collector's wrath. malloc is C stdlib malloc. The garbage collector won't touch it.
myClass.add(something)(otherthings)(thisToo);
Hello, How to implement an object that can do this : myClass.add(something)(otherthings)(thisToo); Is it possible ? TIA, TSalm
Re: myClass.add(something)(otherthings)(thisToo);
tsalm wrote:
Hello,
How to implement an object that can do this :
myClass.add(something)(otherthings)(thisToo);
Is it possible ?
TIA,
TSalm
Something like this might work:
class MyClass{
int[] stuff;
alias add opCall;
MyClass add(int k){
stuff ~= k;
return this;
}
}
Re: myClass.add(something)(otherthings)(thisToo);
On Wed, 10 Dec 2008 02:40:47 +0300, tsalm <[EMAIL PROTECTED]> wrote:
Hello,
How to implement an object that can do this :
myClass.add(something)(otherthings)(thisToo);
Is it possible ?
TIA,
TSalm
Yes:
import std.stdio;
class MyClass
{
class MyClassAdder
{
MyClassAdder opCall(Foo foo)
{
_add(foo);
return this;
}
}
class MyClassRemover
{
MyClassRemover opCall(Foo foo)
{
_remove(foo);
return this;
}
}
this()
{
_adder = new MyClassAdder();
_remover = new MyClassRemover();
}
MyClassAdder add(Foo foo)
{
_add(foo);
return _adder;
}
MyClassRemover remove(Foo foo)
{
_remove(foo);
return _remover;
}
private void _add(Foo foo) { writefln("added"); }
private void _remove(Foo foo) { writefln("removed"); }
private MyClassAdder _adder;
private MyClassRemover _remover;
}
class Foo
{
}
void main()
{
MyClass myClass = new MyClass();
myClass.add(null)(null)(null);
myClass.remove(null)(null)(null);
}
Re: myClass.add(something)(otherthings)(thisToo);
Reply to TSalm,
Hello,
How to implement an object that can do this :
myClass.add(something)(otherthings)(thisToo);
Is it possible ?
TIA,
TSalm
if you don't mind dropping the )(
class C
{
final void add(T...)(T t)
{
foreach(int i,_;T)
_add(t[i]);
}
//.
}
(new C).add(something, otherthings, thisToo);
Re: myClass.add(something)(otherthings)(thisToo);
On Tue, Dec 9, 2008 at 7:00 PM, BCS <[EMAIL PROTECTED]> wrote:
> class C
> {
> final void add(T...)(T t)
> {
> foreach(int i,_;T)
> _add(t[i]);
> }
> //.
> }
>
>
> (new C).add(something, otherthings, thisToo);
If all the params are the same type, typesafe variadics are a more
efficient/less code-bloaty way to do it.
void add(int[] things...)
{
foreach(thing; things)
_add(thing);
}
Re: myClass.add(something)(otherthings)(thisToo);
On Wed, 10 Dec 2008 03:24:48 +0300, Jarrett Billingsley <[EMAIL PROTECTED]>
wrote:
On Tue, Dec 9, 2008 at 7:00 PM, BCS <[EMAIL PROTECTED]> wrote:
class C
{
final void add(T...)(T t)
{
foreach(int i,_;T)
_add(t[i]);
}
//.
}
(new C).add(something, otherthings, thisToo);
If all the params are the same type, typesafe variadics are a more
efficient/less code-bloaty way to do it.
void add(int[] things...)
{
foreach(thing; things)
_add(thing);
}
*And* allows overriding them!
Re: Freeing of memory (garbage collection)
Steven Schveighoffer: > One thing you can do, that nobody has mentioned yet, is delete memory that > you have allocated using the GC. Leaving the GC manage and free your memory is usually OK. Managing manually your memory allocated from the C heap is doable. But freeing manually and forcefully memory allocated by the GC seems dangerous to me. Bye, bearophile
isExist in associate array
how to check if array key exist in array or not? for example
char[] [char[]] t;
t["tes1"]="val1";
t["tes2"]="val2";
t["tes3"]="val3";
if (t["test1"]) writefln("NONE");
Re: isExist in associate array
raymond wrote:
how to check if array key exist in array or not? for example
char[] [char[]] t;
t["tes1"]="val1";
t["tes2"]="val2";
t["tes3"]="val3";
if (t["test1"]) writefln("NONE");
if("test1" in t) writefln("exists");
changing array lengths
Does the following totally not make sense? I think it should work. int[] a = new int[10]; a.length += 30;
Re: changing array lengths
On Tue, Dec 9, 2008 at 11:54 PM, Ellery Newcomer
<[EMAIL PROTECTED]> wrote:
> Does the following totally not make sense? I think it should work.
>
> int[] a = new int[10];
>
> a.length += 30;
>
It's a weird limitation that's been around forever. Ugh.
Here, have this.
T[] resize(T)(ref T[] arr, ptrdiff_t delta)
{
arr.length = arr.length + delta;
return arr;
}
...
auto a = new int[10];
a.resize(30); // now 40
a.resize(-30); // now 10
Re: myClass.add(something)(otherthings)(thisToo);
Le Wed, 10 Dec 2008 03:16:49 +0100, Denis Koroskin <[EMAIL PROTECTED]> a
écrit:
On Wed, 10 Dec 2008 03:24:48 +0300, Jarrett Billingsley
<[EMAIL PROTECTED]> wrote:
On Tue, Dec 9, 2008 at 7:00 PM, BCS <[EMAIL PROTECTED]> wrote:
class C
{
final void add(T...)(T t)
{
foreach(int i,_;T)
_add(t[i]);
}
//.
}
(new C).add(something, otherthings, thisToo);
If all the params are the same type, typesafe variadics are a more
efficient/less code-bloaty way to do it.
void add(int[] things...)
{
foreach(thing; things)
_add(thing);
}
*And* allows overriding them!
Thanks you all !
