Hi,
I have a C variadic function (passed from C code into my D code via
function pointer) that I need to call with a static array.
So according to the D documentation, static arrays are passed by value
in D2 and by reference in C and D1.
(Even though http://dlang.org/abi.html claims "Static ar
Am 20.07.2014 18:37, schrieb bearophile:
Daniel Gibson:
For "normal" functions http://dlang.org/interfaceToC.html tells me to
add a "ref" in the function signature, to tell D to pass it by
reference (couldn't this be implicit for extern (C) functions?)
I don't know why D isn't adapting such t
Am 21.07.2014 16:34, schrieb bearophile:
Ary Borenszweig:
Wat?
Hash methods should be automatic for simple structs.
Bye,
bearophile
That would be too much magic => special cases one has to know about.
Cheers,
Daniel
Am 21.07.2014 06:07, schrieb Daniel Murphy:
"Daniel Gibson" wrote in message news:lqh3vb$c2b$1...@digitalmars.com...
* passing stuff to the function is done as C expects it (not done,
also: are there other cases than the static array one that are
different?)
Dynamic arrays.
D used t
Am 22.07.2014 11:01, schrieb Daniel Murphy:
Old D code (from the 32-bit only days) used to do this successfully:
printf("Hello %.*s\n", "segfault");
So it relied on both the length and pointer being passed. Unfortunately
this was done quite a lot, so simply changing the rules so string
litera
Am 24.07.2014 01:52, schrieb Andrei Alexandrescu:
I'm unconvinced. Most algorithms that need inequality don't need
equality comparison; instead, they consider objects for which both !(a <
b) && !(b < a) in the same "equivalence class" that doesn't assume they
are actually equal.
Bottom line, in
Am 25.07.2014 12:07, schrieb Jonathan M Davis:
And once you define opEquals, you have to define
toHash. So, what you're suggesting would force a lot more code to define
toHash, which will likely cause far more bugs than simply requiring that
Is it actually hard to define toHash, or should it be
Am 25.07.2014 18:11, schrieb "Marc Schütz" ":
I'm astonished that it doesn't work like that already. When I first read
the operator overloading docs, I really liked that in D I don't need to
define all the individual comparison operators, but only opCmp. I
Well, to be fair the documentation, is
Am 25.07.2014 20:45, schrieb Jonathan M Davis:
On Friday, 25 July 2014 at 13:34:55 UTC, H. S. Teoh via Digitalmars-d
wrote:
On Fri, Jul 25, 2014 at 09:46:55AM +, Jonathan M Davis via
Digitalmars-d wrote:
Even worse, if you define opEquals, you're then forced to define
toHash, which is much
Am 31.07.2014 03:07, schrieb Andrei Alexandrescu:
A coworker asked about the idiomatic way to get the hash of a string in
D, and somewhat surprisingly the best answer I could find is: "to get
the hash of an lvalue x, call typeof(x).getHash(&x)."
That's admittedly quite clunky and indirect. Is it
Am 31.07.2014 02:50, schrieb Tobias Müller:
Walter Bright wrote:
On 7/30/2014 3:53 PM, Artur Skawina via Digitalmars-d wrote:
No, with the assert definition you're proposing, it won't. It would
be allowed to optimize away the bounds check. And this is just one of
many problems with the assert=
Am 31.07.2014 04:53, schrieb Walter Bright:
On 7/30/2014 6:38 PM, Daniel Gibson wrote:
I'm in favor of a "harmless" assert().
In C(++) I sometimes use things like
assert(x != NULL);
if(x != NULL) {
x->foo = 42;
// ...
}
I have that assertion to hopefully find bugs during development
Am 31.07.2014 15:32, schrieb Johannes Pfau:
Am Wed, 30 Jul 2014 17:32:10 -0700
schrieb Andrei Alexandrescu :
On 7/30/14, 5:29 PM, Andrei Alexandrescu wrote:
On 7/30/14, 4:51 PM, Tobias Müller wrote:
With relatively 'dumb' compilers, this is not a big problem, but
optimizers
are more and more
Am 31.07.2014 17:26, schrieb Artur Skawina via Digitalmars-d:
On 07/31/14 15:44, Daniel Gibson via Digitalmars-d wrote:
And don't forget this (rather old) case:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8537
(I really don't get why anyone would want such an optimization:
Am 31.07.2014 18:29, schrieb Andrei Alexandrescu:
On 7/31/14, 8:37 AM, Daniel Gibson wrote:
When I tell it to write something, I want it to do that, even if it
might look like nonsense (if anything, it could create a warning).
I'm afraid those days are long gone by now. -- Andrei
At least fo
Am 31.07.2014 21:19, schrieb Walter Bright:
That's the way assert in C/C++ conventionally worked. But this is
changing. Bearophile's reference made it clear that Microsoft C++ 2013
has already changed, and I've seen discussions for doing the same with
gcc and clang.
This will break so much code
Am 31.07.2014 21:46, schrieb H. S. Teoh via Digitalmars-d:
On Thu, Jul 31, 2014 at 09:37:11PM +0200, Daniel Gibson via Digitalmars-d wrote:
[...]
This thread however shows that many D users (who probably have more D
experience than myself) are not aware that assert() may influence
optimization
Am 31.07.2014 21:59, schrieb bearophile:
Daniel Gibson:
so they can make sure to use assert() accordingly.
What's the correct way to use the assert-assume hybrid?
I guess in many cases I'd avoid using assert() in fear of breaking my
defensively written program (like that example from earli
Am 31.07.2014 22:57, schrieb Andrei Alexandrescu:
On 7/31/14, 12:37 PM, Daniel Gibson wrote:
This thread however shows that many D users (who probably have more D
experience than myself) are not aware that assert() may influence
optimization and would prefer to have separate syntax to tell the
Am 31.07.2014 23:21, schrieb Sean Kelly:
On Thursday, 31 July 2014 at 06:57:15 UTC, Walter Bright wrote:
On 7/30/2014 3:39 PM, Joseph Rushton Wakeling via Digitalmars-d wrote:
My take is that, for this reason, these should be asserts and not
enforce() statements. What are your thoughts on the
Am 31.07.2014 23:59, schrieb Walter Bright:
On 7/31/2014 10:40 AM, Daniel Gibson wrote:
It's a major PITA to debug problems that only happen in release builds.
Debugging optimized code was a well known problem even back in the 70's.
Nobody has solved it, and nobody wants unoptimized code.
Y
Am 01.08.2014 03:12, schrieb Walter Bright:
On 7/31/2014 3:21 PM, Daniel Gibson wrote:
And I agree with your stance on those fine-grained optimization
switches from
your other post. GCC currently has 191 flags the influence
optimization[1]
Just consider this from a testing standpoint. As I men
Am 01.08.2014 12:03, schrieb "Marc Schütz" ":
A compiler is a program that turns code in one programming language to
equivalent machine code, according to a language specification. There
are obviously many different equivalent machine code programs
corresponding to any sufficiently complex highe
Am 01.08.2014 05:17, schrieb Walter Bright:
Frankly, it never occurred to me that it wasn't obvious. When something
is ASSERTED to be true, then it is available to the optimizer. After
all, that is what optimizers do - rewrite code into a mathematically
equivalent form that is provably the same
Am 01.08.2014 05:27, schrieb Walter Bright:
On 7/31/2014 1:11 PM, Daniel Gibson wrote:
I guess in many cases I'd avoid using assert() in fear of breaking my
defensively written program (like that example from earlier: assert(x
!is null);
if(x) { x.foo = 42; }).
I just hang my head in my hands
Am 01.08.2014 16:58, schrieb Andrei Alexandrescu:
You may dislike what Walter wanted assert to be, but really this has
been it from the beginning. Back in the day when I joined him I
questioned the validity of making "assert" a keyword. He explained that
he wanted it to be magic in the same way
Am 01.08.2014 18:47, schrieb Daniel Murphy:
"Daniel Gibson" wrote in message news:lrgcei$211u$1...@digitalmars.com...
I'm a bit surprised that back then your reaction was not "well, that's
a neat idea, but people must know about it, so let's make it explicit
in the documentation".
Haha, I th
Am 01.08.2014 20:50, schrieb Walter Bright:
On 8/1/2014 7:08 AM, Daniel Gibson wrote:
I'm not a native speaker..
I couldn't tell - your english is excellent.
Thank you :)
.. but even if I were: words used for constructs/function-names/... in
programming often don't 100% match their "real"
Am 01.08.2014 22:16, schrieb eles:
On Friday, 1 August 2014 at 17:43:27 UTC, Timon Gehr wrote:
On 08/01/2014 07:19 PM, Sebastiaan Koppe wrote:
The debug and the release build may be subjected to different input
and hence traverse different traces of abstract states. It is not
valid to say tha
Am 02.08.2014 00:01, schrieb Timon Gehr:
On 08/01/2014 11:40 PM, Chris Cain wrote:
On Friday, 1 August 2014 at 21:29:48 UTC, Timon Gehr wrote:
en.wikipedia.org/wiki/Evidence
http://en.wikipedia.org/wiki/Sausage
...
ingredient in dishes such as stews and casseroles
Am 02.08.2014 04:13, schrieb David Bregman:
is this
http://www.cplusplus.com/reference/cassert/assert/
the same as this?
http://msdn.microsoft.com/en-us/library/1b3fsfxw.aspx
can you see the difference now?
Oh, interesting quote from the __assume() link:
"Use __assume in an ASSERT only when
Am 02.08.2014 22:02, schrieb Johannes Pfau:
Am Sat, 02 Aug 2014 12:19:41 -0700
schrieb Walter Bright :
On 8/2/2014 6:20 AM, Artur Skawina via Digitalmars-d wrote:
The bug was _introduced_ by the assert, the code was 100% correct.
Asserts are part of the code, and writing incorrect asserts is
Am 03.08.2014 09:16, schrieb Andrei Alexandrescu:
We need a better json library at Facebook. I'd discussed with Sönke the
possibility of taking vibe.d's json to std but he said it needs some
more work. So I took std.jgrandson to proof of concept state and hence
ready for destruction:
http://erda
Am 03.08.2014 22:05, schrieb bachmeier:
Thanks for the summary. I apologize for the uninformed question, but is
it possible to explain how the change wrt assert will break existing
code? Those details are probably buried in the extensive threads you've
referenced. I ask because my understanding o
Am 04.08.2014 00:15, schrieb Andrei Alexandrescu:
That said, should we proceed carefully about realizing this advantage?
Of course; that's a given. But I think it's very important to fully
understand the advantages of gaining an edge over the competition.
Gaining an edge over the competition?
Am 04.08.2014 00:45, schrieb Dmitry Olshansky:
04-Aug-2014 02:35, Daniel Gibson пишет:
Am 04.08.2014 00:15, schrieb Andrei Alexandrescu:
That said, should we proceed carefully about realizing this advantage?
Of course; that's a given. But I think it's very important to fully
understand the adv
Well, this is not just about branch prediction, but about "let the
compiler assume the condition is always true and let it eliminate code
that handles other cases".
I /think/ that in C with GCC assume() could be implemented (for release
mode, otherwise it's just like assert()) like
#define
Am 04.08.2014 02:28, schrieb Andrei Alexandrescu:
On 8/3/14, 3:35 PM, Daniel Gibson wrote:
Am 04.08.2014 00:15, schrieb Andrei Alexandrescu:
That said, should we proceed carefully about realizing this advantage?
Of course; that's a given. But I think it's very important to fully
understand the
Am 04.08.2014 02:30, schrieb Andrei Alexandrescu:
On 8/3/14, 4:01 PM, Timon Gehr wrote:
On 08/04/2014 12:15 AM, Andrei Alexandrescu wrote:
I suspect it is one of those ideas of Walter's that has consequences
that reach further than anyone foresees. but that's OK, because it
is fundamentally
Am 04.08.2014 03:02, schrieb Andrei Alexandrescu:
On 8/3/14, 5:40 PM, Daniel Gibson wrote:
Ok, so you agree that there's a downside and code (that you consider
incorrect, but that most probably exists and works ok so far) will
*silently* break (as in: the compiler won't tell you about it).
Yes
Am 04.08.2014 03:17, schrieb John Carter:
As you get...
* more and more optimization passes that rely on asserts,
* in particular pre and post condition asserts within the standard
libraries,
* you are going to have flocks of user code that used to compile without
warning
* and ran without any k
Am 06.08.2014 00:17, schrieb Idan Arye:
On Tuesday, 5 August 2014 at 21:10:25 UTC, Tofu Ninja wrote:
Can you explain the utility of both of them? I am not big into
functional programming so I am not seeing it.
The purpose of `bindTo` is to emulate the `let` expressions found in
many functional
Am 11.08.2014 13:02, schrieb "Ola Fosheim Grøstad"
":
I think dataflow in combination with transactional memory (Haswell and
newer CPUs) could be a killer feature.
FYI: Intel TSX is not a thing anymore, it turned out to be buggy and is
disabled by a microcode update now:
http://techreport.co
Am 15.08.2014 22:27, schrieb Francesco Cattoglio:
On Friday, 15 August 2014 at 19:53:28 UTC, Walter Bright wrote:
Currently, D supports:
1. C++ function name mangling
2. C++ namespace name mangling
3. C++ class field and vtbl[] layout
4. C++ function calling conventions
But what is missing is
44 matches
Mail list logo
