--
Why bother?
import std.algorithm : max;
F fun (F a, F b) { return max(a,b) + 1.; }
unittest { assert (gun(1, 2) == gun(2, 1)); } // Passes
F pun (F a, F b) { return sin(max(a,b)); }
unittest { assert (fun(1, 2) == fun(2, 1)); } // Fails
// Fun, gun, pun...
unittest { assert (fun(1, 2) =
On 08/27/2014 07:38 AM, Lemonfiend wrote:
I get:
src\app.d(19): Error: None of the overloads of 'foo' are callable using
argument types (C3), candidates are:
src\app.d(28):main.foo(C1 c)
src\app.d(38):main.foo(C2 c)
It does work when I explicitly import c3.foo.
--- file app.d
mo
On Monday, 28 July 2014 at 08:16:37 UTC, bearophile wrote:
Domingo Alvarez Duarte:
Based on a question about manually allocated structures with
payload I found that a solution proposed seems to work when
compiled with dmd but segfaults when compiled with gdc.
...
int size;
Domingo Alvarez Duarte:
Based on a question about manually allocated structures with
payload I found that a solution proposed seems to work when
compiled with dmd but segfaults when compiled with gdc.
...
int size;
char[0] _b;
@property char[] bu
On Saturday, 17 May 2014 at 01:08:47 UTC, Ali Çehreli wrote:
On 05/16/2014 05:55 PM, Alexandre L. wrote:
>
>> I'll try to fetch git head and get everything working.
>>
>> Alexandre L.
>
> Nevermind that.
> For some reasons, the bug was happening when my main.d file
looked like
> this:
>
> import
On 05/16/2014 05:55 PM, Alexandre L. wrote:
>
>> I'll try to fetch git head and get everything working.
>>
>> Alexandre L.
>
> Nevermind that.
> For some reasons, the bug was happening when my main.d file looked like
> this:
>
> import std.stdio;
> //import std.string; // will work when imported
I'll try to fetch git head and get everything working.
Alexandre L.
Nevermind that.
For some reasons, the bug was happening when my main.d file
looked like this:
import std.stdio;
//import std.string; // will work when imported
int main()
{
string str = "Les chemises";
// doesnt work
w
On Saturday, 17 May 2014 at 00:31:14 UTC, Ali Çehreli wrote:
On 05/16/2014 04:52 PM, Alexandre L. wrote:
Hello,
I was playing around with indexOf when I noticed that the
parameter
CaseSensitive seems to have a weird behavior.
Let's say the following code:
string str = "Les chemises sont sèch
On 05/16/2014 04:52 PM, Alexandre L. wrote:
Hello,
I was playing around with indexOf when I noticed that the parameter
CaseSensitive seems to have a weird behavior.
Let's say the following code:
string str = "Les chemises sont sèches";
write(std.string.indexOf(str, "Les")); // Returns 0, as ex
On 02/22/14 18:22, andrea9940 wrote:
> I was trying to get my vector struct to use extensively references for
> passing parameters and I found a subtle bug which make me lose a few hour.
>
> A sample code that shows the bug is here http://pastebin.com/rvcNdjAE (fails
> with dmd 2.064 on linux)
>
On Saturday, 22 February 2014 at 17:22:51 UTC, andrea9940 wrote:
Hi everyone,
I was trying to get my vector struct to use extensively
references for passing parameters and I found a subtle bug
which make me lose a few hour.
A sample code that shows the bug is here
http://pastebin.com/rvcNdjA
On Saturday, 22 February 2014 at 17:22:51 UTC, andrea9940 wrote:
Hi everyone,
I was trying to get my vector struct to use extensively
references for passing parameters and I found a subtle bug
which make me lose a few hour.
A sample code that shows the bug is here
http://pastebin.com/rvcNdjA
On Thursday, 13 February 2014 at 17:12:28 UTC, Dicebot wrote:
On Thursday, 13 February 2014 at 16:57:19 UTC, John Colvin
wrote:
Don't you mean const/immutable fields with initialisers don't
become instance fields? Or is this actually as strange as it
sounds?
Yes, it is legacy behavior (== bug
On Thursday, 13 February 2014 at 16:57:19 UTC, John Colvin wrote:
Don't you mean const/immutable fields with initialisers don't
become instance fields? Or is this actually as strange as it
sounds?
Yes, it is legacy behavior (== bug) that persisted since D1 days
and was addressed only recently
On Thursday, 13 February 2014 at 16:52:58 UTC, bearophile wrote:
Andre:
could you have a look whether this is a bug with tupleof?
In case you have a const string with a default value,
the attribute is not in the tupleof list.
struct A {
const string a = "abc";
string d;
}
void
Am 13.02.2014 17:52, schrieb bearophile:
Andre:
could you have a look whether this is a bug with tupleof?
In case you have a const string with a default value,
the attribute is not in the tupleof list.
struct A {
const string a = "abc";
string d;
}
void main(){
assert(A().tupleof.
Andre:
could you have a look whether this is a bug with tupleof?
In case you have a const string with a default value,
the attribute is not in the tupleof list.
struct A {
const string a = "abc";
string d;
}
void main(){
assert(A().tupleof.length == 2); // fails -> leng
Am 13.02.2014 17:42, schrieb Tobias Pankrath:
On Thursday, 13 February 2014 at 16:37:20 UTC, Andre wrote:
Hi,
could you have a look whether this is a bug with tupleof?
In case you have a const string with a default value,
the attribute is not in the tupleof list.
struct A {
const string a
On Thursday, 13 February 2014 at 16:37:20 UTC, Andre wrote:
Hi,
could you have a look whether this is a bug with tupleof?
In case you have a const string with a default value,
the attribute is not in the tupleof list.
struct A {
const string a = "abc";
string d;
}
void main(){
On Wednesday, 13 November 2013 at 11:25:58 UTC, bearophile wrote:
Gary Willoughby:
On Wednesday, 13 November 2013 at 11:03:48 UTC, bearophile
wrote:
Associative arrays don't have a dup.
According to this they do: http://dlang.org/hash-map.html
Right, sorry, I have added a note to the bug r
Gary Willoughby:
On Wednesday, 13 November 2013 at 11:03:48 UTC, bearophile
wrote:
Associative arrays don't have a dup.
According to this they do: http://dlang.org/hash-map.html
Right, sorry, I have added a note to the bug report.
Bye,
bearophile
On Wednesday, 13 November 2013 at 11:12:55 UTC, Gary Willoughby
wrote:
On Wednesday, 13 November 2013 at 11:03:48 UTC, bearophile
wrote:
Associative arrays don't have a dup.
According to this they do: http://dlang.org/hash-map.html
And adding parens works fine. `hashmap.dup()`.
On Wednesday, 13 November 2013 at 11:03:48 UTC, bearophile wrote:
Associative arrays don't have a dup.
According to this they do: http://dlang.org/hash-map.html
Gary Willoughby:
int[string] a;
auto b = a.sizeof;
auto c = a.length;
auto d = a.dup;
auto e = a.keys;
auto f = a.values;
a.rehash;
}
Compile with: rdmd -property test.d
Out
On Tuesday, 29 October 2013 at 11:46:53 UTC, Rene Zwanenburg
wrote:
On Monday, 28 October 2013 at 19:30:12 UTC, Maxim Fomin wrote:
Here is my attempt:
import std.stdio;
struct S
{
int i;
this(int i) { writefln("ctor, %X", i); this.i = i; }
this(this) { writefln("postblit, %X, %X", &th
On 10/29/2013 11:11 AM, Maxim Fomin wrote:
> On Tuesday, 29 October 2013 at 17:57:01 UTC, Ali Çehreli wrote:
>> http://forum.dlang.org/post/l4osr0$2f3q$1...@digitalmars.com
> I did this in 2 January
> (http://forum.dlang.org/thread/lpljpfjxwobniglwn...@forum.dlang.org) and
> received exactly
On Tuesday, 29 October 2013 at 17:57:01 UTC, Ali Çehreli wrote:
On 10/29/2013 08:47 AM, Maxim Fomin wrote:
On Monday, 28 October 2013 at 20:43:01 UTC, Ali Çehreli wrote:
What is the purpose of writeln in that delegate? Obviously,
to print
1. Yet it doesn't happen that way. Is this accepted to
On 10/29/2013 08:47 AM, Maxim Fomin wrote:
On Monday, 28 October 2013 at 20:43:01 UTC, Ali Çehreli wrote:
What is the purpose of writeln in that delegate? Obviously, to print
1. Yet it doesn't happen that way. Is this accepted to be a bug?
Should the programmer 'new' the object instead?
Ali
On Tuesday, 29 October 2013 at 12:03:09 UTC, Rene Zwanenburg
wrote:
On Monday, 28 October 2013 at 19:40:26 UTC, Maxim Fomin wrote:
The fact that structs are movable and there is too few struct
runtime reflection makes them noncollectable. However, you can
wrap struct inside class, in such case
On Tuesday, 29 October 2013 at 11:46:53 UTC, Rene Zwanenburg
wrote:
That's pretty nasty :). But I suspect this is a bug and not by
design. __dtor and __traits are, IMHO, the proverbial escape
hatch D should provide, so I think that's OK. I take it that by
control flow trick you mean the try/c
On Monday, 28 October 2013 at 20:43:01 UTC, Ali Çehreli wrote:
What is the purpose of writeln in that delegate? Obviously, to
print 1. Yet it doesn't happen that way. Is this accepted to be
a bug? Should the programmer 'new' the object instead?
Ali
In my opinion it is a corner case, a cons
On Monday, 28 October 2013 at 19:40:26 UTC, Maxim Fomin wrote:
The fact that structs are movable and there is too few struct
runtime reflection makes them noncollectable. However, you can
wrap struct inside class, in such case struct dtor will be
called.
Yeah, if wrapping inside a class would
On Monday, 28 October 2013 at 19:30:12 UTC, Maxim Fomin wrote:
Here is my attempt:
import std.stdio;
struct S
{
int i;
this(int i) { writefln("ctor, %X", i); this.i = i; }
this(this) { writefln("postblit, %X, %X", &this, i); }
~this() { writefln("dtor, %X, %X", &this, i); }
}
On 10/28/2013 12:30 PM, Maxim Fomin wrote:
> So do you *know* cases or suspect that they may exists? Or remember some
> bug issue?
>
> Here is my attempt:
>
> import std.stdio;
>
> struct S
> {
> int i;
> this(int i) { writefln("ctor, %X", i); this.i = i; }
> this(this) { writefln(
On Monday, 28 October 2013 at 10:07:15 UTC, Rene Zwanenburg wrote:
On Sunday, 27 October 2013 at 23:33:55 UTC, Ali Çehreli wrote:
That's news to me. I know that objects may never be destroyed
but why multiple times? How many lives do they have? ;)
Yeah, I'd like to know this as well. I do reme
On Monday, 28 October 2013 at 16:53:11 UTC, monarch_dodra wrote:
On Monday, 28 October 2013 at 10:07:15 UTC, Rene Zwanenburg
wrote:
Yeah, I'd like to know this as well. I do remember structs
allocated on the heap don't have their destructors called at
all due to the GC not being precise, I thin
On Monday, 28 October 2013 at 10:07:15 UTC, Rene Zwanenburg wrote:
Yeah, I'd like to know this as well. I do remember structs
allocated on the heap don't have their destructors called at
all due to the GC not being precise, I think.
But one object allowed to be destructed multiple times? That
On Sunday, 27 October 2013 at 23:33:55 UTC, Ali Çehreli wrote:
On 10/27/2013 03:04 PM, monarch_dodra wrote:
> it *could* be an (older) emplace bug. Do you reproduce with
head?
I had tested it with head. No, doesn't happen on head.
Thanks for testing that. I'm not set up to build dmd or phobos
On 10/27/2013 03:04 PM, monarch_dodra wrote:
> it *could* be an (older) emplace bug. Do you reproduce with head?
I had tested it with head. No, doesn't happen on head.
> Also, keep in mind that DMD *is* allowed to destroy the same
> object several times.
That's news to me. I know that objects
On Sunday, 27 October 2013 at 21:02:01 UTC, Rene Zwanenburg wrote:
On Thursday, 24 October 2013 at 16:46:37 UTC, Ali Çehreli wrote:
Technically, it is a problem with FooWrapper. Regardless of
whether RefCounted's behavior, by default, structs in D are
freely copyable and movable value types. Th
On Thursday, 24 October 2013 at 16:46:37 UTC, Ali Çehreli wrote:
Technically, it is a problem with FooWrapper. Regardless of
whether RefCounted's behavior, by default, structs in D are
freely copyable and movable value types. The compiler can do
those things as it sees fit.
Since FooWrapper o
On Thursday, 24 October 2013 at 16:40:42 UTC, Jesse Phillips
wrote:
I answered a question related to RefCount on SO
http://stackoverflow.com/questions/4632355/making-a-reference-counted-object-in-d-using-refcountedt/4635050#4635050
Not written to your specific problem, but may give you the
info
On 10/24/2013 07:58 AM, Rene Zwanenburg wrote:
I'm writing a D wrapper for a C library. I was planning to use
RefCounted structs to control the lifetime of objects created by this
library. Please check the following example:
http://dpaste.dzfl.pl/b49962bf
Foo would be an opaque struct. createFo
On Thursday, 24 October 2013 at 14:58:21 UTC, Rene Zwanenburg
wrote:
I'm writing a D wrapper for a C library. I was planning to use
RefCounted structs to control the lifetime of objects created
by this library. Please check the following example:
http://dpaste.dzfl.pl/b49962bf
Foo would be an
On Thursday, 3 October 2013 at 12:24:38 UTC, Zhouxuan wrote:
mixin template test()
{
int next;
}
void foo(alias l, alias t)()
{
t.next = l.next;
}
void main()
{
struct A
{
int next;
}
A a;
mixin test l1;
m
On 08/09/13 21:44, Jacob Carlborg wrote:
Try using opDispatch as a described in the other thread.
I'll give that a go, but I still think this is a bug that needs fixing. The
example in TDPL p. 231 will very clearly also not work due to this issue.
On 2013-09-07 16:10, Joseph Rushton Wakeling wrote:
Hello all,
TDPL gives a description in Section 6.13 (pp. 230-233) of a method for
subtyping by storing a private instance of the base type and using
"alias ... this" to access its methods. The example given is as follows:
class StorableShape
On 07/09/13 16:10, Joseph Rushton Wakeling wrote:
TDPL gives a description in Section 6.13 (pp. 230-233) of a method for subtyping
by storing a private instance of the base type and using "alias ... this" to
access its methods. The example given is as follows:
No one has confirmed yea or nay o
On Monday, 26 August 2013 at 23:04:24 UTC, Andrej Mitrovic wrote:
Bug. Please file it to bugzilla:
http://d.puremagic.com/issues/enter_bug.cgi?product=D
Thanks!
http://d.puremagic.com/issues/show_bug.cgi?id=10907
On 8/27/13, Jack Applegame wrote:
> It is impossible to pack a structure with shared object into
> tuple.
Bug. Please file it to bugzilla:
http://d.puremagic.com/issues/enter_bug.cgi?product=D
Thanks!
On Wednesday, 26 June 2013 at 07:55:29 UTC, Namespace wrote:
Today Mike Parker figured out that it happens only if
scope(exit) is used in combination with glPopAttrib. But
That's not exactly what I was getting at. The problem isn't with
scope(exit) or, I believe, glPopAttrib. It just so happen
Second workaround so far:
Use something like that:
scope(exit) glAvoidAE(glPopAttrib(mask));
with
void glAvoidAE(lazy void Func) {
Func();
}
That's strange.
On Monday, 27 May 2013 at 11:32:46 UTC, Maxim Fomin wrote:
On Monday, 27 May 2013 at 10:07:49 UTC, mimi wrote:
Well, how you can reduce the long ugly name in this case? In
the real function I mentioned it so many times.
By not making the name ugly big.
Other people do.
In addition, sometime
On Monday, 27 May 2013 at 10:07:49 UTC, mimi wrote:
Well, how you can reduce the long ugly name in this case? In
the real function I mentioned it so many times.
By not making the name ugly big.
On Monday, 27 May 2013 at 10:17:01 UTC, Namespace wrote:
void foo( S s )
{
auto local = this.bigUglyName;
auto b = s.bigUglyName;
writeln( "bigUglyName (AKA local)=", local, " b=", b );
}
:P
By the way, yes. Thanks for that, I'm stupid today.
void foo( S s )
{
auto local = this.bigUglyName;
auto b = s.bigUglyName;
writeln( "bigUglyName (AKA local)=", local, " b=", b );
}
:P
Well, how you can reduce the long ugly name in this case? In the
real function I mentioned it so many times.
On Sunday, 26 May 2013 at 23:35:43 UTC, mimi wrote:
import std.stdio;
struct S
{
int bigUglyName;
void foo( S s )
{
alias bigUglyName local;
alias s.bigUglyName b;
writeln( "bigUglyName (AKA local)=", local, " b=", b );
}
}
void main()
{
S s1;
S
bug submitted:
http://d.puremagic.com/issues/show_bug.cgi?id=9969
Thanks for reporting.
By the way, I was compiling for Windows and had only compile time
errors.
On Saturday, 20 April 2013 at 13:37:55 UTC, John Colvin wrote:
On Saturday, 20 April 2013 at 12:23:20 UTC, deed wrote:
import std.stdio : writeln;
template Template (uint n, T)
{
T[n] statArr()
{
T[n] arr;
return arr;
}
T[] dynArr()
{
T[] dynArr = new T[n];
On Saturday, 20 April 2013 at 12:23:20 UTC, deed wrote:
import std.stdio : writeln;
template Template (uint n, T)
{
T[n] statArr()
{
T[n] arr;
return arr;
}
T[] dynArr()
{
T[] dynArr = new T[n];
return dynArr;
}
}
void main()
{
alias
On Saturday, 20 April 2013 at 13:37:55 UTC, John Colvin wrote:
On Saturday, 20 April 2013 at 12:23:20 UTC, deed wrote:
import std.stdio : writeln;
template Template (uint n, T)
{
T[n] statArr()
{
T[n] arr;
return arr;
}
T[] dynArr()
{
T[] dynArr = new T[n];
On Saturday, 20 April 2013 at 12:23:20 UTC, deed wrote:
import std.stdio : writeln;
template Template (uint n, T)
{
T[n] statArr()
{
T[n] arr;
return arr;
}
T[] dynArr()
{
T[] dynArr = new T[n];
return dynArr;
}
}
void main()
{
alias
Made available on dpaste:
http://dpaste.dzfl.pl/7b5c36f8
On dpaste, the struct with an int didn't compile. (Same error
message)
It turns out that
Template!(2, Sint).statArr()[0].writeln();
compiles with
$ dmd test.d -m64
but not with
$ dmd test.d
" -o- do not write object file"
By the description, I first thought of "-o-" as a way to erase
the object files after linking the executable. That would have
been nice.
Sorry but if this is the intent then dmd's help message should make this clear:
" -o- do not write object file"
=> "-o- do not write object file nor executable"
>> Intended. No object files = no way to link the executable.
I was thinking in that case the object files were created in a temp
l
On 4/3/13, Timothee Cour wrote:
> dmd -o- does not write executable
> is this a bug or intended?
Intended. No object files = no way to link the executable.
(this is related:
http://forum.dlang.org/thread/jp2j66$2rdv$1...@digitalmars.com, but the
issue still holds)
On Tue, Apr 2, 2013 at 8:59 PM, Timothee Cour wrote:
> dmd -o- does not write executable
> is this a bug or intended?
> the doc is at best confusing:
> " -o-do not write objec
On 3/23/13, J wrote:
> Is this a bug?
It's a known bug: http://d.puremagic.com/issues/show_bug.cgi?id=8269
On Monday, 26 November 2012 at 03:23:42 UTC, Geancarlo wrote:
Hello, I'm using DMD32 D Compiler v2.060 for on Windows.
writeln(TestStruct.x.offsetof);//bug here
This works without creating your own instance:
writeln(TestStruct.init.x.offsetof);
Thanks
Dan
On 2012-11-26 05:03, jerro wrote:
This works for me if I add parentheses to the line where you get the
error like this:
writeln(TestStruct().x.offsetof);//bug here
This will create an instance of TestStruct.
--
/Jacob Carlborg
On 2012-11-26 05:49, Geancarlo wrote:
Thanks jerro and Ali, I see your points. I thought offsetof was like
C/C++'s sizeof... Guess while taking a crash course at a new language I
will often bump into issues because I haven't read a specific doc.
You do have .sizeof in D as well.
--
/Jacob Carl
Thanks jerro and Ali, I see your points. I thought offsetof was
like C/C++'s sizeof... Guess while taking a crash course at a new
language I will often bump into issues because I haven't read a
specific doc.
On 11/25/2012 07:23 PM, Geancarlo wrote:
Hello, I'm using DMD32 D Compiler v2.060 for on Windows.
module main;
import std.stdio;
int main(string[] argv)
{
writeln(TestStruct.x.offsetof);
TestClass.test1();
TestClass var = new TestClass();
var.test2();
return 0;
}
class TestClass
{
static voi
This works for me if I add parentheses to the line where you get
the error like this:
writeln(TestStruct().x.offsetof);//bug here
The error you were getting is not related to offsetof. The
problem seems to be that if you write TestStruct.x inside a
non-static method, the compiler thinks you a
This also works fine:
void test3()
{
TestStruct dummy;
writeln(dummy.x.offsetof);
}
Good I know I spotted something _real_ this time!
On Wednesday, 27 June 2012 at 11:55:11 UTC, Timon Gehr wrote:
On 06/27/2012 01:24 PM, Timon Gehr wrote:
On 06/27/2012 11:07 AM, Michael wrote:
Hello all,
I came across some weird behaviors yesterday and I can't
figure out
what it's about.
On 06/27/2012 01:24 PM, Timon Gehr wrote:
On 06/27/2012 11:07 AM, Michael wrote:
Hello all,
I came across some weird behaviors yesterday and I can't figure out
what it's about.
(1)
auto factorial(int n) {
if (n < 2) return 1;
return n * factorial(n-1);
}
The compiler complained ab
On 06/27/2012 11:07 AM, Michael wrote:
Hello all,
I came across some weird behaviors yesterday and I can't figure out
what it's about.
(1)
auto factorial(int n) {
if (n < 2) return 1;
return n * factorial(n-1);
}
The compiler complained about "forward declaration of factorial". If
On Wednesday, 27 June 2012 at 09:07:57 UTC, Michael wrote:
Hello all,
I came across some weird behaviors yesterday and I can't
figure out what it's about.
(1)
auto factorial(int n) {
if (n < 2) return 1;
return n * factorial(n-1);
}
The compiler complained about "forward dec
On 02/10/2012 10:28 AM, Ali Çehreli wrote:
> Ubuntu 11.10 64-bit dmd.
>
> The following program gets stuck during the writeln() call.
>
> - The foo() call alone works fine.
>
> - The program works fine when there is no writeln() call nor foo() call.
> All elements get processed in that case and th
On 06/01/2012 14:44, Andrej Mitrovic wrote:
Just implement your own exception type, e.g. ExitException, and then use:
That's more or less what people have already said. What's more, Ashish has already
suggested a further improvement whereby the custom exception carries an exit code.
void m
That should have been int main.
Just implement your own exception type, e.g. ExitException, and then use:
void main() { try { realMain(); } catch (ExitException e) { return 0; }
void exit() { throw ExitException(); }
where realMain is the actual main function. Then just call exit()
whenever you want to.
On 29/12/2011 19:09, Jacob Carlborg wrote:
Could druntime hook up on the atexit function to run destructors and similar
when the
program exits?
I'm not sure. Maybe it could be called upon to run static destructors and destruct
heap-allocated objects. But in order to call scope guards and R
Thanks, Jonathan, for your detailed answer.
Ashish
On Fri, Dec 30, 2011 at 1:41 PM, Jonathan M Davis wrote:
> On Friday, December 30, 2011 10:45:43 Ashish Myles wrote:
>> Ok, now there are two issues here:
>> IMPLEMENTATION: Implementation of a safe_exit() without an explicit
>> Exception seems
On Friday, December 30, 2011 10:45:43 Ashish Myles wrote:
> Ok, now there are two issues here:
> IMPLEMENTATION: Implementation of a safe_exit() without an explicit
> Exception seems to be easy to do at the language level for a
> single-threaded program -- you simply have a hidden/system class like
On Fri, Dec 30, 2011 at 5:43 AM, Jonathan M Davis wrote:
> On Thursday, December 29, 2011 23:03:23 Ashish Myles wrote:
>> Since D
>> could conceivably implement a very safe exit() without an explicit use
>> of Exceptions to get around the "catch Exception() {}" problem you
>> mentioned above, does
On Thursday, December 29, 2011 23:03:23 Ashish Myles wrote:
> Since D
> could conceivably implement a very safe exit() without an explicit use
> of Exceptions to get around the "catch Exception() {}" problem you
> mentioned above, does it make sense to request a safer exit() feature
> for D?
And h
On Thu, Dec 29, 2011 at 7:16 PM, Jonathan M Davis wrote:
>
> A D exit function would have to do essentially the same thing as throw an
> exception and catch it in main anyway. The only way that the stack is going to
> be unwound properly is if you actually unwind it. The only way in the language
>
On Thursday, December 29, 2011 13:43:36 Ashish Myles wrote:
> On Thu, Dec 29, 2011 at 1:26 PM, Andrej Mitrovic
>
> wrote:
> > Probably the easiest thing to do is to throw a custom exception and
> > catch it somewhere in main() to return your status code. Unlike
> > exit(), throwing will take care
On 12/29/2011 12:43 PM, Ashish Myles wrote:
On Thu, Dec 29, 2011 at 1:26 PM, Andrej Mitrovic
wrote:
Probably the easiest thing to do is to throw a custom exception and
catch it somewhere in main() to return your status code. Unlike
exit(), throwing will take care of RAII stuff.
Thanks, Andre
On 2011-12-29 18:22, Jakob Ovrum wrote:
On Thursday, 29 December 2011 at 16:27:33 UTC, Ashish Myles wrote:
std.c.stdlib.exit() seems to break RAII. The code below tests this
both using a struct destructor and an explicit scope(exit) {}. Is
this an intentional feature or a bug?
import std.stdio;
On Thu, Dec 29, 2011 at 1:26 PM, Andrej Mitrovic
wrote:
> Probably the easiest thing to do is to throw a custom exception and
> catch it somewhere in main() to return your status code. Unlike
> exit(), throwing will take care of RAII stuff.
Thanks, Andrej. That option had occurred to me, but I fi
Probably the easiest thing to do is to throw a custom exception and
catch it somewhere in main() to return your status code. Unlike
exit(), throwing will take care of RAII stuff.
On Thu, Dec 29, 2011 at 12:22 PM, Jakob Ovrum wrote:
> On Thursday, 29 December 2011 at 16:27:33 UTC, Ashish Myles wrote:
>>
>> std.c.stdlib.exit() seems to break RAII. The code below tests this
>> both using a struct destructor and an explicit scope(exit) {}. Is
>> this an intentional feature or
On Thursday, 29 December 2011 at 17:22:33 UTC, Jakob Ovrum wrote:
Calling 'exit' doesn't properly shut down the D runtime either,
it's not just constructors.
I mean destructors*.
On Thursday, 29 December 2011 at 16:27:33 UTC, Ashish Myles wrote:
std.c.stdlib.exit() seems to break RAII. The code below tests
this
both using a struct destructor and an explicit scope(exit) {}.
Is
this an intentional feature or a bug?
import std.stdio;
import std.c.stdlib;
void main()
{
On Sat, 22 Oct 2011 03:28:53 -0400, Nick Sabalausky wrote:
Is this a compiler bug?
struct Foo
{
int a;
}
Foo foo;
alias foo.a b;
void main()
{
b = 5; // <-- Error
}
dmd test.d
test.d(11): Error: need 'this' to acce
"Timon Gehr" wrote in message
news:j7ve1p$2rds$1...@digitalmars.com...
> On 10/22/2011 11:03 PM, Nick Sabalausky wrote:
>> "Timon Gehr" wrote in message
>> news:j7u9ld$i8t$1...@digitalmars.com...
>>>
>>> alias has never worked for instance members, even if they are accessible
>>> at compile time
301 - 400 of 419 matches
Mail list logo
