On Saturday, 20 July 2013 at 19:04:29 UTC, Jesse Phillips wrote:
On Saturday, 20 July 2013 at 18:53:44 UTC, JS wrote:
if they want to allow the same op in there class, which they
probably do, they have to override the long hand anyways and
redirect.
Nope, that is why you make the template fin
On Saturday, 20 July 2013 at 18:57:18 UTC, Jesse Phillips wrote:
On Saturday, 20 July 2013 at 18:27:23 UTC, JS wrote:
is there any way to pass t directly to A?
template A(T...) doesn't seem work nor does using an alias.
(or at least, when I try to foreach over it, it doesn't work).
template
On 2013-07-21 06:21, Carl wrote:
I am experimenting with user defined attributes, but am wondering if a
list of all objects with a specified UDA could be generated?
If not, is there a workaround for getting these objects without a direct
reference?
If you modify druntime you can do it. This te
On 2013-07-21 08:45, Namespace wrote:
But D isn't like Ada. It's more like C++ and there Heap allocations is
often used too.
It would be really cool if we had allocators already.
Something like:
with (AllocatorX) { /// will use malloc and free instead of calling the GC
float[] arr;
On Sunday, 21 July 2013 at 09:16:47 UTC, Jacob Carlborg wrote:
On 2013-07-21 08:45, Namespace wrote:
But D isn't like Ada. It's more like C++ and there Heap
allocations is
often used too.
It would be really cool if we had allocators already.
Something like:
with (AllocatorX) { /// will use
Namespace:
But D isn't like Ada.
But D should be a bit more like Ada, for such things :-)
Bye,
bearophile
On Sunday, 21 July 2013 at 10:30:16 UTC, bearophile wrote:
Namespace:
But D isn't like Ada.
But D should be a bit more like Ada, for such things :-)
Bye,
bearophile
I agree, but how? ;)
You know by yourself that Walter & Andrei are very hard to
convince by such things.
Namespace:
I agree, but how? ;)
You know by yourself that Walter & Andrei are very hard to
convince by such things.
I think there is only a small number of Ada ideas worth copying,
like:
- Integral overflows;
- Ranged integers;
- A library of collections allocated in-place in the standard
Now this D entry works again:
http://rosettacode.org/wiki/S-Expressions#D
Probably it can be written without explicit indexes, only using
txt.front, txt.popFrontN, txt.find, etc. Do you want to produce
such modified version?
This simple task shows well why a parser combinators like Parsec
i
21-Jul-2013 00:46, Namespace пишет:
On Saturday, 20 July 2013 at 20:22:56 UTC, Dmitry Olshansky wrote:
21-Jul-2013 00:19, Namespace пишет:
Let us assume we have a method of a class which is used often and the
method is called periodically and must allocate every time a array
between 100 and 400
21-Jul-2013 00:42, Ali Çehreli пишет:
On 07/20/2013 01:22 PM, Dmitry Olshansky wrote:
> 21-Jul-2013 00:19, Namespace пишет:
>> Let us assume we have a method of a class which is used often and the
>> method is called periodically and must allocate every time a array
>> between 100 and 4000 e
That's too bad, because in the real code this example was derived
from I can't have type inference call the right constructor as
there are two constructors with the same run-time argument types.
I'll put in a bug report.
On 07/20/2013 09:43 PM, Ali Çehreli wrote:
> When the parent thread terminates the child processes terminate as well.
I am wrong there: What I said above is true for the main program thread.
When the main program terminates, its threads are terminated as well.
Otherwise, a child can continue
Is it somehow possible to evaluate a string on template parameters ?
Something like this:
enum source = "TYPE var;";
template Eval(TYPE)
{
string Eval()
{
return evaluate(source); <-- replace TYPE with int
}
}
mixin(Eval!int); <-- int var here
Basically
On 07/21/2013 09:26 AM, Martin Krejcirik wrote:
Is it somehow possible to evaluate a string on template parameters ?
Something like this:
enum source = "TYPE var;";
template Eval(TYPE)
{
string Eval()
{
return evaluate(source); <-- replace TYPE with int
This seems to be a somewhat efficient string splitter
http://dpaste.dzfl.pl/4307aa5f
The basic idea is
for(int j = 0; j < s.length; j++)
{
mixin(ExpandVariadicIf!("??Cs[j]??s[j..min(s.length-1, j +
%%L)]::", "d", "
if (r.length <= i) r.length += 5;
On Sunday, July 21, 2013 16:25:15 Carl Sturtivant wrote:
> That's too bad, because in the real code this example was derived
> from I can't have type inference call the right constructor as
> there are two constructors with the same run-time argument types.
You could use a factory function instead
On 07/21/13 18:26, Martin Krejcirik wrote:
> Is it somehow possible to evaluate a string on template parameters ?
> Something like this:
>
> enum source = "TYPE var;";
>
> template Eval(TYPE)
> {
> string Eval()
> {
> return evaluate(source); <-- replace TYPE with int
>
My analogy goes as follows: a chunk of memory for temporary
needs => scratch pad (as in sheet of paper for quick
notes/sketches).
Something along the lines of:
class A{
static float[] buffer;
static this(){
buffer = new float[as_big_as_it_gets];
}
Namespace:
I have a float[1024] buffer which is used, as long as the
requested size is less than 1024. If it's greater, I will
temporary allocate the whole array with new float[Size];
That's one of the ways I solve similar problems.
Any improvements? Or is 1024 to small / big?
An idea is
On Sunday, 21 July 2013 at 21:31:08 UTC, bearophile wrote:
Namespace:
I have a float[1024] buffer which is used, as long as the
requested size is less than 1024. If it's greater, I will
temporary allocate the whole array with new float[Size];
That's one of the ways I solve similar problems.
22-Jul-2013 01:19, Namespace пишет:
I really like the idea.
I've changed it a bit:
I have a float[1024] buffer which is used, as long as the requested size
is less than 1024. If it's greater, I will temporary allocate the whole
array with new float[Size];
Any improvements? Or is 1024 to small /
On 21.7.2013 19:15, Ali Çehreli wrote:
> string Eval()
> {
> string statement = source;
> auto found = statement.findSkip("TYPE");
> assert(found);
>
> return TYPE.stringof ~ statement;
> }
Thanks, actually findSplit is what I need, but works like a cha
Say I have a template function where there are variations, it
would be nice to be able to specify those variables like
strip!Left(s), strip!Right(s), strip(s), etc...
instead of ahving to do stripLeft, stripRight, and strip.
But the goal isn't just to add an extra ! to type but that it
reduce
BTW, I'm not saying D can't do anything like this
enum Dir { Left, Right, Both }
string strip(Dir dir = Dir.Both)(string s)
but one has to call it like
strip!(Dir.Left)(s); (or if using strings, strip!"Left"(s))
Possibly, to make it easier the compiler and localize the enum if
one is used:
JS:
Say I have a template function where there are variations, it
would be nice to be able to specify those variables like
strip!Left(s), strip!Right(s), strip(s), etc...
instead of ahving to do stripLeft, stripRight, and strip.
But the goal isn't just to add an extra ! to type but that it
Doing simple stuff like
for(int i = 0; i < s.length - 1; i++) fails catastrophically if s
is empty. To make right one has to reduce performance by writing
extra checks.
There seems to be no real good reason why size_t is unsigned...
Surely one doesn't require too many strings larger than 2^6
On 07/21/2013 08:47 PM, JS wrote:
> Doing simple stuff like
>
> for(int i = 0; i < s.length - 1; i++) fails catastrophically if s is
> empty. To make right one has to reduce performance by writing extra
checks.
Checks are needed for program correctness. If not in source code, in
compiler gene
On Mon, Jul 22, 2013 at 05:47:34AM +0200, JS wrote:
> Doing simple stuff like
>
> for(int i = 0; i < s.length - 1; i++) fails catastrophically if s is
> empty. To make right one has to reduce performance by writing extra
> checks.
I'm not sure if it's your intention, but your code above has an of
On Monday, 22 July 2013 at 03:58:31 UTC, Ali Çehreli wrote:
On 07/21/2013 08:47 PM, JS wrote:
> Doing simple stuff like
>
> for(int i = 0; i < s.length - 1; i++) fails catastrophically
if s is
> empty. To make right one has to reduce performance by writing
extra checks.
Checks are needed for pr
On Monday, 22 July 2013 at 04:31:12 UTC, H. S. Teoh wrote:
On Mon, Jul 22, 2013 at 05:47:34AM +0200, JS wrote:
Doing simple stuff like
for(int i = 0; i < s.length - 1; i++) fails catastrophically
if s is
empty. To make right one has to reduce performance by writing
extra
checks.
I'm not su
On 07/21/2013 09:36 PM, JS wrote:
> On Monday, 22 July 2013 at 03:58:31 UTC, Ali Çehreli wrote:
>> > There seems to be no real good reason why size_t is
>> unsigned...
>>
>> How about, every addressable memory locations must be countable?
>
> for strings themselves, I would prefer an int to be r
On Mon, Jul 22, 2013 at 06:43:47AM +0200, JS wrote:
> On Monday, 22 July 2013 at 04:31:12 UTC, H. S. Teoh wrote:
> >On Mon, Jul 22, 2013 at 05:47:34AM +0200, JS wrote:
[...]
> >>There seems to be no real good reason why size_t is unsigned...
> >[...]
> >
> >The reason is because it must span the ra
33 matches
Mail list logo
