On 21.10.2011 02:31, Tobias Brandt wrote:
Consider the following program:
class A(uint N) {}
void foo(uint N)(A!N) {}
void main()
{
auto a = new A!1; // compiles
foo(new A!1); // error
foo(new A!1u);
On 21.10.2011 05:24, Robert Jacques wrote:
On Thu, 20 Oct 2011 09:11:27 -0400, Don wrote:
[snip]
I'd like to get to the situation where those overloads can be added
without breaking peoples code. The draconian possibility is to disallow
them in all cases: integer types never match flo
On 20.10.2011 20:39, Norbert Nemec wrote:
Do you mean in the sense of symbolic algebraic transformations at
compile time? D would be the prime candidate for that.
From my reading of the website, it seems to be about getting the
derivative of a function which is specified in *source code* rathe
On 20.10.2011 19:28, Jonathan M Davis wrote:
On Thursday, October 20, 2011 05:13 Don wrote:
Personally, I'd rather completely eliminate implicit conversions between
integers and floating point types. But that's just me.
If it's a narrowing conversion, it should require a ca
On 20.10.2011 14:48, Manu wrote:
On 20 October 2011 15:13, Don mailto:nos...@nospam.com>> wrote:
On 20.10.2011 13:12, Manu wrote:
On 20 October 2011 11:02, Don mailto:nos...@nospam.com>
<mailto:nos...@nospam.com <mailto:nos...@nospam.com>>> wrote:
On 20.10.2011 13:12, Manu wrote:
On 20 October 2011 11:02, Don mailto:nos...@nospam.com>> wrote:
On 20.10.2011 09:47, Manu wrote:
Many architectures do not support real, and therefore it should
never be
used implicitly by the language.
Precision pr
On 19.10.2011 10:13, Manu wrote:
Nicely spotted, I didn't realise the intel/amd distinction ;)
Unless I'm mistaken, it is possible for D to return 'out' parameters by
value right? (in additional return registers, no touching the stack?) ..
Assuming that's the case you would surely standardise so
On 20.10.2011 09:47, Manu wrote:
Many architectures do not support real, and therefore it should never be
used implicitly by the language.
Precision problems aside, I would personally insist that implicit
conversation from any sized int always be to float, not double, for
performance reasons (th
:
== Quote from Don (nos...@nospam.com)'s article
The hack must go.
No. Something as simple as sqrt(2) must work at all costs, period. A
language
that adds a bunch of silly complications to something this simple is
fundamentally
broken. I don't remember your post on implicit preferred conver
On 20.10.2011 05:25, bearophile wrote:
Robert Jacques:
Simple, is a 5_000_000_000 long, and longs convert to reals. Also,
5_000_000_000 does not fit, exactly inside a double.
There is nothing "simple" here...
Bye,
bearophile
Yeah, but the problem isn't with ints, it's with integer literal
On 19.10.2011 20:12, dsimcha wrote:
== Quote from Don (nos...@nospam.com)'s article
In D2 prior to 2.048, sqrt(2) does not compile. The reason is that it's
ambiguous whether it is sqrt(2.0), sqrt(2.0L), or sqrt(2.0f). This also
applies to _any_ function which has overloads for mor
In D2 prior to 2.048, sqrt(2) does not compile. The reason is that it's
ambiguous whether it is sqrt(2.0), sqrt(2.0L), or sqrt(2.0f). This also
applies to _any_ function which has overloads for more than one floating
point type.
In D2 between versions 2.049 and the present, sqrt(2) compiles du
On 19.10.2011 12:50, Gor Gyolchanyan wrote:
good point. I'll need to generate comments for that code, that contain
information about the place, where the code was generated.
There are 2 things I'd really like to have:
1. Be able to obtain the name (possibly an alias) of a function on the
call st
On 19.10.2011 01:52, foobar wrote:
Don Wrote:
On 17.10.2011 01:43, foobar wrote:
foobar Wrote:
Don Wrote:
You're assuming that the compiler can run the code it's generating. This
isn't true in general. Suppose you're on x86, compiling for ARM. You
can't run the A
On 17.10.2011 01:43, foobar wrote:
foobar Wrote:
Don Wrote:
You're assuming that the compiler can run the code it's generating. This
isn't true in general. Suppose you're on x86, compiling for ARM. You
can't run the ARM code from the compiler.
This is quite possi
On 18.10.2011 11:43, Manu wrote:
On 18 October 2011 12:12, Don mailto:nos...@nospam.com>> wrote:
You mean bsr and bsf.
Unfortunately, there are some big problems with them. What is bsr(0) ?
True ;) .. but that's why the API needs to be defined and standardised.
On PowerPC
On 18.10.2011 09:38, Martin Nowak wrote:
http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP14
Your proposal seems to have an implicit "Posix file path syntax is
used", but that opens a can of worms.
Up until now, there has been a policy of ensuring that OS-specific paths
are kept out o
On 18.10.2011 06:25, Robert Jacques wrote:
On Mon, 17 Oct 2011 16:53:42 -0400, Manu wrote:
[snip]
*Count leading/trailing zeroes:* I don't know of any even slightly recent
architecture that doesn't have opcodes to count loading/trailing zeroes,
although they do exist, so perhaps this is a littl
On 16.10.2011 17:39, Ary Manzana wrote:
On 10/16/11 4:56 AM, foobar wrote:
Don Wrote:
On 16.10.2011 04:16, Ary Manzana wrote:
On 10/15/11 5:00 PM, Marco Leise wrote:
Am 15.10.2011, 18:24 Uhr, schrieb Ary Manzana:
On 10/14/11 5:16 PM, Graham Fawcett wrote:
On Fri, 14 Oct 2011 21:10:29
On 16.10.2011 04:16, Ary Manzana wrote:
On 10/15/11 5:00 PM, Marco Leise wrote:
Am 15.10.2011, 18:24 Uhr, schrieb Ary Manzana :
On 10/14/11 5:16 PM, Graham Fawcett wrote:
On Fri, 14 Oct 2011 21:10:29 +0200, Jacob Carlborg wrote:
On 2011-10-14 15:26, Andrei Alexandrescu wrote:
On 10/14/11 6
On 15.10.2011 18:54, Sean Kelly wrote:
At the time, there were some errors in the headers and I wasn't up to tracking
them down.
>It was also unclear whether the headers were copyrighted, though I've
since found that docs surrounding the Boost license that headers aren't
copyrightable.
> Fin
On 15.10.2011 22:00, Marco Leise wrote:
Am 15.10.2011, 18:24 Uhr, schrieb Ary Manzana :
On 10/14/11 5:16 PM, Graham Fawcett wrote:
On Fri, 14 Oct 2011 21:10:29 +0200, Jacob Carlborg wrote:
On 2011-10-14 15:26, Andrei Alexandrescu wrote:
On 10/14/11 6:08 AM, Jacob Carlborg wrote:
On 2011-10
On 13.10.2011 23:07, bearophile wrote:
This comes from a thread in D.learn.
This is a small Python2 program:
from sys import argv
x = len(argv)
s = "hello"
s += x
print s
Python is strongly typed so it refuses to append an integer number to a string:
Traceback (most recent call last):
Fi
On 11.10.2011 18:54, bearophile wrote:
Andrei Alexandrescu:
I was more enthused about that, but later I realized there are very few
situations in which one reasonably has a fixed-size array that is large
enough to make counting inadequate and is also updated often enough to
make the feature wor
On 10.10.2011 20:03, Norbert Nemec wrote:
On 10.10.2011 07:34, Don wrote:
On 10.10.2011 04:41, kenji hara wrote:
2011/10/10 bearophile:
So is this:
y[$-6, 0..$:2]
Translated like this?
y.opIndex(y.opDollar!0 - 6, y.opSlice!1(0, y.opDollar!1, 2))
I have no thought about it.
I'm not
On 11.10.2011 03:29, Andrei Alexandrescu wrote:
On 10/10/11 5:55 PM, Don wrote:
On 06.10.2011 20:56, Steven Schveighoffer wrote:
On Thu, 06 Oct 2011 12:27:16 -0400, Gor Gyolchanyan
wrote:
I see. Thanks for the detailed answer.
I should clarify one point, I realized I am somewhat
On 06.10.2011 20:56, Steven Schveighoffer wrote:
On Thu, 06 Oct 2011 12:27:16 -0400, Gor Gyolchanyan
wrote:
I see. Thanks for the detailed answer.
I should clarify one point, I realized I am somewhat inaccurate on the
reason the type is set to immutable(dchar). In fact, nobody actually
wrote
On 10.10.2011 08:58, Gor Gyolchanyan wrote:
There is a huge difference between a static and a dynamic array.
Dynamic array is an indirected type (objects of that type are pointers
to the actual data), while static arrays are PODs (directly refers to
the data).
Dynamic arrays are always size_t.siz
On 10.10.2011 04:41, kenji hara wrote:
2011/10/10 bearophile:
So is this:
y[$-6, 0..$:2]
Translated like this?
y.opIndex(y.opDollar!0 - 6, y.opSlice!1(0, y.opDollar!1, 2))
I have no thought about it.
I'm not sure that the additional stepping is really useful, but I
think adding it into syntax
On 30.09.2011 02:32, dsimcha wrote:
On 9/29/2011 5:06 PM, David Nadlinger wrote:
Yes, this pattern is very useful indeed, I also often use a similar
solution for generating code for string mixins on the fly. Do we already
have a name for it, by the way? I like to call it »IEDL for »Immediately
E
On 26.09.2011 17:43, Robert Jacques wrote:
Second, timing generally relies on the CPUs Time Stamp Counter, which is
not multi-thread safe; a core switch invalidates all previous TSC
values, and hence, the time measurement itself. Furthermore, the TSC is
not even guaranteed to have a fixed frequen
On 28.09.2011 16:45, Gor Gyolchanyan wrote:
I agree, that rewriting the language is not a good idea until the
current version is fully studied, so i don't want D3 either. D2 is
good enough for now.
But I don't have D2 because most of what makes it unique isn't
implemented or is buggy. And i still
On 26.09.2011 16:55, Mehrdad wrote:
DMD 2.055 seems to be crashing on my computer (Windows 7 x64).
When I press Debug, I see it's doing so in CloseHandle, probably because
I've turned on "Enable close exception" with Visual Studio's "Global
Flags" tool. (It takes a reboot to take effect.)
So th
On 27.09.2011 04:08, Simen Kjaeraas wrote:
On Tue, 27 Sep 2011 03:38:11 +0200, Jonathan M Davis
wrote:
isIntegral was specifically designed for testing that a type was
one of byte, ubyte, short, ushort, int, uint, long, and ulong, and that's
exactly what it's doing.
The name indicates it che
On 24.09.2011 00:47, Manu Evans wrote:
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s
article
On 9/22/11 1:39 AM, Don wrote:
On 22.09.2011 05:24, a wrote:
How would one do something like this without intrinsics (the
code is
c++ using
gcc vector extensions):
[sni
On 22.09.2011 20:19, Marco Leise wrote:
Am 22.09.2011, 19:26 Uhr, schrieb Peter Alexander
:
On 22/09/11 7:39 AM, Don wrote:
On 22.09.2011 05:24, a wrote:
How would one do something like this without intrinsics (the code is
c++ using
gcc vector extensions):
[snip]
At present, you can'
On 22.09.2011 05:24, a wrote:
How would one do something like this without intrinsics (the code is c++ using
gcc vector extensions):
[snip]
At present, you can't do it without ultimately resorting to inline asm.
But, what we've done is to move SIMD into the machine model: the D
machine model
On 21.09.2011 22:32, Sean Kelly wrote:
On Sep 21, 2011, at 12:59 PM, Andrei Alexandrescu wrote:
On 9/21/11 12:59 PM, bearophile wrote:
Andrei Alexandrescu:
which has enjoyed moderate audience and success. I uploaded the
slides at http://erdani.com/d/generic-programming-galore.pdf and
the vid
On 21.09.2011 21:23, Gor F. Gyolchanyan wrote:
As much as I'd like D to develop sweet language features like named function
parameters, directing effort to increase compatibility of D with other languages
(most notably, C++) would be a better idea, because if D gets cheaper and
cheaper
to use wi
On 19.09.2011 18:12, Andrei Alexandrescu wrote:
On 9/19/11 10:46 AM, Robert Jacques wrote:
So, on balance, I'd say the two pointers representation is categorically
worse than the fat pointer representation.
Benchmark. A few of your assumptions don't hold.
Andrei
Note that high-performance l
On 17.09.2011 19:58, Peter Alexander wrote:
On 17/09/11 4:32 PM, Adam D. Ruppe wrote:
Peter Alexander wrote:
In contrast, my D hobby project at only a few thousand lines of code
already takes 11s to build and doesn't do any fancy metaprogramming
or use CTFE.
Curious, did you use a library lik
On 08.09.2011 17:26, Christian Kamm wrote:
Timon Gehr wrote:
I am strongly in favor of disallowing any cases where mixin declarations
shadow declarations that were used to compute mixin declarations in a
scope that allows forward references.
Any thoughts on this?
Order-of-static-evaluation p
on.
Considering that Tiobe has a bad reputation which has been mentioned
both on this board and on reddit multiple times, and both bearophile and
Don had reservations about the Tiobe "news", I think I have some
justification in saying should have shown some restraint in touting Tiobe.
Imperial units are superior.
"It's zero degrees out." 0 F is actually pretty cold.
0 C is slightly chilly, but nothing to get worked up about.
Real men use Kelvin.
0 K is cold.
Inches beat centimeters any day of the week. Just like with
kilometers, centimeters are useless. (ever gone on a
On 12.09.2011 17:43, Andrei Alexandrescu wrote:
On 9/12/11 10:19 AM, Jeff Nowakowski wrote:
On 09/11/2011 10:28 PM, Caligo wrote:
I don't understand why some would down vote such a news. a lot of
haters out
there I suppose.
Probably because Tiobe is a piece of shit when it comes to accuracy,
On 12.09.2011 12:47, Walter Bright wrote:
On 9/11/2011 2:31 AM, Don wrote:
Do you have an example?
One is initializing the ctype array - the first 128 are initialized,
followed by 128 zeros.
As I said in my other post, we could deal with this using a CTFE library
solution.
It hardly seems
On 11.09.2011 17:07, Daniel Murphy wrote:
"Jacob Carlborg" wrote in message
news:j4i33b$1bc2$1...@digitalmars.com...
I find this strange:
D can call C++ free functions and virtual member functions but it cannot
call non-virtual or static member functions.
Especially not be able to call static
On 11.09.2011 11:43, bearophile wrote:
Don:
Do you have an example?
In bug 3849 there the only example I've found (it's not my code):
immutable ubyte _ctype[256] =
[
_CTL,_CTL,_CTL,_CTL,_CTL,_CTL,_CTL,_CTL,
_CTL,_CTL|_SPC,_CTL|_SPC,_CTL|_SPC,_CTL|_SPC,_CTL|_SPC
On 09.09.2011 17:49, Andrei Alexandrescu wrote:
http://www.reddit.com/r/programming/comments/k7pwu/eclipse_default_line_length_of_80_chars_outdated/
Andrei
Interesting to me was the quote from Linus, saying that indentation
depth should never exceed 3. If you accept that, then 80 characters
On 09.09.2011 21:53, Walter Bright wrote:
On 9/9/2011 11:48 AM, bearophile wrote:
It seems Pull 375 also turns this program in a compile-time error:
int[3] arr = [1, 2];
void main() {}
Walter told me that this code used to work as designed, this means
it's not a bug.
Despite not being a bug, I
On 01.09.2011 06:43, David Nadlinger wrote:
I forgot to specify a timezone in the announcement, so depending on your
location the code review period for the etc.curl module by Jonas Drewsen
has either already ended, or is going to end later today:
- Finally, it is not quite clear what the best
On 01.09.2011 23:35, Timon Gehr wrote:
On 09/01/2011 11:15 PM, kennytm wrote:
Timon Gehr wrote:
On 09/01/2011 09:41 PM, Don wrote:
On 31.08.2011 14:35, Timon Gehr wrote:
On 08/31/2011 04:41 AM, Jonathan M Davis wrote:
Objects would have writeTo and toString would presumably be
deprecated
On 31.08.2011 14:35, Timon Gehr wrote:
On 08/31/2011 04:41 AM, Jonathan M Davis wrote:
Objects would have writeTo and toString would presumably be
deprecated.
I have never understood the rationale behind deprecating toString once
we have writeTo. Why should it be deprecated?
Code bloat. Eve
On 01.09.2011 16:06, dsimcha wrote:
== Quote from Alex Rønne Petersen (xtzgzo...@gmail.com)'s article
On 01-09-2011 15:01, Lars T. Kyllingstad wrote:
On Wed, 31 Aug 2011 23:56:04 -0400, dsimcha wrote:
Since we have such an embarrassment of riches lately in terms of new
modules to be reviewed,
On 31.08.2011 09:35, bearophile wrote:
Don:
If caching is the _only_ case which is required,
They have developed this observational purity plus a way to enforce it, to
allow static analyzability of contracts (so they are allowed to call only
observationally pure methods), while keeping
On 29.08.2011 15:29, Stewart Gordon wrote:
On 25/08/2011 02:41, Michel Fortin wrote:
bool frontEquals(R, V)(R range, V value)
{
if (range.empty)
return false;
else
return range.front == value;
}
This will work fine with most ranges, but if you encounter an infinite
range (with empty
defined as
On 31.08.2011 09:03, Jonathan M Davis wrote:
On Wednesday, August 31, 2011 08:53:29 Don wrote:
On 31.08.2011 04:41, Jonathan M Davis wrote:
On Tuesday, August 30, 2011 20:59:06 Paul D. Anderson wrote:
Can someone clarify for me the status and/or direction of string
formatting in D?
We'v
3, 4 and 6 don't work, or don't work as
expected (to me at least). 1. prints 'BigInt', 3 and 4 are compile errors.
I know bigint is a controversial example because Don has strong feelings
against 1 and favors 2. (See bug #5231). I don't really have an opinion one
way o
On 30.08.2011 17:31, bearophile wrote:
I've found a nice paper, "99.44% pure: Useful Abstractions in Specifications",
By Mike Barnett, David A. Naumann, Wolfram Schulte, Qi Sun (Microsoft Research, 2004):
http://www.cs.ru.nl/ftfjp/2004/Purity.pdf
It presents yet another kind of purity, "observ
dsimcha wrote:
== Quote from Rainer Schuetze (r.sagita...@gmx.de)'s article
The lexer used by Visual D is also CTFE capable:
http://www.dsource.org/projects/visuald/browser/trunk/vdc/lexer.d
As Timon pointed out, it will separate into D tokens, not the more
combined elements in your array.
Here'
foobar wrote:
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
On 8/23/11 6:15 AM, foobar wrote:
== Quote from bearophile (bearophileh...@lycos.com)'s article
foobar:
you raise a valid concern but this looks too complicated.
I'd suggest to simplify into only two cas
e constants, and C1 > C2.
(correct condition was: a > C2 && a < C1)
Sent from my iPhone
On Aug 21, 2011, at 12:39 PM, Don wrote:
Sean Kelly wrote:
On Aug 18, 2011, at 10:29 AM, Nick Sabalausky wrote:
"Bernard Helyer" wrote in message
news:j2ithq$12kd$1..
Sean Kelly wrote:
On Aug 18, 2011, at 10:29 AM, Nick Sabalausky wrote:
"Bernard Helyer" wrote in message
news:j2ithq$12kd$1...@digitalmars.com...
I asked the Ars forums ( http://arstechnica.com/civis/viewtopic.php?
f=20&t=1153378&p=21965411 ) and I ask the same of you: should
unambiguously un
Vijay Nayar wrote:
On Wed, 17 Aug 2011 17:51:48 -0500, Andrei Alexandrescu wrote:
I doubt that would work well. Let's ignore for now mundane issues such
as the ambiguity of 3...5 and focus on something like:
int x;
...
switch (x) {
case 3 ... 5: return 1;
default: return 0;
}
We'd need to cha
Timon Gehr wrote:
On 08/18/2011 02:38 PM, Bernard Helyer wrote:
Faramir on the Ars forums makes an excellent point:
"With the c preprocessor, both theoretically and as it is used in
practice, you can easily get dead code in certain compile paths that is
live in others."
I think template mixins
Timon Gehr wrote:
On 08/12/2011 09:32 PM, bearophile wrote:
Timon Gehr:
foreach_reverse(i;0..array.length) writeln(array[i]),i--;
I'd like to statically forbid some more usages of the comma operator
in D :-)
Some of them are already forbidden compared to C. This is valid C code:
int main
Jonathan M Davis wrote:
On Friday, August 12, 2011 12:39:01 Don wrote:
kennytm wrote:
Don wrote:
I've had a look at a dozen or so of these, and they were all real. I
didn't see any which require a cast to "make the compiler shut up".
That's pretty impressive. In C++
bearophile wrote:
Don:
2) I have found many situations where I am able to solve a problem with both a
simple and slow brute force solver, and a complex and fast algorithm to solve a
problem. The little program maybe is too much slow for normal usage, but it's
just few lines long (espec
kennytm wrote:
Don wrote:
I've had a look at a dozen or so of these, and they were all real. I
didn't see any which require a cast to "make the compiler shut up".
That's pretty impressive. In C++ I find that such messages are nearly
always false positives.
The
bearophile wrote:
I have added this bit of code to my dmd, it gives warnings in cases of integral
signed-unsigned comparisons:
https://github.com/D-Programming-Language/dmd/pull/119
Then I have compiled Phobos (with unittests) with the -wi switch, this has
generated some of those signed-unsign
bearophile wrote:
Don:
"out" contracts seem to be almost useless, unless you have a theorem prover. The
reason is, that they test nothing apart from the function they are attached to, and it's
much better to do that with unittesting.<
I see three different situations wh
Andrej Mitrovic wrote:
On Windoze I think it's pretty standard to use -longname. I really
like forward-slash style arguments too (boo-hoo for you posixers,
idk.).
Does anything on Windows use --longname, apart from direct ports of
posix tools?
Lutger Blijdestijn wrote:
Don wrote:
bearophile wrote:
Contracts don't replace unittests, they complement each other.
They are nice but have little value over plain assert
_unless_ we are talking about classes and _inheritance_, which isn't the
case here.
It's easy to for
bearophile wrote:
Contracts don't replace unittests, they complement each other.
They are nice but have little value over plain assert
_unless_ we are talking about classes and _inheritance_, which isn't the
case here.
It's easy to forget to test the output of a function, the "out" contract
Walter Bright wrote:
On 8/9/2011 2:46 AM, Don wrote:
From a discussion on D.learn.
If x and y are different integral types, then in an expression like
x >> y
the integral promotion rules are applied to x and y.
This behaviour is obviously inherited from C, but why did C use such a
c
From a discussion on D.learn.
If x and y are different integral types, then in an expression like
x >> y
the integral promotion rules are applied to x and y.
This behaviour is obviously inherited from C, but why did C use such a
counter-intuitive and bug-prone rule?
Why isn't typeof(x >> y) s
Walter Bright wrote:
On 8/8/2011 9:44 PM, Don wrote:
Aargh, you're right.
I've been slowly going through the reports. While I've found only one
real bug, and several "sort of" problems if you squint at them the right
way, most are issues I put in the category of
Jacob Carlborg wrote:
On 2011-08-07 03:19, bearophile wrote:
I have discussed about this topic once in past, but in the meantime I
have seen this is a quite common problem, so I think it doesn't harm
to touch this topic again.
This is a direct D translation of the original C or C++ code:
//
David Nadlinger wrote:
On 8/9/11 5:46 AM, Don wrote:
Don:
I think these are false positives too. The ones I saw were of the
form: […]
4995: FuncDeclaration *fd;
4996: Expression *pthis = NULL;
4997: if (deleg->op == TOKdelegate)
4998: {
4999: fd = ((DelegateExp *)deleg)->func;
5000:
bearophile wrote:
Double leading underscores are for temporary things, that will change and improve, like __traits.
> But this ctWriteln is meant to stay.
No it isn't. If we get bug 3702 ("magic namespace") approved, the name
of __ctfe and __ctfeWriteln will change. They are intentionally ugly
bearophile wrote:
Don:
I think these are false positives too. The ones I saw were of the form:
When p is a pointer,
assert(p);
y = p->x; // error: p is uninitialized
This was true in the first "release" of those warnings files, but is it true
still? There are only 10 of
bearophile wrote:
Vladimir Panteleev:
Done:
http://dump.thecybershadow.net/b1e4cb6ef0a8d3c5f54d5cb09ddd1a9e/DMD.log
There are only 10 NULL deference warnings left:
s2ir.c(1043): warning C6011: Dereferencing NULL pointer 'pu++'
false (only if malloc fails)
s2ir.c(980): warning C6011: Deref
KennyTM~ wrote:
On Aug 7, 11 22:23, Vladimir Panteleev wrote:
On Sun, 07 Aug 2011 13:29:20 +0300, Walter Bright
wrote:
It's less complex (!) if you are not trying to make a working dmd. It
just needs to compile.
OK, that wasn't actually too bad.
https://github.com/CyberShadow/dmd/tree/compi
bearophile wrote:
Max Klyga:
So this feature has to be either mandatory or not. Making it optional
leads to confusion as Jonathan mentioned.
On this, what I have suggested it not the same thing that the original proposal says. In the original proposal the
"ref" and "out" are optional. In my
dsimcha wrote:
My apologies for not announcing this yesterday. For some reason I
thought today was the official end of review. Anyhow, Lars
Kyllingstad's new std.path module, which has been in review for the past
3 weeks, is up for vote. Please vote yes or no in this thread.
Code:
https://
Adam Ruppe wrote:
But what's the purpose of those callq? They seem to call the
successive asm instruct
I find AT&T syntax to be almost impossible to read, but it looks
like they are comparing the instruction pointer for some reason.
call works by pushing the instruction pointer on the stack, t
bearophile wrote:
Peter Alexander:
It's interesting that you've brought up the issue of the message being
sent out about D, because I feel it is exactly the opposite: it's far
too positive. Everyone seems to only talk about all the cool features in
D and seem to ignore all the issues that exi
Michel Fortin wrote:
On 2011-08-02 13:15:52 +, bearophile said:
A tuple isn't an object, it's more like a record, it's almost like a
more handy POD. So tuples are data structures that you use with code
(functions) that they don't contain.
Actually, that's up to debate in my opinion. And
Mehrdad wrote:
I'm just wondering, is there a plan to fix the
|int[3] a = [1, 2, 3];
|
issue, to not make it allocate on the heap?
It kind of sucks to see people bash D for something so trivial like
this. :\
Yes. It's bug 2356.
dennis luehring wrote:
Am 29.07.2011 22:02, schrieb Walter Bright:
Here's another one:
T* p;
...
if (A)
p = &t;
...
if (B)
... *p ...
B is true if and only if A is true. B can even be the same expression as
A, such as a->b->c. Clang complains on the *p that p is "u
Nick Sabalausky wrote:
"Walter Bright" wrote in message
news:j12ubk$dqd$2...@digitalmars.com...
On 7/30/2011 3:50 PM, Nick Sabalausky wrote:
The file "dmd2\src\druntime\src\rt\minit.obj" in the 2.054 zip is out of
date WRT the matching asm file. (At least as far as the timestamps, I
don't
kno
a heck of a lot less limitations than CTFE used to have.
Great
job, Don!
Thanks. It's been possible to work on this because there are now so many
people fixing the critical compiler bugs. In particular, Kennytm has
been an enormous help. As well as a phenomenal number of patches
bearophile wrote:
Peter Alexander:
I also posted my thoughts, although I think I was a bit more negative
towards D than you were :-)
I think your answer is among the best of that thread.
Regarding this you have written:
int[3] a = [1, 2, 3]; // in D, this allocates then copies
int a[3] = {1
obos are all stable enough that they wouldn't
normally break each other unless a bad changeset gets committed or your
versions get too out-of-sync with each other.
Andre, Walter, Don and the other big committers probably have a better idea
of how this usually goes, though...
Just check
Don wrote:
Robert Clipsham wrote:
Hi all,
I took the liberty of running dmd through clang's static analysis, and
it's turned up quite a few (486) potential bugs in dmd:
http://octarineparrot.com/assets/dmd/
There's bound to be a few false positives in there (please feel
Robert Clipsham wrote:
Hi all,
I took the liberty of running dmd through clang's static analysis, and
it's turned up quite a few (486) potential bugs in dmd:
http://octarineparrot.com/assets/dmd/
There's bound to be a few false positives in there (please feel free to
report them to the nice
Walter Bright wrote:
On 7/12/2011 10:11 PM, bcs wrote:
I broke down and installed wine:
bcs@doors:~/Downloads/dmc$ cat split.cpp
#include
struct S0 {
unsigned f1 : 1;
};
struct S0 s;
int main (void) {
int x = -3;
int y = x>= (0, s.f1);
printf ("%d\n", y);
return 0;
}
bcs@doors:
://d.puremagic.com/issues/show_bug.cgi?id=3952
https://github.com/D-Programming-Language/dmd/pull/237 ) will make
run-time D interpretation even more useful.
There are disadvantages:
- Even with some printing function, CTFE interpreter is limited. Don
will remove some more CTFE limitations like
dsimcha wrote:
The documentation for CTFE is outdated and specifies limitations that no
longer exist thanks to Don's massive overhaul. For example, a big one is that
pointers now work. What limitations that could potentially be removed still
do exist in CTFE as of 2.054?
The updated CTFE docu
Robert Clipsham wrote:
Hi all,
I took the liberty of running dmd through clang's static analysis, and
it's turned up quite a few (486) potential bugs in dmd:
http://octarineparrot.com/assets/dmd/
There's bound to be a few false positives in there (please feel free to
report them to the nice
501 - 600 of 2058 matches
Mail list logo
