Re: Universal Construction Syntax for Pointers?
On 06/13/2014 10:29 PM, Meta wrote: I thought this was possible, but DMD 2.065 doesn't allow it, saying no constructor for int: int* p = new int(3); Is something like this planned for the future? I know we can already do: int n = int(3); Those both compile with 2.066 Ali
Re: Universal Construction Syntax for Pointers?
On Saturday, 14 June 2014 at 06:39:56 UTC, Ali Çehreli wrote: On 06/13/2014 10:29 PM, Meta wrote: I thought this was possible, but DMD 2.065 doesn't allow it, saying no constructor for int: int* p = new int(3); Is something like this planned for the future? I know we can already do: int n = int(3); Those both compile with 2.066 Ali Right, thanks. It's difficult to keep track of what's already released and what's in Git HEAD.
Re: Universal Construction Syntax for Pointers?
Would auto i = (int*)(3); make sense? Does it work?
Re: Does __gshared have shared semantics?
On Sat, 14 Jun 2014 01:24:03 +
Mike Franklin via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
In other words, is 'shared __gshared' redundant?
Redundant? Not exactly.
__gshared makes it so that the variable is treated like a C variable - it's
not in TLS - but its _type_ is still considered to be thread-local by D. So,
you get no protection from the type system when using a __gshared variable.
It'll treat it like a normal, TLS variable. So, you need to be very careful
when using __gshared.
shared on the other hand _is_ treated differently by the type system. Like
__gshared, it's not in TLS, but that fact is then embedded in its type, so the
compiler won't make any optimizations based on TLS for a shared variable, and
it will at least partially protect you agains using it in contexts which are
guaranteed to be wrong for shared. e.g with the current version of the
compiler in git, this code
shared int i;
void main()
{
++i;
}
produces this error
q.d(5): Deprecation: Read-modify-write operations are not allowed for shared
variables. Use core.atomic.atomicOp!+=(i, 1) instead.
whereas if it were __gshared, it wouldn't complain at all.
So, when marking a variable both shared and __gshared, the __gshared is kind
of pointless, since shared essentially indicates everything that __gshared
does plus more. However, the compiler will give you an error message if you
try (at least with the current git master anyway - I'm not sure what it did
with 2.065, since I don't have it installed at the moment), so there really
isn't much reason to worry about what it would actually do if it compiled.
- Jonathan M Davis
Re: Universal Construction Syntax for Pointers?
On Saturday, 14 June 2014 at 08:09:12 UTC, Philippe Sigaud via Digitalmars-d-learn wrote: Would auto i = (int*)(3); make sense? Does it work? No: Error: C style cast illegal, use cast(int*)3 And I don't think it should, because the heap allocation that you're probably expecting should be explicit IMO. For me it's also unintuitive, because I would read it as constructing a pointer that points to the address 3.
Re: Why is stdin.byLine.writeln so slow?
On Friday, 13 June 2014 at 22:12:01 UTC, Ali Çehreli wrote:
On 06/13/2014 03:02 PM, monarch_dodra wrote:
No, it just receives a range, so it does range formating. eg:
[ ~ Element ~ , ~ Element ... ].
It still looks like it could send the formatting characters as
well as the elements separately to the output stream:
[
Element
,
...
]
I am assuming that the slowness in OP's example is due to
constructing a long string.
It already does what you suggest, and doesn't constructing one
big string. You can test this
void main() {
import std.stdio;
stdin.byLine.writeln;
}
When you type in several lines in the terminal, it will output
the first element as soon as you pressed enter for the first line.
Re: DMD Fails with fPIC error
On 06/14/2014 03:58 AM, Reuben wrote: Hi, I'm new to D and am trying to compile a simple hello world program. I get the following error when compiling it: dmd test.d /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../../../x86_64-pc-linux-gnu/bin/ld: /opt/dmd-2.065/lib64/libphobos2.a(lifetime_488_4cd.o): relocation R_X86_64_32 against `_D15TypeInfo_Shared7__ClassZ' can not be used when making a shared object; recompile with -fPIC /opt/dmd-2.065/lib64/libphobos2.a: could not read symbols: Bad value collect2: error: ld returned 1 exit status --- errorlevel 1 This error occurs regardless of whether I use the -fPIC option or not. Compiling DMD from source does not change anything. I am using DMD 2.065.0 on Sabayon amd64, compiled from the dlang overlay with gcc (Gentoo Hardened 4.7.3-r1 p1.4, pie-0.5.5) 4.7.3. Thanks in advance. From the error it looks like you are compiling test.d as shared while linking against the static version of the standard library. If dmd test.d is the command being run there probably is an error in with the configuration in dmd.conf, the conf file is probably in /etc. Depending on the desired behavior you'll need to remove the -shared flag from the configuration or add -defaultlib=:libphobos2.so -- Mike Wey
Re: Casts and @trusted
That really is it. The other methods are just other gets to the
buffer, like this:
T[] get_dup(TS strat=TS.cyclic)(size_t n) const {
static if (strat==TS.once) size_t numreads = fixNToFill(n);
else size_t numreads = n;
auto ret = new T[](numreads);
size_t read = index;
foreach(i;0..numreads) {
ret[i] = _buffer[read].dup;
if (read == 0) read = fill-1;
else --read;
}
return ret;
}
But ah, the .ptr property is not supposed to work for array
element? In any case it still works as cast(T*) (_buffer[read]).
Here's the unittest I slapped together:
unittest {
char[5] hello = hello;
char[5] world = world;
char[5] forty = forty;
char[5] three = three;
char[5] gdbye = gdbye;
alias chars_t = char[5];
chars_t[] foo = [hello,world,forty,three];
chars_t[] oob = foo.dup.reverse;
StaticRingBuffer!(chars_t,4) bar;
bar.put(foo);
assert(bar.index==3);
const(chars_t)*[4] ptrs;
bar.get_ref(4,ptrs);
assert(bar.get_dup(4) == oob);
foreach(i,ptr; ptrs) assert(*ptr == oob[i]);
assert(bar.get_dup(7) ==
[three,forty,world,hello,three,forty,world]);
bar.put(gdbye);
assert(bar.index==0);
assert(bar.get_dup(4) == [gdbye,three,forty,world]);
assert(bar.get_dup(7) ==
[gdbye,three,forty,world,gdbye,three,forty]);
}
But now I see my problem is that a simple const(T*)[N] already
initializes its elements to null, so nothing past that should
modify them. And without the casts, the type on (_buffer[read])
is a const(T*) instead of something else which finally makes
sense. Somehow I thought .ptr was a property of everything.
And now I realize that I can just put the ptr array within the
get scope, and return it, to initialize a lhs const(T*)[] by
value. I was making things hard on myself by trying to modify a
passed-in buffer.
Subclass of Exception
One stupid question: in Python subclassing of Exception looks
like:
class MyError(Exception): pass
but in D, if I'm right, we should write more code:
class MyError : Exception {
this(string msg) { super(msg); }
}
(without constructor we get error: ...Cannot implicitly generate
a default ctor when base class BASECLASS is missing a default
ctor...)
Is any shorter D way?
Re: DMD Fails with fPIC error
On Saturday, 14 June 2014 at 10:45:25 UTC, Mike Wey wrote: On 06/14/2014 03:58 AM, Reuben wrote: Hi, I'm new to D and am trying to compile a simple hello world program. I get the following error when compiling it: dmd test.d /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../../../x86_64-pc-linux-gnu/bin/ld: /opt/dmd-2.065/lib64/libphobos2.a(lifetime_488_4cd.o): relocation R_X86_64_32 against `_D15TypeInfo_Shared7__ClassZ' can not be used when making a shared object; recompile with -fPIC /opt/dmd-2.065/lib64/libphobos2.a: could not read symbols: Bad value collect2: error: ld returned 1 exit status --- errorlevel 1 This error occurs regardless of whether I use the -fPIC option or not. Compiling DMD from source does not change anything. I am using DMD 2.065.0 on Sabayon amd64, compiled from the dlang overlay with gcc (Gentoo Hardened 4.7.3-r1 p1.4, pie-0.5.5) 4.7.3. Thanks in advance. From the error it looks like you are compiling test.d as shared while linking against the static version of the standard library. If dmd test.d is the command being run there probably is an error in with the configuration in dmd.conf, the conf file is probably in /etc. Depending on the desired behavior you'll need to remove the -shared flag from the configuration or add -defaultlib=:libphobos2.so dmd.conf contains the default settings. I haven't specified -shared anywhere. The only thing I can think of is that if -fPIC is required, DMD might be implying it somehow. Compiling with -defaultlib seems to have fixed it. I'm getting a warning, but the program compiles and seems to run OK. dmd -defaultlib=:libphobos2.so -fPIC test.d /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../../../x86_64-pc-linux-gnu/bin/ld: test.o: warning: relocation in readonly section `.rodata'. /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../../../x86_64-pc-linux-gnu/bin/ld: warning: creating a DT_TEXTREL in object. Is the warning something I should be worried about?
Re: Universal Construction Syntax for Pointers?
And I don't think it should, because the heap allocation that you're probably expecting should be explicit IMO. For me it's also unintuitive, because I would read it as constructing a pointer that points to the address 3. I agree. I'm trying to get a feel on the limits of this new 'type(value)' syntax.
Re: Subclass of Exception
Paul:
class MyError : Exception {
this(string msg) { super(msg); }
}
Don't call exceptions errors, because in D there are also errors,
so they should have distinct names.
Is any shorter D way?
Perhaps not.
Bye,
bearophile
Re: Subclass of Exception
On Saturday, 14 June 2014 at 11:59:53 UTC, Paul wrote:
One stupid question: in Python subclassing of Exception looks
like:
class MyError(Exception): pass
but in D, if I'm right, we should write more code:
class MyError : Exception {
this(string msg) { super(msg); }
}
(without constructor we get error: ...Cannot implicitly
generate a default ctor when base class BASECLASS is missing
a default ctor...)
Is any shorter D way?
In this regard D is same as C++. When you create derived class,
you need to define constructors, even if all they do is passing
arguments to base class' constructor. It's really annoying,
especially when base class has many constructors.
But in D you can apply some template magic to automate this
process for exceptions.
Example:
import std.stdio;
template TemplateException(T)
{
class TemplateException : Exception
{
public:
this(string msg, string file = __FILE__, size_t line =
__LINE__, Throwable next = null) {
super(msg, file, line, next);
}
}
}
void throwException(Exception ex)
{
try {
throw ex;
}
catch(TemplateException!int e) {
writeln(int);
}
catch(TemplateException!double e) {
writeln(double);
}
catch(TemplateException!string e) {
writeln(string);
}
}
int main()
{
auto intEx = new TemplateException!int(int error);
auto doubleEx = new TemplateException!double(double error);
auto stringEx = new TemplateException!string(string error);
throwException(intEx);
throwException(doubleEx);
throwException(stringEx);
return 0;
}
You also can tempalte with string literals instead of types to
gain more flexibility and use alias statement to provide
convenient names.
Re: Subclass of Exception
On Saturday, 14 June 2014 at 12:17:46 UTC, FreeSlave wrote:
On Saturday, 14 June 2014 at 11:59:53 UTC, Paul wrote:
One stupid question: in Python subclassing of Exception looks
like:
class MyError(Exception): pass
but in D, if I'm right, we should write more code:
class MyError : Exception {
this(string msg) { super(msg); }
}
(without constructor we get error: ...Cannot implicitly
generate a default ctor when base class BASECLASS is missing
a default ctor...)
Is any shorter D way?
In this regard D is same as C++. When you create derived class,
you need to define constructors, even if all they do is passing
arguments to base class' constructor. It's really annoying,
especially when base class has many constructors.
But in D you can apply some template magic to automate this
process for exceptions.
Example:
import std.stdio;
template TemplateException(T)
{
class TemplateException : Exception
{
public:
this(string msg, string file = __FILE__, size_t line =
__LINE__, Throwable next = null) {
super(msg, file, line, next);
}
}
}
void throwException(Exception ex)
{
try {
throw ex;
}
catch(TemplateException!int e) {
writeln(int);
}
catch(TemplateException!double e) {
writeln(double);
}
catch(TemplateException!string e) {
writeln(string);
}
}
int main()
{
auto intEx = new TemplateException!int(int error);
auto doubleEx = new TemplateException!double(double
error);
auto stringEx = new TemplateException!string(string
error);
throwException(intEx);
throwException(doubleEx);
throwException(stringEx);
return 0;
}
You also can tempalte with string literals instead of types to
gain more flexibility and use alias statement to provide
convenient names.
Thank you!!
Re: DMD Fails with fPIC error
On 06/14/2014 02:01 PM, Reuben wrote: On Saturday, 14 June 2014 at 10:45:25 UTC, Mike Wey wrote: On 06/14/2014 03:58 AM, Reuben wrote: Depending on the desired behavior you'll need to remove the -shared flag from the configuration or add -defaultlib=:libphobos2.so dmd.conf contains the default settings. I haven't specified -shared anywhere. The only thing I can think of is that if -fPIC is required, DMD might be implying it somehow. Try running dmd test.d -v the last line in the outpus from dmd should show hows it's invoking gcc for the linking step. Posting that here might give us some clue of what dmd is doing. Compiling with -defaultlib seems to have fixed it. I'm getting a warning, but the program compiles and seems to run OK. dmd -defaultlib=:libphobos2.so -fPIC test.d /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../../../x86_64-pc-linux-gnu/bin/ld: test.o: warning: relocation in readonly section `.rodata'. /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../../../x86_64-pc-linux-gnu/bin/ld: warning: creating a DT_TEXTREL in object. Is the warning something I should be worried about? I don't know about this one. -- Mike Wey
Re: Returning dynamic array from the function
Hi, I'm new to D and stumbled upon this very interesting discussion. My question now is: can you provide an example of how to return a collection of homogeneous elements whose size is not known at compile time (for wich you would normally use a dynamic array) from a function? Thanks, Marco
Is it normal that unittests of phobos are executed with my project build?
I get a failure on a test in format.d when I build my own project with unittest. I though importing phobos header would not regenerate their unittest modules. Any idea of what can cause this issue? I already have reinstalled dmd with visualD completely.
Re: DMD Fails with fPIC error
On Saturday, 14 June 2014 at 13:05:52 UTC, Mike Wey wrote: On 06/14/2014 02:01 PM, Reuben wrote: On Saturday, 14 June 2014 at 10:45:25 UTC, Mike Wey wrote: On 06/14/2014 03:58 AM, Reuben wrote: Depending on the desired behavior you'll need to remove the -shared flag from the configuration or add -defaultlib=:libphobos2.so dmd.conf contains the default settings. I haven't specified -shared anywhere. The only thing I can think of is that if -fPIC is required, DMD might be implying it somehow. Try running dmd test.d -v the last line in the outpus from dmd should show hows it's invoking gcc for the linking step. Posting that here might give us some clue of what dmd is doing. dmd test.d -v gcc test.o -o test -m64 -L/opt/dmd-2.065/lib64 -Xlinker -rpath -Xlinker /opt/dmd-2.065/lib64 -Xlinker --export-dynamic -l:libphobos2.a -lpthread -lm -lrt dmd -defaultlib=:libphobos2.so -fPIC test.d -v gcc test.o -o test -m64 -L/opt/dmd-2.065/lib64 -Xlinker -rpath -Xlinker /opt/dmd-2.065/lib64 -Xlinker --export-dynamic -l:libphobos2.so -lpthread -lm -lrt It looks like the only difference is which version of Phobos we link. I think the reason for this might be that since my version of gcc is hardened, it uses -fPIE by default for linking. (http://wiki.gentoo.org/wiki/Hardened/Toolchain#Automatic_generation_of_Position_Independent_Executables_.28PIEs.29)
Re: Returning dynamic array from the function
On Saturday, 14 June 2014 at 14:02:52 UTC, Marco Cosentino wrote:
Hi,
I'm new to D and stumbled upon this very interesting discussion.
My question now is:
can you provide an example of how to return a collection of
homogeneous elements whose size is not known at compile time
(for
wich you would normally use a dynamic array) from a function?
int[] foo() {
int[] data = [1,2,3,4];// create new array on the heap
data ~= [5,6,7,8]; // append some data
return data;
}
The problem with the OP's code was not per se that he returned a
slice, but that he took this slice from a fixed-length local
array. The example above doesn't do that, and is therefore safe.
Re: hijacking override from template mixin
On Monday, 9 June 2014 at 15:54:21 UTC, Ivan Kazmenko wrote: I'd expect a multiple overrides of same function error, much like if I just paste the mixin code by hand. Is that a bug or working by design? In the latter case, please explain the reasoning. http://dlang.org/template-mixin.html says: The declarations in a mixin are ‘imported’ into the surrounding scope. If the name of a declaration in a mixin is the same as a declaration in the surrounding scope, the surrounding declaration overrides the mixin one.
Re: Returning dynamic array from the function
int[] data = [1,2,3,4];// create new array on the heap Thanks for the answer. This is the bit of information I was missing: how to create an array in the heap. Is also this a valid way to do so? int[] data = new int[0]; data ~= [4,2,3,1];
Re: Returning dynamic array from the function
On Saturday, 14 June 2014 at 21:37:51 UTC, Marco Cosentino wrote: int[] data = [1,2,3,4];// create new array on the heap Thanks for the answer. This is the bit of information I was missing: how to create an array in the heap. Is also this a valid way to do so? int[] data = new int[0]; data ~= [4,2,3,1]; Simply int[] = [4,2,3,1]; will do. Arrays are always created on the heap by default. To override that, you can assign to a static array, which resides on the the stack. Then you slice your static array.
Re: Subclass of Exception
On Sat, 14 Jun 2014 11:59:52 +
Paul via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote:
One stupid question: in Python subclassing of Exception looks
like:
class MyError(Exception): pass
but in D, if I'm right, we should write more code:
class MyError : Exception {
this(string msg) { super(msg); }
}
(without constructor we get error: ...Cannot implicitly generate
a default ctor when base class BASECLASS is missing a default
ctor...)
Is any shorter D way?
If you're creating an exception that doesn't take any new arguments (so it's
just its type that's important rather than it having any new members), then
the typical declaration would be
/++
My exception type.
+/
class MyException : Exception
{
/++
Params:
msg = The message for the exception.
file = The file where the exception occurred.
line = The line number where the exception occurred.
next = The previous exception in the chain of exceptions, if any.
+/
this(string msg, string file = __FILE__, size_t line = __LINE__, Throwable
next = null) @safe pure nothrow
{
super(msg, file, line, next);
}
/++
Params:
msg = The message for the exception.
next = The previous exception in the chain of exceptions.
file = The file where the exception occurred.
line = The line number where the exception occurred.
+/
this(string msg, Throwable next, string file = __FILE__, size_t line =
__LINE__) @safe pure nothrow
{
super(msg, file, line, next);
}
}
There have been attempts to write mixins or templates which generate this for
you - e.g.
mixin(genExceptionType(MyException));
but then you can't have documentation on it, because mixed-in code is not
examined when the documentation is generated, and you can't document the mixin
itself. So, at this point, it just makes the most sense to take my example,
change its name and documentation, and then use that rather than trying to
generate it - though if you don't care about documentation at all (which is
usually a bad idea but might make sense on small projects), then it would be
simple enough to create a function which will generate the string to mix in
for you.
- Jonathan M Davis
what is going on with cgcs.c:351?
I've bumped up against this cryptic error from time to time. I can't really pin it down to a simple self contained example as it tends to come up when I try to have template-heavy modules interact and there is a lot to untangle. I can't see the pattern in my code that triggers the assertion failure. Right now, its happening when attempting to use a struct that returns itself after each option is set, so that I can chain options... when I use this struct in one part of my code, it's fine. When I use it in another, I get a failure at backend/cgcs:351... but only if I try to set any of the options. I've been slowly making my way through my code trying to bracket the problem but there's a lot of complicating factors, like Algebraic!T and templated constructors and structs that alias functions that retrieve from __gshared associative arrays, so it is going slowly. Looking through the source cgcs.c, it seems to have something to do with operators and/or parsing expression trees. Maybe the error is caused by my use of opDispatch, or forwarding operator functions to aliases. The only other hint is this comment in the source code: /* optelem() should have removed these */ What should I do in this situation?
Re: what is going on with cgcs.c:351?
On Sun, Jun 15, 2014 at 04:44:06AM +, Vlad Levenfeld via Digitalmars-d-learn wrote: I've bumped up against this cryptic error from time to time. I can't really pin it down to a simple self contained example as it tends to come up when I try to have template-heavy modules interact and there is a lot to untangle. Have you tried Vladimir Panteleev's excellent DustMite utility? It takes a (potentially very complicated) D source tree, a test command the checks for the particular failure you're experiencing, and incrementally reduces your code until it finds a minimal case that reproduces that error. Very handy for reducing large complicated projects that triggers an internal compiler error when it's infeasible to do the reduction by hand. It *may* sometimes take a long time to reduce the code, so it does help if you can remove the obviously irrelevant parts by hand first, but in any case it's better than trying to do the full reduction yourself -- you could let it run in the background while you work on something else in the meantime. T -- I am a consultant. My job is to make your job redundant. -- Mr Tom
Re: what is going on with cgcs.c:351?
Update and clarification: this triggers the error: flight_info.add (Plot (ts.zip (vs), gfx, txt) .color (blue*white) .title (`velocity`) , square (0.15) ); this compiles: flight_info.add (Plot (ts.zip (vs), gfx, txt), square (0.15)); this also compiles: auto plot = Plot (ts.zip (vs), gfx, txt); flight_info.add (plot .color (blue*white) , square (0.15) ); but this will not: auto plot = Plot (ts.zip (vs), gfx, txt); flight_info.add (plot .color (blue*white) .title (`velocity`) , square (0.15) ); For clarification, the Plot constructor (and all of its option-setting functions) return a copy of the Plot with the new option set. It looks like when I pass it through more than one layer of return this inside of the function arguments for flight_info.add, it triggers the backend/cgcs.c assertion.
Re: what is going on with cgcs.c:351?
I had not heard of this tool before. This looks like it's going to be very handy, thank you!
Re: what is going on with cgcs.c:351?
I'd also like to note that elsewhere in my code (in a unittest to
be precise), I am using the full functionality of the Plot struct
with no hiccups...
info.add (
Plot (ℕ!24.map!(i = 0.8*i)
.map!(x = τ(x, sin (x^^2))),
gfx, txt)
.title (`testing`)
.y_axis (`output`, Plot.Range (-1, 1))
.x_axis (`input`)
.text_size (8)
.color (blue * white),
square (0.5).map!(v = v*vec(1.2,1))
) .align_to (Alignment.top_right)
.decorate ((Bounding_Box bounds){gfx.draw (blue.alpha (0.5),
bounds);});
This compiles and runs without issues even though it is using
even more of the thing that made the other examples fail, in the
exact same sort of context.
