On Sunday, 29 July 2012 at 06:27:32 UTC, Dmitry Olshansky wrote:
OK. Now back to the biggest question:
Slices use references (sometimes) to previous bitarray. Since
it's a slice (like an array) this could be expected.
The "sometimes" part is not god enough! The problem is that
small string op
On Sunday, 29 July 2012 at 06:27:32 UTC, Dmitry Olshansky wrote:
Thus BitArray either becomes value type (that may come as
unexpected, see your option c/d). Or it becomes full reference
type as in option a (though it sucks). Sorry but b is no go, as
it makes code unpredictable I'd rather take m
On 29-Jul-12 12:55, Era Scarecrow wrote:
On Sunday, 29 July 2012 at 06:27:32 UTC, Dmitry Olshansky wrote:
Thus BitArray either becomes value type (that may come as unexpected,
see your option c/d). Or it becomes full reference type as in option a
(though it sucks). Sorry but b is no go, as it ma
On Sunday, 29 July 2012 at 09:03:08 UTC, Dmitry Olshansky wrote:
On 29-Jul-12 12:55, Era Scarecrow wrote:
Doing it this way the arguments being passed as reference
slices would ensure unneeded copies wouldn't be made. On the
other hand a smaller portion of the code would need to be
updated. Al
On 29-Jul-12 13:18, Era Scarecrow wrote:
On Sunday, 29 July 2012 at 09:03:08 UTC, Dmitry Olshansky wrote:
On 29-Jul-12 12:55, Era Scarecrow wrote:
Doing it this way the arguments being passed as reference slices
would ensure unneeded copies wouldn't be made. On the other hand a
smaller portion
On Sunday, 29 July 2012 at 09:30:06 UTC, Dmitry Olshansky wrote:
I have simpler suggestion. Maybe doing it as 2 containers:
BitSet is a plain value type with small array optimization
(what you called BitArray in last 2 posts) and no slicing (only
as opSlice() I.e. as a whole). Best used for s
On 29-Jul-12 14:28, Era Scarecrow wrote:
On Sunday, 29 July 2012 at 09:30:06 UTC, Dmitry Olshansky wrote:
I have simpler suggestion. Maybe doing it as 2 containers:
BitSet is a plain value type with small array optimization (what you
called BitArray in last 2 posts) and no slicing (only as opS
On Sunday, 29 July 2012 at 10:34:50 UTC, Dmitry Olshansky wrote:
Might be a third option: A template struct that represents a
BitArray type (with 90% of the code); you then insert a
structure with key functions that would handle the
value/reference & duplication part.
Sounds a lot like mixi
On Sat, 28 Jul 2012 22:47:01 +0200, Chad J
wrote:
isInputRange!___ r2 = [1,2,3].some.complex.expression();
It doesn't make sense. isInputRange!() isn't a type, so how do I
constrain what type is returned from some arbitrary expression?
So far the only way I know how to do this is to pa
On Sunday, 29 July 2012 at 09:30:06 UTC, Dmitry Olshansky wrote:
I have simpler suggestion. Maybe doing it as 2 containers:
BitSet is a plain value type with small array optimization
(what you called BitArray in last 2 posts) and no slicing (only
as opSlice() I.e. as a whole). Best used for sm
I think having the delete keyword for classes was a very good
thing, altough I don't know the problems it has for the GC and
probably other things.
Consider this scenario:
class Base
{
// ...
}
class Derived : Base
{
// ...
FILE *f;
this()
On 07/29/2012 03:03 PM, Minas Mina wrote:
Having a destructor and that you know when is going to be called is VERY
useful!
So by removing the "delete" keyword, what happens? We won't have a way
to destroy objects in a predictable way anymore? (I'm not talking about
structs in any way).
Thanks
On Sun, 29 Jul 2012 15:03:09 +0200, Minas Mina
wrote:
Having a destructor and that you know when is going to be called is VERY
useful!
So by removing the "delete" keyword, what happens? We won't have a way
to destroy objects in a predictable way anymore? (I'm not talking about
structs in
Thanks for the answers.
So clear() or destroy() in 2.060 be used to call the destructor,
but the actual memory of the object won't be freed, right?
Is this is true, why wasn't "delete" changed to behave like
destroy()?
On 07/28/2012 06:17 PM, Zhenya wrote:
Why do not D allow templates with more than one tuple
parameters,at the same time that C++11 support it:
This is a gratuitous restriction. They will be supported at some point.
Minas Mina:
Is this is true, why wasn't "delete" changed to behave like
destroy()?
Maybe to not silently break D code that uses delete, and allow
easier future changes in the library/runtime code that implements
destroy().
Bye,
bearophile
On 07/28/2012 06:47 PM, Simen Kjaeraas wrote:
On Sat, 28 Jul 2012 18:17:14 +0200, Zhenya wrote:
Why do not D allow templates with more than one tuple
parameters,at the
same time that C++11 support it:
Well, Walter implemented type tuples with automatic flattening,
The lack of multiple tupl
Era Scarecrow:
As you guess I have had to use many arrays of bits in my programs
:-)
4124 - Set/reset all bits ie:
BitArray ba = BitArray(100);
ba[] = true;
Others haven't been done yet.
Among those 4124 suggestions the most important, and very simple
to implement, are:
- set n-th bit
On 07/27/2012 04:35 PM, bearophile wrote:
But implementing good non-null types in library code is hard
It is closer to impossible than to hard.
(rather harder than implementing vector ops in library code on library defined
vectors). I think @disable isn't enough to cover what Spec# shows goo
On 07/28/2012 01:47 PM, Chad J wrote:
> What I want to do is constrain that the type of r3 is some kind of
> range. I don't care what kind of range, it could be a range of integers,
> a range of floats, an input range, a forward range, and so on. I don't
> care which, but it has to be a range.
I
Timon Gehr:
Non-null types in Spec# are unsound.
Really? I didn't know it. Surely its non-null design looks quite
refined and thought-out. But maybe as say it's not enough still.
Do you have a link where it shows it's unsound?
Thank you,
bye,
bearophile
I just hit another downside with custom version(): two libraries
might use the same name to mean different things.
The version has no namespacing, so that's another reason for not
using it for custom things. The config modules might be the best
idea
for libraries too. I wonder if we could do a d
On Sun, 29 Jul 2012 16:13:03 +0200, Timon Gehr wrote:
On 07/28/2012 06:47 PM, Simen Kjaeraas wrote:
On Sat, 28 Jul 2012 18:17:14 +0200, Zhenya wrote:
Why do not D allow templates with more than one tuple
parameters,at the
same time that C++11 support it:
Well, Walter implemented type tupl
On 07/29/2012 08:32 AM, Simen Kjaeraas wrote:
On Sat, 28 Jul 2012 22:47:01 +0200, Chad J
wrote:
isInputRange!___ r2 = [1,2,3].some.complex.expression();
It doesn't make sense. isInputRange!() isn't a type, so how do I
constrain what type is returned from some arbitrary expression?
So far th
On 07/29/2012 11:54 AM, Ali Çehreli wrote:
On 07/28/2012 01:47 PM, Chad J wrote:
> What I want to do is constrain that the type of r3 is some kind of
> range. I don't care what kind of range, it could be a range of integers,
> a range of floats, an input range, a forward range, and so on. I d
I have the following code.
Heavily cutdown.
How would I do the same thing in D?
//
class NInfo
{
public:
Stack info;
}
int cols = 5;
int rows = 10;
ninfo = new NInfo*[cols+2];
int r;
for (r=0; r
rookie:
I have the following code.
Heavily cutdown.
How would I do the same thing in D?
Do you want something like this?
struct NInfo {
public int[] info;
}
void main() {
int cols = 3;
int rows = 5;
auto nInfo = new NInfo[][](rows + 2, cols + 2);
foreach (r, row; nInf
struct NInfo {
public int[] info;
}
In the D Phobos there is no efficient stack yet, so I've used a
dynamic array. If you need to append many items use an appender
or use some truly segmented stack data structure.
Also if NInfo must really be a class, things become a little more
complex
Hi Bearophile,
What you gave is perfect.
Thanks,
Rookie
On Sunday, 29 July 2012 at 18:06:29 UTC, bearophile wrote:
struct NInfo {
public int[] info;
}
In the D Phobos there is no efficient stack yet, so I've used a
dynamic array. If you need to append many items use an appender
or use s
On Sun, 29 Jul 2012 19:11:17 +0200, Chad J
wrote:
So there. Now, you simply use auto a = constrain!isInputRange(
expression );. Is this what you wanted?
That's pretty good. It's still not as concise or easy to discover as
the language's natural syntax for type declarations, but it's the
On 2012-07-29 18:42, Adam D. Ruppe wrote:
I just hit another downside with custom version(): two libraries
might use the same name to mean different things.
The version has no namespacing, so that's another reason for not
using it for custom things. The config modules might be the best idea
for
On 07/29/2012 10:22 AM, Chad J wrote:
> On 07/29/2012 11:54 AM, Ali Çehreli wrote:
>> ForwardRange!int r1 = inputRangeObject(map!"2 * a"(a1));
>> ForwardRange!int r2 = inputRangeObject(map!"a ^^ 2"(a1));
> IIRC, these are classes that come with all the typical runtime overhead,
> right?
Yes, in
On Sunday, 29 July 2012 at 14:41:48 UTC, bearophile wrote:
As you guess I have had to use many arrays of bits in my
programs :-)
I'll do what I can :)
4124 - Set/reset all bits ie:
BitArray ba = BitArray(100);
ba[] = true;
Others haven't been done yet.
Among those 4124 suggestions the mo
On 07/29/2012 06:24 PM, bearophile wrote:
Timon Gehr:
Non-null types in Spec# are unsound.
Really? I didn't know it. Surely its non-null design looks quite refined
and thought-out. But maybe as say it's not enough still. Do you have a
link where it shows it's unsound?
Google for "freedom b
std.file seems to have a getAttributes function, but I see no
corresponding setAttributes function. What do I do if I want to copy
the attributes from one file to another?
On Sunday, July 29, 2012 16:47:50 Chad J wrote:
> std.file seems to have a getAttributes function, but I see no
> corresponding setAttributes function. What do I do if I want to copy
> the attributes from one file to another?
std.file does not provide that functionality. You'll need to use whatev
On 07/29/2012 04:55 PM, Jonathan M Davis wrote:
On Sunday, July 29, 2012 16:47:50 Chad J wrote:
std.file seems to have a getAttributes function, but I see no
corresponding setAttributes function. What do I do if I want to copy
the attributes from one file to another?
std.file does not provide
Era Scarecrow:
If it has to determine between compact and non-compact, then I
really don't see how any speed improvement can be made,
Maybe it's better to consider two use cases: dynamic length
allocated on the heap (or allocated with a given allocator, often
a stack-styled allocator), and
I have a use case where I would like to be able to pass both a
forward and backward iteration of an array to a function:
void foo(InputR, OutputR)(InputR i, OutputR j)
if (isInputRange!InputR && isOutputRange!(OutputR, InputR))
{
...
}
main()
{
//forward:
foo(a[1..n], b[1..n]);
//
On Sunday, 29 July 2012 at 23:26:09 UTC, Andrew wrote:
I have a use case where I would like to be able to pass both a
forward and backward iteration of an array to a function:
void foo(InputR, OutputR)(InputR i, OutputR j)
if (isInputRange!InputR && isOutputRange!(OutputR, InputR))
{
...
}
m
On 07/30/2012 01:26 AM, Andrew wrote:
I have a use case where I would like to be able to pass both a
forward and backward iteration of an array to a function:
void foo(InputR, OutputR)(InputR i, OutputR j)
if (isInputRange!InputR && isOutputRange!(OutputR, InputR))
{
...
}
main()
{
//forward:
f
On Sunday, 29 July 2012 at 23:42:09 UTC, Timon Gehr wrote:
On 07/30/2012 01:26 AM, Andrew wrote:
I have a use case where I would like to be able to pass both a
forward and backward iteration of an array to a function:
void foo(InputR, OutputR)(InputR i, OutputR j)
if (isInputRange!InputR && isO
void main()
{
string[] x = ["_100", "_10", "_20"];
sort(x);
writeln(x);
}
result:
["_10", "_100", "_20"]
I need to treat these as if they were integrals, although the
underscore complicates things here since it should be ignored. So the
result I want is:
["_10", "_20", "_100"]
How wo
On 7/30/12, Andrej Mitrovic wrote:
> How would you implement that? It could be a nice exercise! :)
Here's a super-inefficient way to do it:
auto y = to!(size_t[])(pipe!(map!(y => y[1 .. $]))(x).array);
sort(y);
auto z = map!(y => "_" ~ to!string(y))(y);
Heheh, memory waste galore.
Andrej Mitrovic:
void main()
{
string[] x = ["_100", "_10", "_20"];
sort(x);
writeln(x);
}
result:
["_10", "_100", "_20"]
I need to treat these as if they were integrals, although the
underscore complicates things here since it should be ignored.
So the
result I want is:
["_10",
On Monday, July 30, 2012 04:09:18 Andrej Mitrovic wrote:
> void main()
> {
> string[] x = ["_100", "_10", "_20"];
> sort(x);
> writeln(x);
> }
I have a solution, but I think that it uncovers a bug in sort:
import std.algorithm;
import std.stdio;
void main()
{
string[] x = ["_100"
Jonathan M Davis:
void main()
{
string[] x = ["_100", "_10", "_20"];
sort!"a.length < b.length ? true : a < b"(x);
writeln(x);
}
I get an AssertError about it failing to sort, but the result
is correct.
Take a look at my solution (another thread, it seems), why are
you comparing
On Monday, July 30, 2012 04:39:26 bearophile wrote:
> Jonathan M Davis:
> > void main()
> > {
> >
> > string[] x = ["_100", "_10", "_20"];
> > sort!"a.length < b.length ? true : a < b"(x);
> > writeln(x);
> >
> > }
> >
> > I get an AssertError about it failing to sort, but the result
Jonathan M Davis:
Otherwise, wouldn't _100 come before _20?
But he has said:
I need to treat these as if they were integrals, although the
underscore complicates things here since it should be ignored.
So the result I want is:
["_10", "_20", "_100"]
No mention of 100 coming before 20.
B
On 7/30/12, bearophile wrote:
> import std.stdio, std.algorithm, std.conv;
> void main() {
> auto data = ["_100", "_10", "_20"];
> schwartzSort!(s => to!int(s[1 .. $]))(data);
> writeln(data);
> }
Very nice! Thanks.
On Monday, July 30, 2012 04:48:02 bearophile wrote:
> Jonathan M Davis:
> > Otherwise, wouldn't _100 come before _20?
>
> But he has said:
> > I need to treat these as if they were integrals, although the
> > underscore complicates things here since it should be ignored.
> > So the result I want i
Jonathan M Davis:
And it avoids having to do any conversions like your solution
does.<
I understand now, thank you for explaining.
But in general I suggest to avoid using a solution like yours,
unlesss this sorting is recognized by profiling as important for
the performance of the program (a
On 7/30/12, Jonathan M Davis wrote:
> It _does_ assume that all numbers start with an underscore and don't have
> leading zeroes though.
That's good for me.
Nice solution too, very simple. Odd that it uncovered a bug. Oh well..
On 7/30/12, bearophile wrote:
> Because sorting numbers as
> strings is a very good source of bugs.
Thinking about this, pretty much any interpretation of strings is a
very good source of bugs. I've been thinking how e.g. path
manipulation might better be done with tokenization. For example if
yo
On Monday, July 30, 2012 05:15:51 Andrej Mitrovic wrote:
> But I haven't seen any libraries
> which use tokenization for paths.. maybe some exist out there..
Boost.
And I think that Java has a library that does (maybe its standard library - if
not is probably an Apache library). I don't recall f
55 matches
Mail list logo
