Re: C++ vs D aggregates
Dejan Lekic Wrote: Do D2 aggregates behave the same, or are there notable differences? D restricts usage to static initializers only, C++ doesn't have this limitation.
Re: DMD semantic passes overview?
On 2011-12-02 19:01, Nick Sabalausky wrote: I don't suppose there's any information out there on how DMD's sematic passes work? (esp, regarding types, forward reference resolution and DSymbol::scope as used by AggregateDeclaration, but I suppose getting that specific might be asking too much). I've been digging through the code, and so far what I've been able to grok is that there's theree passes (semantic, semantic2 and semantic3), each node in the AST tries to run the (same) semantic pass for it's own members and for anything they reference, and during the first pass some stuff gets deferred to right after the first pass. I'll keep digging though, but any help would be, umm, helpful :) You can always run DMD with the verbose option which will give you some idea of what DMD does. But you might already figured out that. -- /Jacob Carlborg
Why is align() on structures not allowed within unit-test code blocks?
Is there a good reason why align() applied to structure definitions is not
allowed on the struct definition line within unit-test code blocks?
E.g.:
unittest {
align(1) struct Foo {
charc;
int i;
}
void Bar() {
Foo f;
}
}
int main() {
return 0;
}
fails to compile. The error message is:
found 'align' instead of statement
The error message is the same for both DMD and GDC.
If you take the align(1) out it compiles OK.
If you move the structure definition out of the unit-test block but leave the
align(1) in place it compiles OK.
If you put the align(1) on each member variable definition instead of the
struct line it compiles OK.
If the structure type is only used within the unit-test code then I would think
it ought to be possible to define it (including it's alignment attribute)
within that unit-test code block.
Re: C++ vs D aggregates
On 12/04/2011 12:00 PM, Kagamin wrote:
Dejan Lekic Wrote:
Do D2 aggregates behave the same, or are there notable differences?
D restricts usage to static initializers only, C++ doesn't have this limitation.
This works:
struct S{int x;}
void main(){
int a;
S x = {a};
}
What does not?
Re: Why is align() on structures not allowed within unit-test code blocks?
On 12/04/2011 03:01 PM, GrahamC wrote:
Is there a good reason why align() applied to structure definitions is not
allowed on the struct definition line within unit-test code blocks?
E.g.:
unittest {
align(1) struct Foo {
char c;
int i;
}
void Bar() {
Foo f;
}
}
int main() {
return 0;
}
fails to compile. The error message is:
found 'align' instead of statement
The error message is the same for both DMD and GDC.
If you take the align(1) out it compiles OK.
If you move the structure definition out of the unit-test block but leave the
align(1) in place it compiles OK.
If you put the align(1) on each member variable definition instead of the
struct line it compiles OK.
If the structure type is only used within the unit-test code then I would think
it ought to be possible to define it (including it's alignment attribute)
within that unit-test code block.
The reason is that it is parsed as function-local and that DMD's parser
for some strange reason uses different grammar rules for declarations
when inside a function body. You could maybe file a bug report.
A possible workaround is to take the declaration out of the unittest
block and wrap it into a version(unittest) block like this:
version(unittest) {
align(1) struct Foo {
char c;
int i;
}
}
unittest {
void Bar() {
Foo f;
}
}
int main() {
return 0;
}
It invades the namespace of the module when compiling with -unittest though.
Re: C++ vs D aggregates
On 03-12-2011 20:14, Dejan Lekic wrote: I recently stumbled on this thread: http://stackoverflow.com/ questions/5666321/what-is-assignment-via-curly-braces-called-and-can-it- be-controlled The important part is this: 8 - begin - The Standard says in section §8.5.1/1, An aggregate is an array or a class (clause 9) with no user-declared constructors (12.1), no private or protected non-static data members (clause 11), no base classes (clause 10), and no virtual functions (10.3). And then it says in §8.5.1/2 that, When an aggregate is initialized the initializer can contain an initializer-clause consisting of a brace-enclosed, comma-separated list of initializer-clauses for the members of the aggregate, written in increasing subscript or member order. If the aggregate contains subaggregates, this rule applies recursively to the members of the subaggregate. 8 - end - Do D2 aggregates behave the same, or are there notable differences? Does TDPL have a chapter on this? I think my searching skills may be failing me. - Alex
Re: Why is align() on structures not allowed within unit-test code
Timon Gehr: The reason is that it is parsed as function-local and that DMD's parser for some strange reason uses different grammar rules for declarations when inside a function body. You could maybe file a bug report. http://d.puremagic.com/issues/show_bug.cgi?id=7065 Bye, bearophile
Re: Compile time metaprogramming
On Sat, 03 Dec 2011 10:26:09 +0100, David Nadlinger s...@klickverbot.at wrote: On 12/3/11 1:43 AM, simendsjo wrote: On 02.12.2011 23:28, Jonathan M Davis wrote: There's also been at least a couple of cases where people have worked on unit libraries and discussed them in the main newsgroup, but so far, nothing has gotten to the point where it's been reviewed for introduction to Phobos, and I don't know if any of those projects is still alive. It would definitely be an asset though. I seem to remember someone wanting to work on a library for GSoC and that he would work on it even if it wasn't accepted. I might remember wrong, and the person might have left the project. That was Cristi Cobzarenco, but he then proposed a different project, linear algebra stuff [1], which he ended up working on because I already had a more or less working implementation of an units library lying around: [2]. I posted my project to the NG, and there seemed to actually be two or three people interested in it, but I didn't submit it to formal review yet, because it sometimes breaks in interesting ways due to compiler bugs (issue 3467 [3] and the likes), and I had enough work to do for my own GSoC project anyway. I, for one, wholeheartedly support the inclusion of this in Phobos. Oh, and Walter's reply to #3467 is scary. I hope he comes around to seeing he's not making sense.
Re: writef %d of string
On 02/12/2011 03:19, bearophile wrote: Stewart Gordon: It's perfectly legal code, If that code is legal, then in my opinion it's the rules of the language that are wrong and in need to be changed :-) You mean all programming languages should support CTFE for argument validation? What if the format string isn't even known at compile time in the first place? Some C(++) compilers understand printf and will warn if the format string doesn't match the arguments, but even this is rare AIUI. I don't know what 'AIUI' means. As I understand it. http://www.acronymfinder.com/ is your friend. And GCC (and Clang too) do it, so it's not a rare thing. I meant rare among the world's various C compilers. Are you going by usage statistics? To enforce well-formed format strings at compile time would require it to be made a language builtin. Or just a built-in rule, as in GCC. What do you mean by a built-in rule exactly? Or maybe template metaprogramming can do it. Of course. It's not hard to create something like this: writelnt!%d %f(53, 1.55); But I think you need a D compiler able to remove unneeded template instantiations from the binary, to avoid bloat. snip Maybe there's a way that the template instances can be very small, delegating most of the work to non-templated functions. Stewart.
Re: writef %d of string
Stewart Gordon: You mean all programming languages should support CTFE for argument validation? This is not necessary, and it's not sufficient... What if the format string isn't even known at compile time in the first place? In this case the format string validation is done at run-time. It's opportunistic static typing. And it's better than leaving all the tests at run-time. In a dynamically typed language I accept format strings to be verified at run-time. In a compiled language I want some of advantages of static typing, where possible. http://www.acronymfinder.com/ is your friend. Or even better, reduce the usage of uncommon acronyms in normal communications :-) I meant rare among the world's various C compilers. Are you going by usage statistics? In the end D wants to be better than C and C compilers. What do you mean by a built-in rule exactly? In GCC there is a hard-coded routine that tests (or tries to) the correctness of format strings known at compile-time. Maybe there's a way that the template instances can be very small, delegating most of the work to non-templated functions. This is easy to do, just call the same runtime function after the compile-time test done in the template :-) But DMD probably has to learn to better remove unnecessary template instances from the resulting binary. Walter has discussed this topic a bit several times. Bye, bearophile
