How to translate C# 'readonly' keyword into D
I'm a C# programmer, when I apply IoC pattern I use readonly
keyword
(http://msdn.microsoft.com/en-us/library/acdd6hb7%28v=vs.71%29.aspx)
in this manner:
:// C# code
:interface IFoo {
: void Fun();
:}
:
:class Foo: IFoo {
: void Fun() {...}
:}
:class Bar {
: private readonly IFoo foo;
: // inject IFoo into Bar
: Bar(IFoo foo) {
:// assert(foo != null);
:this.foo = foo;
: }
: void Gun() {
:// foo = new Foo(); ERROR: foo is readonly!
:foo.Fun();
: }
:}
Can someone help me to translate readonly IFoo foo; so that the
dmd compiler raises an error when I write foo = new Foo(); ?
I try:
:// D code
:interface IFoo {
: void fun();
:}
:
:class Foo: IFoo {
: void fun() {
: writeln(fun...);
: }
:}
:
:class Bar {
: private const IFoo service;
: this(const IFoo service) {
: this.service = service;
: }
:
: void gun() {
: service.fun();
: }
:}
:unittest {
: const(IFoo) s = new Foo;
: auto bar = new Bar(s);
: bar.gun();
:}
but the compiler complains:
Error: function main.IFoo.fun () is not callable using argument
types () const
Re: How to translate C# 'readonly' keyword into D
On Monday, 4 February 2013 at 09:02:31 UTC, o3o wrote:
I'm a C# programmer, when I apply IoC pattern I use readonly
keyword
(http://msdn.microsoft.com/en-us/library/acdd6hb7%28v=vs.71%29.aspx)
in this manner:
:// C# code
:interface IFoo {
: void Fun();
:}
:
:class Foo: IFoo {
: void Fun() {...}
:}
:class Bar {
: private readonly IFoo foo;
: // inject IFoo into Bar
: Bar(IFoo foo) {
:// assert(foo != null);
:this.foo = foo;
: }
: void Gun() {
:// foo = new Foo(); ERROR: foo is readonly!
:foo.Fun();
: }
:}
Can someone help me to translate readonly IFoo foo; so that
the dmd compiler raises an error when I write foo = new
Foo(); ?
I try:
:// D code
:interface IFoo {
: void fun();
:}
:
:class Foo: IFoo {
: void fun() {
: writeln(fun...);
: }
:}
:
:class Bar {
: private const IFoo service;
: this(const IFoo service) {
: this.service = service;
: }
:
: void gun() {
: service.fun();
: }
:}
:unittest {
: const(IFoo) s = new Foo;
: auto bar = new Bar(s);
: bar.gun();
:}
but the compiler complains:
Error: function main.IFoo.fun () is not callable using argument
types () const
In D, everything accessible from const is also const. You
specifically state that you will not modify your IFoo instance.
But then you call foo(). foo() in turn isn't marked as const, so
this can modify IFoo, and thus break const.
So.. Every method you call through a const instance must also be
const, otherwise you have the ability to change something that
should be a constant.
Re: How to translate C# 'readonly' keyword into D
On Monday, 4 February 2013 at 10:26:55 UTC, simendsjo wrote:
On Monday, 4 February 2013 at 09:02:31 UTC, o3o wrote:
I'm a C# programmer, when I apply IoC pattern I use
readonly keyword
(http://msdn.microsoft.com/en-us/library/acdd6hb7%28v=vs.71%29.aspx)
in this manner:
:// C# code
:interface IFoo {
: void Fun();
:}
:
:class Foo: IFoo {
: void Fun() {...}
:}
:class Bar {
: private readonly IFoo foo;
: // inject IFoo into Bar
: Bar(IFoo foo) {
:// assert(foo != null);
:this.foo = foo;
: }
: void Gun() {
:// foo = new Foo(); ERROR: foo is readonly!
:foo.Fun();
: }
:}
Can someone help me to translate readonly IFoo foo; so that
the dmd compiler raises an error when I write foo = new
Foo(); ?
I try:
:// D code
:interface IFoo {
: void fun();
:}
:
:class Foo: IFoo {
: void fun() {
: writeln(fun...);
: }
:}
:
:class Bar {
: private const IFoo service;
: this(const IFoo service) {
: this.service = service;
: }
:
: void gun() {
: service.fun();
: }
:}
:unittest {
: const(IFoo) s = new Foo;
: auto bar = new Bar(s);
: bar.gun();
:}
but the compiler complains:
Error: function main.IFoo.fun () is not callable using
argument types () const
In D, everything accessible from const is also const. You
specifically state that you will not modify your IFoo instance.
But then you call foo(). foo() in turn isn't marked as const,
so this can modify IFoo, and thus break const.
So.. Every method you call through a const instance must also
be const, otherwise you have the ability to change something
that should be a constant.
So this works:
interface IFoo {
void fun() const;
}
class Foo : IFoo {
void fun() const {}
}
class Bar {
private const IFoo service;
this(const IFoo service) {
this.service = service;
}
void gun() {
service.fun();
}
}
unittest {
const s = new Foo();
auto bar = new Bar(s);
bar.gun();
}
void main() {}
Re: How to translate C# 'readonly' keyword into D
On 2013-02-04 10:02, o3o wrote:
I'm a C# programmer, when I apply IoC pattern I use readonly keyword
(http://msdn.microsoft.com/en-us/library/acdd6hb7%28v=vs.71%29.aspx) in
this manner:
:// C# code
:interface IFoo {
: void Fun();
:}
:
:class Foo: IFoo {
: void Fun() {...}
:}
:class Bar {
: private readonly IFoo foo;
: // inject IFoo into Bar
: Bar(IFoo foo) {
:// assert(foo != null);
:this.foo = foo;
: }
: void Gun() {
:// foo = new Foo(); ERROR: foo is readonly!
:foo.Fun();
: }
:}
Can someone help me to translate readonly IFoo foo; so that the dmd
compiler raises an error when I write foo = new Foo(); ?
The closest would probably be defining a property with only a getter:
class Bar
{
private IFoo foo_;
private @property foo () { return foo_; }
this (IFoo foo)
{
foo_ = foo;
}
}
You can still change the foo_ variable.
--
/Jacob Carlborg
Re: How to translate C# 'readonly' keyword into D
On Monday, 4 February 2013 at 10:26:55 UTC, simendsjo wrote:
[cut]
So.. Every method you call through a const instance must also
be const, otherwise you have the ability to change something
that should be a constant.
Thanks simendsjo, now I get it...
So, let me continue the example (I remove const for
simplicity)...
I would like check that bar.gun() call fun() function from IFoo
unittest {
auto foo = new MockIFoo(); //Will not compile.Mock doesn't
(yet) exist
auto bar = new Bar(foo);
bar.gun();
foo.Received().fun(); // pass if 'fun' was called
}
void main() {}
In other words, I need a mock object like nsubstitute
(http://nsubstitute.github.com/help/getting-started/) or moq
(http://code.google.com/p/moq/)
In your old post
http://forum.dlang.org/thread/il29hs$2svt$1...@digitalmars.com
you were asking for mocking frameworks...do you found any
solution?
Thanks
How to read fastly files ( I/O operation)
Dear, I am looking to parse efficiently huge file but i think D lacking for this purpose. To parse 12 Go i need 11 minutes wheras fastxtoolkit (written in c++ ) need 2 min. My code is maybe not easy as is not easy to parse a fastq file and is more harder when using memory mapped file. I do not see where i can get some perf as i do not do many copy and i use mmfile. fastxtoolkit do not use mmfile and store his result into a struct array for each sequences but is is still faster!!! thanks to any help i hope we can create a faster parser otherwise that is too slow to use D instead C++
Re: GtkD button size
On Sunday, 3 February 2013 at 16:07:06 UTC, Artur Skawina wrote: On 02/03/13 16:53, SaltySugar wrote: GTKD. Can someone explain me how to change button size in vbox, hbox? setSizeRequest (70, 50); doesn't work. Thanks. Try playing with an interactive gui tool, such as glade. The fill, expand and size request interactions will be immediately visible. artur I'm waiting other answers :)
Re: How to translate C# 'readonly' keyword into D
First, AFAIK, there is no equivalent of C# readonly in D,
despite the fact that D uses 3 keywords for various kinds of
immutability.
Second, here you can find a mocking library for D:
http://www.dsource.org/projects/dmocks/wiki/DMocks
On Monday, 4 February 2013 at 13:35:24 UTC, o3o wrote:
On Monday, 4 February 2013 at 10:26:55 UTC, simendsjo wrote:
[cut]
So.. Every method you call through a const instance must also
be const, otherwise you have the ability to change something
that should be a constant.
Thanks simendsjo, now I get it...
So, let me continue the example (I remove const for
simplicity)...
I would like check that bar.gun() call fun() function from IFoo
unittest {
auto foo = new MockIFoo(); //Will not compile.Mock
doesn't (yet) exist
auto bar = new Bar(foo);
bar.gun();
foo.Received().fun(); // pass if 'fun' was called
}
void main() {}
In other words, I need a mock object like nsubstitute
(http://nsubstitute.github.com/help/getting-started/) or moq
(http://code.google.com/p/moq/)
In your old post
http://forum.dlang.org/thread/il29hs$2svt$1...@digitalmars.com
you were asking for mocking frameworks...do you found any
solution?
Thanks
Re: Allocating large 2D array in D
Sparsh Mittal: I am allocating 2d array as: double[gridSize][gridSize] gridInfo; which works for small dimension, but for large dimension, 16Mb limit comes. Walter has decided to introduce a very low limit for the size of static arrays. (Both Clang and G++ support larger ones). Would you please tell me how do allocate a large 2d array (which has to be done as a dynamic array)? It is a square grid and dimensions are already known. This allocates your array, filled with NaNs: auto gridInfo = new double[][](gridSize, gridSize); If you want to skip most or all the initialization then take a look at two functions in std.array. In most cases the partially initialized function is enough, and it's quite safer. Bye, bearophile
Re: Allocating large 2D array in D
Thanks for your prompt reply. It was very helpful.
Re: Allocating large 2D array in D
On Monday, 4 February 2013 at 15:23:20 UTC, Sparsh Mittal wrote:
I am allocating 2d array as:
double[gridSize][gridSize] gridInfo;
which works for small dimension, but for large dimension, 16Mb
limit comes.
Would you please tell me how do allocate a large 2d array
(which has to be done as a dynamic array)? It is a square grid
and dimensions are already known.
I also searched internet but could not find an answer. Thanks.
If all (but last of) the dimensions are known at compile time,
then you can dynamically allocate an array of fixed sized arrays:
//
enum size_t gridSize = 4_000;
enum size_t total = gridSize * gridSize;
static assert (total == 16_000_000); //16 million doubles total
static assert (total * double.sizeof == 128_000_000); //126 Megs
allocated
void main()
{
double[gridSize][] gridInfo = new
double[gridSize][](gridSize);
}
//
This will give you a dense array: Eg: all the data is contiguous
in memory.
You can also use the convenient 2D notation:
//
import std.stdio;
enum gridSize = 4;
enum total = gridSize * gridSize;
void main()
{
double[][] gridInfo = new double[][](gridSize, gridSize);
}
//
DO NOTE though that in this case, you have a (probably compact
but) jagged array. What this means is that instead of having one
single solid block of data, you have a top level array, that
references a second level of arrays.
EG: It is (should be) equivalent to:
//
enum size_t gridSize = 4_000;
enum size_t total = gridSize * gridSize;
void main()
{
double[][] gridInfo = new double[][](gridSize); //Create an
array of empty array;
//Initialize gridInfo. Scope block to avoid polution
{
double[] megaBlock = new double[](total); //Create all
the data
foreach (i ; 0 .. gridSize) //Iterate on each gridInfo
entry
{
size_t offset = i * gridSize;
gridInfo[i] = megaBlock[offset .. offset +
gridSize];//Connect the arrays;
}
}
}
//
It's not a big deal, but indexing *might* be a little slower with
this scheme.
Re: Allocating large 2D array in D
monarch_dodra:
If all (but last of) the dimensions are known at compile time,
then you can dynamically allocate an array of fixed sized
arrays:
//
enum size_t gridSize = 4_000;
enum size_t total = gridSize * gridSize;
static assert (total == 16_000_000); //16 million doubles total
static assert (total * double.sizeof == 128_000_000); //126
Megs allocated
void main()
{
double[gridSize][] gridInfo = new
double[gridSize][](gridSize);
}
//
This will give you a dense array: Eg: all the data is
contiguous in memory.
Nice. This idiom should be added to the D docs.
Bye,
bearophile
Re: Allocating large 2D array in D
Steven Schveighoffer: Wow, this is something I didn't know was possible. Very useful! It's it cute when you use a language almost daily for few years, and then you see a new way to allocate built-in arrays? :-) Bye, bearophile
Re: How to read fastly files ( I/O operation)
On 2013-02-04 15:04, bioinfornatics wrote:
I am looking to parse efficiently huge file but i think D lacking for this
purpose.
To parse 12 Go i need 11 minutes wheras fastxtoolkit (written in c++ ) need 2
min.
My code is maybe not easy as is not easy to parse a fastq file and is more
harder when using memory mapped file.
Why are you using mmap? Don't you just go through the file sequentially?
In that case it should be faster to read in chunks:
foreach (ubyte[] buffer; file.byChunk(chunkSize)) { ... }
Question about wchar[]
I am using wchar[] and find the usage clunky. Am I doing something wrong? Example: // Compiler complains that wchar[] != immutable(char)[] wchar[] wstr = This is a wchar[]; // Compiler accepts this wchar[] wstr = This is a wchar[]w.dup; // Compiler accepts this wchar[] wstr; wstr ~= This is a wchar[]; If the compiler knows the type in the last example with concatenation, shouldn't it be able to figure that out in the first example. I am using windows and DMD HEAD. Thanks, ollie
Re: Question about wchar[]
On 02/04/2013 10:13 AM, ollie wrote: I am using wchar[] and find the usage clunky. Am I doing something wrong? Example: // Compiler complains that wchar[] != immutable(char)[] wchar[] wstr = This is a wchar[]; There is nothing but a wchar slice that is going to provide access to the chars on the right-hand side. Unfortunately that is not possible because neither the right-hand side has wchars nor they are mutable. // Compiler accepts this wchar[] wstr = This is a wchar[]w.dup; That's fine: You explicitly make a mutable wchar array. // Compiler accepts this wchar[] wstr; wstr ~= This is a wchar[]; That's fine because the binary ~ operator always makes copies of elements. If the compiler knows the type in the last example with concatenation, shouldn't it be able to figure that out in the first example. The missing bit is that a copy of the char literal itself is not made automatically. Ali
Re: Question about wchar[]
On Mon, 04 Feb 2013 13:13:22 -0500, ollie ol...@home.net wrote: I am using wchar[] and find the usage clunky. Am I doing something wrong? Example: // Compiler complains that wchar[] != immutable(char)[] wchar[] wstr = This is a wchar[]; It's not so much the wchar vs. char, but the mutable vs. immutable. It could be argued that the message should say wchar[] != wstring instead. This works: immutable(wchar)[] wstr = This is a wchar[]; or wstring wstr = This is a wchar[]; // Compiler accepts this wchar[] wstr = This is a wchar[]w.dup; Right, because you are duplicating the string onto the heap, and making it mutable. // Compiler accepts this wchar[] wstr; wstr ~= This is a wchar[]; If the compiler knows the type in the last example with concatenation, shouldn't it be able to figure that out in the first example. No, because the first example does not involve heap allocation, just straight assignment. Appending involves concatenation, and making a copy of the original, so it is safe to do so. -Steve
Re: Question about wchar[]
On 02/04/2013 10:22 AM, Ali Çehreli wrote: On 02/04/2013 10:13 AM, ollie wrote: I am using wchar[] and find the usage clunky. Am I doing something wrong? Example: // Compiler complains that wchar[] != immutable(char)[] wchar[] wstr = This is a wchar[]; There is nothing but a wchar slice that is going to provide access to the chars on the right-hand side. Unfortunately that is not possible because neither the right-hand side has wchars nor they are mutable. As Steven's post shows, it would work if the left-hand side was immutable: immutable(wchar)[] wstr = This is a wchar[]; That line involves some help from the compiler: Because the type of the literal on the right-hand side is not specified, the compiler makes one that matches the type of the left-hand side. In other words, one should not do what I did and assume that literals like this are always char arrays. They are char arrays only when there is c at the end like thisc. Otherwise, although they default to char, the actual type is decided by the compiler. Ali
Re: How to read fastly files ( I/O operation)
FG wrote:
On 2013-02-04 15:04, bioinfornatics wrote:
I am looking to parse efficiently huge file but i think D lacking for this
purpose. To parse 12 Go i need 11 minutes wheras fastxtoolkit (written in c++
) need 2 min.
My code is maybe not easy as is not easy to parse a fastq file and is more
harder when using memory mapped file.
Why are you using mmap? Don't you just go through the file sequentially?
In that case it should be faster to read in chunks:
foreach (ubyte[] buffer; file.byChunk(chunkSize)) { ... }
I would go even further, and organise the file so N Data objects fit one page,
and read the file page by page. The page-size can easily be obtained from the
system. IMHO that would beat this fastxtoolkit. :)
--
Dejan Lekic
dejan.lekic (a) gmail.com
http://dejan.lekic.org
Re: How to read fastly files ( I/O operation)
On Monday, 4 February 2013 at 19:30:59 UTC, Dejan Lekic wrote:
FG wrote:
On 2013-02-04 15:04, bioinfornatics wrote:
I am looking to parse efficiently huge file but i think D
lacking for this
purpose. To parse 12 Go i need 11 minutes wheras fastxtoolkit
(written in c++
) need 2 min.
My code is maybe not easy as is not easy to parse a fastq
file and is more
harder when using memory mapped file.
Why are you using mmap? Don't you just go through the file
sequentially?
In that case it should be faster to read in chunks:
foreach (ubyte[] buffer; file.byChunk(chunkSize)) { ... }
I would go even further, and organise the file so N Data
objects fit one page,
and read the file page by page. The page-size can easily be
obtained from the
system. IMHO that would beat this fastxtoolkit. :)
AFAIK, he is reading text data that needs to be parsed line by
line, so byChunk may not be the best approach. Or at least, not
the easiest approach.
I'm just wondering if maybe the reason the D code is slow is not
just because of:
- unicode.
- front + popFront.
ranges in D are notorious for being slow to iterate on text,
due to the double decode.
If you are *certain* that the file contains nothing but ASCII
(which should be the case for fastq, right?), you can get more
bang for your buck if you attempt to iterate over it as an array
of bytes, and convert the bytes to char on the fly, bypassing any
and all unicode processing.
Re: Question about wchar[]
On Mon, 04 Feb 2013 13:28:43 -0500, Steven Schveighoffer wrote: On Mon, 04 Feb 2013 13:13:22 -0500, ollie ol...@home.net wrote: wchar[] wstr = This is a wchar[]; It's not so much the wchar vs. char, but the mutable vs. immutable. It could be argued that the message should say wchar[] != wstring instead. I am aware of the immutable/mutable issue. My intention was a mutable string. Right, because you are duplicating the string onto the heap, and making it mutable. I thought druntime always created dynamic arrays on the heap and returned a slice. // Compiler accepts this wchar[] wstr; wstr ~= This is a wchar[]; No, because the first example does not involve heap allocation, just straight assignment. Appending involves concatenation, and making a copy of the original, so it is safe to do so. What is the storage (heap/stack) of straight assignment if this were a local variable. Or do you mean that This is a wchar[] was already created on the heap as an immutable(wchar)[] then assigned to wstr. Thanks for your replies Steven and Ali, ollie
Re: Question about wchar[]
On Monday, February 04, 2013 19:45:02 ollie wrote: Right, because you are duplicating the string onto the heap, and making it mutable. I thought druntime always created dynamic arrays on the heap and returned a slice. It does, but duping or iduping an array or string literal would allocate _again_. Also, in at least some cases (e.g. Linux) string literals end up in ROM such that they're shared (both across threads and across uses - e.g. multiple uses of the string literal hello world will potentially end up being exactly the same string in memory). As such, they're actually allocated as part of the program itself rather than when they're used (unlike with normal array literals). So, doing auto str = hello world; won't necessarily allocate anything. But I believe that that's implementation- dependent (e.g. I'm don't think that that happens on Windows). - Jonathan M Davis
Re: Question about wchar[]
On Mon, 04 Feb 2013 14:45:02 -0500, ollie ol...@home.net wrote: What is the storage (heap/stack) of straight assignment if this were a local variable. Or do you mean that This is a wchar[] was already created on the heap as an immutable(wchar)[] then assigned to wstr. The string is actually stored in code, not on the heap. When you assign, you get a pointer right into code (ROM). On some OSes, you can possibly modify this value, on some you will get a memory error. In D1, where there was no immutable, string literals *were* char[]. Then you could have funky stuff like this: auto str = hello; str[0] = 'j'; auto str2 = hello; writefln(str2); // writes jello Of course, this only worked on one of the OSes (I think it was windows). On the others you would get an error. Array literals are different, they are allocated on the heap when they are used. so ['h', 'e', 'l', 'l', 'o'] is very different than hello. There has in the past been a push to make ALL array literals immutable, but it has never gone anywhere. -Steve
Re: Question about wchar[]
On Mon, 04 Feb 2013 15:09:06 -0500, Steven Schveighoffer wrote: On Mon, 04 Feb 2013 14:45:02 -0500, ollie ol...@home.net wrote: What is the storage (heap/stack) of straight assignment if this were a local variable. Or do you mean that This is a wchar[] was already created on the heap as an immutable(wchar)[] then assigned to wstr. The string is actually stored in code, not on the heap. When you assign, you get a pointer right into code (ROM). I seem to remember that now (had a brain fart). Thank you Jonathan and Steven for your help. ollie
Re: Allocating large 2D array in D
On Monday, 4 February 2013 at 16:54:37 UTC, bearophile wrote: Steven Schveighoffer: Wow, this is something I didn't know was possible. Very useful! It's it cute when you use a language almost daily for few years, and then you see a new way to allocate built-in arrays? :-) Bye, bearophile Technically, the straight up C - style syntax also does this just as well: int[2][] a = new int[2][2]; Since the last [2] gets rewritten to [](2) But when written that way, I find it is not very clear what happens. Ideally, I wish we could allocate static arrays on the heap easily: int[2]* p = new int[2]() Anybody know why this doesn't work? In a GC language like D, that has to track capacity/usage of its dynamic arrays, there is a real gain to being able to specify: I want my damn array to be fixed in size: Don't track any growing information for me.
Re: GtkD button size
On 02/04/2013 03:03 PM, SaltySugar wrote: On Sunday, 3 February 2013 at 16:07:06 UTC, Artur Skawina wrote: On 02/03/13 16:53, SaltySugar wrote: GTKD. Can someone explain me how to change button size in vbox, hbox? setSizeRequest (70, 50); doesn't work. Thanks. Try playing with an interactive gui tool, such as glade. The fill, expand and size request interactions will be immediately visible. artur I'm waiting other answers :) A VBox or A HBox will always expand the Widget in the direction opposite of the on it's managing, if it expands the Widget in that direction depends on the options passed to packStart. So get the size request to work with those containers you'll have to wrap a HBox in a VBoc or visa versa. A more convenient container would be the ButtonBox which doesn't expand the Button in the direction it's not managing. And thus properly handles the size request. A Grid or Table might also apply depending on the complete layout. -- Mike Wey
Re: Allocating large 2D array in D
monarch_dodra:
Ideally, I wish we could allocate static arrays on the heap
easily:
int[2]* p = new int[2]()
To do that I wrap the array inside a static struct:
struct Arr {
int[2] a;
}
Arr* data = new Arr;
writeln(data.a[1]);
Anybody know why this doesn't work?
Maybe it's just a matter of syntax. You see it if you use:
struct Arr {
int[2] a;
alias this = a;
}
Arr* data = new Arr;
Now what's data[1]? It's data.a[1] or is it the second (missing)
struct Arr?
So to do that you need transparent references, like ref int[2],
that in D are only present inside functions.
Bye,
bearophile
Re: Allocating large 2D array in D
See also: http://d.puremagic.com/issues/show_bug.cgi?id=9265 Bye, bearophile
A little of coordination for Rosettacode
Is the Fwend user of Rosettacode (or some other interested person) around here? I have written partial D implementations for three tasks, maybe a little of coordination will speedup the work: http://rosettacode.org/wiki/Permutations/Rank_of_a_permutation http://rosettacode.org/wiki/Universal_Turing_machine http://rosettacode.org/wiki/RCRPG Bye, bearophile
void[] and ubyte[]
Hi, In phobos there are places with void[] and places with ubyte[], and I can't really understand why there is this difference. I don't even see why D has a void array or void pointer anyway. For example, in std.base64, ubyte[] is used as the basic quantity for encoding, while in std.zlib, it's void[]. Both libraries have a similar pair of functions like encode/decode or compress/uncompress. Both act on raw memory. So why not use ubyte[] all the time? Isn't any stretch of bare data on the heap in the end an array of bytes? Void[] seems like a C-anachronism to me. I have no experience with void pointers or arrays, so I am probably missing something. Thanks, Stephan
Re: How to read fastly files ( I/O operation)
On Mon, 4 Feb 2013, monarch_dodra wrote: AFAIK, he is reading text data that needs to be parsed line by line, so byChunk may not be the best approach. Or at least, not the easiest approach. I'm just wondering if maybe the reason the D code is slow is not just because of: - unicode. - front + popFront. First rule of performance analysis.. don't guess, measure.
x.RC.__postblit () is not callable using argument types () const
I've seen these type of errors often and usually the cause kind of jumps out. In this case I'm totally confused. Just trying to move from 2.06 to 2.061. The code is: http://dpaste.dzfl.pl/f40e4d6f and fails with the error in subject line. Observations: - If static if(1) is changed to static if(0) it compiles - If either _valuationHistory or goo member of BSItem is commented out it compiles. I know the code is somewhat cryptic, but I've been using binary reduction comment in/out to try to narrow down this issue. I can not understand why an introduction of opEquals on a struct History with no relationship to RC causes an error to show for RC. Thanks Dan
Re: x.RC.__postblit () is not callable using argument types () const
On 02/04/2013 05:15 PM, Dan wrote:
I've seen these type of errors often and usually the cause kind of jumps
out. In this case I'm totally confused. Just trying to move from 2.06 to
2.061.
The code is: http://dpaste.dzfl.pl/f40e4d6f
and fails with the error in subject line. Observations:
- If static if(1) is changed to static if(0) it compiles
- If either _valuationHistory or goo member of BSItem is commented out
it compiles.
I know the code is somewhat cryptic, but I've been using binary
reduction comment in/out to try to narrow down this issue. I can not
understand why an introduction of opEquals on a struct History with no
relationship to RC causes an error to show for RC.
Thanks
Dan
Further reduced:
struct History(V) {
bool opEquals(const typeof(this) other) const {
return true;
}
}
struct RC {
this(this) { _impl = _impl.dup; }
string[] _impl;
}
struct BSItem {
ValuationHistory _valuationHistory;
RC[int] goo;
}
struct ValuationHistory {
History!double _history;
}
void main() {
}
The problem is related to History.opEquals being 'const'. Remove that
'const' and the code compiles. This must be a (lack of)
const-correctness issue.
Ali
Re: x.RC.__postblit () is not callable using argument types () const
On Tuesday, 5 February 2013 at 01:38:54 UTC, Ali Çehreli wrote: Further reduced: [snip] The problem is related to History.opEquals being 'const'. Remove that 'const' and the code compiles. This must be a (lack of) const-correctness issue. Thanks Ali. If const is removed it will compile. I think you are correct it is a const issue, but I'm at a loss as to why? After all, it does not access anything and just returns true. I don't see any const issues. I can't say for sure, but I feel this worked fine in 2.06. What I find troubling is how long it took me cull the code to the offending and I still don't understand the error. Thanks Dan
Re: x.RC.__postblit () is not callable using argument types () const
On 2/5/13, Dan dbdavid...@yahoo.com wrote: and I still don't understand the error. The error in the git-head version is: Error: mutable method test.RC.__postblit is not callable using a const object Error: cannot modify struct this Slot with immutable members Yeah, it's still not very helpful. And I have no idea where Slot comes from.
Re: Allocating large 2D array in D
On Monday, 4 February 2013 at 22:02:48 UTC, bearophile wrote:
monarch_dodra:
Ideally, I wish we could allocate static arrays on the heap
easily:
int[2]* p = new int[2]()
To do that I wrap the array inside a static struct:
struct Arr {
int[2] a;
}
Arr* data = new Arr;
writeln(data.a[1]);
[SNIP]
Bye,
bearophile
Yeah... but then I do that, I also tend to smash against the
initial:
//
struct Arr {
double[4000][4000] a;
}
Arr* data = new Arr;
writeln(data.a[1]);
//
Error: index 4000 overflow for static array
//
I don't fully understand what this means, so I haven't complained
yet. Is this a legit error on my end, with the compiler
protecting me, or a false positive, where the compiler thinks I
want to allocate Arr on the stack...?
Re: How to translate C# 'readonly' keyword into D
On 2013-02-04 14:35, o3o wrote:
So, let me continue the example (I remove const for simplicity)...
I would like check that bar.gun() call fun() function from IFoo
unittest {
auto foo = new MockIFoo(); //Will not compile.Mock doesn't (yet)
exist
auto bar = new Bar(foo);
bar.gun();
foo.Received().fun(); // pass if 'fun' was called
}
void main() {}
The syntax for template instantiation is:
auto foo = new Mock!(IFoo)();
--
/Jacob Carlborg
Re: How to read fastly files ( I/O operation)
On 2013-02-04 20:39, monarch_dodra wrote: AFAIK, he is reading text data that needs to be parsed line by line, so byChunk may not be the best approach. Or at least, not the easiest approach. He can still read a chunk from the file, or the whole file and then read that chunk line by line. I'm just wondering if maybe the reason the D code is slow is not just because of: - unicode. - front + popFront. ranges in D are notorious for being slow to iterate on text, due to the double decode. If you are *certain* that the file contains nothing but ASCII (which should be the case for fastq, right?), you can get more bang for your buck if you attempt to iterate over it as an array of bytes, and convert the bytes to char on the fly, bypassing any and all unicode processing. Depending on what you're doing you can blast through the bytes even if it's Unicode. It will of course not validate the Unicode. -- /Jacob Carlborg
