For Every lib its a design descision if containers should be value- or
reference-types. In C++ STL they are value-types (i.e. the
copy-constructor does a real copy), while in tango and phobos the
descision was to go for reference-types afaik, but I would like to be
able to write value-types too
On 08.12.2010 23:45, Jonathan M Davis wrote:
On Wednesday, December 08, 2010 14:14:57 Simon Buerger wrote:
For Every lib its a design descision if containers should be value- or
reference-types. In C++ STL they are value-types (i.e. the
copy-constructor does a real copy), while in tango and
On 09.12.2010 23:39, Jesse Phillips wrote:
Simon Buerger Wrote:
vector!int row = [1,2,3];
auto vec = Vector!(Vector!int)(5, row);
then vec should be 5 rows, and not 5 times the same row.
Why? You put row in there and said there was 5 of them.
vec[] = row.dup;
I believe that would be the
On 14.12.2010 20:02, Andrei Alexandrescu wrote:
I kept on literally losing sleep about a number of issues involving
containers, sealing, arbitrary-cost copying vs. reference counting and
copy-on-write, and related issues. This stops me from making rapid
progress on defining D containers and other
On 14.12.2010 20:53, Andrei Alexandrescu wrote:
Coming from an STL background I was also very comfortable with the
notion of value. Walter pointed to me that in the STL what you worry
about most of the time is to _undo_ the propensity of objects getting
copied at the drop of a hat. For example, t
On 21.12.2010 18:45, Bruno Medeiros wrote:
On 09/12/2010 21:55, Simon Buerger wrote:
From a pragmatic viewpoint you are right, copying containers is rare.
But on the other hand, classes imply a kind of identity, so that a set
is a different obejct then an other object with the very same
On 18.01.2011 01:24, spir wrote:
On 01/17/2011 07:57 PM, Daniel Gibson wrote:
IMHO * (multiply) is not good because in theoretical computer science
multiply is used to concatenate two words and thus concatenating a word
with itself n times is word^n (pow(word, n) in mathematical terms).
Weird.
On 28.01.2011 19:31, Andrei Alexandrescu wrote:
1. Containers will be classes.
2. Most of the methods in existing containers will be final. It's up
to the container to make a method final or not.
3. Containers and their ranges decide whether they give away
references to their objects. Sealing i
On 31.01.2011 17:53, Steven Schveighoffer wrote:
http://www.dsource.org/projects/dcollections
-Steve
Well, seems not bad on a quick look. But source is updated 2 years
ago, so I doubt it would compile with current dmd. Anyway, the topic
here is the std-behaviour of the std-lib. But sure, alw
nitely take a closer look later. Thx for mentioning.
On 31.01.2011 19:09, Steven Schveighoffer wrote:
On Mon, 31 Jan 2011 12:48:06 -0500, Simon Buerger wrote:
On 31.01.2011 17:53, Steven Schveighoffer wrote:
http://www.dsource.org/projects/dcollections
-Steve
Well, seems not bad on a quick
On 01.02.2011 18:08, Steven Schveighoffer wrote:
On Tue, 01 Feb 2011 11:44:36 -0500, Michel Fortin
wrote:
On 2011-02-01 11:12:13 -0500, Andrei Alexandrescu
said:
On 1/28/11 8:12 PM, Michel Fortin wrote:
On 2011-01-28 20:10:06 -0500, "Denis Koroskin" <2kor...@gmail.com>
said:
Unfortunatel
On 01.02.2011 20:01, Michel Fortin wrote:
On 2011-02-01 12:07:55 -0500, Andrei Alexandrescu
said:
With this, the question becomes a matter of choosing the right
default: do we want values most of the time and occasional
references, or vice versa? I think most of the time you need
references, a
On 19.02.2011 13:06, spir wrote:
Hello,
What do you think of this?
unittest {
assert(-1.1 + 2.2 == 1.1); // pass
assert(-1.1 + 2.2 + 3.3 == 4.4); // pass
assert(-1.1 + 3.3 + 2.2 == 4.4); // fail
assert(-1.1 + 3.3 == 2.2); // fail
}
There is approxEquals in stdlib, right; but shouldn't builtin
Following came to my mind while coding some generic collection
classes: The toHash and opCmp operations are not supported for
builtin-types though their implementation is trivial.
* toHash
The code is already there inside TypeInfo.getHash. But
typeid(value).getHash(&value) is much uglier than
On 21.02.2011 21:22, Daniel Gibson wrote:
Am 21.02.2011 20:59, schrieb Simon Buerger:
Following came to my mind while coding some generic collection classes:
The toHash and opCmp operations are not supported for builtin-types
though their implementation is trivial.
* toHash
The code is already
sadly no: (-30) - (30) = -170532704 which is
incorrect. It does however work for short/byte (and opCmp still
returning int).
oops, wrong example. It is: (-20) - (20) = 294967296,
sry. Anyway, you see the point with overflows
On 24.02.2011 19:08, Ali Çehreli wrote:
Implicit conversions to immutable in the following two functions feel
harmless. Has this been discussed before?
string foo()
{
char[] s;
return s; // Error: cannot implicitly convert expression
// (s) of type char[] to string
}
string bar()
{
char[] s;
re
It is often said that D's grammar is easier to parse than C++, i.e. it
should be possible to seperate syntactic and semantic analysis, which
is not possible in C++ with the template-"< >" and so on. But I found
following example:
The Line "a * b = c;" can be interpreted in two ways:
-> Declara
On 18.03.2011 17:34, lenochware wrote:
Hello, I have array of type vertex_t vertices[] where vertex_t is:
struct vertex_t {
float[3] xyz;
ubyte[4] color;
...
}
Now, I would like use instead of array "float[3] xyz" "vec3f xyz", where vec3f
is:
struct vec3f {
float x, y, z;
...some
19 matches
Mail list logo
