If I'm reading how pure works, my original example was likely
broken as it was part of a struct that returned a state value
(although the contract constraints meaning was still valid).
So is pure fully usable or is it not yet ready? Makes me think
that pure should have further
Pure does not imply const in D. If you want stronger
guarantees, just turn 'test' into a const (or immutable) member
function. In D, a function can change anything that is mutable
and reachable through its parameters, this includes the
implicit 'this' pointer. The reason for this design is
Probably the restriction was lifted after TDPL was out.
Yes. The compiler will only reorder/run in parallel/optimize if
it is safe (not changing execution semantics). Pure can be used
to prove that certain optimizations are safe. If a pure
function only takes const or immutable arguments,
the signature I meant looks like
pure int squaredPlus(int)immutable;
Which then the only way you could call it, was if the object
itself was immutable, which is definitely safe (I think). Hmmm...
I've been working and building a struct called 'AllTypes' which
I've come to the conclusion is already available as a variant.
However as I look at the documentation I don't see any
methods/constructors to use where I can specify where I want the
data to be access from.
The data I will be
I see that it's not exactly what you are looking for, but have
you looked at std.conv.emplace()?
I've glanced it over, and I don't understand it, but it also
doesn't quite seem right.
I know sometimes I'll know what the type and size is, but most of
the time only my array of data will
On Tuesday, 7 February 2012 at 17:51:42 UTC, Pedro Lacerda wrote:
You can roll your own tagged union instead. The S struct can
store long and
byte[], S.ptr is a pointer to the data.
Yep, a bit like my code, except with switch cases covering all
major types; That and trying to do comparison
I think I have a misunderstanding of how 'package' is suppose to
work. How I understand it, you will give access to the directory,
unlike private which will hide it outside of the same file.
This problem comes up since a struct is declared inside a
package (and even instantiated), however
On Sunday, 22 April 2012 at 23:32:40 UTC, Jonathan M Davis wrote:
1. Package access is _very_ broken:
http://d.puremagic.com/issues/show_bug.cgi?id=143
Fun... So it's not just me... Guess for the 1-2 places I 'll
need package level access instead I gotta either do public or get
some getters
This is an interesting one that has cropped up. I'm curious if
this is because the differences between a fixed/dynamic arrays.
Working around it is easy enough but that it even does it is an
annoyance.
I'm not seeing this exact problem in the archives, and I am
not
sure if it's in the
On Wednesday, 25 April 2012 at 12:43:39 UTC, Steven Schveighoffer
wrote:
http://d.puremagic.com/issues/show_bug.cgi?id=7254 maybe?
Maybe... but it shouldn't be the wrong return; at least being a
static length known at compile-time should convert to char[4].
I'm not sure how try/catch would
On Thursday, 26 April 2012 at 05:16:51 UTC, H. S. Teoh wrote:
Besides, D's auto-deferencing semantics on pointers
makes the difference barely noticeable anyway. Pointers
auto-deference when using '.' member notation, for example. Once
in a while you have to explicitly dereference a pointer or
On Wednesday, 25 April 2012 at 17:52:36 UTC, bioinfornatics wrote:
i search some example of something easy (more easy) to do in D
an not
in another language if possible
- D - C++
- D - Haskell
- D - Java
- D - python
thanks a lot
Associative arrays?
C++:
#include map
#include string
On Thursday, 26 April 2012 at 12:30:02 UTC, Nicolas Sicard wrote:
I think that many D powerful features are also easily done in
Python or have easy to use equivalents, thanks to built-in
dictionaries, list comprehensions, eval, etc. and so many
available libraries. Albeit at the price of a
On Friday, 27 April 2012 at 16:02:00 UTC, Steven Schveighoffer
wrote:
On Fri, 27 Apr 2012 11:33:39 -0400, Joseph Rushton Wakeling
On 27/04/12 17:18, Steven Schveighoffer wrote:
const should not affect code generation *at all*, except for
name mangling
(const MyStruct is a different type from
On Saturday, 28 April 2012 at 00:04:05 UTC, Joseph Rushton
Wakeling wrote:
On 28/04/12 00:29, Era Scarecrow wrote:
At the off chance it's shallow copying, this should remove
that.
Ahhh, that works. Thank you!
... because I found I got about a 2s speedup. It's exactly the
speedup which
On Sunday, 29 April 2012 at 22:35:19 UTC, Jason King wrote:
I'm another of what seem to be legions of people trying to
interface with OS stores that keep void * in c/c++. My
particular one is Windows TLSData, but for my example I don't
need any Windows code, just D.
void* opCast() {
On Sunday, 29 April 2012 at 23:42:39 UTC, WhatMeWorry wrote:
I'm trying to get my head around D's type conversion. What is
the
best way to convert a string to a char array? Or I should say is
this the best way?
string s = Hello There;
char[] c;
c = string.dup;
Also, what is the best way to
On Monday, 30 April 2012 at 00:28:15 UTC, Jason King wrote:
myobject.sizeof returns 4 (in 32 bit DMD) for every object I've
tested, so I'm inclined to suspect its a bog-standard pointer,
just what I'm looking to save and retrieve.
Anybody else want to chime in?
I'd say that's right and wrong.
In some code I'm working on, my asserted when I've confirmed it
was correct. With the opCmp() overridden. 'this' refers to the
current object, so why doesn't the first one succeed?
class X {
int z;
this(int xx) {
z = xx;
}
override int opCmp(Object y){
X x = cast(X)
On Monday, 30 April 2012 at 05:07:04 UTC, Ali Çehreli wrote:
You mean object? A class variable is just a handle to the
class object. Class variables are implemented as pointers, so
yes, they will be the size of a pointer. Since I suspect that
the pointers are 4 bytes on the OP's 32-bit system,
On Monday, 30 April 2012 at 05:22:56 UTC, Jonathan M Davis wrote:
== uses opEquals, not opCmp. It's using Object's opEquals,
which does a
comparison of the references, so it's true when comparing the
exact same
object and false otherwise.
Ahhh of course. Personally I think opCmp includes
On Monday, 30 April 2012 at 18:30:29 UTC, Rowan wrote:
--
File: MyLib.d:
--
module MyLib;
import core.runtime;
import core.sys.windows.windows;
//import std.string;
So if I want to make any file (in this case test.d, which can
just import MyLib after I have -lib'd
On Monday, 30 April 2012 at 19:22:35 UTC, Rowan wrote:
Add 'import test;' to your MyLib module.
That does work, but I didn't want to change the source of
MyLib, I dunno maybe what I'm asking isn't possible.
Is there a reason the library needs to call outside of it's own
library access?
On Tuesday, 1 May 2012 at 02:49:19 UTC, bioinfornatics wrote:
Le lundi 30 avril 2012 à 14:52 +0200, bioinfornatics a écrit :
Anyone know how to know the position of 3 token in one sequence
in one
pass?
tok1 = a
tok2 = b
tok3 = c
seq = blah count me
b= 0 a=2 c=5
iterate over sequence if token
I have the following dilemma. Hopefully I have this right.
struct X {
ref X opAssign(X x2);
ref X opAssign(ref X x2);
}
X fn();
void func(){
X x, x2;
x = x2; //uses ref
x = fn(); //without ref
}
According to the book, this is how it is suppose to be. const is
a added promise not
On Friday, 4 May 2012 at 06:15:21 UTC, Jonathan M Davis wrote:
I believe that the issue is that x2 isn't const, so when the
compiler decides which of the two overloads to use, it picks
the one which doesn't use const. If the const ref version were
the only one, then it would work with x2, but
On Friday, 4 May 2012 at 06:48:40 UTC, Jonathan M Davis wrote:
If you make the one which isn't a ref const as well, it'll
probably work.
Yeah I think so too. It will just be either a direct copy or I
cast the object as const and pass it through. Seems like extra
work to me and should be
On Friday, 4 May 2012 at 06:55:47 UTC, Jonathan M Davis wrote:
With the last beta, there was a discussion in changing how ref
and const ref works to allow rvalues while disallowing whatever
use cases it is that causes problems with that in C++. If that
gets sorted out and fully implemented,
On Friday, 4 May 2012 at 12:42:54 UTC, Steven Schveighoffer wrote:
I don't think it will make a copy of a temporary even if it's
cast to const. I think marking the non-ref version as const
will solve the problem how you wish (as long as the argument
really *isn't* modified inside that
On Friday, 4 May 2012 at 20:35:57 UTC, Era Scarecrow wrote:
Well the result seems to be true enough.. It also seems to
work if both are const. Why didn't I consider that before?
Maybe it should be noted in the next TDPL book.
As I look at my code I realize why now. Pointers and arrays
On Friday, 4 May 2012 at 21:29:14 UTC, Steven Schveighoffer wrote:
On Fri, 04 May 2012 17:26:02 -0400, Era Scarecrow
On Friday, 4 May 2012 at 21:12:55 UTC, Steven Schveighoffer
wrote:
y[] = x2.y[];
// as you did below
That may deal with the language requirements, but the ideal
was to take
On Saturday, 5 May 2012 at 02:21:06 UTC, Jonathan M Davis wrote:
As I understand it, you don't need to do _anything_ special to
avoid having a temporary copied when passed to your function.
Because it's a temporary, it should be moved into the function
parameter, not copied. No postblit or
On Saturday, 5 May 2012 at 03:32:06 UTC, Jonathan M Davis wrote:
If you've declared an opAssign, I'd be very surprised if _any_
assignment worked which didn't work with the opAssign that you
declared. Once you've declared an opAssign, you've taken over
the assignment operator, and you need
On Saturday, 5 May 2012 at 03:32:06 UTC, Jonathan M Davis wrote:
-
Functions are overloaded based on how well the
arguments to a function can match up with the
parameters. The function with the best match is
selected. The levels of matching are:
1. no match
2.
On Saturday, 5 May 2012 at 04:15:21 UTC, Jonathan M Davis wrote:
On Saturday, May 05, 2012 05:50:26 Era Scarecrow wrote:
Hmm maybe it should have a preference for Lvalue vs Rvalue...
So... Walter or Andrei?
1. no match
2. match with implicit conversions (Lvalue required)
3. match
On Saturday, 5 May 2012 at 04:15:21 UTC, Jonathan M Davis wrote:
This will likely be _very_ relevant to the proposed changes
which make ref and const ref work with rvalues (the details on
that are still being sorted out, I believe). However, I don't
believe that either Walter or Andrei
On Wednesday, 9 May 2012 at 20:38:05 UTC, Jonathan M Davis wrote:
You can't. Either just unit test the outer function or extract
the nested function as a private one outside of the outer one.
And if you can't do that because it's a delegate, then it
wouldn't make sense to unit test it
On Friday, 11 May 2012 at 19:24:49 UTC, Graham Fawcett wrote:
It sure would. I suspect that Jesse's approach...
readText(file.in).splitLines()
...would be the most efficient way if you need an actual array:
slurp the whole file at once, then create an array of
memory-sharing slices.
On Friday, 11 May 2012 at 21:13:41 UTC, Paul wrote:
std.utf.UTFException@std\utf.d(644): Invalid UTF-8 sequence (at
index 1)
What are you reading? If it's regular text (0-127) then you
shouldn't have an issue. However 128-255 (or, -1 to -127) are
treated differently. D by default is UTF-8 or
On Sunday, 13 May 2012 at 16:25:42 UTC, japplegame wrote:
I have no idea how to simple initialize shared associative
array. This code compiled but causing access violation when
running.
shared uint[char] arr;
shared static this() {
// next expression seems wrong, because
// arr is
On Monday, 14 May 2012 at 18:00:42 UTC, Roman D. Boiko wrote:
On Monday, 14 May 2012 at 17:37:02 UTC, Dmitry Olshansky wrote:
But hopefully you get the idea. See something simillar in
std.regex, though pointer in there also serves for intrusive
linked-list.
Thanks, most likely I'll go your
On Monday, 14 May 2012 at 18:00:42 UTC, Roman D. Boiko wrote:
On Monday, 14 May 2012 at 17:37:02 UTC, Dmitry Olshansky wrote:
But hopefully you get the idea. See something simillar in
std.regex, though pointer in there also serves for intrusive
linked-list.
Thanks, most likely I'll go your
On Wednesday, 16 May 2012 at 07:04:09 UTC, Jonathan M Davis wrote:
that assertion would pass, but it doesn't, and it shouldn't. If
your range was a reference type (e.g. if it were a class or it
was like the ranges in std.stdio which deal with I/O), then
using it with foreach would consume it,
On Wednesday, 16 May 2012 at 07:41:14 UTC, Jonathan M Davis wrote:
void main()
{
prime_walk pw;
pw.cap = 100;
foreach(i; pw)
writefln(%s %s, i, pw.position);
}
You'd see that pw.postion is always printed as 2, just like
Nick's foo.val
always prints as 0.
Hmmm...
[quote]
0m0.015s
sys 0m0.015s
-- rewrite with prime_walk
module te35;
import std.stdio;
//prime_walk by Era Scarecrow.
//range of primes, nearly O(1) for return.
struct prime_walk {
int map[int];
int position = 2;
int cap = int.max;
int front() {
return position;
}
void popFront
On Wednesday, 16 May 2012 at 11:12:19 UTC, Stephen Jones wrote:
Ali your post above, and T your post in the other forum
(Simpsons bit) is sort of what I was after. I tried both
interface and abstract class but not outright super class. The
problem I have with the solution is the same problem I
On Wednesday, 16 May 2012 at 13:10:06 UTC, Tiberiu Gal wrote:
The correct answer is 55
Your versions of isCircularPrime just truncates the number (
this is actually useful in a next problem though; )
Hmm glancing at the original source I see what you mean. A
slight modification to fill
On Wednesday, 16 May 2012 at 20:50:55 UTC, Nick Sabalausky wrote:
I was initially open to the idea I may have just misunderstood
something, but I'm becoming more and more convinced that the
current foreach over an implicit copy behavior is indeed a
bad idea.
I'd love to see Andrei weigh in
On Saturday, 19 May 2012 at 16:43:03 UTC, Jay Norwood wrote:
On Wednesday, 16 May 2012 at 09:26:45 UTC, Tiberiu Gal wrote:
hi
many claim their code solves the problem in order of ms (
c/pascal/haskell code)
I used the blockwise parallel sieve described here, and
measured nice speed-ups
On Wednesday, 23 May 2012 at 21:02:27 UTC, Paul wrote:
I wonder about the speed between this method and Era's
home-spun solution?
My solution may have a flaw in it's lookup table; namely if I
got one of the codes wrong. I used regex and a site to reference
them all so I Hope it's right. I
On Saturday, 26 May 2012 at 22:02:10 UTC, Jonathan M Davis wrote:
Now, that aside, the results with hash2 definitely look like a
bug to me. It's probably just the result of one more of the
many issues with the current AA implementation.
This is what I'm guessing too. I've made toHashes in my
Curiously I'm making a huffman compression algo for fun, however
I didn't see anything in std.array or anywhere that was to
support bools specifically (in a packed form anyways). So I'm
making one. So far I've got it saving the data as uint, 0 refers
to the most significant bit and 7 the
On Sunday, 27 May 2012 at 06:58:21 UTC, Era Scarecrow wrote:
On Sunday, 27 May 2012 at 06:53:33 UTC, Alex Rønne Petersen
wrote:
std.bitmanip.BitArray.
And I was certain I checked std.bitmanip. Oh well, I'll throw
my current unittests at it and perhaps improve what's already
avaliable
On Sunday, 27 May 2012 at 07:04:36 UTC, Alex Rønne Petersen
wrote:
It could definitely use some improvement. In particular:
* It still uses the deprecated operator overload methods,
rather than opBinary(Right) and opUnary.
* It's not quite const/immutable-friendly.
* It forces the GC on you.
On Sunday, 27 May 2012 at 17:26:33 UTC, Chris Cain wrote:
And also std.container.Array ... it has a specialization that
packs bools. It also appears to be more modern.
Unfortunately I'm not following, either in the documentation or
glancing over the sources.
On Sunday, 27 May 2012 at 18:18:13 UTC, Era Scarecrow wrote:
On Sunday, 27 May 2012 at 17:26:33 UTC, Chris Cain wrote:
And also std.container.Array ... it has a specialization that
packs bools. It also appears to be more modern.
Unfortunately I'm not following, either in the documentation
On Sunday, 27 May 2012 at 18:25:38 UTC, Jonathan M Davis wrote:
AFAIK, there are no plans to get rid of it due to the bool
packing in std.container.Array, so if there's anything that you
can do to improve it, go right ahead. Help is welcome.
Well so far the biggest problem I have is trying
On Monday, 28 May 2012 at 21:59:36 UTC, Dmitry Olshansky wrote:
Check your math. Xor != sub.
1 ^ 0 == 1, 0 ^ 1 == 1;
Compare with
1 sub 0 == 1, 0 sub 1 == 0.
That is, for one thing, sub is asymmetric :)
Hmm well subs would all happen at the 1 bit level. So let's
compare.
xor
0 ^ 0 = 0
0
On Tuesday, 29 May 2012 at 06:30:37 UTC, Dmitry Olshansky wrote:
You surely haven't looked at the source code did you? :)
It's conceptualy non per bit '-', it's a set difference...
I recall looking at it, but to me that just didn't make sense. I
could add subtract back and update it (Not
On Tuesday, 29 May 2012 at 06:56:40 UTC, Dmitry Olshansky wrote:
On 29.05.2012 10:52, Era Scarecrow wrote:
I considered that, but then you actually limit your address
space to
2^63,
No you don't. Since pointer is already a pointer to word-sized
object. It has 2 last bits == 0. Always
Got some improvements, although the bulk work needs to be tested
more otherwise it all seems to work quite well. Once I figure out
how to post to GitHub I'll upload a version for everyone to play
with and review. Code's not beautiful, but other than the length
function, most of it is easy to
On Wednesday, 30 May 2012 at 11:19:43 UTC, Dmitry Olshansky wrote:
It all went nice and well...
Ouch why 36 bytes?
Well for the whole normal size it was 32bytes, or 24 if I drop
the ulong 'reserved' which does a minor optimization so it can
expand rather than duping every time it expands
On Wednesday, 30 May 2012 at 19:43:32 UTC, Dmitry Olshansky wrote:
On 30.05.2012 23:25, Era Scarecrow wrote:
That overhead is for concatenation ? Did it ever occurred to
you that arrays do sometimes reallocate on append. And of
course a ~ b should produce new copy (at least semantically
While working on the BitArray I've come across an interesting
dilemma, which is both bad and good. Let's take the following
struct S {
size_t[] array;
}
Simple enough, however make a const function, and suddenly you
can't return a copy of it.
S copy() const {
return this;
On Friday, 1 June 2012 at 20:24:39 UTC, Era Scarecrow wrote:
//from const, to const
const(S) opSlice(int s, int e) const {
S s = this; //compile error this.array is const
s.array = this[s .. e]; //compile error
return s;
}
Correction: Seems this didn't get updated while I
On Friday, 1 June 2012 at 21:15:18 UTC, Ali Çehreli wrote:
Don't forget inout, which seems to be working at least in this
case:
I'd given up on trying to use inout, being as it's confusing to
try and use, when I try to use it it, it always complains.
Perhaps better documentation/examples or
On Friday, 1 June 2012 at 23:14:14 UTC, Dmitry Olshansky wrote:
There is also cast() that just cancels out all
const/shared/immutable.
Only the first level, transitive const/immutable don't go away
in my experience. Perhaps I'm doing it wrong, or perhaps it's
just a protective feature to
The documentation for bitfields doesn't go into detail if you
can put any default values into it. Can you? It makes sense if
you can that it would convert the whole thing into a single
number (or or-ing the results into a single expression with
shifting and all).
From what I can tell it
I've come across an interesting problem. You can template quite
a few items, but not enums? Some thoughts from the experts would
likely be nice. Consider...
enum(T) X{ //syntax error
bitsPerT = T.sizeof * 8,
//further calculation types can follow
}
assert(X!(byte).bitsPerT == 8);
On Wednesday, 6 June 2012 at 19:27:25 UTC, Johannes Pfau wrote:
Am Wed, 06 Jun 2012 21:01:21 +0200
schrieb Era Scarecrow rtcv...@yahoo.com:
According to http://dlang.org/template.html
something like this:
---
class Bar(T) { T member; }
---
is actually only syntactic
On Wednesday, 6 June 2012 at 20:52:14 UTC, bearophile wrote:
That seems correct, this works:
template Foo(T) {
enum Foo {
bitsPerT = T.sizeof * 8,
}
}
void main() {
pragma(msg, Foo!int.bitsPerT);
}
So if template Foo(T){enum Foo{}} works, then I think it should
also work the
On Wednesday, 6 June 2012 at 17:05:35 UTC, Jonathan M Davis wrote:
On Wednesday, June 06, 2012 16:04:14 Paul wrote:
I have and array string[string][string][string] that works
great for everything I need except that they (assoc. arrays)
don't maintain an order. I need to maintain the order of
On Friday, 8 June 2012 at 16:33:28 UTC, Matthias Walter wrote:
Hi,
trying to traverse the entries of a std.bitmanip.BitArray I
stumbled upon the following problem:
In case I want to accept const(BitArray) objects, it shall look
like the following (maybe using ref const(bool) for the
On Friday, 8 June 2012 at 18:49:42 UTC, Nathan M. Swan wrote:
It seems like you're confusing _associative_ arrays with
_regular_ arrays; they are different things.
A regular array is written as T[], or an array of Ts.
An associative array is written as K[V], or a map from K to V.
If you
On Saturday, 9 June 2012 at 10:09:25 UTC, Matthias Walter wrote:
First, thank you for your answer. I've already made some tiny
modifications in order to make BitArray work for my purposes:
https://github.com/xammy/phobos/commit/eb46d99217f2bf1e6d173964e2954248b08146d6
If you plan to create
Most curiously while making unittests the asserts fail when I've
confirmed it's working. The difference seems to be if it's
immutable/const vs non, and why this makes a difference I don't
see... Can someone give some light to this?
const float i_f = 3.14159265;
float a = i_f;
float b = i_f;
On Monday, 11 June 2012 at 11:47:59 UTC, Matej Nanut wrote:
On Monday, 11 June 2012 at 10:33:22 UTC, Era Scarecrow wrote:
Most curiously while making unittests the asserts fail when
I've confirmed it's working. The difference seems to be if
it's immutable/const vs non, and why this makes
On Monday, 11 June 2012 at 12:54:37 UTC, Adam D. Ruppe wrote:
a == b is probably done by the bits at runtime which match
because it is the same assignment.
But a == i_f might be propagated down there as 80 bit compared
to 32 bit and thus be just slightly different.
Unfortunately I used
On Monday, 11 June 2012 at 20:28:06 UTC, Era Scarecrow wrote:
On Monday, 11 June 2012 at 12:54:37 UTC, Adam D. Ruppe wrote:
a == b is probably done by the bits at runtime which match
because it is the same assignment.
But a == i_f might be propagated down there as 80 bit compared
to 32 bit
On Tuesday, 5 June 2012 at 00:17:08 UTC, bearophile wrote:
Era Scarecrow:
The documentation for bitfields doesn't go into detail if you
can put any default values into it. Can you?
I think you can't. See:
http://d.puremagic.com/issues/show_bug.cgi?id=4425
Bye,
bearophile
K, I think I have
On Tuesday, 12 June 2012 at 13:05:26 UTC, bearophile wrote:
Era Scarecrow:
struct defs {
mixin(bitfields_D!(
bitfields!( //borrowed from std.bitmanip
bool, b, 1,
uint, i, 3,
short, s, 4),
i=2,
s=5));
}
Are you able to support a syntax like:
struct defs {
mixin
On Tuesday, 12 June 2012 at 15:51:31 UTC, Era Scarecrow wrote:
On Tuesday, 12 June 2012 at 13:05:26 UTC, bearophile wrote:
Are you able to support a syntax like:
struct defs {
mixin(bitfields!(
bool, b, 1,
uint, i=2, 3,
short, s=5, 4));
}
That does look cleaner and better IMO
On Thursday, 14 June 2012 at 23:57:36 UTC, Roman D. Boiko wrote:
immutable struct Node{ string s; }
Node[] f()
{
Node[] arr = ...?
return arr;
}
How to fill an array, if its elements are immutable? I want to
assign values calculated by some function.
I recall this in TDPL, you can append
On Saturday, 16 June 2012 at 09:31:35 UTC, Tommi wrote:
Do you consider it to be good or bad style of programming to
use consistently auto as function return type?
One of the pros is that it saves some redundant typing when the
function returns some complex templated type:
auto getValue()
{
On Monday, 18 June 2012 at 13:22:24 UTC, maarten van damme wrote:
and something I forgot to ask, is it a conscious decision to
not print out fired asserts in treads? Normally when an assert
fails my whole program crashes and I can see what went wrong.
With treads however, it quietly dies.
On Wednesday, 20 June 2012 at 17:47:15 UTC, Jonathan M Davis
wrote:
On Wednesday, June 20, 2012 17:47:05 Alex Rønne Petersen wrote:
The static keyword has no effect on module functions, so 2 and
3 are equivalent. There is no significant difference between
static class methods and module
On Sunday, 27 May 2012 at 18:25:38 UTC, Jonathan M Davis wrote:
AFAIK, there are no plans to get rid of it due to the bool
packing in std.container.Array, so if there's anything that you
can do to improve it, go right ahead. Help is welcome.
Annoying, twice I've tried to branch/fork to post
On Tuesday, 3 July 2012 at 02:20:23 UTC, ixid wrote:
I'm not sure what's going on here. Using this code to solve a
reddit programming challenge to return the Nth term of a
Fibonacci-like sequence of arbitrary length:
module main;
import std.stdio, std.array, std.datetime;
ulong
Something that was coming to mind a while back was that classes
can include interfaces while structs cannot. I can understand
easily why this wouldn't work being much lower level compared to
how classes are (And the vast varying of parameters and return
types).
But could the notation be
On Thursday, 5 July 2012 at 18:30:51 UTC, Jonathan M Davis wrote:
Aside from the problem that it looks like inheritance when it's
not, declaring an interface for a struct would actually be too
restrictive in many cases.
snip
If it were defined with an interface, how would you deal with
the
When you use the length property it allocates space and assigns
it to the immutable array. the array now contains data (10 0's).
You've said you won't change any data in it's declaration but the
array itself can be changed (appending or a different array).
I would think the best solution is
On Tuesday, 24 July 2012 at 19:42:34 UTC, David wrote:
I agree. I don't know how the CPU handles misaligned floats,
but from
what I understand, it will do two loads to fetch the two
word-aligned
parts of the float, and then assemble it together. This may be
what's
causing the slowdown.
T
On Friday, 27 July 2012 at 01:50:57 UTC, wmunger wrote:
I need to write to a file that is 50 to 250GB on all three
major operating systems.
I tried to use the c function pwrite64. But it is not
available on the Mac.
I have seen where some have used the iostream in C++ but this
does not
On Friday, 27 July 2012 at 19:01:39 UTC, Namespace wrote:
I also get null references (and every time I hate D a bit
more), but mostly my classmates and other friends whom I've
shown D. And most of them are already back to C++ or C#. And I
can understand them.
If you want that D is sometimes
On Friday, 27 July 2012 at 19:48:33 UTC, Adam D. Ruppe wrote:
On Windows, an access violation (from a null pointer or other
causes) is an exception that is thrown and can even be caught.
On Linux, a segfault is a signal that just kills the program,
it doesn't work like a regular exception.
BitFields:
https://github.com/rtcvb32/phobos/commit/729c96e2f20ddd0c05a1afb488030b5c4db3e012
new BitArray Overhead functions/templates:
https://github.com/rtcvb32/phobos/commit/55aaf82a39f3901f03f5f1ac26fd175c5b2cd167
BitArray:
On Saturday, 28 July 2012 at 20:59:15 UTC, Dmitry Olshansky wrote:
Great! But I strongly suggest to repost it in d.D newsgroup as
it has wider audience and is more appropriate for reviews.
I was thinking of not bothering Andrei or Walter while i fixed
other issues on it before bringing more
On Saturday, 28 July 2012 at 21:07:31 UTC, Jonathan M Davis wrote:
I would point out that while hasSlicing doesn't currently check
for it, if opSlice doesn't return a type which is assignable to
the original range, it won't work in a lot of Phobos functions.
I keep meaning to bring that up for
On Saturday, 28 July 2012 at 21:30:21 UTC, Jonathan M Davis wrote:
Well, it seems that my comment was somewhat misplaced in that
BitArray isn't a range but a container. My comment was directed
at opSlice on ranges. Container types should return whatever
range type is appropriate. That will
1 - 100 of 523 matches
Mail list logo