On 09/08/2014 07:00 PM, Marco Leise wrote:
Am Mon, 8 Sep 2014 18:34:10 +0300
schrieb ketmar via Digitalmars-d digitalmars-d@puremagic.com:
On Mon, 08 Sep 2014 17:25:07 +0200
Timon Gehr via Digitalmars-d digitalmars-d@puremagic.com wrote:
int square(int x)=x*x;
noted.
To clarify
On 09/08/2014 07:02 PM, Andrei Alexandrescu wrote:
However std.algorithm also includes stuff that's arguably numeric, e.g.
min and max etc.
How are min and max numeric?
On 09/08/2014 04:58 PM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
ola.fosheim.grostad+dl...@gmail.com wrote:
comics are not on topic,
The topic of a comic is arbitrary.
On 09/10/2014 07:01 AM, Kagamin wrote:
It's questionable that testing every template instantiation is intended:
you can't do the same for templated functions.
Yes you can.
On 09/10/2014 03:22 PM, Daniel Murphy wrote:
Jacob Carlborg wrote in message news:lupda8$nl1$1...@digitalmars.com...
Could we modify the compiler to allow that? Just for the special
identifiers __LINE__, __FILE__ and similar. It wouldn't be possible to
specify a value for that parameter then.
On 09/09/2014 07:05 PM, Wyatt wrote:
APL actually has really neat semantics (seriously, every programmer
would do well to at least learn _how APL works_) ...
One can do this quite efficiently e.g. here: http://tryapl.org/
On 09/10/2014 08:18 PM, Sönke Ludwig wrote:
Am 10.09.2014 17:41, schrieb Timon Gehr:
On 09/10/2014 03:22 PM, Daniel Murphy wrote:
Jacob Carlborg wrote in message news:lupda8$nl1$1...@digitalmars.com...
Could we modify the compiler to allow that? Just for the special
identifiers __LINE__,
On 09/10/2014 06:54 PM, Dicebot wrote:
On Wednesday, 10 September 2014 at 16:34:06 UTC, Andrei Alexandrescu wrote:
One possibility is to have the first function be a one-liner that
forwards to another. That way there will be less code bloating.
void fun(uint l = __LINE__, A...)(A... as) {
On 09/11/2014 01:46 PM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
ola.fosheim.grostad+dl...@gmail.com wrote:
The D community is as
diverse as the language and even if three people yell in the
same tone, it doesn't mean everyone else believes the same.
I know that, but newbies don't know that.
On 09/11/2014 06:45 PM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
ola.fosheim.grostad+dl...@gmail.com wrote:
On Thursday, 11 September 2014 at 14:14:38 UTC, Timon Gehr wrote:
...
Which unsound general statement? ...
I was quoting relevant passages.
...
If the community
'the community'?
is
On 09/13/2014 03:36 AM, Manu via Digitalmars-d wrote:
Surely, at very least, an extern(C++) class should be final-by-default?
How do you declare virtual extern(C++) class methods then?
On 09/13/2014 06:44 PM, Kagamin wrote:
Is there a reason, why you would need inout there?
s.bar((int* p){ ++*p; });
On 09/13/2014 07:54 PM, Kagamin wrote:
From https://issues.dlang.org/show_bug.cgi?id=10850:
Since apparently inout now refers to the outermost inout function
This sounds questionable. Anybody knows, what happened?
It's one of Kenji Hara's occasional stealth language
changes/refinements.
On 09/13/2014 07:48 PM, Kagamin wrote:
On Saturday, 13 September 2014 at 16:51:09 UTC, Timon Gehr wrote:
s.bar((int* p){ ++*p; });
Huh? inout is for functions, which don't modify their arguments.
With Jakob's code working, this would not be warranted. (But the
situation needs to change in
On 09/13/2014 09:07 PM, Marc =?UTF-8?B?U2Now7x0eiI=?=
schue...@gmx.net wrote:
Wouldn't `const` be enough? AFAICS, `immutable` is mostly useful for
shared data.
const prevents modification, but does not guarantee that no modification
takes place elsewhere. I.e. it enables fewer program
On 09/13/2014 09:58 PM, Kagamin wrote:
On Saturday, 13 September 2014 at 18:36:53 UTC, Timon Gehr wrote:
On 09/13/2014 07:48 PM, Kagamin wrote:
On Saturday, 13 September 2014 at 16:51:09 UTC, Timon Gehr wrote:
s.bar((int* p){ ++*p; });
Huh? inout is for functions, which don't modify their
On 09/14/2014 01:21 AM, Peter Alexander wrote:
On Saturday, 13 September 2014 at 22:25:57 UTC, Walter Bright wrote:
Yeah, well, we have many years of experience with static if and no
apocalypse has yet happened.
Well, we are yet to define static if when it comes to tricky cases,
i.e. cases
On 09/13/2014 10:10 PM, eles wrote:
...
But the surprise comes at the end (slide 57), where he also
criticizes... the static if ...
Are those points valid?:
...
• Unstructured, can do everything (just like goto)
• Complicates static analysis (AST-based tools get hard to write)
• Blocks the path
On 09/14/2014 10:47 AM, Kagamin wrote:
On Saturday, 13 September 2014 at 23:41:55 UTC, Timon Gehr wrote:
All the examples there keep their non-modification guarantees.
Modifications to inout parameters are visible at the call site.
Modifications are visible if you know the inout argument will
On 09/14/2014 10:50 AM, Kagamin wrote:
On Sunday, 14 September 2014 at 01:38:33 UTC, Jakob Ovrum wrote:
This is necessary for `inout` to work with callback functions, such as
with internal iteration (i.e. `opApply`).
Can you write a pass and xfail test for it? This scenario looks
non-trivial.
On 09/15/2014 12:38 AM, Walter Bright wrote:
On 9/14/2014 2:48 PM, deadalnix wrote:
If that is really a concern, please consider commenting on
http://wiki.dlang.org/DIP31
I haven't thought it through, but the DIP looks like a good idea.
It should add the test case in this thread,
static
On 09/14/2014 07:42 PM, Andrei Alexandrescu wrote:
On 9/14/14, 6:17 AM, Marc Schütz schue...@gmx.net wrote:
What if the operation failed without producing an exception? I.e., if we
wrap an API that signals errors by returning false for example, do we
really need to create an exception just to
On 09/15/2014 04:53 AM, Timon Gehr wrote:
On 09/15/2014 12:38 AM, Walter Bright wrote:
On 9/14/2014 2:48 PM, deadalnix wrote:
If that is really a concern, please consider commenting on
http://wiki.dlang.org/DIP31
I haven't thought it through, but the DIP looks like a good idea.
It should
On 09/17/2014 03:43 AM, Orvid King wrote:
Why all this talk?
I've created pull request for dmd, which allows UDA for modules
(https://github.com/D-Programming-Language/dmd/pull/3947) and Walter
says that I should open topic in n.g. and justify the usefulness of this
enhancement.
As far as I
On 09/19/2014 12:06 AM, Brian Schott wrote:
On Thursday, 18 September 2014 at 21:31:26 UTC, Peter Alexander wrote:
Maybe in this case
And in every case. DMD's behavior is correct because it consistent with
DMD.
???
On 09/19/2014 04:59 PM, Andrei Alexandrescu wrote:
On 9/18/14, 10:53 PM, bearophile wrote:
Andrei Alexandrescu:
Wyatt:
(I wouldn't consider the cookie parameter a better solution; I would
consider it a wart.)
That's the right solution.
The cookie parameter is a ugly wart.
No. -- Andrei
On 09/20/2014 02:29 AM, Andrei Alexandrescu wrote:
On 9/19/14, 5:28 PM, Timon Gehr wrote:
On 09/19/2014 04:59 PM, Andrei Alexandrescu wrote:
On 9/18/14, 10:53 PM, bearophile wrote:
Andrei Alexandrescu:
Wyatt:
(I wouldn't consider the cookie parameter a better solution; I would
consider it
On 09/20/2014 06:52 AM, Andrei Alexandrescu wrote:
On 9/19/14, 8:14 PM, Timon Gehr wrote:
To substantiate: It does the wrong thing (same typedef for same base
type) by default and doing the right thing (emulating nominal typing)
may require quite some effort in general (e.g. concatenate
On 09/21/2014 09:05 AM, Daniel Murphy wrote:
Tofu Ninja wrote in message news:nwjquvwnetifhydfa...@forum.dlang.org...
On Saturday, 20 September 2014 at 23:07:16 UTC, Adam D. Ruppe wrote:
string results[](T) = I have no idea what I'm doing;
I agree that's just weird though, someone pointed
On 09/21/2014 07:29 AM, deadalnix wrote:
Free goodie: when you import, all symbol are resolved via the expected
import resolution mechanism. All ? No, the root package is imported in
the local scope.
foo(int a) {
import a.b.c;
// a is now a package and not the parameter a anymore.
}
On 09/21/2014 11:53 AM, Rainer Schuetze wrote:
It also references the issue why this has been changed pretty recently:
https://issues.dlang.org/show_bug.cgi?id=11257
I'm on the fence whether this is convenient or makes it too easy to
break const guarantees. It seems strange that you can modify
On 09/21/2014 03:53 PM, H. S. Teoh via Digitalmars-d wrote:
I.e., this should work:
string foo(string text) {
import std.conv; // includes std.conv.text
return ;// but `text` is never referenced
}
but this should emit an error:
On 09/21/2014 09:54 PM, Walter Bright wrote:
On 9/21/2014 5:55 AM, Timon Gehr wrote:
For local imports, DMD imports _all_ symbols into the local scope,
shadowing
anything that was there, which is plain broken (as Sӧnke's example
shows). BTW:
how do you suggest to treat the root package? I think
On 09/21/2014 10:08 PM, Walter Bright wrote:
On 9/21/2014 12:58 PM, Timon Gehr wrote:
On 09/21/2014 09:54 PM, Walter Bright wrote:
On 9/21/2014 5:55 AM, Timon Gehr wrote:
For local imports, DMD imports _all_ symbols into the local scope,
shadowing
anything that was there, which is plain
On 09/22/2014 12:17 AM, Andrei Alexandrescu wrote:
vivid anecdote fallacy
FWIW:
https://www.google.ch/?gws_rd=crei=XVYfVIu7IcL1OYi7gMgH#q=%22vivid+anecdote+fallacy%22
On 09/21/2014 12:08 AM, Andrei Alexandrescu wrote:
My perception of this thread is that there's an abundance of that misleading
vividness
fallacy (http://en.wikipedia.org/wiki/Misleading_vividness). Rhetoric
techniques blow
the most trivial matters out of proportion and build to the foaming
On 09/22/2014 01:37 AM, deadalnix wrote:
On Sunday, 21 September 2014 at 20:05:57 UTC, Walter Bright wrote:
On 9/20/2014 10:29 PM, deadalnix wrote:
DMD does very bizarre things. I think I should write a DIP, but time
is always
running low...
Free goodie: when you import, all symbol are
On 09/22/2014 03:26 PM, Daniel Murphy wrote:
Timon Gehr wrote in message news:lvmh5b$eo9$1...@digitalmars.com...
When was int x(T)=2; introduced?
At the same time as enum x(T) = 2; I think.
...
Is this documented?
Also, C-style array syntax would actually be string results(T)[] = ;.
On 09/22/2014 10:27 PM, deadalnix wrote:
On Monday, 22 September 2014 at 09:17:16 UTC, Walter Bright wrote:
It is depth first. It starts at the innermost scope, which is the
current scope. Somehow, we don't seem to be talking the same language :-(
Depth first in the sense, go from the inner
On 09/23/2014 10:19 PM, monarch_dodra wrote:
As I said, local imports, IMO, should behave in all aspects as a global
import. It simply only exists during its scope, but is not actually any
more internal than the rest. If a local import creates a symbol
ambiguity, then it's ambiguous, and
On 09/23/2014 09:01 PM, Peter Alexander wrote:
On Tuesday, 23 September 2014 at 18:52:13 UTC, H. S. Teoh via
Digitalmars-d wrote:
1) Change lookup rules so that symbols pulled in by local import are
found last. Walter has stated that he disagrees with this approach
because it complicates symbol
On 09/23/2014 06:01 PM, Andrei Alexandrescu wrote:
alias HMENU = Typedef!(void*, __MODULE__ ~ .HMENU);
alias HFONT = Typedef!(void*, __MODULE__ ~ .HMENU); // oops
mixin(makeTypedef!(HMENU, void*));
mixin(makeTypedef!(HFONT, void*));
I said and I repeat: I do agree it's less convenient than a
On 09/25/2014 12:03 AM, Andrei Alexandrescu wrote:
On 9/24/14, 2:43 PM, Joakim wrote:
On Wednesday, 24 September 2014 at 19:38:37 UTC, bearophile wrote:
Joakim:
I wonder why they found Haskell to be so slow, I thought it was
compiled.
The first reason for the performance of programs is how
On 09/25/2014 06:53 AM, deadalnix wrote:
http://wiki.dlang.org/DIP31
I've been asked to add examples of resolution for various cases (hint
they all error out).
This DIP define their behavior properly,
Not really. For one thing, at the moment, the DIP doesn't really make
clear when and how
On 09/28/2014 02:40 AM, Walter Bright wrote:
On 9/27/2014 4:55 PM, H. S. Teoh via Digitalmars-d wrote:
My take on this, is that uncaught exceptions are a program bug.
Not to me. ...
It is not worth fixing if a program terminates with a stack trace?
On 09/28/2014 01:55 AM, Walter Bright wrote:
On 9/27/2014 4:20 PM, bearophile wrote:
Walter Bright:
It could be nice to have a syntax like lambdas for small
struct/class methods:
https://issues.dlang.org/show_bug.cgi?id=7176
struct Foo {
int bar(int x) pure { return x * x; }
}
Becomes
On 09/29/2014 06:06 AM, Timon Gehr wrote:
On 09/29/2014 02:47 AM, Walter Bright wrote:
On 9/28/2014 4:18 PM, Joseph Rushton Wakeling via Digitalmars-d wrote:
I don't follow this point. How can this approach work with programs
that are
built with the -release switch?
All -release does is not
On 09/29/2014 02:47 AM, Walter Bright wrote:
On 9/28/2014 4:18 PM, Joseph Rushton Wakeling via Digitalmars-d wrote:
I don't follow this point. How can this approach work with programs
that are
built with the -release switch?
All -release does is not generate code for assert()s. ...
On 09/29/2014 12:59 AM, Walter Bright wrote:
...
Unless, of course, you're suggesting that we put this around every
main() function:
void main() {
try {
...
} catch(Exception e) {
assert(0, Unhandled exception: I screwed up);
}
}
I'm
On 09/29/2014 04:43 AM, Walter Bright wrote:
You're right that tuples in D cannot contain storage classes
void foo(ref int x){}
alias p=ParameterTypeTuple!foo;
pragma(msg, p); // (ref int)
(But this does not help.)
On 10/03/2014 09:08 PM, Ali Çehreli wrote:
I know that assert is not a function but it would be nice to have.
import std.exception;
void foo(T...)(T args)
{
// Compiles:
enforce(args);
// DOES NOT COMPILE:
// assert(args);
// Must expand manually:
On 10/04/2014 10:37 PM, Ola Fosheim Grostad wrote:
On Saturday, 4 October 2014 at 19:49:23 UTC, Walter Bright wrote:
On 10/4/2014 7:13 AM, H. S. Teoh via Digitalmars-d wrote:
Beware -- I've only proven that the code is correct, not tested it. --
Donald Knuth.
:-)
Quotes like that prove (!)
On 10/05/2014 08:01 AM, ketmar via Digitalmars-d wrote:
On Sat, 04 Oct 2014 14:48:26 -0700
Andrei Alexandrescu via Digitalmars-d digitalmars-d@puremagic.com
wrote:
There's no interesting way to check this because functions don't list
the exceptions they might throw (like Java does). -- Andrei
On 10/06/2014 01:01 AM, Walter Bright wrote:
On 10/5/2014 2:51 PM, Dicebot wrote:
On Sunday, 5 October 2014 at 20:41:44 UTC, Walter Bright wrote:
On 10/5/2014 8:35 AM, Dicebot wrote:
I am fine with non-default being hard but I
want it to be still possible within legal language restricions.
On 10/07/2014 03:57 PM, ketmar via Digitalmars-d wrote:
On Tue, 07 Oct 2014 14:59:52 +0200
Timon Gehr via Digitalmars-d digitalmars-d@puremagic.com wrote:
What's the point anyway?
non-final try/catch will not make function nothrow.
void doStuff(){ }
void main() nothrow{
try{ doStuff
On 10/07/2014 04:23 PM, ketmar via Digitalmars-d wrote:
On Tue, 07 Oct 2014 16:08:33 +0200
Timon Gehr via Digitalmars-d digitalmars-d@puremagic.com wrote:
What's the point anyway?
non-final try/catch will not make function nothrow.
import core.exception;
void doStuff(){ }
void main
On 10/07/2014 09:26 PM, Walter Bright wrote:
On 10/7/2014 6:56 AM, Timon Gehr wrote:
On 10/06/2014 01:01 AM, Walter Bright wrote:
Relying on program state after entering an unknown state is undefined by
definition.
What definition?
How can one define the behavior of an unknown state?
On 10/07/2014 10:09 PM, Walter Bright wrote:
On 10/7/2014 12:44 PM, Timon Gehr wrote:
On 10/07/2014 09:26 PM, Walter Bright wrote:
On 10/7/2014 6:56 AM, Timon Gehr wrote:
On 10/06/2014 01:01 AM, Walter Bright wrote:
Relying on program state after entering an unknown state is
undefined by
On 10/08/2014 12:10 AM, Nick Sabalausky wrote:
On 10/07/2014 06:47 AM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
ola.fosheim.grostad+dl...@gmail.com wrote:
On Tuesday, 7 October 2014 at 08:19:15 UTC, Nick Sabalausky wrote:
But regardless: Yes, there *is* a theoretical side to logic, but logic
is
On 10/08/2014 02:27 AM, Walter Bright wrote:
On 10/7/2014 2:12 PM, Timon Gehr wrote:
On 10/07/2014 10:09 PM, Walter Bright wrote:
What defined behavior would you suggest would be possible after an
overflow bug is detected?
At the language level, there are many possibilities. Just look at
On 10/08/2014 02:37 AM, H. S. Teoh via Digitalmars-d wrote:
On 10/08/2014 12:10 AM, Nick Sabalausky wrote:
[...]
I've managed to grok it, but yet even I (try as I may) just cannot
truly grok the monty hall problem. I *can* reliably come up with the
correct answer, but *never* through an actual
On 10/08/2014 05:19 AM, Walter Bright wrote:
On 10/7/2014 6:18 PM, Timon Gehr wrote:
I can report these if present.
Writing a strongly worded letter to the White Star Line isn't going to
help you when the ship is sinking in the middle of the North Atlantic.
...
Maybe it is going to help the
On 10/08/2014 10:25 PM, ketmar via Digitalmars-d wrote:
On Wed, 8 Oct 2014 23:20:13 +0300
ketmar via Digitalmars-d digitalmars-d@puremagic.com wrote:
p.s. or vice versa: static if (__ctfe) is always true, to non-ctfe
code will be removed. sorry, i can't really remember what is true, but
anyway,
On 10/10/2014 11:25 PM, Walter Bright wrote:
Essentially, the rules for multiple alias this should be the same as for
multiple imports and multiple mixin templates. These rules work, and the
consistency will be expected.
Agreed. Do you suggest to overload alias this against imports and mixin
On 10/10/2014 07:09 PM, IgorStepanov wrote:
I've created DIP for my pull request.
DIP: http://wiki.dlang.org/DIP66
PR: https://github.com/D-Programming-Language/dmd/pull/3998
Please, comment it.
- C c;
int i = c; //Error: c.a.i vs c.b.i
static assert(is(C : int)); //Ok, because C is subtype
On 10/11/2014 12:07 AM, IgorStepanov wrote:
On Friday, 10 October 2014 at 21:25:17 UTC, Walter Bright wrote:
If 'a' and 'b' both contain overloads for function foo, then it should
behave like imports do (which is a bit complex).
Hmm. Now it works as I wrote it DIP pseudo-code:
The
On 10/11/2014 12:29 AM, Walter Bright wrote:
On 10/10/2014 3:06 PM, Timon Gehr wrote:
On 10/10/2014 11:25 PM, Walter Bright wrote:
Essentially, the rules for multiple alias this should be the same as for
multiple imports and multiple mixin templates. These rules work, and the
consistency will
On 10/11/2014 11:17 PM, Dicebot wrote:
On Saturday, 11 October 2014 at 17:27:22 UTC, monarch_dodra wrote:
On Saturday, 11 October 2014 at 12:45:40 UTC, Dicebot wrote:
On Saturday, 11 October 2014 at 07:36:21 UTC, monarch_dodra wrote:
Wait what? Are you saying there is a single case when this:
On 10/12/2014 06:28 AM, Walter Bright wrote:
On 10/11/2014 3:42 AM, Jacob Carlborg wrote:
On 2014-10-11 00:52, Walter Bright wrote:
I like the C++ rule that says that access control is not considered for
name lookup. I know it makes for some annoying results, but the
simplicity of the rule
On 10/12/2014 09:41 PM, Meta wrote:
On Sunday, 12 October 2014 at 19:36:35 UTC, bearophile wrote:
Meta:
On Sunday, 12 October 2014 at 16:21:50 UTC, bearophile wrote:
What happens if one of these conditions fails? Is an exception thrown?
If you are using refined types, and D is somewhat
On 10/13/2014 01:48 AM, Meta wrote:
On Sunday, 12 October 2014 at 20:58:58 UTC, Timon Gehr wrote:
Yes it is. Why wouldn't it be? Values needn't be completely determined
in order to be reasoned about.
They do if you want to check, for example, n 3. D doesn't currently
support the type of
On 10/18/2014 07:30 PM, Walter Bright wrote:
Also, the glue layer rewrites for loops into goto loops, as gotos
are more powerful and foundational :-)
Well, not really. It rewrites for loops into goto loops because
that's the only control flow construct implemented by the hardware.
On 10/20/2014 07:21 PM, Daniel Murphy wrote:
Timon Gehr wrote in message news:m23eqa$2qfq$1...@digitalmars.com...
On 10/18/2014 07:30 PM, Walter Bright wrote:
Also, the glue layer rewrites for loops into goto loops, as gotos
are more powerful and foundational :-)
Well, not really. It
On 10/18/2014 07:40 PM, Walter Bright wrote:
As I've said before, tripping an assert by definition means the program
has entered an unknown state. I don't believe it is possible for any
language to make guarantees beyond that point.
What about the guarantee that your compiler didn't
On 10/22/2014 11:31 AM, Shammah Chancellor wrote:
A couple of us working on SDC are trying to get ValueRange propigation
implemented. I was wonder if someone could offer some insight as to
how VRP works in DMD. If for example, trying to get the value range of
a global, what is the expected
On 10/22/2014 10:32 PM, Walter Bright wrote:
The specification is straightforward - a narrowing conversion can be
implicitly performed if it can be proved that it would not lose
information.
This is only straightforward to state because it is so ill-defined.
The main aspect in need of
On 05/06/2015 10:01 AM, Andrei Alexandrescu wrote:
Consider:
void fun()
{
int x;
class C
{
...
}
}
Objects of type C have access to x because they have an .outer
pseudo-member.
Problem is, emplace() and any other in-situ initialization techniques
fail (e.g.
On 05/10/2015 12:38 AM, Timon Gehr wrote:
142| return parent.reallocate(b, gs);
172| return parent.alignedReallocate(b, gs, a);
(Note that those code snippets also occur in their documentation.)
On 05/09/2015 06:09 PM, Andrei Alexandrescu wrote:
On 5/9/15 6:27 AM, Timon Gehr wrote:
On 05/07/2015 11:12 PM, Andrei Alexandrescu wrote:
Helps an allocator without good reallocation capabilities:
http://erdani.com/d/phobos-prerelease/std_experimental_allocator_quantizer.html
Destruction
On 05/10/2015 12:38 AM, Timon Gehr wrote:
monotone increasing and piecewise constant with one fixed point per piece.
(Note that monotone increasing is implied by piecewise constant with one
fixed point per piece, so it does not necessarily need to be documented
separately.)
On 05/10/2015 07:39 AM, H. S. Teoh via Digitalmars-d wrote:
I also just realized that on Posix the profiling code apparently relies
on the rdtsc instruction, which counts CPU cycles in a 64-bit counter --
given the high frequencies of modern CPUs, moderately long-running
CPU-intensive processes
On 05/10/2015 11:50 AM, Andrei Alexandrescu wrote:
In C, C++, and D people have allocated memory for a long time in the
following manner:
...
Long story short, arrays should sit on a different heap than objects.
...
Unless this has been fixed in the interim, I believe DMD lowers new
S(args)
On 05/10/2015 05:29 AM, Andrei Alexandrescu wrote:
On 5/9/15 3:38 PM, Timon Gehr wrote:
Thanks! Looks good, except:
106| if (!parent.expand(b, goodAllocSize(needed) - b.length))
Let's see, this is a tad tricky. needed is the needed size, i.e.
b.length + delta. We want to expand to a final
On 05/10/2015 05:32 AM, Andrei Alexandrescu wrote:
On 5/9/15 3:41 PM, Timon Gehr wrote:
On 05/10/2015 12:38 AM, Timon Gehr wrote:
142| return parent.reallocate(b, gs);
172| return parent.alignedReallocate(b, gs, a);
(Note that those code snippets also occur in their documentation.)
Can't
On 05/10/2015 05:38 AM, Andrei Alexandrescu wrote:
On 5/9/15 3:54 PM, Timon Gehr wrote:
On 05/10/2015 12:38 AM, Timon Gehr wrote:
monotone increasing and piecewise constant with one fixed point per
piece.
(Note that monotone increasing is implied by piecewise constant with one
fixed point
On 05/10/2015 01:48 PM, Timon Gehr wrote:
bool expand(ref void[] b, size_t delta);
Post: !result || b.length == old(b).length + delta Expands b by
delta bytes. If delta == 0, succeeds without changing b. If b is null,
the call evaluates b = allocate(delta) and returns b !is null.
On 05/11/2015 05:28 PM, Andrei Alexandrescu wrote:
On 5/10/15 5:08 AM, Timon Gehr wrote:
On 05/10/2015 01:48 PM, Timon Gehr wrote:
bool expand(ref void[] b, size_t delta);
Post: !result || b.length == old(b).length + delta Expands b by
delta bytes. If delta == 0, succeeds without
On 05/11/2015 08:06 PM, Timon Gehr wrote:
On 05/11/2015 05:28 PM, Andrei Alexandrescu wrote:
On 5/10/15 5:08 AM, Timon Gehr wrote:
On 05/10/2015 01:48 PM, Timon Gehr wrote:
bool expand(ref void[] b, size_t delta);
Post: !result || b.length == old(b).length + delta Expands b by
delta
On 05/11/2015 08:31 PM, Timon Gehr wrote:
- The assertion in line 141 may fail. (expand can return false.)
(Same thing further down, line 167.)
On 05/11/2015 08:45 PM, Andrei Alexandrescu wrote:
On 5/11/15 11:06 AM, Timon Gehr wrote:
- If the rounding function is not piecewise constant with one fixed
point per piece, it can happen that 'allocated = needed' but 'allocated
goodAllocSize(needed)'. Then, the allocated size will be
On 05/11/2015 08:48 PM, Andrei Alexandrescu wrote:
On 5/11/15 11:31 AM, Timon Gehr wrote:
- The assertion in line 141 may fail. (expand can return false.)
OK, it seems the previous commit should take care of that.
...
Nope.
Well, yes, in the sense that there is no longer a possibly failing
On 05/12/2015 01:38 AM, Timon Gehr wrote:
- If b.ptr is null, then line 113 is bad in case goodAllocSize(0) 0.
That should be fixed in the same commit; I just handle expansion of null
blocks up front in expand().
...
OK.
(Scrap that.)
On 05/07/2015 11:12 PM, Andrei Alexandrescu wrote:
Helps an allocator without good reallocation capabilities:
http://erdani.com/d/phobos-prerelease/std_experimental_allocator_quantizer.html
Destruction welcome.
Andrei
quantizer.d is not in the commit:
On 05/13/2015 02:16 PM, Idan Arye wrote:
I think the `in` contracts check should be statically dispatched, so
that only the contracts relevant to the reference-type you are calling
the method from will be checked.
https://issues.dlang.org/show_bug.cgi?id=6857
On 05/13/2015 12:51 PM, iackhtak wrote:
There was discussion about broken contract programing. One broken
thing was in contract within inheritance. If you add different
in-contract in overridden parent and derived function only one
will be checked.
No, this is incorrect. Only one needs to pass
On 05/13/2015 02:16 PM, Benjamin Thaut wrote:
On Wednesday, 13 May 2015 at 12:05:48 UTC, Timon Gehr wrote:
On 05/13/2015 12:51 PM, iackhtak wrote:
There was discussion about broken contract programing. One broken
thing was in contract within inheritance. If you add different
in-contract in
On 05/12/2015 04:54 AM, Andrei Alexandrescu wrote:
On 5/11/15 4:59 PM, Timon Gehr wrote:
On 05/11/2015 08:48 PM, Andrei Alexandrescu wrote:
On 5/11/15 11:31 AM, Timon Gehr wrote:
- The assertion in line 141 may fail. (expand can return false.)
OK, it seems the previous commit should take
On 05/12/2015 05:52 PM, Steven Schveighoffer wrote:
On 5/10/15 8:58 AM, Timon Gehr wrote:
On 05/10/2015 11:50 AM, Andrei Alexandrescu wrote:
In C, C++, and D people have allocated memory for a long time in the
following manner:
...
Long story short, arrays should sit on a different heap than
On 05/12/2015 07:58 AM, Martin Nowak wrote:
On Monday, 11 May 2015 at 21:18:53 UTC, Walter Bright wrote:
D already does (for Win32) a generic compression on names. It works a
lot better than poorly reinventing compression - it's far less
complex, less buggy, easier to implement, etc.
I'd
On 05/13/2015 04:54 PM, Benjamin Thaut wrote:
On Wednesday, 13 May 2015 at 12:54:52 UTC, Timon Gehr wrote:
This will accept the same arguments as Base. Only one in-contract in
the inheritance chain must pass in order for the call to go through.
But wasn't exactly that the problem about the
301 - 400 of 1775 matches
Mail list logo
