Re: __traits(compiles,...) <=> ? is(typeof(...))
On 29/10/12 12:03, Jonathan M Davis wrote: On Monday, October 29, 2012 11:42:59 Zhenya wrote: Hi! Tell me please,in this code first and second static if,are these equivalent? with arg = 1, __traits(compiles,"check(arg);") = true, is(typeof(check(arg))) = false. In principle, is(typeof(code)) checks whether the code in there is syntatically and semantically valid but does _not_ check whether the code actually compiles. For instance, it checks for the existence of the symbols that you use in it, but it doesn't check whether you can actually use the symbol (e.g. it's private in another module). Not even that. It checks if the expression has a type. That's all. The expression has be syntactically valid or it won't compile at all. But inside is(typeof()) it is allowed to be semantically invalid. I started using is(typeof()) as a check for compilability, and other people used the idea as well. But it only works if you can convert "compilable" into "has a type".
Interesting C header translation problem
Came across this:
#ifdef __GNUC__
#define PACKED __attribute__((packed))
#else
#define PACKED
#endif
typedef enum {
// Lots o' stuff
} PACKED my_enum_t;
typedef struct {
// Lots o' stuff
const void *ptr;
} PACKED my_struct_t;
There are a handful of interesting (read: annoying ;) ) problems that
are (*ahem*) packed into that:
1. Totally different ABI based on whether or not the **C** side was
compiled with a GNU compiler.
2. How to do conditional "align(1)" with minimal ugliness.
3. WTF does it even mean to have a packed enum?
4. Having a pointer at the end of a packed struct is asking for trouble
according to D's docs ("The garbage collector assumes that pointers and
references to gc allocated objects will be on size_t byte boundaries.
If they are not, undefined behavior will result.") Probably nothing
that can be done about this one, though, other than just expect the
user to be careful.
5. From what I can gather from GCC and DMD docs, it sounds like
__attribute__((packed)) means:
align(1) struct my_struct_t{
align(1):
// blah, blah, members
}
BUT, are there any other...ummm..."fun" surprises that could pop up and
need to be taken into account?
6. The easy one: I'm pretty sure "const void *ptr" translates to
"const(void)* ptr", right?
For the moment, my "solution" is to just include a note saying "Don't
compile the *.c files with __GNUC__ defined" ;) But what would be the
best realistic way to handle these issues? Any established practices?
Re: How to place char* of stringZ to ubyte[]?
On Mon, 29 Oct 2012 19:50:57 +0100
"bearophile" wrote:
> denizzzka:
>
> > I am trying to send to remote host utf8 text with zero byte at
> > end (required by protocol)
>
> What if your UTF8 string coming from D already contains several
> zeros?
>
If you need to send a string with an embedded null through a
null-terminated-string protocol, then you're pretty much screwed anyway.
FWIW ;)
('Course, the embedded nulls could be stripped if they're not actually
important.)
Re: Interesting C header translation problem
On 30-10-2012 10:41, Nick Sabalausky wrote:
Came across this:
#ifdef __GNUC__
#define PACKED __attribute__((packed))
#else
#define PACKED
#endif
typedef enum {
// Lots o' stuff
} PACKED my_enum_t;
typedef struct {
// Lots o' stuff
const void *ptr;
} PACKED my_struct_t;
There are a handful of interesting (read: annoying ;) ) problems that
are (*ahem*) packed into that:
1. Totally different ABI based on whether or not the **C** side was
compiled with a GNU compiler.
Absolutely fucking horrible API design. These matters are, if anything,
related to the system ABI, not the compiler ABI. Making the layout
depend on the compiler ABI makes any sort of sane interoperability with
the API from non-C languages virtually impossible to do reliably.
2. How to do conditional "align(1)" with minimal ugliness.
I can't think of anything that doesn't involve repetitive code or
mixins. But worse than that, it's not like you can detect what compiler
was used to build some random library.
3. WTF does it even mean to have a packed enum?
Nothing.
4. Having a pointer at the end of a packed struct is asking for trouble
according to D's docs ("The garbage collector assumes that pointers and
references to gc allocated objects will be on size_t byte boundaries.
If they are not, undefined behavior will result.") Probably nothing
that can be done about this one, though, other than just expect the
user to be careful.
More generally, a pointer that is not aligned on a 4-byte (on 32-bit
systems) or 8-byte (on 64-bit systems) boundary will not be picked up by
the GC. This can happen in many situations, e.g.:
struct S
{
align (1):
byte b;
int* p;
byte b;
byte b;
int* p;
}
And many other possible layouts.
The best way to deal with terrible APIs in this regard is to use
GC.addRoot() to keep such pointers alive. This does of course mean that
you have to use GC.removeRoot() to make it collectable again...
5. From what I can gather from GCC and DMD docs, it sounds like
__attribute__((packed)) means:
align(1) struct my_struct_t{
align(1):
// blah, blah, members
}
BUT, are there any other...ummm..."fun" surprises that could pop up and
need to be taken into account?
It only implies the inner align, not the outer one. GCC has an aligned
attribute on variables that can be used to get the effect of the outer
one. But no, no real surprises or gotchas here.
6. The easy one: I'm pretty sure "const void *ptr" translates to
"const(void)* ptr", right?
Yep.
For the moment, my "solution" is to just include a note saying "Don't
compile the *.c files with __GNUC__ defined" ;) But what would be the
best realistic way to handle these issues? Any established practices?
Honestly, I don't know. I would go stab the original API designers in
the face and tell them to clean up their mess.
--
Alex Rønne Petersen
a...@lycus.org
http://lycus.org
Callbacks and interfacing with C
Ok, a C function pointer like this:
struct MyStruct{
int (*foo)(int);
};
Translates to D as this:
struct MyStruct{
int function(int) foo;
}
But what about calling conventions? There isn't any "int extern(C)
function(int)" is there? Not sure if that would even make sense.
So do you just make sure that whatever func you assign to it is an
extern(C)? Or something else?
Re: Callbacks and interfacing with C
On 30-10-2012 11:13, Nick Sabalausky wrote:
Ok, a C function pointer like this:
struct MyStruct{
int (*foo)(int);
};
Translates to D as this:
struct MyStruct{
int function(int) foo;
}
But what about calling conventions? There isn't any "int extern(C)
function(int)" is there? Not sure if that would even make sense.
So do you just make sure that whatever func you assign to it is an
extern(C)? Or something else?
You generally do it this way:
alias extern (C) int function(int) MyFn;
struct MyStruct {
MyFn foo;
}
This makes sure the calling convention is correct. In general, calling
convention is part of both the function signature and function pointer
type - function pointers just default to extern (D).
--
Alex Rønne Petersen
a...@lycus.org
http://lycus.org
Re: Interesting C header translation problem
On Tue, 30 Oct 2012 11:05:28 +0100
Alex Rønne Petersen wrote:
> On 30-10-2012 10:41, Nick Sabalausky wrote:
> > Came across this:
> >
> > #ifdef __GNUC__
> > #define PACKED __attribute__((packed))
> > #else
> > #define PACKED
> > #endif
> >
> > typedef enum {
> > // Lots o' stuff
> > } PACKED my_enum_t;
> >
> > typedef struct {
> > // Lots o' stuff
> > const void *ptr;
> > } PACKED my_struct_t;
> >
> > There are a handful of interesting (read: annoying ;) ) problems
> > that are (*ahem*) packed into that:
> >
> > 1. Totally different ABI based on whether or not the **C** side was
> > compiled with a GNU compiler.
>
> Absolutely fucking horrible API design. These matters are, if
> anything, related to the system ABI, not the compiler ABI. Making the
> layout depend on the compiler ABI makes any sort of sane
> interoperability with the API from non-C languages virtually
> impossible to do reliably.
>
Yea, sounds like the best thing after all is to just say "Just don't
compile the C side that way."
> >
> > 2. How to do conditional "align(1)" with minimal ugliness.
>
> I can't think of anything that doesn't involve repetitive code or
> mixins. But worse than that, it's not like you can detect what
> compiler was used to build some random library.
>
It would require repeating or mixing in the entire body wouldn't it? I
didn't think there was any way to mixin just an attribute or
otherwise get the same effect, but thought I'd check.
> [snip #3-6]
I see, thanks.
>
> >
> > For the moment, my "solution" is to just include a note saying
> > "Don't compile the *.c files with __GNUC__ defined" ;) But what
> > would be the best realistic way to handle these issues? Any
> > established practices?
> >
>
> Honestly, I don't know. I would go stab the original API designers in
> the face and tell them to clean up their mess.
>
lol :) I think this one was actually designed to be usable in low-end
microcontrollers (nanopb:
Re: Callbacks and interfacing with C
On Tue, 30 Oct 2012 11:15:55 +0100
Alex Rønne Petersen wrote:
> On 30-10-2012 11:13, Nick Sabalausky wrote:
> > Ok, a C function pointer like this:
> >
> > struct MyStruct{
> > int (*foo)(int);
> > };
> >
> > Translates to D as this:
> >
> > struct MyStruct{
> > int function(int) foo;
> > }
> >
> > But what about calling conventions? There isn't any "int extern(C)
> > function(int)" is there? Not sure if that would even make sense.
> >
> > So do you just make sure that whatever func you assign to it is an
> > extern(C)? Or something else?
> >
>
> You generally do it this way:
>
> alias extern (C) int function(int) MyFn;
>
> struct MyStruct {
> MyFn foo;
> }
>
> This makes sure the calling convention is correct. In general,
> calling convention is part of both the function signature and
> function pointer type - function pointers just default to extern (D).
>
Hmm, that leads me to another Q:
extern(C): // <-- Note this
alias int function(int) MyFn;
struct MyStruct {
MyFn foo1;
int function(int) foo2;
}
void bar(int function(int) foo3) {...}
Which, if any, of foo1/foo2/foo3 are extern(C)? (I know bar definitely
is.)
Re: Copying with immutable arrays
On 29/10/12 07:19, Ali Çehreli wrote:
On 10/28/2012 02:37 AM, Tobias Pankrath wrote:
> the struct
> SwA from above does neither correspond to SA nor to SB, it's imo more
> like SC:
>
> struct SC {
> immutable(int)* i;
> }
Just to confirm, the above indeed works:
struct SC {
immutable(int)* i;
}
void main()
{
immutable(SC)[] arr1;
SC[] arr2 = arr1.dup;// compiles
}
> Now a copy would do no harm, everything that was immutable in the source
> and is still accessable from the copy is immutable, too. Any reason
> (despite of implemenational issues) that this is not how it works?
Getting back to the original code, the issue boils down to whether we
can copy imutable(string[]) to string[]:
import std.stdio;
struct SwA {
string[] strings;
}
void main()
{
immutable(SwA)[] arr1;
writeln(typeid(arr1[0].strings));
}
The program prints the following:
immutable(immutable(immutable(char)[])[])
Translating the innermost definition as string:
immutable(immutable(string)[])
Let's remove the struct and look at a variable the same type as the member:
immutable(string[]) imm = [ "a", "b" ];
writeln(typeid(imm));
The typeid is the same:
immutable(immutable(immutable(char)[])[])
So we can concentrate on 'imm' for this exercise. This is the same
compilation error:
immutable(string[]) imm = [ "aaa", "bbb" ];
string[] mut = imm; // <-- compilation ERROR
If that compiled, then both 'imm' and 'mut' would be providing access to
the same set of strings. But the problem is, 'mut' could replace those
strings (note that it could not modify the characters of those strings,
but it could replace the whole string):
mut[0] = "hello";
That would effect 'imm' as well. ('imm' is the equivalent of SwA.strings
from your original code.)
Ali
Awesome answer, it's these kinds of responses that make the D community
so great.
Re: Callbacks and interfacing with C
Nick Sabalausky: Which, if any, of foo1/foo2/foo3 are extern(C)? (I know bar definitely is.) A general comment: if you are not sure of the answer, then the programmer that will read your code will probably have similar problems. So in such cases it's better to try to not write that code. Bye, bearophile
Re: How to place char* of stringZ to ubyte[]?
denizzzka: I am concerned about the extra allocations of temp arrays. here is it, or not? compiler optimizes it? There is one allocation, and usually the D compilers can't optimize it away. In my case it does not matter but for the future I would like to know how it can be implemented without overhead. If you don't want overhead you need some static buffer, bigger than any possible string, and to copy data on it and slice it as needed. Otherwise appending one null char risks allocating. If you append it in-place in the original string the risk of allocations is lower, but not zero. byte[] data = [0]; Why not "byte[] data;" ? I was thinking about keeping the protocol invariant, but you are right, it's probably useless. A null is enough to denote an empty string. alias this = data; // new syntax What difference between this syntax and "alias Something this"? There's no difference. Instead of focusing on other syntaxes that actually do something useful (like [$] to define fixed-size arrays automatically, or somehting else), Walter has accepted to add one more way to do the same thing. I don't like this change. Bye, bearophile
DFL Button.backColor
Hi!
Explain me please,why this code doesn't work
import dfl.all;
void main()
{
auto form = new Form;
auto button = new Button;
button.backColor = Color(0,0,0);
button.foreColor = Color(0,0,0);
form.controls.add(button);
Application.run(form);
}
It displays usualy button in system style,but should display
black button
finding composed structs
Please help me with any flaws in logic or understanding:
For any struct S, '==' means either bitwise comparison or a call
to opEquals of S if it exists.
If S has no (dynamic arrays, associative arrays, pointers, or
class references as members (recursively)) then bitwise compare
is equivalent to a deep compare.
But if you do have any of those and you want true deep comparison
semantics, you must implement a correct opEquals at the first
introduction of those members, and carry that forward through all
composed structures to S.
struct A { int x = 3; }
struct B { A a; }
struct C { B b; }
struct D { C c; }
So in this case, D has deep equality semantics for ==.
But change A to struct A { string x; } and the deep equality
semantics for D disappears. To get it back an opEquals must be
correctly implemented in A, B, C, and D.
Is this accurate?
If true and not an issue, people must not be relying too much on
deep equality semantics like this. But how else can you find
things?
Thanks
Dan
Re: DFL Button.backColor
On Tuesday, 30 October 2012 at 13:34:21 UTC, Zhenya wrote:
Hi!
Explain me please,why this code doesn't work
import dfl.all;
void main()
{
auto form = new Form;
auto button = new Button;
button.backColor = Color(0,0,0);
button.foreColor = Color(0,0,0);
form.controls.add(button);
Application.run(form);
}
It displays usualy button in system style,but should display
black button
Oh,sorry,I should check it
http://wiki.dprogramming.com/Dfl/BugList
Thank you:)
Re: finding composed structs
On Tuesday, 30 October 2012 at 15:26:22 UTC, Dan wrote:
Please help me with any flaws in logic or understanding:
For any struct S, '==' means either bitwise comparison or a
call to opEquals of S if it exists.
If S has no (dynamic arrays, associative arrays, pointers, or
class references as members (recursively)) then bitwise compare
is equivalent to a deep compare.
But if you do have any of those and you want true deep
comparison semantics, you must implement a correct opEquals at
the first introduction of those members, and carry that forward
through all composed structures to S.
struct A { int x = 3; }
struct B { A a; }
struct C { B b; }
struct D { C c; }
So in this case, D has deep equality semantics for ==.
But change A to struct A { string x; } and the deep equality
semantics for D disappears. To get it back an opEquals must be
correctly implemented in A, B, C, and D.
Is this accurate?
If true and not an issue, people must not be relying too much
on deep equality semantics like this. But how else can you find
things?
Thanks
Dan
You are correct. But I argue and I think TDPL says the same, that
== should compare all members and is should bitwise compare.
However that is currently not the case.
Re: UTF-8 strings and endianness
On Monday, 29 October 2012 at 15:22:39 UTC, Adam D. Ruppe wrote: UTF-8 isn't affected by endianness. If this is true why does the BOM have marks for big and little endian? http://en.wikipedia.org/wiki/Byte_order_mark#Representations_of_byte_order_marks_by_encoding
Re: UTF-8 strings and endianness
On Tuesday, 30 October 2012 at 17:12:41 UTC, Jesse Phillips wrote: On Monday, 29 October 2012 at 15:22:39 UTC, Adam D. Ruppe wrote: UTF-8 isn't affected by endianness. If this is true why does the BOM have marks for big and little endian? http://en.wikipedia.org/wiki/Byte_order_mark#Representations_of_byte_order_marks_by_encoding UTF8 has only one?
Re: Callbacks and interfacing with C
On 10/30/12, Nick Sabalausky wrote:
> Which, if any, of foo1/foo2/foo3 are extern(C)? (I know bar definitely
> is.)
All of them.
void main()
{
pragma(msg, MyFn);
pragma(msg, typeof(MyStruct.foo2));
pragma(msg, typeof(bar));
}
extern (C) int function(int)
extern (C) int function(int)
extern (C) void(extern (C) int function(int) foo3)
extern (C) int function(int)
extern (C) int function(int)
extern (C) void(extern (C) int function(int) foo3)
It's because extern(C): leaks everywhere, whether on purpose or not.
It can be a benefit for writing shorter code, but when reading such
code it's easy to forget to check for an extern(C): declaration at the
top and just wrongly assume that it's all extern(D).
Re: Threading Question
On Oct 25, 2012, at 11:18 PM, Jacob Carlborg wrote: > On 2012-10-26 01:18, Sean Kelly wrote: >> On Oct 25, 2012, at 4:12 PM, Alex Rønne Petersen wrote: >>> >>> What's used on OS X? I forget... >> >> The method used is similar to how GC works on Windows--there's a kernel call >> that can be used to explicitly suspend a thread. I can't remember the >> function name offhand though. > > The Posix functions weren't working properly? The semaphore implementation for OSX is not signal-safe. Originally, druntime used the signal approach on OSX and had deadlock issues in the signal handler (OSX semaphores wrap a global mutex to obtain something from a shared pool). Also, semaphores on OSX are just ridiculously slow. The current method for suspending and scanning threads on OSX is much faster. I wish Posix in general had the same feature. Using signals is really a hack. It may be worth dropping use of SIGUSR1/2 in favor of the realtime signals as well, since SIGUSR1/2 are in pretty common use.
Re: UTF-8 strings and endianness
10/30/2012 5:17 PM, Tobias Pankrath пишет: On Tuesday, 30 October 2012 at 17:12:41 UTC, Jesse Phillips wrote: On Monday, 29 October 2012 at 15:22:39 UTC, Adam D. Ruppe wrote: UTF-8 isn't affected by endianness. If this is true why does the BOM have marks for big and little endian? http://en.wikipedia.org/wiki/Byte_order_mark#Representations_of_byte_order_marks_by_encoding UTF8 has only one? Even Wiki knows the simple truth: > Byte order has no meaning in UTF-8, [5] so its only use in UTF-8 is to signal at the start that the text stream is encoded in UTF-8 -- Dmitry Olshansky
Re: Threading Question
On 30-10-2012 19:04, Sean Kelly wrote: On Oct 25, 2012, at 11:18 PM, Jacob Carlborg wrote: On 2012-10-26 01:18, Sean Kelly wrote: On Oct 25, 2012, at 4:12 PM, Alex Rønne Petersen wrote: What's used on OS X? I forget... The method used is similar to how GC works on Windows--there's a kernel call that can be used to explicitly suspend a thread. I can't remember the function name offhand though. The Posix functions weren't working properly? The semaphore implementation for OSX is not signal-safe. Originally, druntime used the signal approach on OSX and had deadlock issues in the signal handler (OSX semaphores wrap a global mutex to obtain something from a shared pool). Also, semaphores on OSX are just ridiculously slow. The current method for suspending and scanning threads on OSX is much faster. I wish Posix in general had the same feature. Using signals is really a hack. It may be worth dropping use of SIGUSR1/2 in favor of the realtime signals as well, since SIGUSR1/2 are in pretty common use. Real time signals as in? -- Alex Rønne Petersen a...@lycus.org http://lycus.org
Re: finding composed structs
On Tuesday, 30 October 2012 at 16:44:02 UTC, Ali Çehreli wrote: There is the following discussion currently on the main D forum: http://forum.dlang.org/thread/iphhuttpkogmfwpuv...@forum.dlang.org That behavior will be changed: http://forum.dlang.org/thread/iphhuttpkogmfwpuv...@forum.dlang.org?page=4#post-k6a30m:24140h:241:40digitalmars.com Interesting, thanks! In reading this and (per Tobias' comment) revisiting TDPL I think my original statement was incomplete and the situation is not as bad as I thought. For any struct S, '==' means either bitwise comparison or a call to opEquals of S if it exists. From TDPL: Objects of struct type can be compared for equality out of the box with == and ! =. Comparison is carried out member by member and yields false if at least two corresponding members in the compared objects are not equal, and true otherwise. So the issue in my example is not a problem with structs in general, but just a bug related to dynamic arrays only. My fear of having to provide opEquals at each level is unwarranted - the compiler will generate good ones for me (except for dynamic arrays until the bug is fixed). I've convinced myself of this in the following example. http://dpaste.dzfl.pl/14649c64 So until this bug is fixed any time I have any dynamic array, including string in struct S, implement opEquals. When the bug is fixed I can remove them. What I didn't realize is that including an opEquals in A will cause generation of opEquals in B,C,D for free (maybe only if called). If this is still off base please let me know. Thanks Dan
Re: crash suggestions
On Monday, 29 October 2012 at 23:02:46 UTC, Ali Çehreli wrote: I wonder whether this bug is related to your case: http://d.puremagic.com/issues/show_bug.cgi?id=5570 After all, you do pass a struct that includes non-integral types. That bug may be it. Ali Thanks for following up and all your answers in general. That bug may be related - but unfortunately I'll have to leave it to the experts to decide - until I learn more. As another follow up: Do you use a debugger? Maybe you use windows and it is different/better for debugging? Ironically the original purpose of pprint was for poor man debugging capabilities. Thanks Dan
Re: Callbacks and interfacing with C
On 2012-10-30 18:44, Andrej Mitrovic wrote:
All of them.
void main()
{
pragma(msg, MyFn);
pragma(msg, typeof(MyStruct.foo2));
pragma(msg, typeof(bar));
}
extern (C) int function(int)
extern (C) int function(int)
extern (C) void(extern (C) int function(int) foo3)
extern (C) int function(int)
extern (C) int function(int)
extern (C) void(extern (C) int function(int) foo3)
It's because extern(C): leaks everywhere, whether on purpose or not.
It can be a benefit for writing shorter code, but when reading such
code it's easy to forget to check for an extern(C): declaration at the
top and just wrongly assume that it's all extern(D).
It doesn't leak into local declarations in a function:
extern (C):
void foo ()
{
alias void function () Foo;
void function (int) a;
auto b = cast(void function ()) a;
pragma(msg, Foo);
pragma(msg, typeof(a));
pragma(msg, typeof(b));
}
void function()
void function(int)
void function()
--
/Jacob Carlborg
Re: UTF-8 strings and endianness
On Tuesday, 30 October 2012 at 17:17:36 UTC, Tobias Pankrath wrote: On Tuesday, 30 October 2012 at 17:12:41 UTC, Jesse Phillips wrote: On Monday, 29 October 2012 at 15:22:39 UTC, Adam D. Ruppe wrote: UTF-8 isn't affected by endianness. If this is true why does the BOM have marks for big and little endian? http://en.wikipedia.org/wiki/Byte_order_mark#Representations_of_byte_order_marks_by_encoding UTF8 has only one? oops, mixed up and thought he just said "UTF isn't ..."
Re: finding composed structs
On Tuesday, 30 October 2012 at 20:16:12 UTC, Tobias Pankrath
wrote:
In the meantime you can use this function template to compare
structs field by field.
bool oneStepEqual(T,F)(ref T lhs, ref F rhs)
if(is(Unqual!T == Unqual!F) && is(T == struct))
{
bool result = true;
foreach(mem; __traits(allMembers, T))
{
static if(!is(typeof(__traits(getMember, T, mem)) ==
function))
{
result = result && (__traits(getMember, lhs, mem)
== __traits(getMember, rhs, mem));
}
}
return result;
}
Beautiful version: http://dpaste.dzfl.pl/2340d73f
Re: finding composed structs
On Tuesday, 30 October 2012 at 19:16:18 UTC, Dan wrote:
So until this bug is fixed any time I have any dynamic array,
including string in struct S, implement opEquals. When the bug
is fixed I can remove them. What I didn't realize is that
including an opEquals in A will cause generation of opEquals in
B,C,D for free (maybe only if called).
If this is still off base please let me know.
Thanks
Dan
In the meantime you can use this function template to compare
structs field by field.
bool oneStepEqual(T,F)(ref T lhs, ref F rhs)
if(is(Unqual!T == Unqual!F) && is(T == struct))
{
bool result = true;
foreach(mem; __traits(allMembers, T))
{
static if(!is(typeof(__traits(getMember, T, mem)) ==
function))
{
result = result && (__traits(getMember, lhs, mem) ==
__traits(getMember, rhs, mem));
}
}
return result;
}
Re: __traits(compiles,...) <=> ? is(typeof(...))
On 10/30/2012 02:53 AM, Jonathan M Davis wrote: On Tuesday, October 30, 2012 02:22:42 Timon Gehr wrote: On 10/30/2012 01:43 AM, Jonathan M Davis wrote: On Tuesday, October 30, 2012 00:29:22 Timon Gehr wrote: On 10/30/2012 12:17 AM, Jonathan M Davis wrote: On Monday, October 29, 2012 23:38:34 Timon Gehr wrote: On 10/29/2012 12:03 PM, Jonathan M Davis wrote: On Monday, October 29, 2012 11:42:59 Zhenya wrote: Hi! Tell me please,in this code first and second static if,are these equivalent? with arg = 1, __traits(compiles,"check(arg);") = true, is(typeof(check(arg))) = false. In principle, is(typeof(code)) checks whether the code in there is syntatically and semantically valid but does _not_ check whether the code actually compiles. For instance, it checks for the existence of the symbols that you use in it, but it doesn't check whether you can actually use the symbol (e.g. it's private in another module). ... Accessing private symbols is always illegal, even within typeof expressions.> As I understand it, that's not supposed to be the case. is(typeof(T.init)) tests for existance not for compilability, and private symbols are fully visible by everything that imports the module that they're in. They're just not accessible. I completely agree that it would be better for them to be hidden as well, but it doesn't work that way right now, and no one has been able to convince Walter that it should. ... That is a different issue. But as long as private symbols are visible, they should work with is(typeof(blah)), because it's testing for their existence, not whether they can be used or not.. - Jonathan M Davis wtf. ??? Nothing else would make sense. As long as private symbols are visible, then typeof should interact with them like it interacts with all other visible symbols. It's not testing for compilability, just existence. It would be very inconsistent for it to consider private variables as non-existent when they're visible. Even if there was no difference between accessibility in an information hiding context and accessibility related to existence of a suitable frame pointer, and therefore, an actual inconsistency, it would not be very clever to fix an inconsistency by generalising the stupid bits instead of the parts that are sane. You are arguing for a "language change" in either case. Everything else considers them to exist. It's just that nothing outside of the module that they're declared in can use them. The _only_ thing that private affects at this point is whether a symbol can be used. So, it should definitely affect __traits(compiles, foo), but since is(typeof(foo)) only cares about existence, not compilability, it should work with private variables. Well, define 'work'. It should evaluate to 'false'. typeof(foo) should not compile if foo refers to a private declaration in a different module. Is that not obvious? Things change if/when private variable become invisible outside of their module, but for now, they're not. I do not care whether they are invisible or not. In fact, this can become an implementation detail. What needs fixing is the symbol conflicts involving inaccessible symbols situation. It is ridiculous.
Re: finding composed structs
On Tuesday, 30 October 2012 at 20:17:06 UTC, Tobias Pankrath wrote: Beautiful version: http://dpaste.dzfl.pl/2340d73f Beautiful indeed. Does the same approach work for generating correct versions of opCmp, assuming arbitrary order by field comparison as ordered in struct? Also hashing? Thanks Dan
Re: finding composed structs
On 10/30/12 4:17 PM, Tobias Pankrath wrote:
On Tuesday, 30 October 2012 at 20:16:12 UTC, Tobias Pankrath
wrote:
In the meantime you can use this function template to compare structs
field by field.
bool oneStepEqual(T,F)(ref T lhs, ref F rhs)
if(is(Unqual!T == Unqual!F) && is(T == struct))
{
bool result = true;
foreach(mem; __traits(allMembers, T))
{
static if(!is(typeof(__traits(getMember, T, mem)) == function))
{
result = result && (__traits(getMember, lhs, mem) ==
__traits(getMember, rhs, mem));
}
}
return result;
}
Beautiful version: http://dpaste.dzfl.pl/2340d73f
Y u no short circuit?
Andrei
Re: finding composed structs
Beautiful version: http://dpaste.dzfl.pl/2340d73f Y u no short circuit? Andrei Left as an exercise to the reader.
Re: finding composed structs
On Tuesday, 30 October 2012 at 21:02:22 UTC, Dan wrote: On Tuesday, 30 October 2012 at 20:17:06 UTC, Tobias Pankrath wrote: Beautiful version: http://dpaste.dzfl.pl/2340d73f Beautiful indeed. Does the same approach work for generating correct versions of opCmp, assuming arbitrary order by field comparison as ordered in struct? Also hashing? Thanks Dan Dunno, if __traits(allMembers...) enforces any order on its result. It looks like DMD does use the definition/declaration order, but that's not in any documentation. The opCmp would depend on this. You could sort the fields by name for a defined order.
Re: finding composed structs
On 10/30/2012 09:16 PM, Tobias Pankrath wrote:
On Tuesday, 30 October 2012 at 19:16:18 UTC, Dan wrote:
So until this bug is fixed any time I have any dynamic array,
including string in struct S, implement opEquals. When the bug is
fixed I can remove them. What I didn't realize is that including an
opEquals in A will cause generation of opEquals in B,C,D for free
(maybe only if called).
If this is still off base please let me know.
Thanks
Dan
In the meantime you can use this function template to compare structs
field by field.
bool oneStepEqual(T,F)(ref T lhs, ref F rhs)
if(is(Unqual!T == Unqual!F) && is(T == struct))
{
bool result = true;
foreach(mem; __traits(allMembers, T))
{
static if(!is(typeof(__traits(getMember, T, mem)) == function))
{
result = result && (__traits(getMember, lhs, mem) ==
__traits(getMember, rhs, mem));
}
}
return result;
}
You might want to shortcut after the first failed comparison.
Re: Threading Question
On Oct 30, 2012, at 11:06 AM, Alex Rønne Petersen wrote: > On 30-10-2012 19:04, Sean Kelly wrote: >> >> >> The semaphore implementation for OSX is not signal-safe. Originally, >> druntime used the signal approach on OSX and had deadlock issues in the >> signal handler (OSX semaphores wrap a global mutex to obtain something from >> a shared pool). Also, semaphores on OSX are just ridiculously slow. The >> current method for suspending and scanning threads on OSX is much faster. I >> wish Posix in general had the same feature. Using signals is really a hack. >> >> It may be worth dropping use of SIGUSR1/2 in favor of the realtime signals >> as well, since SIGUSR1/2 are in pretty common use. >> > > Real time signals as in? SIGRTMIN - SIGRTMAX. Linux supports them, but I'm not sure which other Posix OSes.
Re: Reordered class fields?
On Monday, 22 October 2012 at 11:06:50 UTC, Jacob Carlborg wrote: On 2012-10-22 10:48, bearophile wrote: This page says: http://dlang.org/class.html The D compiler is free to rearrange the order of fields in a class to optimally pack them in an implementation-defined manner. Consider the fields much like the local variables in a function - the compiler assigns some to registers and shuffles others around all to get the optimal stack frame layout. This frees the code designer to organize the fields in a manner that makes the code more readable rather than being forced to organize it according to machine optimization rules. Explicit control of field layout is provided by struct/union types, not classes.< Ok, I didn't know that. The order of the fields is rearranged for packing. Does that affect the tupleof property? The example in http://dlang.org/class.html for Class properties tulpleof seems to implie that the the fields the returned Expression Tuple are arranged in lexical order (i.e., as defined by the programmer in the class definition). Is this always true for classes? What about structs?
