Re: with(a,b,c, ...) blocks..
Theoretically legal...
void func()
//in/out contracts
body with (E) { //with replaces normal block
}
This seems sensible. Multiple with seems like a recipe for
confusion and member name clashes.
Re: How to define an interator to provide array like behaviour in a class?
On 2012-10-17 00:23, Jonathan M Davis wrote: 2. Or make it a range (see http://dlang.org/statement.html#foreach_with_ranges and http://ddili.org/ders/d.en/ranges.html ), which would probably be a bad idea, since containers really shouldn't be ranges. Why is that a bad idea? -- /Jacob Carlborg
Re: How to define an interator to provide array like behaviour in a class?
On Wednesday, October 17, 2012 08:14:45 Jacob Carlborg wrote: On 2012-10-17 00:23, Jonathan M Davis wrote: 2. Or make it a range (see http://dlang.org/statement.html#foreach_with_ranges and http://ddili.org/ders/d.en/ranges.html ), which would probably be a bad idea, since containers really shouldn't be ranges. Why is that a bad idea? For starters, iterating over the container would empty it. - Jonathan M Davis
Re: optlink and weak symbols
On 2012-10-17 07:07, Ellery Newcomer wrote: I am interfacing with some C code [python.dll], which has some structs declared like so: PyTypeObject PyType_Type; I wish to be able to link to PyType_Type like so: extern(C) __gshared PyTypeObject PyType_Type; in linux, I can do exactly that, but optlink is generating a new memory location for PyType_Type. strings output suggests that my lib file contains the symbol PyType_Type. Is this sort of thing supposed to work? You need to declare the variable as extern if it's defined in the C code: extern(C) extern __gshared PyTypeObject PyType_Type; http://dlang.org/interfaceToC.html#C%20Globals -- /Jacob Carlborg
Re: How to define an interator to provide array like behaviour in a class?
On 2012-10-17 08:17, Jonathan M Davis wrote: For starters, iterating over the container would empty it. Right, but that is really weird, in my opinion. -- /Jacob Carlborg
Re: Stack trace output on windows
On Tue, 16 Oct 2012 17:52:38 +0100, Benjamin Thaut c...@benjamin-thaut.de wrote: Am 16.10.2012 18:38, schrieb Regan Heath: I have some C/C++ code which handles windows SEH exceptions and can output (in debug mode) a stack trace, for example: But, it doesn't output symbol names for the D functions. Does anyone know why not? Is there some reason it cannot? Perhaps the debug information in the binary is incomplete.. IIRC that was an issue in the past and may still be. I managed to wind my way through the code and find the stacktrace.d module with the StackTrace class which appears to be producing the stack trace. Comparing it to my own, the major difference is on the StackWalk call I pass FunctionTableAccessRoutine and GetModuleBaseRoutine routines (3rd and 2nd to last parameters) .. I'm guessing there is some reason this wont work in D, can anyone enlighten me? R You could use cv2pdb to convert the debugging symbols into the pdb format, then the stackwaler will always be able to resolve the stack. So, the problem in my case is that dbghelp.dll doesn't understand the DMD CodeView (CV) debug information? Ahh.. I think I've figured out where I've been going wrong. It's been a while since I worked with any D and I was not passing the -g or -gc compile flags, only -debug, duh! I figured this out when cv2pdb complained .. no codeview debug entries found But, now I cannot compile.. (DMD32 D Compiler v2.060) C:\dmd -g -debug crash.d OPTLINK (R) for Win32 Release 8.00.12 Copyright (C) Digital Mars 1989-2010 All rights reserved. http://www.digitalmars.com/ctg/optlink.html OPTLINK : Error 118: Filename Expected Path=..etc.. Adding -v shows a linker command of: C:\Development\D\dmd2\windows\bin\link.exe crash,,nul,user32+kernel32/co/noi; The input file crash.obj is present, and a quick test removing the /co (debug information) C:\Development\D\dmd2\windows\bin\link.exe crash,,nul,user32+kernel32/co/noi; works fine.. any ideas where this is going wrong? Depending on your version of the dbghelp.dll, which comes with the windows sdk, or visual studio, it will also correctlry resolve cv smybols. I have windows 7 64 bit service pack 1 with visual studio 2010 installed and the D stacktracking correctly resolves cv symbols for me. Interesting. I searched and found 13 different versions of dbghelp.dll installed on my system. I have windows 7 64 bit SP1 with VS2010 installed and it's not working for me. I suspect in my case it's using one of the other 12 dlls. In my VS2010 folder(s) I found 3 dbghelp.dll's all version 6.12.2.633, does that match yours? In c:\Windows\System32 SysWOW64 and the winsxs folders the version is 6.1.7601.17514, which looks older but has a newer date on it. I also found version 6.1.7600.16385 in the winsxs folders. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Operator overloading through UFCS doesn't work
On 10/16/2012 05:57 PM, Maxim Fomin wrote: ... At NG discussion it may look nice to define some type and then add operator overloading methods Operator overloading is not magic, so your statement can be shortened to ... and then add methods Which is still not correct, because that is not what UFCS does. but as soon as you import some other modules, authors of which also consider UFCS operators a good idea, Who has stated that? It just does not make sense to explicitly ban them, as they are not special. everything breaks including namespace conflict The usual disambiguation procedures apply. (Which are broken in DMD at the moment, because module-scope private symbols can cause conflicts.) Infix operators are not special. It is just notation. as well as loosing ability to manipulate that type within built-in expression as well. I did not get that.
Re: Operator overloading through UFCS doesn't work
On 10/14/2012 09:14 AM, Maxim Fomin wrote: On Sunday, 14 October 2012 at 07:01:30 UTC, Tommi wrote: Actually, it seems that alias this has precedence over UFCS. So, a free function opUnary wouldn't ever suit better than an actual method opUnary of the thing referred to by that alias this. http://dpaste.dzfl.pl/d0a4431d Free function doesn't suit better than actual method. The issue is absence of the actual method. opUnary method has priority over alias this, which does make sense because alias this is chosen only when it is impossible to apply operation over A type. If this request is approved and compiler has opUnary definition outside type (which suits better then alias this) such function would hijack alias this. If not, there is a new case when something is going special than at usual cases and only for the purpose of writing operator overloading methods outside the body of the type. The goal must be to get rid of all special behaviour that can result in strange interactions. Add the suitable operator function templates to built-in types. Always rewrite operators to operator function calls. Problem solved. (And people are already asking for custom constant folding procedures, even without having this in place to use as a supporting argument.)
Re: Operator overloading through UFCS doesn't work
On Wednesday, 17 October 2012 at 10:24:57 UTC, Artur Skawina wrote: Operator overloading can be abused - that's an obvious and well known fact. But that same feature can also be very useful, if used right. Worrying about UFCS problems in the context of op-overloading needlessly complicates the issue - the UFCS problems are there also w/o op-overloads. ... skipped artur I don't see how this addresses the issue I try to put attention to. The discussion it turning into repetition of views.
Re: Stack trace output on windows
I didn't go through the trouble and find out which version of dbghelp.dll exactly supports cv debugging symbols, but I know it depends on that. So I can not help you there. The linker line looks fine, looks the same for me but works (also with dmd 2.060) Did you modify your sc.ini file? Kind Regards Benjamin Thaut
Re: Operator overloading through UFCS doesn't work
On 10/14/2012 09:01 AM, Maxim Fomin wrote:
On Saturday, 13 October 2012 at 19:50:02 UTC, Timon Gehr wrote:
On 10/13/2012 06:02 PM, Maxim Fomin wrote:
...
Different groups of people have different mind and same things produce
different sense on them. From my point of view operator overloading
methods are special functions and not treating them as candidates for
UFCS does make more sense.
I do not understand how an operation that happens to be called '+' is
fundamentally different from an operation that is called 'add'.
The first one is an operator, which sometimes, may be rewritten to
function call, the second one is a function call.
What is the difference between an operator and a function call? Is it
important?
int add(int a, int b){ return a+b; }
// or conversely (not valid syntax):
int (int a)+(int b){ return add(a,b); }
Even if you convince in your opinion,
language addition without applied purposes makes no benefit.
I guess the functionality could be achieved in DMD mostly by removing
code. (Code for good error messages excluded!)
I don't understand what you are trying to say. Anyway, you can write a
pull request and propose it at github. It would be interesting to see
reaction of others.
Built-in types shouldn't be special except maybe that the parser
recognises related keywords.
It should go like this:
a + b = a.opBinary!+(b); // opBinary_r woes left out,
// but would require treatment
a + b = __add(a,b); // if a and b of built-in type
a.opBinary!+(b) = __add(a,b); // if a and b of built-in type
Where __add(a,b) is the representation of an AST node of a built-in add
operation involving operands a and b.
All the code in DMD that supposedly tries to make up for this kind of
inconsistencies (and sometimes fails, because it does not catch all the
ways the language features interact) can be gotten rid of.
Re: Operator overloading through UFCS doesn't work
On Wednesday, 17 October 2012 at 11:00:05 UTC, Timon Gehr wrote: On 10/16/2012 05:57 PM, Maxim Fomin wrote: ... At NG discussion it may look nice to define some type and then add operator overloading methods Operator overloading is not magic, so your statement can be shortened to ... and then add methods Which is still not correct, because that is not what UFCS does. It is not correct as long as you cavil at lexis, however the statement has room for correction. but as soon as you import some other modules, authors of which also consider UFCS operators a good idea, Who has stated that? It just does not make sense to explicitly ban them, as they are not special. Who stated that they should be explicitly banned? I explained potential problem in previous posts. everything breaks including namespace conflict The usual disambiguation procedures apply. (Which are broken in DMD at the moment, because module-scope private symbols can cause conflicts.) Infix operators are not special. It is just notation. as well as loosing ability to manipulate that type within built-in expression as well. I did not get that. Again, the problem is in conflict between different declared operator overloading functions across different modules.
Re: How to define an interator to provide array like behaviour in a class?
On 2012-10-17 17:45, Jonathan M Davis wrote: Well, what would you expect? Ranges are consumed when you iterate over them. So, if an container is a range, it will be consumed when you iterate over it. That's the way that it _has_ to work given how ranges work, and that's why you overload opSlice to return a range which is iterated over rather than making the container itself a range. How does this work with built-in arrays? -- /Jacob Carlborg
Re: How to define an interator to provide array like behaviour in a class?
On Wed, Oct 17, 2012 at 06:58:52PM +0200, Jacob Carlborg wrote: On 2012-10-17 17:45, Jonathan M Davis wrote: Well, what would you expect? Ranges are consumed when you iterate over them. So, if an container is a range, it will be consumed when you iterate over it. That's the way that it _has_ to work given how ranges work, and that's why you overload opSlice to return a range which is iterated over rather than making the container itself a range. How does this work with built-in arrays? [...] If I understand it correctly, arrays work because when you pass an array to a range function, you're actually passing a slice of it to the function. That slice gets consumed, but the original array is unchanged. T -- A linguistics professor was lecturing to his class one day. In English, he said, A double negative forms a positive. In some languages, though, such as Russian, a double negative is still a negative. However, there is no language wherein a double positive can form a negative. A voice from the back of the room piped up, Yeah, yeah.
Re: How to define an interator to provide array like behaviour in a class?
On 10/17/2012 09:58 AM, Jacob Carlborg wrote: On 2012-10-17 17:45, Jonathan M Davis wrote: Well, what would you expect? Ranges are consumed when you iterate over them. So, if an container is a range, it will be consumed when you iterate over it. That's the way that it _has_ to work given how ranges work, and that's why you overload opSlice to return a range which is iterated over rather than making the container itself a range. How does this work with built-in arrays? Array is a separate concept than slice; a slice provides access to the elements of an array. Arrays are containers that are owned by the runtime, slices are ranges over their elements. Only the slices are consumed. Ali
Re: Code review: JSON unmarshaller
I could make my marshaller/unmarshaller only update objects in place. I think this is more useful and would remove the overlap between orange and the JSON library. We could then write a JSON archiver for orange and include it in std.json as well. The call to unmarshal would look like: bool unmarshalJSON(T)(JSONValue val, out T ret); The following restrictions would apply: * T must be fully instantiated (all pointers are valid [not null]) * T must not be recursive (results in infinite recursion, and hence stack overflow) And the marshaller: JSONValue marshalJSON(T)(in T val); For marshalling, the restrictions are: * Slices are handled as if they were an array (copy all values) * Same as unmarshaller, except null pointers will be treated as JSON null I really like Go's JSON marshaller/unmarshaller, so I'm trying to model after that one. It allows updating an object in place, which was already a goal. There should probably be some standard D serialization format. In working with a structure trained on data (for machine learning, natural language processing, etc), a complete serialization solution makes sense. But for simple data passing, JSON makes a lot of sense. What do you think, do you think there's a place in Phobos for a simple JSON marshaller/unmarshaller? I'll have some updated code soon, and I'll post back when that's done, in case you'd like to have a look.
Re: How to define an interator to provide array like behaviour in a class?
On Wednesday, October 17, 2012 10:08:15 H. S. Teoh wrote: On Wed, Oct 17, 2012 at 06:58:52PM +0200, Jacob Carlborg wrote: On 2012-10-17 17:45, Jonathan M Davis wrote: Well, what would you expect? Ranges are consumed when you iterate over them. So, if an container is a range, it will be consumed when you iterate over it. That's the way that it _has_ to work given how ranges work, and that's why you overload opSlice to return a range which is iterated over rather than making the container itself a range. How does this work with built-in arrays? [...] If I understand it correctly, arrays work because when you pass an array to a range function, you're actually passing a slice of it to the function. That slice gets consumed, but the original array is unchanged. Pretty much yeah. Thinking of arrays in D as containers in a mistake really. They're not, as weird as that may be. It's the runtime (or the block of memory in the runtime, depending on how you look at it) which is the container, and the array is just a slice into it. But even that's not really an accurate way of looking at it, because you can append to them (altering the size of the underlying container and possibly resulting in them pointing to a different block of memory). Kind of like how arrays are halfway between value types and reference types, they're sort of halfway between ranges and containers. It's quite unfortunate that arrays are by far the most commonly used type of range, because they're a horrible example of one when you get down to the details of how they work. Regardless, it's slicing that you're dealing with when doing range-based operations on arrays, so it's the slice that gets operated on and consumed rather than the original array. And just like how ranges which are structs normally get automatically saved when passed to functions, arrays automatically get saved because they get sliced. And foreach doesn't even use the range API on arrays anyway, so regardless of how they work as ranges, it wouldn't necessarily apply to foreach. - Jonathan M Davis
Re: Code review: JSON unmarshaller
You have mentioned needing an allMembers that excluded
functions in one of your other posts. The following thread was
exactly about that. I can never remember the solution, but I
found it again: :)
http://www.digitalmars.com/d/archives/digitalmars/D/learn/Getting_only_the_data_members_of_a_type_34086.html
The mentioned solution doesn't account for shared fields from a
super class:
class A { int a; }
class S { int b; }
foreach (i, type; typeof(S.tupleof)) {
enum name = S.tupleof[i].stringof[4..$];
writef((%s) %s\n, type.stringof, name);
}
This will print:
(int) b
My implementation is ugly, but it works for this case:
(ret.b) b
(ret.a) a
I could use std.traits.BaseClassTuple, but then I'd have to
filter out common fields, and that sounds like a lot of work,
especially since there's no practical difference.
I used asserts and contracts to validate input, so the
following would
throw an AssertError:
int x = unmarshalJSON!int(`5`);
std.exception.enforce is the right choice in that case. You
don't want the checks to disappear when asserts are turned off.
I wasn't sure if this is bad style, since AssertError is in
core.exception. If this is considered bad style in D, I can
create a
JSONMarshalException and throw that instead.
That makes sense too. There is enforceEx() to throw a specific
type of exception.
Ali
Good point. I'll probably make a JSONMarshalException, which is
separate from JSONException in std.json so the library clearly
indicates which part failed.
Thanks for the link, it was an interesting read! Maybe I'll have
to dig around in std.traits and maybe add some missing stuff.
With mixin() (I'd forgotten about it) I was able to get rid of
all __traits calls except for allMembers.
Re: Sorting algorithms
On Mon, Oct 15, 2012 at 5:52 PM, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: I wanted to investigate small sorts using sorting networks for ages, but never got around to it. That's important for quicksort because it produces many small arrays that need sorting. Could you also test for very small sizes (2 to 4) and essentially test for 1-increment speed up to, say, 30 elements? I assume that's where the major wins come. I think we could use CT-generated sorting networks for arrays below a specific size. The converse risk is growth of generated code. Here: http://dpaste.dzfl.pl/42fac981 I don't know if the benchmarking code is OK. I substract a reference because randomly shuffling an array takes some time. Results for my computer (smaller ratio means faster network sort compared to std.algorithm.sort) Size 1, network: 2.10, std.algorithm.sort: 15.86, ratio network/std.algo: 0.13 Size 2, network: 2.23, std.algorithm.sort: 14.26, ratio network/std.algo: 0.16 Size 3, network: 6.22, std.algorithm.sort: 20.75, ratio network/std.algo: 0.30 Size 4, network: 8.25, std.algorithm.sort: 28.36, ratio network/std.algo: 0.29 Size 5, network: 18.54, std.algorithm.sort: 39.02, ratio network/std.algo: 0.48 Size 6, network: 20.12, std.algorithm.sort: 45.58, ratio network/std.algo: 0.44 Size 7, network: 27.49, std.algorithm.sort: 55.53, ratio network/std.algo: 0.50 Size 8, network: 33.91, std.algorithm.sort: 66.02, ratio network/std.algo: 0.51 Size 9, network: 53.98, std.algorithm.sort: 75.54, ratio network/std.algo: 0.71 Size 10, network: 46.66, std.algorithm.sort: 81.68, ratio network/std.algo: 0.57 Size 11, network: 65.06, std.algorithm.sort: 111.25, ratio network/std.algo: 0.58 Size 12, network: 66.31, std.algorithm.sort: 109.40, ratio network/std.algo: 0.61 Size 13, network: 74.84, std.algorithm.sort: 115.94, ratio network/std.algo: 0.65 Size 14, network: 90.05, std.algorithm.sort: 131.84, ratio network/std.algo: 0.68 Size 15, network: 95.23, std.algorithm.sort: 145.31, ratio network/std.algo: 0.66 Size 16, network: 104.66, std.algorithm.sort: 162.84, ratio network/std.algo: 0.64 Size 17, network: 125.30, std.algorithm.sort: 167.49, ratio network/std.algo: 0.75 Size 18, network: 133.10, std.algorithm.sort: 182.20, ratio network/std.algo: 0.73 Size 19, network: 143.92, std.algorithm.sort: 195.58, ratio network/std.algo: 0.74 Size 20, network: 155.01, std.algorithm.sort: 211.59, ratio network/std.algo: 0.73 Size 21, network: 171.43, std.algorithm.sort: 224.47, ratio network/std.algo: 0.76 Size 22, network: 177.46, std.algorithm.sort: 236.92, ratio network/std.algo: 0.75 Size 23, network: 192.22, std.algorithm.sort: 253.38, ratio network/std.algo: 0.76 Size 24, network: 205.39, std.algorithm.sort: 270.83, ratio network/std.algo: 0.76 Size 25, network: 213.25, std.algorithm.sort: 281.01, ratio network/std.algo: 0.76 Size 26, network: 233.96, std.algorithm.sort: 283.57, ratio network/std.algo: 0.83 Size 27, network: 246.73, std.algorithm.sort: 297.67, ratio network/std.algo: 0.83 Size 28, network: 260.41, std.algorithm.sort: 313.88, ratio network/std.algo: 0.83 Size 29, network: 280.06, std.algorithm.sort: 321.01, ratio network/std.algo: 0.87 Size 30, network: 298.65, std.algorithm.sort: 342.55, ratio network/std.algo: 0.87 Size 31, network: 308.09, std.algorithm.sort: 355.70, ratio network/std.algo: 0.87 Size 32, network: 323.89, std.algorithm.sort: 380.31, ratio network/std.algo: 0.85 On the computers I tested it (Windows, Linux, different machines), the cutoff is at about 35-38 elements.
Returning dynamic array from the function
I tryed to learn how arrays works and found another strange thing:
import std.stdio;
int[] create()
{
int[5] a1 = [ 10, 20, 30, 40, 50 ];
int[] b1 = a1;
writeln(b1: , b1);
return b1;
}
void main()
{
int[] a2 = create();
writeln(a2: , a2);
}
Result of execution:
b1: [10, 20, 30, 40, 50]
a2: [-142625792, 32767, 4358059, 0, 5]
Please explain what's wrong with this code? Why variable a2
contains crap? Is this another dmd/druntime bug or I missed
something?
Re: Returning dynamic array from the function
On 2012-10-17, 21:17, m0rph wrote:
I tryed to learn how arrays works and found another strange thing:
import std.stdio;
int[] create()
{
int[5] a1 = [ 10, 20, 30, 40, 50 ];
int[] b1 = a1;
writeln(b1: , b1);
return b1;
}
void main()
{
int[] a2 = create();
writeln(a2: , a2);
}
Result of execution:
b1: [10, 20, 30, 40, 50]
a2: [-142625792, 32767, 4358059, 0, 5]
Please explain what's wrong with this code? Why variable a2 contains
crap? Is this another dmd/druntime bug or I missed something?
b1 points to the exact same data as does a1. This data is stack-
allocated, and thus a2 points to an overwritten stack frame.
--
Simen
Re: Returning dynamic array from the function
On Wednesday, 17 October 2012 at 19:22:05 UTC, Simen Kjaeraas
wrote:
On 2012-10-17, 21:17, m0rph wrote:
I tryed to learn how arrays works and found another strange
thing:
import std.stdio;
int[] create()
{
int[5] a1 = [ 10, 20, 30, 40, 50 ];
int[] b1 = a1;
writeln(b1: , b1);
return b1;
}
void main()
{
int[] a2 = create();
writeln(a2: , a2);
}
Result of execution:
b1: [10, 20, 30, 40, 50]
a2: [-142625792, 32767, 4358059, 0, 5]
Please explain what's wrong with this code? Why variable a2
contains crap? Is this another dmd/druntime bug or I missed
something?
b1 points to the exact same data as does a1. This data is stack-
allocated, and thus a2 points to an overwritten stack frame.
It doesn't give an error when marking the function with safe.
@safe
int[] create()
{
}
Re: Code review: JSON unmarshaller
Here's the updated code. It's got a marshaller and unmarshaller: https://gist.github.com/3894337 It's about 650 lines. If you have time, I'd be very interested in getting some feedback (or from anyone else who sees this post of course). The main problem I'm having right now is that classes/structs have to be static. I'm not 100% sure why the compiler cannot see non-static classes/structs at compile time. Do you happen to know why? It seems like a template should work in either case, assuming I'm understanding D templates correctly. I didn't find any clear documentation for static outer classes, only static inner classes. It's not the same as static Java classes, which cannot be instantiated (if memory serves).
Re: Returning dynamic array from the function
b1 points to the exact same data as does a1. This data is stack- allocated, and thus a2 points to an overwritten stack frame. Thanks for explanation, I thought contetns of a1 are copied to the heap when assignment operator executed.
Re: Returning dynamic array from the function
sclytrack:
It doesn't give an error when marking the function with safe.
@safe
int[] create()
{
}
I think marking it @safe is not relevant. In theory a good type
system should give an error message on similar code. I don't know
if D is supposed to spot similar error situations.
Bye,
bearophile
Re: Code review: JSON unmarshaller
On Tuesday, 16 October 2012 at 06:37:55 UTC, Jacob Carlborg wrote: The goal of Orange was to be able serialize basically everything found in D. Can it serialize Variant?
Re: Returning dynamic array from the function
On Wednesday, October 17, 2012 21:46:50 bearophile wrote:
sclytrack:
It doesn't give an error when marking the function with safe.
@safe
int[] create()
{
}
I think marking it @safe is not relevant. In theory a good type
system should give an error message on similar code. I don't know
if D is supposed to spot similar error situations.
@safe is irrelevant, because the code is just plain broken in the first place.
It really should be an error (
http://d.puremagic.com/issues/show_bug.cgi?id=7087 ), just like it's an error
to return a pointer to a local variable. But unfortunately, since all it takes
to trick the compiler is passing the slice (or pointer in the case of the
pointer to a local variable) to a function which then returns that
slice/pointer, there's no way for the compiler to always catch it for you.
The only way that @safe could really be applicable would be if it became
@system to take the address of a local variable or to slice a static array.
And perhaps it should be, but that and catching the most obvious cases are all
that the compiler could do to catch this for you.
- Jonathan M Davis
Re: Returning dynamic array from the function
On Wednesday, 17 October 2012 at 19:46:51 UTC, bearophile wrote:
sclytrack:
It doesn't give an error when marking the function with safe.
@safe
int[] create()
{
}
I think marking it @safe is not relevant. In theory a good type
system should give an error message on similar code. I don't
know if D is supposed to spot similar error situations.
Bye,
bearophile
If that's the case then they should call it safeR D instead of
safe D.
Re: Operator overloading through UFCS doesn't work
On 10/17/12 12:46, Timon Gehr wrote: On 10/15/2012 01:00 PM, Artur Skawina wrote: ... An overloaded operator is just another normal method; you get the same type of problems when dealing with normal methods - eg in types having an alias this - an UFCS method must take precedence over one reachable via the alias - just like in the overloaded op case. The only sane alternative would be disallowing UFCS for types with an alias this (which would be a severe limitation). ... Just no. Why make symbol lookup even more complicated just in order to add an strange exception to the language that either enables new forms of hijacking or would be a severe limitation? Like i said in a later message - I think the /functionality/ should be available, how it's handled is a different issue. The reason why I'd want UFCS take priority over alias-this is that in the presence of multiple aliases and external components method hijacking is actually likely to become a problem. Eg a newer /library/ version can silently hijack an apps UFCS extension method. Plus, the aliases can severely limit the available ufcs namespace; and the compiler won't even flag many conflicts as errors. UFCS is a much cheaper alternative to sub-typing, having it work for as many cases as possible is important. Think: app that uses an own GUI module on top of a themeing library on top of a GUI widget toolkit on top of a basic windowing system. Being able to extend functionality (by adding just a method or two, in the app) without having to create an extra type hierarchy and dealing with all the conversion issues could be very useful. UFCS is just optional syntax sugar, so I can buy the 'no changes for this' argument - only then I fear that it's usefulness decreases to the point where the cost is no longer justified. For the cases where creating a new type is overkill, one can always use a free function. [Yeah, I'm ignoring the 'functional-style' aspect, I know. UFCS might help there, but a DSL would be better long-term solution IMHO, and would also avoid the @property related issues (extra parens). But that's off-topic, at least in this thread.] artur
Re: Returning dynamic array from the function
Jonathan M Davis: there's no way for the compiler to always catch it for you. I think there are type systems able to always catch this kind of bug (conservative region analysis, it means that if it can't demonstrate the memory doesn't escape, it prudently refuses the code). D doesn't have such kind of type system. Bye, bearophile
Re: Returning dynamic array from the function
The only way that @safe could really be applicable would be if it became @system to take the address of a local variable or to slice a static array. And perhaps it should be, but that and catching the most obvious cases are all that the compiler could do to catch this for you. Hmmm, you could have the compiler add a runtime check and see if slices are stack allocated (EAX = ESP I think), then quit with an error, or alternatively it would make a copy afterwards, or at least a warning.
Re: Returning dynamic array from the function
On Wednesday, October 17, 2012 13:07:13 Jonathan M Davis wrote: The only way that @safe could really be applicable would be if it became @system to take the address of a local variable or to slice a static array. And perhaps it should be, but that and catching the most obvious cases are all that the compiler could do to catch this for you. It looks like taking the address of a local variable already is @system, but taking a slice of a static array is not. That really should change: http://d.puremagic.com/issues/show_bug.cgi?id=8838 - Jonathan M Davis
Re: How to define an interator to provide array like behaviour in a class?
1. Define opApply (see section labeled Foreach over Structs and Classes with opApply after here: http://dlang.org/statement.html#foreach_with_ranges) 2. Or make it a range (see http://dlang.org/statement.html#foreach_with_ranges and http://ddili.org/ders/d.en/ranges.html ), which would probably be a bad idea, since containers really shouldn't be ranges. 3. Or do what std.container does and overload opSlice which returns a range over the container (see http://dlang.org/operatoroverloading.html#Slice and http://dlang.org/phobos/std_container.html in addition to the links in #2). Overall, this is the best approach. But regardless of which approach you take, you really should read up on ranges if you want to be doing much with D's standard library, and http://ddili.org/ders/d.en/ranges.html is the best tutorial on them at this point. There's also this recent article by Walter Bright which explains one of the main rationales behind ranges: http://www.drdobbs.com/architecture-and-design/component-programming-in- d/240008321 - Jonathan M Davis Awesome thanks Jonathan! I've read that guide on ranges before and they sound very interesting. I'm currently playing with recursive collections and opApply works great.
Re: Returning dynamic array from the function
On 10/17/2012 10:15 PM, sclytrack wrote:
On Wednesday, 17 October 2012 at 19:46:51 UTC, bearophile wrote:
sclytrack:
It doesn't give an error when marking the function with safe.
@safe
int[] create()
{
}
I think marking it @safe is not relevant. In theory a good type system
should give an error message on similar code. I don't know if D is
supposed to spot similar error situations.
Bye,
bearophile
If that's the case then they should call it safeR D instead of safe D.
I think what he meant to say was that it should be illegal to do this
even in @system code, not that it is OK that it passes with @safe.
Re: Code review: JSON unmarshaller
On Wednesday, 17 October 2012 at 19:44:47 UTC, Tyler Jameson Little wrote: The main problem I'm having right now is that classes/structs have to be static. That seems weird, I've done something similar with non-static structs before. Maybe it will help if you use __traits(getMember, obj, name) instead of mixin.
Re: Sorting algorithms
On 10/17/12 3:07 PM, Philippe Sigaud wrote: On Mon, Oct 15, 2012 at 5:52 PM, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: I wanted to investigate small sorts using sorting networks for ages, but never got around to it. That's important for quicksort because it produces many small arrays that need sorting. Could you also test for very small sizes (2 to 4) and essentially test for 1-increment speed up to, say, 30 elements? I assume that's where the major wins come. I think we could use CT-generated sorting networks for arrays below a specific size. The converse risk is growth of generated code. Here: http://dpaste.dzfl.pl/42fac981 I don't know if the benchmarking code is OK. I substract a reference because randomly shuffling an array takes some time. Results for my computer (smaller ratio means faster network sort compared to std.algorithm.sort) Size 1, network: 2.10, std.algorithm.sort: 15.86, ratio network/std.algo: 0.13 Size 2, network: 2.23, std.algorithm.sort: 14.26, ratio network/std.algo: 0.16 Size 3, network: 6.22, std.algorithm.sort: 20.75, ratio network/std.algo: 0.30 Size 4, network: 8.25, std.algorithm.sort: 28.36, ratio network/std.algo: 0.29 Size 5, network: 18.54, std.algorithm.sort: 39.02, ratio network/std.algo: 0.48 Size 6, network: 20.12, std.algorithm.sort: 45.58, ratio network/std.algo: 0.44 Size 7, network: 27.49, std.algorithm.sort: 55.53, ratio network/std.algo: 0.50 Size 8, network: 33.91, std.algorithm.sort: 66.02, ratio network/std.algo: 0.51 [snip] Looking great, thanks. I'm on the road with little time and connectivity, but I want to encourage you with integrating this with std.sort. There seems to be a big gain drop off at size 9, so we could use sorting networks for size = 8. (I'm also worried about generated code size.) So next step would be to integrate the sorting network within std.sort and see how it works there. Please don't let this good work go to waste! Andrei
std.range.chunks for char[]
Is there an equivalent to std.range.chunks that will work on a char array? As in, it will return a range iterating over chunks of code points?
Re: std.range.chunks for char[]
On Thursday, October 18, 2012 01:19:02 cal wrote: Is there an equivalent to std.range.chunks that will work on a char array? As in, it will return a range iterating over chunks of code points? Not that I'm aware of (though there _may_ be a function that you could do it with that I'm not thinking of), but such a function would be an order of magnitude worse than chunks, because it would have to actually walk the string to determine where to slice it. Writing it would be fairly trivial though. - Jonathan M Davis
independent or parallel process
I want the function below to run independently -- like a unix
background process, without delaying subsequent code in main. I
tried the following using std.parallelism:
void main() {
function_a(int a, int b) {
...
}
auto new_task = task!function_a(11, 12);
new_task.executeInNewThread(1);
// more code ...
}
I get errors: core.thread.ThreadException ... unable to set
thread priority ...
Re: optlink and weak symbols
On 10/16/2012 11:16 PM, Jacob Carlborg wrote: You need to declare the variable as extern if it's defined in the C code: extern(C) extern __gshared PyTypeObject PyType_Type; http://dlang.org/interfaceToC.html#C%20Globals nice tip, but adding extern doesn't change link behavior at all.
