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 vari
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
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 conce
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.or
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
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 firs
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 l
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
Thank you all. All ok!
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.
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 bel
On 07/24/13 12:54, monarch_dodra wrote:
> 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
>>
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
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,
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
wrote:
> On Wednesday, 24 July 2013 at 08:16:39 UTC, MGW wrote:
>>
>> On Wednesday, 24 July 2013 at 08:08:19 UTC,
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
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,
b
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 annoyin
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.
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 thi
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
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.
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.
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.wind
I work with Qt from D and I do not need the DOS window. How to
turn it off.
25 matches
Mail list logo
