Re: Using alias parameters with class members in CTFE (related to UDAs)
Am Wed, 24 Jul 2013 02:13:50 +0200 schrieb Andrej Mitrovic andrej.mitrov...@gmail.com: On 7/23/13, Johannes Pfau nos...@example.com wrote: Does anyone know why this code is not working? http://dpaste.dzfl.pl/b89e7b3f Add 'static' to getAttribute and it will work. I know, it's weird, and I've seen this sort of workaround used before. I think it's a compiler bug. Thanks! I already feared I'd have to use some string mixin tricks :-)
How to disable the DOS window at the start of my program on D
I work with Qt from D and I do not need the DOS window. How to turn it off.
Re: How to disable the DOS window at the start of my program on D
On Wednesday, 24 July 2013 at 07:00:35 UTC, MGW wrote:
I work with Qt from D and I do not need the DOS window. How to
turn it off.
Generally speaking to disable the console window on Windows by
using code only something along these lines will work.
version(Windows) {
import core.sys.windows.windows : FreeConsole;
FreeConsole();
}
There is a way to instruct the linker to remove it also but thats
more fun.
Auto keyword with const variable
This code:
void test(const int n)
{
auto j = n;
j++;
}
Gives this error:
cannot modify const expression j
Is this considered a feature or a bug? I would assume most people
wouldn't want new variables inheriting const.
Re: How to disable the DOS window at the start of my program on D
On Wednesday, 24 July 2013 at 08:08:19 UTC, Rikki Cattermole
wrote:
version(Windows) {
import core.sys.windows.windows : FreeConsole;
FreeConsole();
}
DOS window flashes at the start, and that's bad.
Re: How to disable the DOS window at the start of my program on D
On Wednesday, 24 July 2013 at 08:16:39 UTC, MGW wrote:
On Wednesday, 24 July 2013 at 08:08:19 UTC, Rikki Cattermole
wrote:
version(Windows) {
import core.sys.windows.windows : FreeConsole;
FreeConsole();
}
DOS window flashes at the start, and that's bad.
Take a look at DLL def files. I believe from memory that they
will help with that.
For Microsofts linker (64bit) take a look at
http://msdn.microsoft.com/en-us/library/vstudio/fcc1zstk.aspx and
/SUBSYSTEM:Windows.
For an example .def file (thats has been made for a dll but
should work ok) look at http://dlang.org/dll.html at mydll.def.
The later should work for both 64bit and 32bit I believe.
Re: Auto keyword with const variable
Alex H:
void test(const int n)
{
auto j = n;
j++;
}
Gives this error:
cannot modify const expression j
Is this considered a feature or a bug? I would assume most
people wouldn't want new variables inheriting const.
It's a bit annoying. I don't remember people discussing this
small problem. I don't know if it's easy to fix it and what
side effects such change could cause.
Bye,
bearophile
Re: Auto keyword with const variable
On Wednesday, 24 July 2013 at 08:07:55 UTC, Alex H wrote:
This code:
void test(const int n)
{
auto j = n;
j++;
}
Gives this error:
cannot modify const expression j
Is this considered a feature or a bug? I would assume most
people
wouldn't want new variables inheriting const.
There is no error. All right.
auto - the type expects the maximum transfer of properties from
the context.
int j = n; j++ // if change j
Re: Auto keyword with const variable
Am 24.07.2013 11:39, schrieb bearophile:
Alex H:
void test(const int n)
{
auto j = n;
j++;
}
Gives this error:
cannot modify const expression j
Is this considered a feature or a bug? I would assume most
people wouldn't want new variables inheriting const.
It's a bit annoying. I don't remember people discussing this
small problem. I don't know if it's easy to fix it and what
side effects such change could cause.
should that be fixed - i don't think that any auto removal of
const, immutable, shared or anything else should just happen silently
and how would it look to preserve the const if auto would auto-rip it of?
Re: Auto keyword with const variable
dennis luehring: and how would it look to preserve the const if auto would auto-rip it of? You could write: immutable j = n; For every default behavour you need a way to implement the other nicely :-) Currently for the problem of the OP you can use this: Unqual!(typeof(n)) j = n; Bye, bearophile
Re: Auto keyword with const variable
On Wednesday, 24 July 2013 at 10:01:14 UTC, bearophile wrote:
dennis luehring:
and how would it look to preserve the const if auto would
auto-rip it of?
You could write:
immutable j = n;
For every default behavour you need a way to implement the
other nicely :-)
Currently for the problem of the OP you can use this:
Unqual!(typeof(n)) j = n;
Bye,
bearophile
Definitly. Auto means same type. I think it could be OK if it
followed IFTI rules? After all, in concept, it's kind of the same
mechanism.
I wouldn't go any further than that though.
//
void foo(T)(T t)
{
pragma(msg, T.stringof);
}
void main(string[] args)
{
immutable int[] i = [1, 2, 3];
foo(i);
auto j = i;
pragma(msg, typeof(j).stringof);
}
//
immutable(int)[]
immutable(int[])
//
Problem: I don't really see a good usecase for making auto have
special IFTI behavior. Keeping it to same type, 100% of the
time seems like the best.
Re: How to disable the DOS window at the start of my program on D
For Win32/OPTLINK, I passed the following flag to dmd in a lil' project of mine:
-L/SUBSYSTEM:WINDOWS:4.0
Worked for me.
LMB
On Wed, Jul 24, 2013 at 5:24 AM, Rikki Cattermole
alphaglosi...@gmail.com wrote:
On Wednesday, 24 July 2013 at 08:16:39 UTC, MGW wrote:
On Wednesday, 24 July 2013 at 08:08:19 UTC, Rikki Cattermole wrote:
version(Windows) {
import core.sys.windows.windows : FreeConsole;
FreeConsole();
}
DOS window flashes at the start, and that's bad.
Take a look at DLL def files. I believe from memory that they will help with
that.
For Microsofts linker (64bit) take a look at
http://msdn.microsoft.com/en-us/library/vstudio/fcc1zstk.aspx and
/SUBSYSTEM:Windows.
For an example .def file (thats has been made for a dll but should work ok)
look at http://dlang.org/dll.html at mydll.def.
The later should work for both 64bit and 32bit I believe.
Re: Auto keyword with const variable
On 07/24/13 12:09, monarch_dodra wrote: Keeping it to same type, 100% of the time seems like the best. No, it's a design bug. The head qualifier(s) should always be stripped when copying objects. Stripping is always fine (ie safe), not doing it just creates other problems, like the one in OP, or unnecessary template bloat. The IFTI special cases that are already there are just handling one of the symptoms. As you can always declare something as 'immutable' or 'const', instead of 'auto', the default would have to be head-mutable [1]. Ie, this would then work: const int a; immutable b = a; // immutable int const c = a; // const int auto d = a; // int Right now, you have to do `auto d = cast()a;` or use the Unqual hack... artur [1] If D had a `var` qualifier, then defaulting to 'const' might be better. But it doesn't.
Re: Auto keyword with const variable
On Wednesday, 24 July 2013 at 10:37:40 UTC, Artur Skawina wrote:
On 07/24/13 12:09, monarch_dodra wrote:
Keeping it to same type, 100% of the time seems like the
best.
No, it's a design bug. The head qualifier(s) should always be
stripped
when copying objects. Stripping is always fine (ie safe)
Nope. Stop. Wrong. Qualification is transitive in D, unlike in
C++. Even when copying, stripping qualification is not safe:
//
struct S
{
int* p;
}
void main()
{
immutable i = 1;
auto a = immutable(S)(i);
auto b = cast(S)a; //Unsafe cast
*b.p = 2; //This'll probably crash on a linux
//Program corrupted by here.
assert(i == *i); //This fails (!!!) on my win32
}
//
Long story short, never cast to Unqual. Always to an implicit
cast, and let the compiler complain if it is illegal:
//
struct S1
{
int a;
}
struct S2
{
int* p;
}
void main()
{
immutable i = 1;
auto a1 = immutable(S1)(i);
auto a2 = immutable(S2)(i);
S1 b1 = a1; //OK!
S2 b2 = a2; //Error: cannot implicitly convert expression
(a2) of type immutable(S2) to S2
}
//
Re: How to disable the DOS window at the start of my program on D
On Wednesday, 24 July 2013 at 10:20:08 UTC, Leandro Motta Barros wrote: For Win32/OPTLINK, I passed the following flag to dmd in a lil' project of mine: -L/SUBSYSTEM:WINDOWS:4.0 Worked for me. Yes, this is the way to do it. But if you're going to specify a subsystem version number, I believe 5.01 is the version to use for 32-bit x86 and 5.02 for 64-bit. 4.0 is the subsystem version for Win9x support. Not that it will hurt anything to use it, and I don't really know the details of the how it affects the startup process, but it's recommended to use 5.01 or 5.02 these days.
Re: Auto keyword with const variable
On Wednesday, 24 July 2013 at 08:07:55 UTC, Alex H wrote:
This code:
void test(const int n)
{
auto j = n;
j++;
}
Gives this error:
cannot modify const expression j
Is this considered a feature or a bug? I would assume most
people
wouldn't want new variables inheriting const.
This is the exact behavior I would expect. I think of auto as
this variable is going to be the same type as that variable.
Since in is const int, then j also is going to be const int. If
you want to copy n into a nonconst variable, you have to cast
away the const.
int j = cast( int )n;
auto j = cast( int )n;
Re: How to disable the DOS window at the start of my program on D
Thank you all. All ok!
Re: Is this documented behaviour?
On Tuesday, 23 July 2013 at 20:13:33 UTC, John Colvin wrote: On Tuesday, 23 July 2013 at 17:06:37 UTC, Dicebot wrote: On Tuesday, 23 July 2013 at 17:03:52 UTC, John Colvin wrote: Sorry, I should have been more clear. It's the first case that seems weird to me. Why? '*aptr' is 'a' pretty much by definition of pointer dereferencing. To be honest, I wasn't expecting foo(*aptr) to compile at all, with a taking address of temporary error or similar. It's clearly the right behaviour to allow it, but it took me by surprise at first. Pass-by-Ref is pretty much sugar for pass-pointer-by-value. Basically, if you can take the address of the argument, then passing it is fair game. It's because you can't take the address of a temporary that you can't pass a temporary by ref (unless you are Microsoft Visual Studio, then there's no problem at all apparently 0_o). Of course, *aptr does not return a temporary, so passing that is fair game too.
Re: Is this documented behaviour?
On Tuesday, 23 July 2013 at 20:13:33 UTC, John Colvin wrote:
To be honest, I wasn't expecting foo(*aptr) to compile at all,
with a taking address of temporary error or similar.
But there are no temporaries here. You seem to mix concepts of
temporary and stack variable with deterministic lifetime.
Taking address of a temporary is something like this:
int foo() { return 42; }
...
int* ptr = (foo());
Re: Is this documented behaviour?
On Wednesday, 24 July 2013 at 14:52:53 UTC, monarch_dodra wrote: On Tuesday, 23 July 2013 at 20:13:33 UTC, John Colvin wrote: On Tuesday, 23 July 2013 at 17:06:37 UTC, Dicebot wrote: On Tuesday, 23 July 2013 at 17:03:52 UTC, John Colvin wrote: Sorry, I should have been more clear. It's the first case that seems weird to me. Why? '*aptr' is 'a' pretty much by definition of pointer dereferencing. To be honest, I wasn't expecting foo(*aptr) to compile at all, with a taking address of temporary error or similar. It's clearly the right behaviour to allow it, but it took me by surprise at first. Pass-by-Ref is pretty much sugar for pass-pointer-by-value. Basically, if you can take the address of the argument, then passing it is fair game. It's because you can't take the address of a temporary that you can't pass a temporary by ref (unless you are Microsoft Visual Studio, then there's no problem at all apparently 0_o). Of course, *aptr does not return a temporary, so passing that is fair game too. I'm actually amazed how many years I've had the wrong conception of pointers in my head. Despite having written *ptr = val a million times, I was still imagining *ptr to be an rvalue i.e. read-from-this-address-and-return-value. How on earth did I never make the connection?!
Re: Is this documented behaviour?
On Tuesday, 23 July 2013 at 16:34:54 UTC, John Colvin wrote:
void foo(ref int a)
{
a = 5;
}
void main()
{
int a = 0;
int* aptr = a;
foo(*aptr);
assert(a == 5);
a = 0;
int b = *aptr;
foo(b);
assert(b == 5);
assert(a == 0);
}
The fact that adding an explicit temporary changes the
semantics seems weird to me.
Thanks for the explanations people, I have now fixed a rather
worrying mistake in my programming knowledge: WHAT IT ACTUALLY
MEANS TO DEREFERENCE A POINTER!
Seriously, I've written programs in assembly and I still had it
wrong. It's a wonder I ever wrote any correct code in my life.
Re: Is this documented behaviour?
On Wednesday, 24 July 2013 at 15:03:33 UTC, Dicebot wrote:
On Tuesday, 23 July 2013 at 20:13:33 UTC, John Colvin wrote:
To be honest, I wasn't expecting foo(*aptr) to compile at all,
with a taking address of temporary error or similar.
But there are no temporaries here. You seem to mix concepts of
temporary and stack variable with deterministic lifetime.
Taking address of a temporary is something like this:
int foo() { return 42; }
...
int* ptr = (foo());
nope, I get that. I was just confusing the basics of how pointers
work *facepalm*
Re: How to disable the DOS window at the start of my program on D
On Wednesday, 24 July 2013 at 08:24:03 UTC, Rikki Cattermole wrote: Take a look at DLL def files. I believe from memory that they will help with that. Yeah, that or the linker flag. I talked about the .def file in this thread: http://forum.dlang.org/thread/xkvdpdsfzevanucrg...@forum.dlang.org This has got to be one of the most frequently asked questions in here, we should really make an easy to see note somewhere!
Re: Auto keyword with const variable
On Wednesday, July 24, 2013 10:07:54 Alex H wrote:
This code:
void test(const int n)
{
auto j = n;
j++;
}
Gives this error:
cannot modify const expression j
Is this considered a feature or a bug? I would assume most people
wouldn't want new variables inheriting const.
The behavior is correct and desirable. It would be a big problem for generic
code if the type of auto didn't match the right-hand side of the expression.
In some cases, it might be okay if auto gave you the tail-const type, but even
that could be problematic depending on the type.
- Jonathan M Davis
Re: Auto keyword with const variable
On Wednesday, 24 July 2013 at 11:26:32 UTC, Mike Parker wrote:
...
This is the exact behavior I would expect. I think of auto as
this variable is going to be the same type as that variable.
Since in is const int, then j also is going to be const int. If
you want to copy n into a nonconst variable, you have to cast
away the const.
int j = cast( int )n;
auto j = cast( int )n;
+1
This works fine for pods, no cast required
int j = n; ++j;
...and this does what one would expect too
struct S {
int* value;
}
void funky(const S s) {
int* s1 = s.value;
*s1 = 5;
}
/d535/f466.d(9): Error: cannot implicitly convert expression
(s.value) of type const(int*) to int*
void funky(const S s) {
S s1 = s;
*s1.value = 5;
}
/d297/f947.d(9): Error: cannot implicitly convert expression (s)
of type const(S) to S
