On Tuesday, 13 January 2015 at 18:25:38 UTC, ketmar via
Digitalmars-d-learn wrote:
On Tue, 13 Jan 2015 17:09:31 +
Dominikus Dittes Scherkl via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
/// interpret an array of one type as an array of a
different type.
may i point
On Tuesday, 13 January 2015 at 20:11:45 UTC, anonymous wrote:
On Tuesday, 13 January 2015 at 20:00:57 UTC, Dominikus Dittes
Scherkl wrote:
So if I have a function that allowes to do this:
uint a;
a.bit[16] = true;
writeln(a); // 65536
Is it also already available?
a |= 1 16;
Of course
On Tuesday, 6 January 2015 at 09:11:10 UTC, bearophile wrote:
Dominikus Dittes Scherkl:
Yeah. I wish it would be possilbe to do something like:
alias @smooth = @save pure nothrow @nogc;
and then use this instead.
You most probably want something more principled instead, as
the algebra of
On Monday, 5 January 2015 at 22:04:58 UTC, Steven Schveighoffer
wrote:
Making some way to bundle attributes, or be able to negate
currently one-way attributes would go a long way IMO.
Yeah. I wish it would be possilbe to do something like:
alias @smooth = @save pure nothrow @nogc;
and then
Is it possible to use static if in a template structure to have
some member functions only for specific types?
E.g.:
struct Foo(T)
{
...
T get() { ... }
static if(isMutable!T)
{
void set(T x) { ... }
}
}
On Monday, 5 January 2015 at 17:55:49 UTC, Justin Whear wrote:
On Mon, 05 Jan 2015 17:47:09 +, Dominikus Dittes Scherkl
wrote:
Is it possible to use static if in a template structure to
have some
member functions only for specific types?
Yep. This is actually a frequently used pattern
On Friday, 2 January 2015 at 13:33:40 UTC, Don wrote:
BTW in the existing CTFE you can cast int - float and long
- double.
So you can implement pow for 64 bit floats already. It's only
80-bit reals that are a problem, because there is no integer
type that is large enough.
Why?
long has 64
On Monday, 8 December 2014 at 08:46:49 UTC, bearophile wrote:
Freddy:
Why not keep size_t implictly convertable but disallow it for
usize.
This is an interesting idea. (But the name uword seems
better).
YES.
And I want a signed variant of this (instead of the ugly
ptrdiff_t):
I want to
On Friday, 28 November 2014 at 10:55:27 UTC, bearophile wrote:
In D code it's a good idea to set as const/immutable (where
possible) all variables that don't need to change, for both
safety and compiler-enforced code documentation.
In my D functions sometimes I create dynamic arrays that later
On Wednesday, 19 November 2014 at 09:06:16 UTC, Maroc Leise wrote:
Clearly size_t (which I tend to alias with ℕ in my code for
brevity and coolness)
No, this is far from the implied infinite set.
A much better candidate for ℕ is BigUInt (and ℤ for BigInt)
On Monday, 3 November 2014 at 21:17:09 UTC, Philippe Sigaud via
Digitalmars-d-learn wrote:
struct polynomial(uint base)
{
private:
uint[] N;
public:
this(uint x) { base = x; }
base is part of the type. polynomial is just a 'recipe' for a
type,
the real struct would be Polynomial!(0),
On Tuesday, 4 November 2014 at 00:51:10 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Mon, Nov 03, 2014 at 04:29:17PM -0800, Walter Bright via
Digitalmars-d wrote:
On 11/3/2014 10:03 AM, Nick Treleaven wrote:
On 02/11/2014 20:33, Walter Bright wrote:
It's simply not workable to put a wall between
If I have a struct with numeric template parameter, how can I
access it within member functions? Like normal member variables?
And how about the constructor?
struct polynomial(uint base)
{
private:
uint[] N;
public:
this(uint x) { base = x; }
...
void add(Polynomial!base P)
{
On Thursday, 9 October 2014 at 08:50:52 UTC, Martin Nowak wrote:
Would this affect your code?
No, I always wrote it on the right.
Do you think it makes your code better or worse?
Better.
Is this just a pointless style change?
No, removing confusing style is good.
On Wednesday, 8 October 2014 at 01:22:49 UTC, Timon Gehr wrote:
The secret behind the monty hall scenario, is that the host is
actually
leaking extra information to you about where the car might be.
You make a first choice, which has 1/3 chance of being right,
then the
host opens another
On Friday, 12 September 2014 at 07:49:59 UTC, eles wrote:
On Thursday, 11 September 2014 at 20:11:45 UTC, deadalnix wrote:
- Other memory management technique require bookkeeping. In a
multicore environment, that mean expensive synchronization.
It is also true that when you start to really
On Wednesday, 10 September 2014 at 19:19:09 UTC, Walter Bright
wrote:
On 9/10/2014 3:34 AM, Dominikus Dittes Scherkl wrote:
On Tuesday, 9 September 2014 at 18:59:33 UTC, Walter Bright
wrote:
1. The compiler has -gx, which will stomp the stack upon
function return.
Nice. But this will be set
On Tuesday, 9 September 2014 at 18:59:33 UTC, Walter Bright wrote:
1. The compiler has -gx, which will stomp the stack upon
function return.
Nice. But this will be set for the whole program.
But if I want to use e.g. a crypto-library, the rest of the
program should not be slowed by stomping
On Tuesday, 9 September 2014 at 14:42:14 UTC, David Nadlinger
wrote:
On Tuesday, 9 September 2014 at 07:09:52 UTC, bearophile wrote:
John Colvin:
http://www.daemonology.net/blog/2014-09-06-zeroing-buffers-is-insufficient.html
D could incorporate something like this, no?
See:
On Sunday, 7 September 2014 at 21:03:17 UTC, Vladimir Panteleev
wrote:
I've picked up an older project for using D on barebones Win32
as a better C.
Thanks to recent advances in DMD (-betterC and -m32mscoff), I
could get a Hello, world program on Win32 down to just 438
bytes when compiled.
On Saturday, 6 September 2014 at 02:30:50 UTC, Cassio Butrico
wrote:
What criteria do you take into consideration for the choice of
a programming language.
and why? does not mention what language would be, but what
criteria led them to choose.
First of all I want efficient generated code:
On Wednesday, 27 August 2014 at 05:45:34 UTC, eles wrote:
While this may be true in this case, I think that, in general,
you cannot draw such a clear line between what's recoverable
and what's not. If you really want to push things to the
extreme, the sole unrecoverable error shall be
On Sunday, 24 August 2014 at 13:14:45 UTC, Marc Schütz wrote:
http://wiki.dlang.org/User:Schuetzm/scope
I like this.
It removes pretty much all of the need for manual memory
management for me. I would love to see this implemented.
On Wednesday, 20 August 2014 at 06:11:42 UTC, blake kim wrote:
But I don't think this is right. Many C APIs need structure as
argument and adjusting align each structure doesn't make sense.
Is this problem a Bug of D ?
Default alignment in D is pointersize (size_t) - so 8 on 64bit.
But most C
On Wednesday, 20 August 2014 at 07:04:50 UTC, Jacob Carlborg
wrote:
* Remove template constraints. I think, at least with
std.algorithm, it's mostly obvious what to pass and I rarely
need to look at the constraints
BTW aren't they a bit over-complicated?
(args.length == 0 || (args.length 0
I have several times seen a construct
template foo(T...) if(T.length == 1)
{
...
}
What is that good for?
Why using variadic parameter if anyway exactly one parameter is
required?!?
On Wednesday, 20 August 2014 at 15:26:14 UTC, monarch_dodra wrote:
AFAIK, it's a historical workaround to accept T as either alias
or not alias, as varargs have auto alias. EG:
foo!int //OK
foo!hello //OK too
Ah, ok.
And why historical? Is that not necessary anymore? What better
solution is
On Wednesday, 20 August 2014 at 15:37:18 UTC, Philippe Sigaud via
Digitalmars-d-learn wrote:
No better solution that I know of.
alias template parameters (alias a) match symbols (names,
user-defined
types) whereas type parameter (T) match only pure types.
So when we need to match anything,
On Monday, 18 August 2014 at 16:30:13 UTC, Nikolay wrote:
I found this code sample in vibe:
void connect(NetworkAddress addr)
{
enforce(.connect(m_ctx.socketfd, addr.sockAddr,
addr.sockAddrLen) == 0, Failed to connect UDP
socket.~to!string(getLastSocketError()));
}
What
On Monday, 11 August 2014 at 07:04:42 UTC, Andrew Godfrey wrote:
Reminder: The PR is ready for review:
https://github.com/D-Programming-Language/dlang.org/pull/623
Jonathan has summarized his position in the commments.
What do the rest of you think?
H. S. Teoh, Jakob, Ali, Marc, Dominikus,
On Monday, 11 August 2014 at 14:15:05 UTC, Nordlöw wrote:
Here's my current try:
string toMathML(T)(T x) @trusted /** pure */ if
(isFloatingPoint!T)
{
import std.conv: to;
import std.algorithm: findSplit; //
immutable parts = to!string(x).findSplit(e);
if (parts[2].length ==
On Friday, 8 August 2014 at 15:17:25 UTC, seany wrote:
The .., range operator, when used like this :
string a = abcd;
string b = a[0 .. a.count()-1];
sets b to abc. is this the expected behavior?
Yes. [..] is exclusive the last element.
So [0..1] is a single element [0]
That allows to avoid
On Friday, 1 August 2014 at 06:18:06 UTC, Jonathan M Davis wrote:
On Wednesday, 30 July 2014 at 06:11:58 UTC, Dominikus Dittes
Scherkl wrote:
[...]
should go in the official terminology. (otherwise we would
need a new, third term to describe the other thing that is
not directly accessible in
On Wednesday, 30 July 2014 at 05:55:58 UTC, Jonathan M Davis
wrote:
I'm completely opposed to changing the official terminology.
Why?
What buys it, to have two terms slice and dynamic array if
they mean exactly the same thing?
Especially if we have two different things, the memory and the
On Sunday, 27 July 2014 at 13:17:42 UTC, Iain Buclaw wrote:
The cent and ucent keywords have been reserved since... well...
certainly before the first D1 (as opposed to D0.xx) release
[2]. But that's all they have ever seemed to be. Just
reserved keywords that give odd errors when you try to
On Friday, 18 July 2014 at 13:17:34 UTC, Kagamin wrote:
On Thursday, 17 July 2014 at 18:13:18 UTC, Frustrated wrote:
Are those that say the GC is fine and works for 90-95% of apps
without issue just ignorant? Or are they arrogant?
When one is writing a real time app and have the absolute
On Wednesday, 16 July 2014 at 13:04:37 UTC, Johannes Pfau wrote:
I experimented a little more with Volatile!T and I don't think
you can make this example work:
struct Timer
{
uint control;
uint data;
}
enum timerA = (Volatile!Timer)* = cast()0xDEADBEAF;
timerA.control |= 0b1;
How
On Tuesday, 15 July 2014 at 05:26:57 UTC, Philippe Sigaud via
Digitalmars-d-learn wrote:
@property allows you to call a function without the parenthesis
(), to imitate a field in a struct or class.
Ah, ok. That means without @property I would need to write
defaultInit!T() instead of
Is it possible to write custom properties for basic types, so
that I can write e.g. int.myProp instead of myProp!int()
[analogue to x.myProp instead of myProp(x)]?
On Monday, 14 July 2014 at 11:28:15 UTC, Philippe Sigaud via
Digitalmars-d-learn wrote:
Halas, that's not what the OP wants. He needs properties on the
*type*
itself: int.foo instead of foo!int.
Yes, exactly.
So no, this is not possible.
Hmm.
So how do I use stuff like this:
template
On Wednesday, 9 July 2014 at 19:54:47 UTC, H. S. Teoh via
Digitalmars-d-learn wrote:
[...]
The problem is that the function needs to return
int, but given two uints, their difference may be
greater than int.max, so simply subtracting them
will not work. So the best I can come up with is:
Should of course be:
int compare2(uint x, int y)
{
return (x int.max) ? 1 : (cast(int)x - y);
}
On Wednesday, 9 July 2014 at 14:51:41 UTC, Meta wrote:
One of the uglier things in D is also a long-standing problem
with C and C++, in that comparison of signed and unsigned
values is allowed.
I would like that, if it would be implemented along this line:
/// Returns -1 if a b, 0 if they
Of course without the ! after opCmp in the several cases.
On Wednesday, 9 July 2014 at 17:13:21 UTC, H. S. Teoh via
Digitalmars-d-learn wrote:
On Wed, Jul 09, 2014 at 04:24:38PM +, Dominikus Dittes
Scherkl via Digitalmars-d-learn wrote:
/// Returns -1 if a b, 0 if they are equal or 1 if a b.
/// this will always yield a correct result, no matter
On Wednesday, 9 July 2014 at 17:13:21 UTC, H. S. Teoh via
Digitalmars-d-learn wrote:
The branched version would look something like this:
mov eax, [address of u]
mov ebx, [address of s]
cmp ebx, $#0
jge label1 ; first branch
mov
On Tuesday, 8 July 2014 at 06:08:58 UTC, Brian Schott wrote:
On Tuesday, 8 July 2014 at 06:02:51 UTC, Iain Buclaw via
Digitalmars-d wrote:
I would ask why are you passing integers to isNaN.
We passed T to isNaN, and sometimes T was uint.
I would like to have a NaN in any type and be able to
Hello.
I want to create some finite algebra, where the elements are
enumerated but operations on them are defined (with composition
tables).
e.g.:
enum color = { white, yellow, red, blue, orange, violet, green,
black };
color a = blue;
a += yellow;
assert(a == green);
is this possible
On Sunday, 18 May 2014 at 21:58:54 UTC, bearophile wrote:
I presume some ways to improve it are to add to core.bitop some
D standard intrinsics to detect overflows and carry, to
increase run-time performance to sufficient levels. If they are
not fast, people will be less willing to used them.
On Tuesday, 20 May 2014 at 13:03:59 UTC, Nordlöw wrote:
You have a typo: @save instead of @safe
Oops. This happens all the time :-/
You should also guard the use of asm to x86 architectures only
with version.
Uh?
I thought the D assembler should be generic? So if the target
platform
Did I understand correct that a function can only be @nogc if
also all functions that it calls are @nogc too (and of course it
doesn't use the GC itself)?
If so, should this be possible:
string foo()
{
// use GC to allocate some string
}
bar @nogc
{
mixin(foo());
}
Because, bar()
On Tuesday, 20 May 2014 at 17:14:31 UTC, John Colvin wrote:
On Tuesday, 20 May 2014 at 12:25:11 UTC, Dominikus Dittes
Scherkl wrote:
Did I understand correct that a function can only be @nogc if
also all functions that it calls are @nogc too (and of course
it doesn't use the GC itself)?
If
201 - 252 of 252 matches
Mail list logo
