Is there a function in phobos which will return a Tuple of a
Type's members, for use in a foreach statement?
I need this for collecting info on all Type Members's User
Attributes. Currently, I have written a recursive function which
does this, but I'm looking for a more elegant solution.
bearophile wrote:
I have not fully understood the problem, but have you tried
[__traits(getAttributes, m)] ?
yes, that's not really relevant to my problem. 'm' in your
example, can't be read at compile time, because
__traits(derivedMembers, ..) returns a Tuple of strings, not
Symbols. I can
Ali Çehreli wrote:
The following program produces this output:
[...code...]
Awesome! Thanks, I wasn't expecting it to actually be as easy as
that. I tried all sort of difference combinations with
__traits(allMembers, ..) but it looks like I just needed to move
it into the foreach loop
Okay, thanks for the help folks.
My goal is this, to have an XML file:
!-- scene.xml --
scene
object class=Person event=greet/
/scene
and a D file:
module person;
import std.stdio;
class Person
{
void greet() {
writeln(hello);
}
}
and then another D file:
@Adam D. Ruppe
Damn, I was afraid you where going to say to do something like
that. It doesn't really work for what I'm thinking about, but
thanks for confirming that my original code can't work.
I have an alternative in mind, but first, is there a possible way
for a Super class to ask
Sean Cavanaugh wrote:
Some reference:
C++ simd intrinsic for dot product (requires SSE 4.1, very
modern)
_mm_dp_ps
Good to know, thanks!
C++ simd instrinsic for horizontal add (requires SSE3, also
reasonably modern)
_mm_hadd_ps
Awesome, I see XMM.HADDPS (amoung others) in core.simd
I'm trying to write a Cross and Dot function using
core.simd.float4 and DMD
The C++ code looks like:
from:
http://fastcpp.blogspot.com/2011/04/vector-cross-product-using-sse-code.html
inline __m128 CrossProduct(__m128 a, __m128 b)
{
return _mm_sub_ps (
_mm_mul_ps (
On a side note, if I run the simple code:
void16 a = 0, b = 0;
void16 r = __simd(XMM.PSHUFB, a, b);
writeln(r.array);
I get the following error:
Internal error: e2ir.c 3817
Sean Kelly wrote:
It should be made to work on Linux. Interested in submitting a
pull request? The function is in src/rt/dmain2.d.
alexrp beat me to it:
https://github.com/D-Programming-Language/dmd/pull/941
https://github.com/D-Programming-Language/druntime/pull/211
I should not I've only tried with DMD (so far). I'll try with LDC
and GDC in the morning.
Is it possible?
I get a message rt_loadLibrary() not supported on Posix when I
try. Is there something I'm doing wrong or is loading shared
libraries not supported at all on Linux systems?
thanks.
On Thursday, 10 May 2012 at 11:11:14 UTC, Jacob Carlborg wrote:
On 2012-05-10 09:09, F i L wrote:
Is it possible?
I get a message rt_loadLibrary() not supported on Posix when
I try. Is
there something I'm doing wrong or is loading shared libraries
not
supported at all on Linux systems
I'm trying to store arbitrary D object information in an XML
file, then load and create the objects it represents
programmatically. For example, I have the file test.xml, which
looks like:
!-- test.xml --
scene
main.Person name=Philip age=24
!-- nothing yet --
asserts aren't compiled into release builds (except
assert(false)). So, if the loop only contains asserts, the
compiler *should* be able to strip out the loop altogether. I
don't know if DMD actually does that, though.
Or you could use debug statements:
debug foreach (x; largeArray) {
Forums are messing up, so I'll try and respond in sections.
/test
Actually, all of this discussion has made me think that having a
compiler flag to change FP values to zero as default would be a
good idea.
Basically my opinion is largely influenced by a couple things.
That is:
- I believe a lot of good programmers are used to using zero for
default.
On Monday, 16 April 2012 at 03:25:15 UTC, bearophile wrote:
F i L:
I should be able to tackle something like adding a compiler
flag to default FP variables to zero. If I write the code,
would anyone object to having a flag for this?
I strongly doubt Walter Andrei will accept
On Monday, 16 April 2012 at 04:05:35 UTC, Ary Manzana wrote:
On 4/16/12 12:00 PM, F i L wrote:
On Monday, 16 April 2012 at 03:25:15 UTC, bearophile wrote:
F i L:
I should be able to tackle something like adding a compiler
flag to
default FP variables to zero. If I write the code, would
Jonathan M Davis wrote:
No. You always have a bug if you don't initialize a variable to
the value that
it's supposed to be. It doesn't matter whether it's 0, NaN,
527.1209823, or
whatever. All having a default value that you're more likely to
use means is
that you're less likely to have to
On Saturday, 14 April 2012 at 06:43:11 UTC, Manfred Nowak wrote:
F i L wrote:
It sounds like circular reasoning.
Several considerations pressed the design into the current form:
1) always changing output on unchanged input is hard to debug
2) GC needs to be saved from garbage, that looks
On Saturday, 14 April 2012 at 06:29:40 UTC, Ali Çehreli wrote:
On 04/13/2012 09:00 PM, F i L wrote:
default is NaN
Just to complete the picture, character types have invalid
initial values as well: 0xFF, 0x, and 0x for char,
wchar, and dchar, respectively.
Ali
That's
On Saturday, 14 April 2012 at 07:59:25 UTC, Jonathan M Davis
wrote:
On Saturday, April 14, 2012 09:45:57 F i L wrote:
If D doesn't accommodate entering Laymen, how does it expect to
gain popularity in any major way? Efficiency puts D on the map,
convenience is what brings the tourists.
I
Jerome BENOIT wrote:
Why would a compiler set `real' to 0.0 rather then 1.0, Pi,
?
Because 0.0 is the lowest (smallest, starting point, etc..)
numerical value. Pi is the corner case and obviously has to be
explicitly set.
If you want to take this further, chars could even be
On Saturday, 14 April 2012 at 10:38:45 UTC, Silveri wrote:
On Saturday, 14 April 2012 at 07:52:51 UTC, F i L wrote:
On Saturday, 14 April 2012 at 06:43:11 UTC, Manfred Nowak
wrote:
F i L wrote:
4) use hardware signalling to overcome some of the limitations
impressed by 3).
4) I have no idea
dennis luehring wrote:
what does make float default to 0.0 better - does it just feel
better?
Not just. It's consistent with Int types, therefor easier for
newbs to pick up since all numeric value types behave the same.
I even think char should default to a usable value as well. Most
On Saturday, 14 April 2012 at 12:48:01 UTC, Andrej Mitrovic wrote:
On 4/14/12, bearophile bearophileh...@lycos.com wrote:
Having a variable not initialized is a common source of bugs.
I'm going to argue that this was true for C/C++ but is much
less true
for D. One benefit of having integrals
On Saturday, 14 April 2012 at 15:44:46 UTC, Jerome BENOIT wrote:
On 14/04/12 16:47, F i L wrote:
Jerome BENOIT wrote:
Why would a compiler set `real' to 0.0 rather then 1.0, Pi,
?
Because 0.0 is the lowest (smallest, starting point, etc..)
quid -infinity ?
The concept of zero
On Saturday, 14 April 2012 at 15:35:13 UTC, Andrej Mitrovic wrote:
On 4/14/12, F i L witte2...@gmail.com wrote:
This is exactly what I'm trying to get at.
Anyway it's not all bad news since we can use a workaround:
struct Float {
float payload = 0.0;
alias payload this;
}
void main
On Saturday, 14 April 2012 at 17:30:19 UTC, Andrej Mitrovic wrote:
On 4/14/12, F i L witte2...@gmail.com wrote:
a Hack though, since it doesn't work with 'auto'.
What do you mean?
Only that:
auto f = 1.0f; // is float not Float
On Saturday, 14 April 2012 at 18:02:57 UTC, Andrej Mitrovic wrote:
On 4/14/12, F i L witte2...@gmail.com wrote:
auto f = 1.0f; // is float not Float
UFCS in 2.059 to the rescue:
struct Float
{
float payload = 0.0;
alias payload this;
}
@property Float f(float val) { return
On Saturday, 14 April 2012 at 18:07:41 UTC, Jerome BENOIT wrote:
On 14/04/12 18:38, F i L wrote:
On Saturday, 14 April 2012 at 15:44:46 UTC, Jerome BENOIT
wrote:
On 14/04/12 16:47, F i L wrote:
Jerome BENOIT wrote:
Why would a compiler set `real' to 0.0 rather then 1.0, Pi,
?
Because
From the FaQ:
NaNs have the interesting property in that whenever a NaN is
used as an operand in a computation, the result is a NaN.
Therefore, NaNs will propagate and appear in the output
whenever a computation made use of one. This implies that a NaN
appearing in the output is an
So it's what I thought, the only reason is based on a faulty
premise, IMO.
Jonathan M Davis wrote:
Types default to the closest thing that they have to an invalid
value so that
code blows up as soon as possible if you fail to initialize a
variable to a
proper value and so that it fails
On Saturday, 14 April 2012 at 05:19:38 UTC, dennis luehring wrote:
Am 14.04.2012 06:00, schrieb F i L:
struct Foo {
int x, y;// ready for use.
float z, w; // messes things up.
float r = 0; // almost always...
}
how often in your code is 0 or 0.0 the real
Timon Gehr wrote:
First of all, you don't really need the debug statements,
assertions are stripped from -release'd code anyway.
The assertions in the function body are not part of the
function interface. (eventually, contracts can be on function
declarations lacking a function body)
Why/where should I use contracts vs debug statements? Is it
completely arbitrary? If so, I wonder if contracts syntax is even
needed:
int foo(int bar)
in
{
assert(bar != 0);
}
body
{
return bar + 1;
}
The thing I like more about debug statements, is that I
Given the code, test.d:
import std.stdio;
export void test()
{
writeln(Test);
}
compiled with: # dmd -lib -H test.d
I end up with test.lib (good so far), and test.di:
import std.stdio;
export void test()
{
writeln(Test);
}
wtf? why is test() fully
Jonathan M Davis wrote:
http://stackoverflow.com/questions/7720418/whats-not-in-an-interface-file
I see. Thanks again, Jonathan. I know this has been said before,
but these sorts of explanations really should be part of the
documentation.
39 matches
Mail list logo
