Re: 0 negative loop condition bug or misunderstanding on my part
On 7 March 2012 19:30, H. S. Teoh hst...@quickfur.ath.cx wrote: On 03/06/2012 10:05 PM, ixid wrote: Ah, thank you, so it's wrapping. That seems like a bad idea, what is the benefit to size being unsigned rather than signed? This case would seem like one where allowing negatives is clearly better and more intuitive. Because you don't describe things as -5 metres tall, so you don't describe things as -1024 bytes long. size_t makes sense unsigned because negatives make no sense for size. However, if you cast array.length to an int, it may work, haven't tested it. -- James Miller
Re: 0 negative loop condition bug or misunderstanding on my part
On 03/07/2012 07:05 AM, ixid wrote: Ah, thank you, so it's wrapping. That seems like a bad idea, what is the benefit to size being unsigned rather than signed? This case would seem like one where allowing negatives is clearly better and more intuitive. The problem is not that length is unsigned. The issue is the implicit conversion from signed to unsigned. The right thing would be to disallow signed - unsigned and unsigned - signed implicit conversion unless value range propagation can prove it safe, and to make comparison between signed and unsigned actually work by translating it to more than one machine instruction.
Re: 0 negative loop condition bug or misunderstanding on my part
On 03/07/2012 11:01 AM, Timon Gehr wrote: On 03/07/2012 07:05 AM, ixid wrote: Ah, thank you, so it's wrapping. That seems like a bad idea, what is the benefit to size being unsigned rather than signed? This case would seem like one where allowing negatives is clearly better and more intuitive. The problem is not that length is unsigned. The issue is the implicit conversion from signed to unsigned. The right thing would be to disallow signed - unsigned and unsigned - signed implicit conversion unless value range propagation can prove it safe, and to make comparison between signed and unsigned actually work by translating it to more than one machine instruction. Furthermore, bitwise boolean operators should still accept arguments of arbitrary signedness but the result should implicitly convert to both signed and unsigned.
Re: Raw socket TCP/IP
this might be a little late but could it be that the ethernet header was also needed?
Re: 0 negative loop condition bug or misunderstanding on my part
On 3/7/12, Timon Gehr timon.g...@gmx.ch wrote: The problem is not that length is unsigned. The issue is the implicit conversion from signed to unsigned. You bet. I've once had this hard to spot bug where I've used a call that was something like max(0, min(10, expression)), and this ended up returning a negative int because expression was combining an integer with a .length property of some array (I don't recall the exact call though). It was truly a WTF moment.
Re: Why is std.algorithm.reduce impure?
On Wed, 07 Mar 2012 01:41:22 +0100, Jonathan M Davis jmdavisp...@gmx.com wrote: It really takes very little for something to be impure, and optimizations often do it, because they end up using low-level constructs which aren't pure - some of which could be but aren't and others which probably can't be. Just so this is clear - no optimization of the compiler is going to change the purity of a function. An optimization on the part of the programmer (like using appender) might, though.
Re: Why is std.algorithm.reduce impure?
On 03/07/2012 05:29 PM, Simen Kjærås wrote: On Wed, 07 Mar 2012 01:41:22 +0100, Jonathan M Davis jmdavisp...@gmx.com wrote: It really takes very little for something to be impure, and optimizations often do it, because they end up using low-level constructs which aren't pure - some of which could be but aren't and others which probably can't be. Just so this is clear - no optimization of the compiler is going to change the purity of a function. An optimization on the part of the programmer (like using appender) might, though. Appender must become pure.
Re: duplicate symbol linker errors, my fault or D's?
On Tuesday, 6 March 2012 at 07:29:54 UTC, Jacob Carlborg wrote: Actually the -lib switch might be the answer to one of the incremental compilation problems DMD suffers from. That DMD usually does not output all symbols to all object files which can result in missing symbols when doing incremental compilation. I've heard that the when using the -lib flag DMD will output all symbols to all object files. Hey you know, this could also be a problem because of my original post. Instead of missing symbols, with -lib, you could start to suffer from unintended duplicates, too.
SocketStream exceptions and disconnect handling
Hi all,
I'm trying to handle disconnections transparently on SocketStream. I
thought something like this:
void send(ubyte[] buffer) in { assert(buffer.length 0); }
body {
if (!stream.isAlive) connect();
auto sent = stream.write(buffer);
if (sent == 0)
throw new Exception(Error while writing);
}
But that's impossible because isAlive doesn't exists for SocketStream and I
can't get the underlying socket object. Is that something missing or should
I handle it differently?
Pedro Lacerda
Re: SocketStream exceptions and disconnect handling
My english is bugged, I mean handle reconnections transparently. Sorry.
Pedro Lacerda
2012/3/7 Pedro Lacerda pslace...@gmail.com
Hi all,
I'm trying to handle disconnections transparently on SocketStream. I
thought something like this:
void send(ubyte[] buffer) in { assert(buffer.length 0); }
body {
if (!stream.isAlive) connect();
auto sent = stream.write(buffer);
if (sent == 0)
throw new Exception(Error while writing);
}
But that's impossible because isAlive doesn't exists for SocketStream and
I can't get the underlying socket object. Is that something missing or
should I handle it differently?
Pedro Lacerda
Re: SocketStream exceptions and disconnect handling
On Wed, 07 Mar 2012 17:29:25 -, Pedro Lacerda pslace...@gmail.com
wrote:
2012/3/7 Pedro Lacerda pslace...@gmail.com
Hi all,
I'm trying to handle disconnections transparently on SocketStream. I
thought something like this:
void send(ubyte[] buffer) in { assert(buffer.length 0); }
body {
if (!stream.isAlive) connect();
auto sent = stream.write(buffer);
if (sent == 0)
throw new Exception(Error while writing);
}
But that's impossible because isAlive doesn't exists for SocketStream
and
I can't get the underlying socket object. Is that something missing or
should I handle it differently?
The underlying problem is that you cannot detect if a socket is still
connected without trying to read (recv) or write (send) to it, it is only
once you attempt an operation that it will report that it has been
closed. This is why isAlive wont/can't exist in any really useful way.
The underlying socket routines indicate closure by returning 0 bytes
read/written. So, the real Q here is how does socketstream (is it built
on std.socket?) reflect this information to you?
Regan
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Why is std.algorithm.reduce impure?
On Wednesday, March 07, 2012 17:58:43 Timon Gehr wrote: On 03/07/2012 05:29 PM, Simen Kjærås wrote: On Wed, 07 Mar 2012 01:41:22 +0100, Jonathan M Davis jmdavisp...@gmx.com wrote: It really takes very little for something to be impure, and optimizations often do it, because they end up using low-level constructs which aren't pure - some of which could be but aren't and others which probably can't be. Just so this is clear - no optimization of the compiler is going to change the purity of a function. An optimization on the part of the programmer (like using appender) might, though. Appender must become pure. Most definitely. A variety of things which are currently impure must become pure. Some things which didn't used to be pure still are, but there's still plenty left that need to be sorted out. - Jonathan M Davis
Re: 0 negative loop condition bug or misunderstanding on my part
On Wednesday, March 07, 2012 11:01:05 Timon Gehr wrote: On 03/07/2012 07:05 AM, ixid wrote: Ah, thank you, so it's wrapping. That seems like a bad idea, what is the benefit to size being unsigned rather than signed? This case would seem like one where allowing negatives is clearly better and more intuitive. The problem is not that length is unsigned. The issue is the implicit conversion from signed to unsigned. The right thing would be to disallow signed - unsigned and unsigned - signed implicit conversion unless value range propagation can prove it safe, and to make comparison between signed and unsigned actually work by translating it to more than one machine instruction. Though that's one of those things that you're not going to convince Walter of - primarily, I believe, because it would require a lot more casting. The interesting part about _that_ is that if it's bad enough, it will actually make code _worse_, because the cast forces things. To really deal with it cleanly, you'd proabably need something similar to the const_cast nonsense in C++ except that it just converts signedness. I suspect that the reality of the matter is that if we disallowed implicit conversions between signed and unsigned, a number of bugs would completely go away, but others would creep in as a result, and the overal situation wouldn't necessarily be any better, but I don't know. My initial reaction would be to agree with you, but there are definitely cases where such an approach would get annoying and bug-prone (due to the casting involved). But regardless, I really don't think that you're going to convince Walter on this one, given what he's said in the past. - Jonathan M Davis
Re: Why is std.algorithm.reduce impure?
On Wednesday, March 07, 2012 17:29:24 Simen Kjærås wrote: On Wed, 07 Mar 2012 01:41:22 +0100, Jonathan M Davis jmdavisp...@gmx.com wrote: It really takes very little for something to be impure, and optimizations often do it, because they end up using low-level constructs which aren't pure - some of which could be but aren't and others which probably can't be. Just so this is clear - no optimization of the compiler is going to change the purity of a function. An optimization on the part of the programmer (like using appender) might, though. I didn't say that it did, though maybe I wasn't clear enough. Optimizations of the _algorithms_ involved can make a function impure - such as use Appender instead of ~= when building arrays. - Jonathan M Davis
Re: 0 negative loop condition bug or misunderstanding on my part
On 3/7/2012 12:57 PM, Jonathan M Davis wrote: On Wednesday, March 07, 2012 11:01:05 Timon Gehr wrote: On 03/07/2012 07:05 AM, ixid wrote: Ah, thank you, so it's wrapping. That seems like a bad idea, what is the I suspect that the reality of the matter is that if we disallowed implicit conversions between signed and unsigned, a number of bugs would completely go away, but others would creep in as a result, and the overal situation wouldn't necessarily be any better, but I don't know. My initial reaction would be to agree with you, but there are definitely cases where such an approach would get annoying and bug-prone (due to the casting involved). But regardless, I really don't think that you're going to convince Walter on this one, given what he's said in the past. - Jonathan M Davis After writing enough container libraries and whatnot in C++, I always end up going bed while thinking life would be so much easier if implicit signed/unsigned conversions were not allowed. Then I go to sleep, wake up, and realize how much more horrific the code would be in other places if this was actually true. The best compromise would probably have been to make size_t signed when migrating to 64 bit memory addressing, and leave the unsigned/signed problems specificaly with size_t values back in the past of 32 bit and older systems. On a related note I would love to see something in std.somewhere (conv?) to provide a complete set of narrowing and signed/unsigned conversion functions: The matrix is basically the following methods: 1) Reduce size (64-32-16-8 bits) but maintain signedness with three types: 2) Methods to flip signedness of the value (but mainting bitwidth) multiplied against three types of operations: a) truncating (i.e. mask off the lower bits) b) saturating (values outside of range are clamped to min or max of the narrower range) c) throwing (values outside of narrow range throw a range exception)
Re: 0 negative loop condition bug or misunderstanding on my part
On Wednesday, March 07, 2012 13:20:41 Sean Cavanaugh wrote: On 3/7/2012 12:57 PM, Jonathan M Davis wrote: On Wednesday, March 07, 2012 11:01:05 Timon Gehr wrote: On 03/07/2012 07:05 AM, ixid wrote: Ah, thank you, so it's wrapping. That seems like a bad idea, what is the I suspect that the reality of the matter is that if we disallowed implicit conversions between signed and unsigned, a number of bugs would completely go away, but others would creep in as a result, and the overal situation wouldn't necessarily be any better, but I don't know. My initial reaction would be to agree with you, but there are definitely cases where such an approach would get annoying and bug-prone (due to the casting involved). But regardless, I really don't think that you're going to convince Walter on this one, given what he's said in the past. - Jonathan M Davis After writing enough container libraries and whatnot in C++, I always end up going bed while thinking life would be so much easier if implicit signed/unsigned conversions were not allowed. Then I go to sleep, wake up, and realize how much more horrific the code would be in other places if this was actually true. The best compromise would probably have been to make size_t signed when migrating to 64 bit memory addressing, and leave the unsigned/signed problems specificaly with size_t values back in the past of 32 bit and older systems. On a related note I would love to see something in std.somewhere (conv?) to provide a complete set of narrowing and signed/unsigned conversion functions: The matrix is basically the following methods: 1) Reduce size (64-32-16-8 bits) but maintain signedness with three types: 2) Methods to flip signedness of the value (but mainting bitwidth) multiplied against three types of operations: a) truncating (i.e. mask off the lower bits) b) saturating (values outside of range are clamped to min or max of the narrower range) c) throwing (values outside of narrow range throw a range exception) std.conv.to will check non-implicit, narrowing conversions to make sure that the number will fit in the new type (throwing a ConvException if it won't), but if you're converting between types of the same size but which differ in signedness, then that's an implicit conversion, at it's the same as if you didn't use std.conv.to at all. - Jonathan M Davis
Re: D RTTI?
On 03/07/12 00:19, H. S. Teoh wrote:
On Tue, Mar 06, 2012 at 11:40:19PM +0100, Artur Skawina wrote:
On 03/06/12 20:37, H. S. Teoh wrote:
On Tue, Mar 06, 2012 at 01:51:51AM +0100, Artur Skawina wrote:
[...]
class A {
string prop1;
int prop2;
void serialize(this THIS)() {
__serialize(cast(THIS*)this);
}
}
void __serialize(T)(T* obj) {
writef(%s {\n, typeid(*obj));
foreach (name; __traits(allMembers, T)) {
static if (__traits(compiles,__traits(getMember,obj,name))) {
alias typeof(__traits(getMember,obj,name)) MT;
static if (is(MT==function))
continue;
else {
auto m = __traits(getMember,obj,name);
if (is(MT:const(char[])))
writef( %s %s = \%s\;\n, typeid(MT), name, m);
else
writef( %s %s = %s;\n, typeid(MT), name, m);
}
}
}
writef(}\n);
}
And it will do the right thing for derived classes too.
[...]
Hmm, it only does the right thing for derived class if invoked with the
derived class pointer. It doesn't work (and in retrospect can't possibly
work, since this THIS is a compile-time parameter) if you only have
the base class pointer.
[...]
What I needed was for serialize() to be polymorphic at runtime, so it
does have to be overloaded in every derived class. Hmph... looks like I
can't avoid using mixins. :-(
If you can register the classes to be serialized then typeid() can
help the __serialize() implementation...
True. But TypeInfo doesn't let you access actual data members without
using void* casts and pointer arithmetic, whereas compile-time
introspection does.
What i meant is something like this:
int prop2;
void serialize(this THIS)() {
+ if (auto p = typeid(this) in serializers)
+ (*p)(this);
+ else
__serialize(cast(THIS*)this);
}
}
@@ -14,6 +17,13 @@
int propB2;
}
+alias void delegate(void*) SDG;
+SDG[typeof(typeid(int))] serializers;
+
+void __register(T)(T* o) {
+ serializers[typeid(T)] = cast(SDG)(T* o) { __serialize(o); };
+}
+
void __serialize(T)(T* obj) {
writef(%s {\n, typeid(*obj));
foreach (name; __traits(allMembers, T)) {
which doesn't need mixins in every derived class, you just need to
call __register with an instance once, before doing the serializing.
[it's a quick hack, written while typing this email; in real code
you probably want to stick to just one approach and assert when trying
to serialize an unknown type etc]
artur
Method invocation -- why it's not working?
1 struct A
2 {
3 double[2] _x;
4 }
5
6 @property ref double y(ref A a) {return a._x[1];}
7
8 void main()
9 {
10 A a1;
11 a1.y=2.;
12 }
dmd test.d gives me:
Error: no property 'y' for type 'A'
Ddoc: no docs generated for nested structs?
I wrote a whole bunch of documentation for a struct that I later decided to transplant inside another struct (because the two are closely linked), and now the former struct's docs have vanished. Is this expected behaviour? T -- I am a consultant. My job is to make your job redundant. -- Mr Tom
Re: Method invocation -- why it's not working?
On Thu, 08 Mar 2012 00:21:36 +0100, Comrad
comrad.karlov...@googlemail.com wrote:
1 struct A
2 {
3 double[2] _x;
4 }
5
6 @property ref double y(ref A a) {return a._x[1];}
7
8 void main()
9 {
10 A a1;
11 a1.y=2.;
12 }
dmd test.d gives me:
Error: no property 'y' for type 'A'
Uniform function call syntax is not implemented. Due to what
was originally a bug, it works for arrays.
Re: Method invocation -- why it's not working?
On 03/07/2012 03:21 PM, Comrad wrote:
1 struct A
2 {
3 double[2] _x;
4 }
5
6 @property ref double y(ref A a) {return a._x[1];}
7
8 void main()
9 {
10 A a1;
11 a1.y=2.;
12 }
dmd test.d gives me:
Error: no property 'y' for type 'A'
You are testing out the new UFCS, right? Well, I really really hope that
I will be embarrassed by saying this: That feature has been DOA! :p
So many people celebrated the feature on the D.announce newsgroup. I've
pointed out a number of times that I couldn't get even the simplest test.
And there is a unittest that tests the feature but nope... It just
doesn't work. :(
Ali
Re: Method invocation -- why it's not working?
On 03/07/2012 03:54 PM, Ali Çehreli wrote:
On 03/07/2012 03:21 PM, Comrad wrote:
1 struct A
2 {
3 double[2] _x;
4 }
5
6 @property ref double y(ref A a) {return a._x[1];}
7
8 void main()
9 {
10 A a1;
11 a1.y=2.;
12 }
dmd test.d gives me:
Error: no property 'y' for type 'A'
You are testing out the new UFCS, right? Well, I really really hope that
I will be embarrassed by saying this: That feature has been DOA! :p
So many people celebrated the feature on the D.announce newsgroup. I've
pointed out a number of times that I couldn't get even the simplest test.
And there is a unittest that tests the feature but nope... It just
doesn't work. :(
Ali
Ok, now I see how I fooled myself. Posts like the following made me
think that UFCS has been implemented even for ints:
http://forum.dlang.org/post/jhfpca$1bf4$1...@digitalmars.com
I made a further mistake and parsed the unittest in the following change
as using an 'int'. Obviously I was wrong: it is the string literal 1:
https://github.com/D-Programming-Language/dmd/commit/c268c4a2dc20aae024bce81555833b806a56f718
Ali
Re: Method invocation -- why it's not working?
Don't worry Ali I thought the same thing. :p
Re: Ddoc: no docs generated for nested structs?
On Wed, Mar 07, 2012 at 03:49:26PM -0800, H. S. Teoh wrote: I wrote a whole bunch of documentation for a struct that I later decided to transplant inside another struct (because the two are closely linked), and now the former struct's docs have vanished. Is this expected behaviour? [...] Argh, nevermind what I wrote. In the course of moving the code I accidentally inserted another declaration between the struct and the ddoc comment. T -- Nearly all men can stand adversity, but if you want to test a man's character, give him power. -- Abraham Lincoln
Re: 0 negative loop condition bug or misunderstanding on my part
On 3/7/12 2:28 AM, Ali Çehreli wrote:
On 03/06/2012 09:11 PM, ixid wrote:
I'm writing my first basic algorithms, this one is merge sort. This
version throws an exception when array.length - setSize is negative
(which should be fine, the rest of my function would deal with it):
template mergeSort(T)
{
void mergeSort(ref T[] array, const T setSize = 100)
{
T[][] merge;
merge.length = array.length / setSize;
T ii, jj;
for(ii = 0, jj = 0;ii array.length - setSize;ii += setSize, ++jj)
We don't know what T is, but I assume a signed type like int.
array.length is size_t, i.e. an unsigned type. Unsigned types have this
nasty habit of converting the entire expression to unsigned (that is a
rule since C). So array.length - setSize above is size_t.
Wouldn't it make more sense to convert the entire expression to signed
if there's at list one signed integer?
I really don't get it...
It's like déjà-vu all the time in this newsgroup.
Re: 0 negative loop condition bug or misunderstanding on my part
On 8 March 2012 15:39, Ary Manzana a...@esperanto.org.ar wrote:
On 3/7/12 2:28 AM, Ali Çehreli wrote:
On 03/06/2012 09:11 PM, ixid wrote:
I'm writing my first basic algorithms, this one is merge sort. This
version throws an exception when array.length - setSize is negative
(which should be fine, the rest of my function would deal with it):
template mergeSort(T)
{
void mergeSort(ref T[] array, const T setSize = 100)
{
T[][] merge;
merge.length = array.length / setSize;
T ii, jj;
for(ii = 0, jj = 0;ii array.length - setSize;ii += setSize, ++jj)
We don't know what T is, but I assume a signed type like int.
array.length is size_t, i.e. an unsigned type. Unsigned types have this
nasty habit of converting the entire expression to unsigned (that is a
rule since C). So array.length - setSize above is size_t.
Wouldn't it make more sense to convert the entire expression to signed if
there's at list one signed integer?
I really don't get it...
It's like déjà-vu all the time in this newsgroup.
Its the semantics in C/C++ and D explicitly tries to have the same
semantics as them. From what I remember its to aid people moving from
those language to D.
--
James Miller
Re: 0 negative loop condition bug or misunderstanding on my part
On Thursday, March 08, 2012 16:15:08 James Miller wrote: Its the semantics in C/C++ and D explicitly tries to have the same semantics as them. From what I remember its to aid people moving from those language to D. More like it's to avoid code silently breaking when it's ported. In general, C/C++ code is either valid D code with identical semantics, or it won't compile as D code. There are a _few_ exceptions (e.g. static arrays are passed by value), but they're far and few between. Porting C/C++ code to D would be much nastier if the C/C++ compiled as D code but had different semantics. In addition to that, I believe that Walter's take on it is to generally leave stuff as it is in C/C++ unless there's a good reason to change it. Obviously, there's a lot which was worth changing, and there's tons of stuff in D which is different form C/C++. But there's a lot of little stuff that wasn't messed with, because there just wasn't a good reason to. - Jonathan M Davis
Re: Ddoc: no docs generated for nested structs?
On Wednesday, March 07, 2012 16:37:44 H. S. Teoh wrote: On Wed, Mar 07, 2012 at 03:49:26PM -0800, H. S. Teoh wrote: I wrote a whole bunch of documentation for a struct that I later decided to transplant inside another struct (because the two are closely linked), and now the former struct's docs have vanished. Is this expected behaviour? [...] Argh, nevermind what I wrote. In the course of moving the code I accidentally inserted another declaration between the struct and the ddoc comment. If it's nested inside of a function, then any docs on the struct shouldn't end up in the documentation. But documentation on structs or classes nested inside of other structs or classes should definitely show up. - Jonathan M Davis
Re: 0 negative loop condition bug or misunderstanding on my part
On 03/07/2012 12:23 AM, Ali Çehreli wrote: There are probably hundreds of discussions about that over the years on many different language newsgroups and forums. :) There is no clear winner: Both sides of the arguments seem to have good points. Ali know any good ones off the top of your head?
Re: 0 negative loop condition bug or misunderstanding on my part
On 03/07/2012 07:51 PM, Ellery Newcomer wrote:
On 03/07/2012 12:23 AM, Ali Çehreli wrote:
There are probably hundreds of discussions about that over the years on
many different language newsgroups and forums. :) There is no clear
winner: Both sides of the arguments seem to have good points.
Ali
know any good ones off the top of your head?
Really randomly:
* Unsigned is better because some things are never negative: sizes,
indexes, etc.
* But we occasionally need to subtract one from the other. The following
is not safe unless we are sure that the left-hand side is greater:
size_t i = /* ... */;
size_t j = /* ... */;
foo(i - j); // Is this the difference or a very large number?
Another bug because of an unsigned type:
for (size_t i = /* ... */; i = 0; --i) {
(Although I think most compilers catch that one.)
I searched for the following terms on comp.lang.c++.moderated and found
many interesting discussions:
size_t unsigned signed
I don't have a strong opinion myself.
Ali
Can I do an or in a version block?
I would like to do something like this:
version (linux || BSD) {
// do something...
} else {
version (Windows) {
// do something else
} else {
// do something else
assert(false, Unsupported operating system);
}
}
The only way I've been able to do this, is by splitting up the
two versions and repeat code.
Is there a better way to do this? A static if can do this, so is
there a way that I can use a static if somehow?
Re: Can I do an or in a version block?
On 8 March 2012 18:38, Tyler Jameson Little beatgam...@gmail.com wrote:
I would like to do something like this:
version (linux || BSD) {
// do something...
} else {
version (Windows) {
// do something else
} else {
// do something else
assert(false, Unsupported operating system);
}
}
The only way I've been able to do this, is by splitting up the two versions
and repeat code.
Is there a better way to do this? A static if can do this, so is there a way
that I can use a static if somehow?
I don't think there is an 'elseif' for versions, probably because you
are normally checking mutually exclusive version descriptions.
Otherwise, its probably a good idea to keep the syntax as is, since it
stops people from abusing the mechanic.
--
James Miller
Re: Can I do an or in a version block?
On 03/07/2012 10:07 PM, James Miller wrote:
On 8 March 2012 18:38, Tyler Jameson Littlebeatgam...@gmail.com wrote:
I would like to do something like this:
version (linux || BSD) {
// do something...
} else {
version (Windows) {
// do something else
} else {
// do something else
assert(false, Unsupported operating system);
}
}
The only way I've been able to do this, is by splitting up the two versions
and repeat code.
Is there a better way to do this? A static if can do this, so is there a way
that I can use a static if somehow?
I don't think there is an 'elseif' for versions, probably because you
are normally checking mutually exclusive version descriptions.
Otherwise, its probably a good idea to keep the syntax as is, since it
stops people from abusing the mechanic.
--
James Miller
I had played with this in the past. The assignment to version has an
interesting meaning of collecting everything assigned to it:
import std.stdio;
version (linux)
{
version = linuxOrBSD;
version = foo;
}
version (BSD)
{
version = linuxOrBSD;
version = foo;
}
void main()
{
version (linuxOrBSD) {
writeln(linux or BSD);
// do something...
} else {
version (Windows) {
// do something else
} else {
// do something else
assert(false, Unsupported operating system);
}
}
// Later on even this works
version (foo) {
writeln(even foo!);
}
}
Ali
Re: Can I do an or in a version block?
On Thursday, March 08, 2012 06:38:48 Tyler Jameson Little wrote:
I would like to do something like this:
version (linux || BSD) {
// do something...
} else {
version (Windows) {
// do something else
} else {
// do something else
assert(false, Unsupported operating system);
}
}
The only way I've been able to do this, is by splitting up the
two versions and repeat code.
Is there a better way to do this? A static if can do this, so is
there a way that I can use a static if somehow?
You can do
version(x) {}
else version(y) {}
else {}
but there is no logical and or logical or with versions. It's _only_ checking
whether a particular version exists or not. Walter Bright is completely
against having anything more complicated with versioning, since he thinks that
it just engenders bad code and bugs.
Now, you could do
version(x)
version = xOrY
else version(y)
version = xOrY
version(xOrY) {}
and then xOrY will exist for the rest of that module. But that's as close as
you're going to ge to logical and or logical or for versions.
Of course, if the issue is linux || FreeBSD, you might want to just consider
using Posix. Unless you're doing something that is specific to linux and
FreeBSD but not Posix in general (which I would expect to be unlikely), Posix
will do the trick just fine.
- Jonathan M Davis
Re: Method invocation -- why it's not working?
On Thursday, 8 March 2012 at 00:04:55 UTC, Ali Çehreli wrote:
On 03/07/2012 03:54 PM, Ali Çehreli wrote:
On 03/07/2012 03:21 PM, Comrad wrote:
1 struct A
2 {
3 double[2] _x;
4 }
5
6 @property ref double y(ref A a) {return a._x[1];}
7
8 void main()
9 {
10 A a1;
11 a1.y=2.;
12 }
dmd test.d gives me:
Error: no property 'y' for type 'A'
You are testing out the new UFCS, right? Well, I really really
hope that
I will be embarrassed by saying this: That feature has been
DOA! :p
So many people celebrated the feature on the D.announce
newsgroup. I've
pointed out a number of times that I couldn't get even the
simplest test.
And there is a unittest that tests the feature but nope... It
just
doesn't work. :(
Ali
Ok, now I see how I fooled myself. Posts like the following
made me think that UFCS has been implemented even for ints:
http://forum.dlang.org/post/jhfpca$1bf4$1...@digitalmars.com
I made a further mistake and parsed the unittest in the
following change as using an 'int'. Obviously I was wrong: it
is the string literal 1:
https://github.com/D-Programming-Language/dmd/commit/c268c4a2dc20aae024bce81555833b806a56f718
Ali
Basically, I was following Andrei's book, where this feature is
described. It's a pity, that it's not working (except arrays
somehow) :( - I need it!
Re: Method invocation -- why it's not working?
On Thu, Mar 08, 2012 at 07:32:18AM +0100, Comrad wrote: [...] Basically, I was following Andrei's book, where this feature is described. It's a pity, that it's not working (except arrays somehow) :( - I need it! Yeah there are some features in the book that aren't completely implemented yet. They are being looked into with high priority. T -- Acid falls with the rain; with love comes the pain.
Re: Method invocation -- why it's not working?
On Wednesday, March 07, 2012 22:40:02 H. S. Teoh wrote: On Thu, Mar 08, 2012 at 07:32:18AM +0100, Comrad wrote: [...] Basically, I was following Andrei's book, where this feature is described. It's a pity, that it's not working (except arrays somehow) :( - I need it! Yeah there are some features in the book that aren't completely implemented yet. They are being looked into with high priority. True. But I would point out that TDPL never actually says that it works with all types. It only shows it with arrays. Now, it's not entirely clear on whether it's supposed to work with all types, but it definitely doesn't say that it does. It wouldn't surprise me at all if Andrei wrote it with the intention that it was only supposed to work with arrays but wasn't clear enough in his description. Still, there are definitely a lot of people who want it to work with all types, so it's likely that it will be expanded to work with more types. Whether it will ever work with _all_ types is somewhat in question due to ambiguity issues involving structs and classes (e.g. when a member function and a free function using UFCS would conflict). But there's a decent chance that that will be resolved and UFCS will end up working for all types. Until then though, all it works with is arrays. - Jonathan M Davis
Re: Can I do an or in a version block?
Now, you could do
version(x)
version = xOrY
else version(y)
version = xOrY
version(xOrY) {}
Huh, clever! I like it!! I hope I don't have to do that very
often, though...
Of course, if the issue is linux || FreeBSD, you might want to
just consider
using Posix. Unless you're doing something that is specific to
linux and
FreeBSD but not Posix in general (which I would expect to be
unlikely), Posix
will do the trick just fine.
Yeah, that was just an example. Perhaps a better example would be
comparing versions of something:
version (LIBV1 || LIBV2) {
// include some dirty hacks for old versions
} else {
// do some new fancy stuff for new features
}
I was mostly thinking that there are things that linux and BSD
share that other BSDs may not. I know that Mac OS X has some
subtle differences in a few things.
Anyway, I think this answers my question. I can get by with using
your suggestion for those (hopefully) rare cases where I need
something more specific.
Thanks!
Re: Can I do an or in a version block?
Now, you could do
version(x)
version = xOrY
else version(y)
version = xOrY
version(xOrY) {}
Huh, clever! I like it!! I hope I don't have to do that very
often, though...
Of course, if the issue is linux || FreeBSD, you might want to
just consider
using Posix. Unless you're doing something that is specific to
linux and
FreeBSD but not Posix in general (which I would expect to be
unlikely), Posix
will do the trick just fine.
Yeah, that was just an example. Perhaps a better example would be
comparing versions of something:
version (LIBV1 || LIBV2) {
// include some dirty hacks for old versions
} else {
// do some new fancy stuff for new features
}
I was mostly thinking that there are things that linux and BSD
share that other BSDs may not. I know that Mac OS X has some
subtle differences in a few things.
Anyway, I think this answers my question. I can get by with using
your suggestion for those (hopefully) rare cases where I need
something more specific.
Thanks!
Re: Raw socket TCP/IP
Just curious, but what exactly do you need a raw IP socket for?
Re: Raw socket TCP/IP
Am 08.02.2012 19:35, schrieb Eyyub: BUMP, I really need help please ! Eyyub. what are you trying to archive? did you got an Ethernet-Frame+IP-Frame+(your replacement for tcp or udp) - or are your trying to change the tcp frame before sending? and if your using Windows: http://msdn.microsoft.com/en-us/library/windows/desktop/ms740548%28v=vs.85%29.aspx here are two basic types of such raw sockets: The first type uses a known protocol type written in the IP header that is recognized by a Winsock service provider. An example of the first type of socket is a socket for the ICMP protocol (IP protocol type = 1) or the ICMPv6 protocol (IP procotol type = 58). The second type allows any protocol type to be specified. An example of the second type would be an experimental protocol that is not directly supported by the Winsock service provider such as the Stream Control Transmission Protocol (SCTP). Limitations on Raw Sockets On Windows 7, Windows Vista, Windows XP with Service Pack 2 (SP2), and Windows XP with Service Pack 3 (SP3), the ability to send traffic over raw sockets has been restricted in several ways: -TCP data cannot be sent over raw sockets. -UDP datagrams with an invalid source address cannot be sent over raw sockets. The IP source address for any outgoing UDP datagram must exist on a network interface or the datagram is dropped. This change was made to limit the ability of malicious code to create distributed denial-of-service attacks and limits the ability to send spoofed packets (TCP/IP packets with a forged source IP address). These above restrictions do not apply to Windows Server 2008 R2, Windows Server 2008 , Windows Server 2003, or to versions of the operating system earlier than Windows XP with SP2.
Re: Method invocation -- why it's not working?
On Thursday, 8 March 2012 at 06:43:45 UTC, Jonathan M Davis wrote: On Wednesday, March 07, 2012 22:40:02 H. S. Teoh wrote: On Thu, Mar 08, 2012 at 07:32:18AM +0100, Comrad wrote: [...] Basically, I was following Andrei's book, where this feature is described. It's a pity, that it's not working (except arrays somehow) :( - I need it! Yeah there are some features in the book that aren't completely implemented yet. They are being looked into with high priority. True. But I would point out that TDPL never actually says that it works with all types. It only shows it with arrays. Now, it's not entirely clear on whether it's supposed to work with all types, but it definitely doesn't say that it does. It wouldn't surprise me at all if Andrei wrote it with the intention that it was only supposed to work with arrays but wasn't clear enough in his description. It's not correct. In TDPL it is clearly stated, that this is a general feature of the language. Still, there are definitely a lot of people who want it to work with all types, so it's likely that it will be expanded to work with more types. Whether it will ever work with _all_ types is somewhat in question due to ambiguity issues involving structs and classes (e.g. when a member function and a free function using UFCS would conflict). But there's a decent chance that that will be resolved and UFCS will end up working for all types. Until then though, all it works with is arrays. - Jonathan M Davis Anyway, for structures this feature is really needed.
Re: Method invocation -- why it's not working?
On Thursday, March 08, 2012 08:37:38 Comrad wrote: On Thursday, 8 March 2012 at 06:43:45 UTC, Jonathan M Davis wrote: On Wednesday, March 07, 2012 22:40:02 H. S. Teoh wrote: On Thu, Mar 08, 2012 at 07:32:18AM +0100, Comrad wrote: [...] Basically, I was following Andrei's book, where this feature is described. It's a pity, that it's not working (except arrays somehow) :( - I need it! Yeah there are some features in the book that aren't completely implemented yet. They are being looked into with high priority. True. But I would point out that TDPL never actually says that it works with all types. It only shows it with arrays. Now, it's not entirely clear on whether it's supposed to work with all types, but it definitely doesn't say that it does. It wouldn't surprise me at all if Andrei wrote it with the intention that it was only supposed to work with arrays but wasn't clear enough in his description. It's not correct. In TDPL it is clearly stated, that this is a general feature of the language. Then please give me a page number. Last time I looked it over, I saw _nothing_ which said that it worked on types in general, and _all_ examples used arrays. Still, there are definitely a lot of people who want it to work with all types, so it's likely that it will be expanded to work with more types. Whether it will ever work with _all_ types is somewhat in question due to ambiguity issues involving structs and classes (e.g. when a member function and a free function using UFCS would conflict). But there's a decent chance that that will be resolved and UFCS will end up working for all types. Until then though, all it works with is arrays. - Jonathan M Davis Anyway, for structures this feature is really needed. It would be nice, but I honestly don't understand the people who think that the lack of it is crippling. It's just one of those nice-to-have features. Most languages don't have anything of the sort. - Jonathan M Davis
