On Tuesday, 25 December 2012 at 05:28:54 UTC, Zhenya wrote:
On Tuesday, 25 December 2012 at 02:43:52 UTC, r_m_r wrote:
On 12/25/2012 07:42 AM, r_m_r wrote:
assert(!__traits(compiles, b._bar));
sorry, i made a typo: it should be bar_ instead of _bar.
Interestingly, the below assertion fails a
On Tuesday, 25 December 2012 at 06:19:02 UTC, r_m_r wrote:
i dunno. i'm no D expert either ;-)
BTW its interesting that while the following assertion fails at
runtime:
assert(!__traits(compiles, b.bar_));
the assertion below executes without errors (as expected):
assert(!__traits(compiles,
On 12/25/2012 10:53 AM, evilrat wrote:
i'm not D expert, but isn't the first statement(b.bar_) evaluated to
b.opCall(Foo.opCall)? so the first assert may be true in this case
i dunno. i'm no D expert either ;-)
BTW its interesting that while the following assertion fails at runtime:
assert(!_
On Tuesday, 25 December 2012 at 02:43:52 UTC, r_m_r wrote:
On 12/25/2012 07:42 AM, r_m_r wrote:
assert(!__traits(compiles, b._bar));
sorry, i made a typo: it should be bar_ instead of _bar.
Interestingly, the below assertion fails at run time:
assert(!__traits(compiles, b.bar_));
but this
On Tuesday, 25 December 2012 at 02:43:52 UTC, r_m_r wrote:
On 12/25/2012 07:42 AM, r_m_r wrote:
assert(!__traits(compiles, b._bar));
sorry, i made a typo: it should be bar_ instead of _bar.
Interestingly, the below assertion fails at run time:
assert(!__traits(compiles, b.bar_));
but this
On 12/25/2012 07:42 AM, r_m_r wrote:
assert(!__traits(compiles, b._bar));
sorry, i made a typo: it should be bar_ instead of _bar.
Interestingly, the below assertion fails at run time:
assert(!__traits(compiles, b.bar_));
but this won't compile (as expected):
assert(b.bar_ == 20); //main.d
On 12/25/2012 06:09 AM, bearophile wrote:
D "private" is enforced only across distinct modules.
I've justed tested this and I think you're right (it seems a bit
counter-intuitive though ;-) ).
How about this:
//file: foo.d
module foo;
struct Foo
{
private int bar_;
@property int b
r_m_r:
check this: http://dpaste.dzfl.pl/eec6d152
D "private" is enforced only across distinct modules.
Bye,
bearophile
On 12/25/2012 02:06 AM, Zhenya wrote:
Is it correct,that this code doesn't compile:
check this: http://dpaste.dzfl.pl/eec6d152
regards,
r_m_r
On Monday, December 24, 2012 16:08:36 Andrei Alexandrescu wrote:
> On 12/24/12 1:49 PM, Jonathan M Davis wrote:
> > On Monday, December 24, 2012 13:45:10 Andrei Alexandrescu wrote:
> Actually D's rules are different from C++'s in that regard; Walter
> mentioned D is more sanguine about destroying d
On 12/24/12 2:46 PM, anonymous wrote:
On Monday, 24 December 2012 at 18:50:12 UTC, Jonathan M Davis wrote:
const int& i = foo(bar(min(5, 7)));
which would allow a reference to be kept around, which D disallows.
Does it?
const(int)* i = &foo(bar(min(5, 7)));
We plan to forbid that.
Andrei
On 12/24/12 1:49 PM, Jonathan M Davis wrote:
On Monday, December 24, 2012 13:45:10 Andrei Alexandrescu wrote:
The very binding of rvalues to const ref would allow that breakage. We
can't allow that to happen.
But it's only bound for the length of the statement. After that, the binding
can no l
On Monday, December 24, 2012 21:42:09 monarch_dodra wrote:
> Side question, is this legal?
>
> "int a = min(min(1,2), min(3,4));"
>
> How long do those temps last? I like this piece of code, because
> the previous had that fishy "const int&", which raises eyebrows,
> but I think this example coul
On Monday, 24 December 2012 at 19:09:35 UTC, Jonathan M Davis
wrote:
On Monday, December 24, 2012 20:03:24 monarch_dodra wrote:
Hum... Indeed, it takes by ref *and* returns by ref. Passing in
to out a const ref is *the* smoking gun. Working with D has
gotten me used to functions that take by val
Hi!
Is it correct,that this code doesn't compile:
module foo;
struct Foo
{
private int bar;
alias bar this;
}
///
module main;
import foo;
void main()
{
Foo b;
int a = b;//Error:undefined identifier 'bar', did you mean
'template back(T) //if (!isN
On Monday, December 24, 2012 20:46:00 anonymous wrote:
> On Monday, 24 December 2012 at 18:50:12 UTC, Jonathan M Davis
>
> wrote:
> > const int& i = foo(bar(min(5, 7)));
> >
> > which would allow a reference to be kept around, which D
> > disallows.
>
> Does it?
>
> const(int)* i = &foo(bar(min
On Monday, 24 December 2012 at 18:50:12 UTC, Jonathan M Davis
wrote:
const int& i = foo(bar(min(5, 7)));
which would allow a reference to be kept around, which D
disallows.
Does it?
const(int)* i = &foo(bar(min(5, 7)));
On Monday, December 24, 2012 20:03:24 monarch_dodra wrote:
> Hum... Indeed, it takes by ref *and* returns by ref. Passing in
> to out a const ref is *the* smoking gun. Working with D has
> gotten me used to functions that take by value and return by
> value...
>
> Snap. You got me.
It wouldn't ma
On Monday, 24 December 2012 at 18:42:31 UTC, Andrei Alexandrescu
wrote:
On 12/24/12 1:05 PM, monarch_dodra wrote:
On Monday, 24 December 2012 at 17:37:54 UTC, Andrei
Alexandrescu wrote:
On 12/24/12 12:11 PM, Jonathan M Davis wrote:
On Monday, December 24, 2012 17:55:23 Minas Mina wrote:
On Sun
On Monday, December 24, 2012 19:05:32 monarch_dodra wrote:
> On Monday, 24 December 2012 at 17:37:54 UTC, Andrei Alexandrescu
> wrote:
> > An important smoking gun is C++'s min(), which is allows
> > writing unsafe code without casts.
> >
> > const int& haveANiceDay = min(4, 5);
> >
> >
> > Andr
On Monday, December 24, 2012 13:45:10 Andrei Alexandrescu wrote:
> The very binding of rvalues to const ref would allow that breakage. We
> can't allow that to happen.
But it's only bound for the length of the statement. After that, the binding
can no longer exist (as the binding was a function p
On 12/24/12 1:20 PM, Jonathan M Davis wrote:
On Monday, December 24, 2012 22:11:58 Dmitry Olshansky wrote:
12/24/2012 9:57 PM, Jonathan M Davis пишет:
On Monday, December 24, 2012 12:37:54 Andrei Alexandrescu wrote:
An important smoking gun is C++'s min(), which is allows writing unsafe
code w
On 12/24/12 12:57 PM, Jonathan M Davis wrote:
On Monday, December 24, 2012 12:37:54 Andrei Alexandrescu wrote:
An important smoking gun is C++'s min(), which is allows writing unsafe
code without casts.
const int& haveANiceDay = min(4, 5);
But what does that have to do with const& for funct
On 12/24/12 1:05 PM, monarch_dodra wrote:
On Monday, 24 December 2012 at 17:37:54 UTC, Andrei Alexandrescu wrote:
On 12/24/12 12:11 PM, Jonathan M Davis wrote:
On Monday, December 24, 2012 17:55:23 Minas Mina wrote:
On Sunday, 23 December 2012 at 23:59:55 UTC, Jonathan M Davis
wrote:
On Mond
On Monday, 24 December 2012 at 18:28:04 UTC, Andrej Mitrovic
wrote:
On 12/24/12, Phil Lavoie wrote:
I am currently going through the much recommended book
"Programming Windows" and experiencing some stuff. One of which
was formatting the hInstance and prevHInstance into a string.
You need to
On 12/24/12, Phil Lavoie wrote:
> I am currently going through the much recommended book
> "Programming Windows" and experiencing some stuff. One of which
> was formatting the hInstance and prevHInstance into a string.
You need to initialize the runtime or you will get crashes as soon as
the GC a
Yo,
I am currently going through the much recommended book
"Programming Windows" and experiencing some stuff. One of which
was formatting the hInstance and prevHInstance into a string.
WHICH CRASHES THE PROGRAM! I hope I am doing something wrong!
Please scope the code below and let me know ei
On Monday, December 24, 2012 22:11:58 Dmitry Olshansky wrote:
> 12/24/2012 9:57 PM, Jonathan M Davis пишет:
> > On Monday, December 24, 2012 12:37:54 Andrei Alexandrescu wrote:
> >> An important smoking gun is C++'s min(), which is allows writing unsafe
> >> code without casts.
> >>
> >> const int
12/24/2012 9:57 PM, Jonathan M Davis пишет:
On Monday, December 24, 2012 12:37:54 Andrei Alexandrescu wrote:
An important smoking gun is C++'s min(), which is allows writing unsafe
code without casts.
const int& haveANiceDay = min(4, 5);
But what does that have to do with const& for function
On Monday, 24 December 2012 at 17:37:54 UTC, Andrei Alexandrescu
wrote:
On 12/24/12 12:11 PM, Jonathan M Davis wrote:
On Monday, December 24, 2012 17:55:23 Minas Mina wrote:
On Sunday, 23 December 2012 at 23:59:55 UTC, Jonathan M Davis
wrote:
On Monday, December 24, 2012 00:48:01 Namespace wr
On Monday, December 24, 2012 12:37:54 Andrei Alexandrescu wrote:
> An important smoking gun is C++'s min(), which is allows writing unsafe
> code without casts.
>
> const int& haveANiceDay = min(4, 5);
But what does that have to do with const& for function parameters? I can agree
that it's bad f
On 12/24/12 12:11 PM, Jonathan M Davis wrote:
On Monday, December 24, 2012 17:55:23 Minas Mina wrote:
On Sunday, 23 December 2012 at 23:59:55 UTC, Jonathan M Davis
wrote:
On Monday, December 24, 2012 00:48:01 Namespace wrote:
but Andrei is dead set against
- Jonathan M Davis
Why?
He's con
On Monday, December 24, 2012 17:55:23 Minas Mina wrote:
> On Sunday, 23 December 2012 at 23:59:55 UTC, Jonathan M Davis
>
> wrote:
> > On Monday, December 24, 2012 00:48:01 Namespace wrote:
> >but Andrei is dead set against
> >
> > - Jonathan M Davis
>
> Why?
He's convinced that it's caused prob
On Sunday, 23 December 2012 at 23:59:55 UTC, Jonathan M Davis
wrote:
On Monday, December 24, 2012 00:48:01 Namespace wrote:
but Andrei is dead set against
- Jonathan M Davis
Why?
On Monday, December 24, 2012 17:25:05 Monarch Dodra wrote:
> That's the way the ddoc is generated anyways: Everything on the
> left.
Which should probably be fixed IMHO. Regardless, in Phobos or druntime, if
const is found on the left, it gets moved to the right.
- Jonathan M Davis
On Monday, 24 December 2012 at 15:52:01 UTC, Jonathan M Davis
wrote:
On Monday, December 24, 2012 14:32:55 monarch_dodra wrote:
"ref" is a function qualifier, not a type qualifier, so you
could
even write it as:
"const(ReturnType) foo() const ref;"
So technically, it is symetric.
I'm pretty
On Monday, December 24, 2012 14:32:55 monarch_dodra wrote:
> "ref" is a function qualifier, not a type qualifier, so you could
> even write it as:
> "const(ReturnType) foo() const ref;"
>
> So technically, it is symetric.
I'm pretty sure that ref is nonsensical in that example. What would ref on
On Monday, December 24, 2012 12:16:15 Namespace wrote:
> Put another way: how long will we probably still wait for a
> solution? Yet another release, or 2? Say, 6 months or even
> longer? When it comes in the near future (ie a maximum of 1-2
> months), then it would be sufficient simply to templati
On Monday, December 24, 2012 14:01:10 Namespace wrote:
> One more thing: Which pull request is for "auto ref" for
> none-template functions?
There isn't one.
- Jonathan M Davis
On Saturday, 22 December 2012 at 21:21:21 UTC, Ali Çehreli wrote:
On 12/22/2012 12:55 AM, bearophile wrote:
> To help writing/improving/debugging such code maybe it's
useful to
> create a pass() range in Phobos.
I liked the idea yesterday but I thought that the name was a
little off.
Ditto.
On Sunday, 23 December 2012 at 15:05:16 UTC, Namespace wrote:
On Sunday, 23 December 2012 at 14:55:30 UTC, bearophile wrote:
Namespace:
Shouldn't we fix this? Most of the Newcomer are confused with
the fact,
Take a look in bugzilla. I opened an enhancement request to
fix this situation, but
On Sunday, 23 December 2012 at 23:33:34 UTC, Namespace wrote:
On Sunday, 23 December 2012 at 23:01:37 UTC, Andrej Mitrovic
wrote:
On 12/23/12, Namespace wrote:
Is that my fault? :o
Is there any official manual for building dmd, druntime and
phobos?
You're probably building druntime 2.061 wi
One more thing: Which pull request is for "auto ref" for
none-template functions?
On Sunday, 23 December 2012 at 16:20:47 UTC, Mike Wey wrote:
If you declare an char array you could pass it's pointer and
length as the first two arguments.
char[] buff = new char[1024];
fgets(buff.ptr, buff.length, someStream);
buff = buff[0 .. strlen(buff)];
Thanks, that does work (buff.
Put another way: how long will we probably still wait for a
solution? Yet another release, or 2? Say, 6 months or even
longer? When it comes in the near future (ie a maximum of 1-2
months), then it would be sufficient simply to templatize my
methods. But if it goes for much longer (which I stro
On Sunday, 23 December 2012 at 08:00:56 UTC, n00b wrote:
Hello.
My program has a great deal of computation to do, so I thought
I'd create several threads in order to use multiple processors.
It worked fine with a simple "test" program, but when I try to
do this with the real program, only 1 pr
On Monday, December 24, 2012 09:38:43 bearophile wrote:
> Dmitry Olshansky:
> > make -fwin32.mak release
>
> I think there's a space between -f and win32.
There's a good chance that it doesn't matter one way or the other.
- Jonathan M Davis
Dmitry Olshansky:
make -fwin32.mak release
I think there's a space between -f and win32.
Bye,
bearophile
12/24/2012 3:33 AM, Namespace пишет:
On Sunday, 23 December 2012 at 23:01:37 UTC, Andrej Mitrovic wrote:
On 12/23/12, Namespace wrote:
Is that my fault? :o
Is there any official manual for building dmd, druntime and
phobos?
You're probably building druntime 2.061 with dmd 2.060. First you n
On Monday, December 24, 2012 09:08:09 Namespace wrote:
> Yes that's what I thought. My question was, if it's bad if now a
> lot of my functions/methods are templatized.
That would depend on what you're doing. It's a problem with classes, because
templated functions can't be virtual. With everythi
Yes that's what I thought. My question was, if it's bad if now a
lot of my functions/methods are templatized.
51 matches
Mail list logo
