Mehrdad wfunct...@hotmail.com wrote in message
news:j1lh84$2n2j$1...@digitalmars.com...
A readText() function that would read a text file (**and** autodetect its
encoding from its BOM) would be of great help.
http://www.dsource.org/projects/semitwist/browser/trunk/src/semitwist/util/io.d#L24
On 2011-08-07 21:28, dsimcha wrote:
Yeah, I was trying to wrap my head around the whole key concept. I
wasn't very successful. I also tried out Orange and filed a few bug
reports. It may be that Orange isn't the right tool for the job for MPI,
though modulo some bug fixing and polishing it could
On 2011-08-07 23:18, Jonathan M Davis wrote:
On Sunday 07 August 2011 18:58:53 Stijn Herreman wrote:
module main;
import std.stdio;
import my_module;
int main()
{
my_method();
return 0;
}
module my_module;
import std.stdio;
package void my_method()
{
writeln(Hello
On 2011-08-08 00:29, Robert Clipsham wrote:
On 07/08/2011 22:18, Jonathan M Davis wrote:
Personally, I don't see much point in using the package specifier when
you're
not actually using a package hierarchy (you're just making it so that
everything but stuff which actually uses a hierarchy can
On Monday 08 August 2011 08:55:22 Jacob Carlborg wrote:
On 2011-08-07 23:18, Jonathan M Davis wrote:
On Sunday 07 August 2011 18:58:53 Stijn Herreman wrote:
module main;
import std.stdio;
import my_module;
int main()
{
my_method();
return 0;
}
module
On Aug 8, 11 06:45, bearophile wrote:
KennyTM~:
__ctfeWrite is not complex, but I don't see the need for it.
I don't understand your point. Given __ctfeWrite you are able to create a
__ctfeWriteln but you can't do the opposite.
If I have to print something complex, like something
On 08/08/2011 02:10, Jonathan M Davis wrote:
Ah. Then package is horribly broken at the moment. Lovely. I guess that that
just goes to show that it's not used heavily or there would be a lot more
complaints about it.
Another possibility is it's not used because it doesn't work - that's my
On 2011-08-08 09:11, Jonathan M Davis wrote:
On Monday 08 August 2011 08:55:22 Jacob Carlborg wrote:
Or because neither of the modules are in package they are perhaps in an
implicit global package making package in this case behave as public.
Except that I don't think that sub-packages have
On 2011-08-07 20:42:30 +, bearophile bearophileh...@lycos.com said:
This is a recently opened (not by me) enhancement request thread:
http://d.puremagic.com/issues/show_bug.cgi?id=6442
It proposes something that I remember was discussed and refused two
times in past: to require (but only
On 08-08-2011 01:07, Robert Clipsham wrote:
On 07/08/2011 23:59, Andrej Mitrovic wrote:
So I wanted to make myself a template called macro, but it turns out
it's a keyword:
template macro()
{
}
test.d(7): TemplateIdentifier expected following template
test.d(7): Declaration expected, not
I think he means the The Future of D videos found here:
http://prowiki.org/wiki4d/wiki.cgi?Videos
What I'm wondering about is whether something like this is still
planned though. I don't mind the keyword being taken that much.
Andrej Mitrovic:
What I'm wondering about is whether something like this is still
planned though. I don't mind the keyword being taken that much.
Like goto keyword in Java :o)
Bye,
bearophile
On 8/8/11 1:56 AM, Jacob Carlborg wrote:
On 2011-08-08 00:29, Robert Clipsham wrote:
On 07/08/2011 22:18, Jonathan M Davis wrote:
Personally, I don't see much point in using the package specifier when
you're
not actually using a package hierarchy (you're just making it so that
everything but
Michel Fortin wrote:
On 2011-08-07 20:42:30 +, bearophile bearophileh...@lycos.com said:
This is a recently opened (not by me) enhancement request thread:
http://d.puremagic.com/issues/show_bug.cgi?id=6442
It proposes something that I remember was discussed and refused two
times in
This is off topic but if you're interested you can get it to run using
float if you change the Sphere code to:
FP eps = 1e-2; instead of 1e-4;
Hi,
at http://www.d-programming-language.org/expression.html the following
expressions are said to be illegal:
i = i++;
c = a + (a = b);
The documentation says they are illegal because the order of evaluation
is implementation-defined. That is possible because the order of
evaluation of the
Jens Mueller:
Why did D choose to follow C/C++'s defined sequence points?
I think to simplify the implementation, because I think it comes from the
evolution (the back-end too) of a C++ compiler.
But Walter has said two or three times that he's interested in changing D
semantics, and define
On Mon, 08 Aug 2011 01:08:39 +0900, dsimcha dsim...@yahoo.com wrote:
On 8/7/2011 12:01 PM, Lutger Blijdestijn wrote:
dsimcha wrote:
On 8/7/2011 11:36 AM, Jacob Carlborg wrote:
Currently, the only available format is XML.
Ok, I'll look into writing a binary archiver that assumes that the
On 2011-08-08 15:55, Andrei Alexandrescu wrote:
On 8/8/11 1:56 AM, Jacob Carlborg wrote:
On 2011-08-08 00:29, Robert Clipsham wrote:
On 07/08/2011 22:18, Jonathan M Davis wrote:
Personally, I don't see much point in using the package specifier when
you're
not actually using a package
Jens Mueller Wrote:
I'm having trouble understanding the difference between order of
evaluation and sequence points.
Order of evaluation matters when subexpressions contain sequence points.
bearophile wrote:
Max Klyga:
So this feature has to be either mandatory or not. Making it optional
leads to confusion as Jonathan mentioned.
On this, what I have suggested it not the same thing that the original proposal says. In the original proposal the
ref and out are optional. In my
Michel Fortin Wrote:
I recently had to use getopt. You use it like that:
bool option;
int counter;
getopt(args,
option|o, option,
counter|c, counter);
The problem is that taking addresses of a stack variable is disabled in
SafeD, which
bearophile Wrote:
This is a recently opened (not by me) enhancement request thread:
http://d.puremagic.com/issues/show_bug.cgi?id=6442
D is the language to save keystrokes. This proposal is plain invalid.
Though I think, `main` arguments should eliminated altogether and be accessed
statically.
const ReusableOpts opts = getopts();
const string[] args = mainArgs; // @property: parse args on demand, remove the
code from startup.
On Aug 9, 11 02:32, Kagamin wrote:
bearophile Wrote:
This is a recently opened (not by me) enhancement request thread:
http://d.puremagic.com/issues/show_bug.cgi?id=6442
D is the language to save keystrokes. This proposal is plain invalid.
I disagree. If you want to save keystrokes, use
bearophile Wrote:
This is a recently opened (not by me) enhancement request thread:
http://d.puremagic.com/issues/show_bug.cgi?id=6442
D is the language to save keystrokes. This proposal is plain invalid.
We're not going to reject a feature proposal simply because it involves more
typing
Eric Poggel (JoeCoder):
determinism can be very important when it comes to
reducing network traffic. If you can achieve it, then you can make sure
all players have the same game state and then only send user input
commands over the network.
It seems a hard thing to obtain, but I agree
KennyTM~:
I understand that you could implement `writeln` in terms of `write`, but
I question its practical value. Why do you need to print a tree at
compile time? pragma(msg) and __ctfeWriteln are mainly for debugging,
and adding a newline is very suitable (e.g. it won't mess up the
I think we can use auto ref.
2011/08/08 21:45 Michel Fortin michel.for...@michelf.com:
On 2011-08-07 20:42:30 +, bearophile bearophileh...@lycos.com said:
This is a recently opened (not by me) enhancement request thread:
http://d.puremagic.com/issues/show_bug.cgi?id=6442
It proposes
KennyTM~ Wrote:
I disagree. If you want to save keystrokes, use Perl.
Perl is dynamically typed, right? D is statically typed, so it can statically
check most things like out variables won't overwrite const arguments.
KennyTM~ wrote:
On Aug 7, 11 22:23, Vladimir Panteleev wrote:
On Sun, 07 Aug 2011 13:29:20 +0300, Walter Bright
newshou...@digitalmars.com wrote:
It's less complex (!) if you are not trying to make a working dmd. It
just needs to compile.
OK, that wasn't actually too bad.
Don:
I think these are false positives too. The ones I saw were of the form:
When p is a pointer,
assert(p);
y = p-x; // error: p is uninitialized
This was true in the first release of those warnings files, but is it true
still? There are only 10 of those errors reported now.
Bye,
Andrei Alexandrescu:
this(int a, int b, int c, int d) {
mixin(initFromParameters());
...
}
A similar macro could help assignments.
Do you see people using that in real code?
Bye,
bearophile
bearophile wrote:
Vladimir Panteleev:
Done:
http://dump.thecybershadow.net/b1e4cb6ef0a8d3c5f54d5cb09ddd1a9e/DMD.log
There are only 10 NULL deference warnings left:
s2ir.c(1043): warning C6011: Dereferencing NULL pointer 'pu++'
false (only if malloc fails)
s2ir.c(980): warning C6011:
On 8/8/11 1:59 PM, bearophile wrote:
Andrei Alexandrescu:
this(int a, int b, int c, int d) {
mixin(initFromParameters());
...
}
A similar macro could help assignments.
Do you see people using that in real code?
Yes.
Andrei
On 8/8/11 6:08 AM, Andrei Alexandrescu wrote:
On 8/7/11 1:16 PM, Andrej Mitrovic wrote:
struct Foo
{
int a;
int b;
int c;
int d;
}
Just define a mixin and use it:
this(int a, int b, int c, int d) {
mixin(initFromParameters());
...
}
There is currently no »legal« way to get the parameter
David Nadlinger wrote:
On 8/8/11 6:08 AM, Andrei Alexandrescu wrote:
On 8/7/11 1:16 PM, Andrej Mitrovic wrote:
struct Foo
{
int a;
int b;
int c;
int d;
}
Just define a mixin and use it:
this(int a, int b, int c, int d) {
mixin(initFromParameters());
...
}
There is currently no
On 8/8/11 6:08 AM, Andrei Alexandrescu wrote:
On 8/7/11 1:16 PM, Andrej Mitrovic wrote:
struct Foo
{
int a;
int b;
int c;
int d;
}
Just define a mixin and use it:
this(int a, int b, int c, int d) {
mixin(initFromParameters());
...
}
There is currently no »legal«
On Aug 9, 11 03:19, bearophile wrote:
KennyTM~:
I understand that you could implement `writeln` in terms of `write`, but
I question its practical value. Why do you need to print a tree at
compile time? pragma(msg) and __ctfeWriteln are mainly for debugging,
and adding a newline is very
On 8/8/11 10:41 PM, Jonathan M Davis wrote:
In this particular example, what goes in initFromParameters is specific to Foo
anyway. So, you'd have to write it by hand regardless.
If Andrei intended his answer this way, I don't quite see how it would
be an appropriate solution, as Andrej
Done deal:
import std.traits;
string FieldInit(T, int len, string fun)()
{
string result;
auto fields = [__traits(allMembers, T)];
result ~= this(;
foreach (y, x; (RepresentationTypeTuple!T)[0..len])
{
result ~= x.stringof ~ ~ fields[y] ~ , ;
}
result =
On Mon, 08 Aug 2011 03:17:13 +0200, Mehrdad wfunct...@hotmail.com wrote:
OK so apparently the GC was working fine, my bad.
I'm not sure about the compiler, though.
When I have this code:
void foo(int a, scope void delegate(int) sink)
{
sink(a);
}
void main()
On Mon, 08 Aug 2011 04:51:19 +0200, Mehrdad wfunct...@hotmail.com wrote:
I just made something I thought I'd share.
It's great for those times when the compiler decides to randomly put a
closure on the heap.
The usage is pretty simple:
int x = 5;
auto adder5 =
On 8/8/2011 3:02 PM, bearophile wrote:
Eric Poggel (JoeCoder):
determinism can be very important when it comes to
reducing network traffic. If you can achieve it, then you can make sure
all players have the same game state and then only send user input
commands over the network.
It seems a
On Aug 9, 11 05:05, Andrej Mitrovic wrote:
Done deal:
import std.traits;
string FieldInit(T, int len, string fun)()
{
string result;
auto fields = [__traits(allMembers, T)];
result ~= this(;
foreach (y, x; (RepresentationTypeTuple!T)[0..len])
{
result ~=
Double leading underscores are for temporary things, that will change and
improve, like __traits. But this ctWriteln is meant to stay. And the leading
ctfe is redundant, so I suggest to call it ctWriteln, there is no need to
give it an ugly name. It means compile time write with newline instead
On 8/8/11 10:41 PM, Jonathan M Davis wrote:
In this particular example, what goes in initFromParameters is specific
to Foo anyway. So, you'd have to write it by hand regardless.
If Andrei intended his answer this way, I don't quite see how it would
be an appropriate solution, as Andrej
On 8/8/11, KennyTM~ kenn...@gmail.com wrote:
Template-mixin is often shorter and less error-prone.
-
mixin template FieldInit(size_t count, alias fun)
{
this(RepresentationTypeTuple!(typeof(this))[0..count] params)
{
foreach (y, x; __traits(allMembers,
On 8/9/11 12:25 AM, Jonathan M Davis wrote:
On 8/8/11 10:41 PM, Jonathan M Davis wrote:
In this particular example, what goes in initFromParameters is specific
to Foo anyway. So, you'd have to write it by hand regardless.
If Andrei intended his answer this way, I don't quite see how it would
Double leading underscores are for temporary things, that will change and
improve, like __traits. But this ctWriteln is meant to stay. And the
leading ctfe is redundant, so I suggest to call it ctWriteln, there is
no need to give it an ugly name. It means compile time write with
newline
Le 06/08/2011 21:38, Walter Bright a écrit :
http://www.reddit.com/r/programming/comments/jar93/john_carmack_gives_his_thoughts_on_static/c2akmf8
If someone has this on their system, I think it'd be great if you could
run the dmd source code through it and see if it finds any bugs.
Other
On 8/9/11 12:25 AM, Jonathan M Davis wrote:
On 8/8/11 10:41 PM, Jonathan M Davis wrote:
In this particular example, what goes in initFromParameters is specific
to Foo anyway. So, you'd have to write it by hand regardless.
If Andrei intended his answer this way, I don't quite see how it
You could use the 'scope' keyword, no?
From what I've heard it's being deprecated/removed -- although I'd be
glad to hear otherwise.
'scope' in the position you have it, will not prevent this, no.
What is the purpose of 'scope' in the parameter list?
AFAIK it disallows you to escape a reference. `in` is actually const scope.
FWIW, Google's C++ style guide explicitly requires passing pointers to
arguments (whenever possible) when they are to be modified or used as out
parameters, and passed by const when they are not. This makes it more
obvious at the caller's end which parameters are going to be modified and
which
You could use the 'scope' keyword, no?
From what I've heard it's being deprecated/removed -- although I'd be
glad to hear otherwise.
scope on function parameters is sticking around as are scoped statements.
What's going around is scoped local variables which put a class on the stack.
Ziad Hatahet:
FWIW, Google's C++ style guide explicitly requires passing pointers to
arguments (whenever possible) when they are to be modified or used as out
parameters, and passed by const when they are not.
It's here:
On 8/8/2011 4:50 PM, Andrej Mitrovic wrote:
AFAIK it disallows you to escape a reference. `in` is actually const scope.
So this heap allocation shouldn't be happening, right?
On 2011-08-08 13:55:32 +, Andrei Alexandrescu
seewebsiteforem...@erdani.org said:
On 8/8/11 1:56 AM, Jacob Carlborg wrote:
On 2011-08-08 00:29, Robert Clipsham wrote:
On 07/08/2011 22:18, Jonathan M Davis wrote:
Personally, I don't see much point in using the package specifier when
On 2011-08-08 18:30:10 +, Kagamin s...@here.lot said:
Michel Fortin Wrote:
I recently had to use getopt. You use it like that:
bool option;
int counter;
getopt(args,
option|o, option,
counter|c, counter);
The problem is that
bearophile wrote:
Don:
I think these are false positives too. The ones I saw were of the form:
When p is a pointer,
assert(p);
y = p-x; // error: p is uninitialized
This was true in the first release of those warnings files, but is it true
still? There are only 10 of those errors
bearophile wrote:
Double leading underscores are for temporary things, that will change and improve, like __traits.
But this ctWriteln is meant to stay.
No it isn't. If we get bug 3702 (magic namespace) approved, the name
of __ctfe and __ctfeWriteln will change. They are intentionally ugly.
On 8/9/11 5:46 AM, Don wrote:
Don:
I think these are false positives too. The ones I saw were of the form: […]
4995: FuncDeclaration *fd;
4996: Expression *pthis = NULL;
4997: if (deleg-op == TOKdelegate)
4998: {
4999: fd = ((DelegateExp *)deleg)-func;
5000: pthis = ((DelegateExp *)deleg)-e1;
David Nadlinger wrote:
On 8/9/11 5:46 AM, Don wrote:
Don:
I think these are false positives too. The ones I saw were of the
form: […]
4995: FuncDeclaration *fd;
4996: Expression *pthis = NULL;
4997: if (deleg-op == TOKdelegate)
4998: {
4999: fd = ((DelegateExp *)deleg)-func;
5000: pthis =
Jacob Carlborg wrote:
On 2011-08-07 03:19, bearophile wrote:
I have discussed about this topic once in past, but in the meantime I
have seen this is a quite common problem, so I think it doesn't harm
to touch this topic again.
This is a direct D translation of the original C or C++ code:
On 8/8/2011 9:44 PM, Don wrote:
Aargh, you're right.
I've been slowly going through the reports. While I've found only one real bug,
and several sort of problems if you squint at them the right way, most are
issues I put in the category of not up to modern coding best practices. Those
I'm
On Sat, 06 Aug 2011 22:53:31 +0200, Jonathan M Davis jmdavisp...@gmx.com
wrote:
Feel free to create a feature request on it. It may even get the language
changed. However, having more than one invariant complicates things a
bit,
since right now, it's easy for the runtime to just call the
On Fri, 05 Aug 2011 18:43:27 +0200, Kai Meyer k...@unixlords.com wrote:
On 08/05/2011 03:02 AM, Pelle wrote:
Don't declare variables until you need them, just leave bytes_read and
bytes_max here.
Is there a performance consideration? Or is it purely a style or
D-Factor suggestion?
Just
I wonder why there isn't any sleep method in std.concurrency.
I know there is one in core.thread, but I try to avoid using
core modules.
Maybe a sleep method is just not needed in std.concurrency?
If I were to make a program that would constantly have about
60 working threads. Some kind of
On Monday 08 August 2011 07:01:11 BizarreCake wrote:
I wonder why there isn't any sleep method in std.concurrency.
I know there is one in core.thread, but I try to avoid using
core modules.
Maybe a sleep method is just not needed in std.concurrency?
If I were to make a program that would
I'm writing here because I haven't been able to create a smaller example
and I'm not sure what to search for in bugzilla.
DMD adds a storage identifier twice when writing .di files.
This is my code:
///
static @property isGUIThread() {
return cast(bool)IsGUIThread(false);
}
On Monday 08 August 2011 09:42:15 simendsjo wrote:
I'm writing here because I haven't been able to create a smaller example
and I'm not sure what to search for in bugzilla.
DMD adds a storage identifier twice when writing .di files.
This is my code:
///
static @property
On 08.08.2011 09:47, Jonathan M Davis wrote:
On Monday 08 August 2011 09:42:15 simendsjo wrote:
I'm writing here because I haven't been able to create a smaller example
and I'm not sure what to search for in bugzilla.
DMD adds a storage identifier twice when writing .di files.
This is my code:
On Monday, August 08, 2011 12:54:00 AM, simendsjo wrote:
On 08.08.2011 09:47, Jonathan M Davis wrote:
http://d.puremagic.com/issues/show_bug.cgi?id=6360
Thanks. The annoying thing is that I have to manually modify the import
library :|
Could spend the time fixing dmd instead of working
On 08.08.2011 09:57, Brad Roberts wrote:
On Monday, August 08, 2011 12:54:00 AM, simendsjo wrote:
On 08.08.2011 09:47, Jonathan M Davis wrote:
http://d.puremagic.com/issues/show_bug.cgi?id=6360
Thanks. The annoying thing is that I have to manually modify the import library
:|
Could spend
On 06.08.2011 22:53, Jonathan M Davis wrote:
On Saturday 06 August 2011 22:40:15 simendsjo wrote:
On 04.08.2011 11:32, simendsjo wrote:
I would like to use a template mixin to add some fields to a struct, but
I'd also like the template to add additional invariant checks without
having to
On 08.08.2011 10:01, simendsjo wrote:
On 08.08.2011 09:47, Jonathan M Davis wrote:
On Monday 08 August 2011 09:42:15 simendsjo wrote:
I'm writing here because I haven't been able to create a smaller example
and I'm not sure what to search for in bugzilla.
DMD adds a storage identifier twice
I cannot find any string format() method in phobos.
Having to do:
auto a = appender!string();
formattedWrite(a, , ...);
a.data
seems unnecessary in many cases.
On Mon, 08 Aug 2011 14:37:26 +0300, simendsjo simend...@gmail.com wrote:
I cannot find any string format() method in phobos.
What's wrong with format() from std.string?
--
Best regards,
Vladimirmailto:vladi...@thecybershadow.net
On 08.08.2011 13:37, Vladimir Panteleev wrote:
On Mon, 08 Aug 2011 14:37:26 +0300, simendsjo simend...@gmail.com wrote:
I cannot find any string format() method in phobos.
What's wrong with format() from std.string?
Thanks, that was the function I was looking for. I just expected it to
On 08.08.2011 13:41, simendsjo wrote:
On 08.08.2011 13:37, Vladimir Panteleev wrote:
On Mon, 08 Aug 2011 14:37:26 +0300, simendsjo simend...@gmail.com
wrote:
I cannot find any string format() method in phobos.
What's wrong with format() from std.string?
Thanks, that was the function I
Is it possible to run unittests in libraries?
The following doesn't work:
l.d
===
module l;
import std.stdio;
int f() { return 1; } // just to make sure it's actually compiled in
unittest {
writeln(Unittest from lib);
assert(false);
}
t.d
===
import l;
import std.stdio;
void main() {
On 08.08.2011 14:07, simendsjo wrote:
On 08.08.2011 13:41, simendsjo wrote:
On 08.08.2011 13:37, Vladimir Panteleev wrote:
On Mon, 08 Aug 2011 14:37:26 +0300, simendsjo simend...@gmail.com
wrote:
I cannot find any string format() method in phobos.
What's wrong with format() from
On Mon, 08 Aug 2011 04:01:17 -0400, simendsjo simend...@gmail.com wrote:
On 08.08.2011 09:47, Jonathan M Davis wrote:
On Monday 08 August 2011 09:42:15 simendsjo wrote:
I'm writing here because I haven't been able to create a smaller
example
and I'm not sure what to search for in bugzilla.
I use absolute paths in a build script, and Ddoc uses the full path in a
comment in the generated files. This makes version control very
difficult as all developers has to use the same location (and possibly
operating system). Is there a way to avoid this without changing by
build script?
On 08.08.2011 15:33, Steven Schveighoffer wrote:
On Mon, 08 Aug 2011 04:01:17 -0400, simendsjo simend...@gmail.com wrote:
On 08.08.2011 09:47, Jonathan M Davis wrote:
On Monday 08 August 2011 09:42:15 simendsjo wrote:
I'm writing here because I haven't been able to create a smaller
example
simendsjo:
Is this by design, or just an implementation oddity?
Or a design oddity?
Bye,
bearophile
I need to interface with an application that has an IDispatch
(activex/ole/automation) interface. I can find some threads from 2006
about how painful that was. I'm suspecting that in the intervening 5
years progress has been made, but I'm having trouble finding it. The
manual says D
On 08.08.2011 15:46, Jason King wrote:
I need to interface with an application that has an IDispatch
(activex/ole/automation) interface. I can find some threads from 2006
about how painful that was. I'm suspecting that in the intervening 5
years progress has been made, but I'm having trouble
On 08/08/2011 12:33 AM, Pelle wrote:
On Fri, 05 Aug 2011 18:43:27 +0200, Kai Meyer k...@unixlords.com wrote:
On 08/05/2011 03:02 AM, Pelle wrote:
Don't declare variables until you need them, just leave bytes_read and
bytes_max here.
Is there a performance consideration? Or is it purely a
I have a problem I'd really like to use Strides for to simplify my code.
Currently, I do this:
foreach(n; 0..chunks)
comp_arr[n] = values[(n * step_size) + n]
if(!all_same(comp_arr, comp_arr[0]))
It would eliminate an entire 2 lines of code for each time I want
I have a problem I'd really like to use Strides for to simplify my code.
Currently, I do this:
foreach(n; 0..chunks)
comp_arr[n] = values[(n * step_size) + n]
if(!all_same(comp_arr, comp_arr[0]))
It would eliminate an entire 2 lines of code for each time I want
strides, to be able to do
Hi Sean,
This doesn't work when passing a delegate as func, however. Is there a way to
circumvent this?
I tried this with a delegate and a function template, it seems to work:
import std.typecons;
void bar(T)(ref T elem)
{
elem = elem+1;
}
void main()
{
auto data = tuple([0,1,2,3],
Hi,
I'm receiving this error with dmd 2.054:
tmp.d(7): Error: no [] operator overload for type Tuple!(int,short) for
the following test case
import std.typecons;
void main() {
auto x = 1;
Tuple!(int,short) a;
a[0] = 1;
a[x] = 2;
}
If I use a value instead of a variable ie. a[1] = 2; it compiles
Hmm, I just saw your question on SO. Is that nearer to what you ask?
It uses a anonymous template function:
import std.typecons;
void act(alias fun, T...)(ref Tuple!T data)
{
foreach(index, range; data.expand)
foreach(ref element; range)
fun(element);
}
void main()
{
Hi Chris,
import std.typecons;
void main() {
auto x = 1;
Tuple!(int,short) a;
a[0] = 1;
a[x] = 2;
}
If I use a value instead of a variable ie. a[1] = 2; it compiles fine.
The index need to be a compile-time constant, you cannot index a tuple
with a runtime value.
Try using
enum x = 1;
On Mon, 08 Aug 2011 14:17:28 -0400, Kai Meyer k...@unixlords.com wrote:
I am playing with threading, and I am doing something like this:
file.rawRead(bytes);
auto tmpTask = task!do_something(bytes.idup);
task_pool.put(tmpTask);
Is there a way to avoid the idup (or can
On 08.08.2011 23:27, Christian Manning wrote:
Hi,
I'm receiving this error with dmd 2.054:
tmp.d(7): Error: no [] operator overload for type Tuple!(int,short) for
the following test case
import std.typecons;
void main() {
auto x = 1;
Tuple!(int,short) a;
a[0] = 1;
a[x] = 2;
}
If I use a value
Philippe Sigaud wrote:
Hi Chris,
import std.typecons;
void main() {
auto x = 1;
Tuple!(int,short) a;
a[0] = 1;
a[x] = 2;
}
If I use a value instead of a variable ie. a[1] = 2; it compiles fine.
The index need to be a compile-time constant, you cannot index a tuple
with a runtime
1 - 100 of 132 matches
Mail list logo
