On Friday, 17 August 2012 at 04:25:42 UTC, Chris Cain wrote:
On Friday, 17 August 2012 at 04:17:33 UTC, Mehrdad wrote:
Okay so basically, the conclusion I'm drawing is that you have
to combine it with pure/immutable in order to get much more
out of it than compared with C++; otherwise, it's not
On Friday, 17 August 2012 at 04:17:33 UTC, Mehrdad wrote:
Okay so basically, the conclusion I'm drawing is that you have
to combine it with pure/immutable in order to get much more out
of it than compared with C++; otherwise, it's not really
different.
Thanks!
You posted this before seeing
On Friday, 17 August 2012 at 04:17:05 UTC, Jonathan M Davis wrote:
On Friday, August 17, 2012 05:11:49 Mehrdad wrote:
On Friday, 17 August 2012 at 02:49:45 UTC, Jonathan M Davis
wrote:
> But take this code for example:
>
> auto i = new int;
> *i = 5;
> const c = i;
> writeln(c);
> func(c); //
On Friday, 17 August 2012 at 03:44:38 UTC, Mehrdad wrote:
To clarify... the motivation for this question in the first
place was the fact that I've been consistently told (and have
read) that D const provides more guarantees than C++ const, so
I was trying to figure out how.
If what you're sa
On Friday, 17 August 2012 at 03:57:21 UTC, Chris Cain wrote:
On Friday, 17 August 2012 at 03:42:23 UTC, Mehrdad wrote:
Yes, I 100% realize 'pure' and 'immutable' are advantages over
C++.
The question was about 'const' by itself, though, because
otherwise that's not a fair comparison. (The goal
On Friday, August 17, 2012 04:46:34 Chris Cain wrote:
> Notice that I'm making an immutable(S) in that example.
I missed that. It's a known bug and in bugzilla somewhere. I'd have to go
digging to find the exact bug# though. const constructors have the same
problem.
- Jonathan M Davis
On Friday, August 17, 2012 05:11:49 Mehrdad wrote:
> On Friday, 17 August 2012 at 02:49:45 UTC, Jonathan M Davis wrote:
> > But take this code for example:
> >
> > auto i = new int;
> > *i = 5;
> > const c = i;
> > writeln(c);
> > func(c); //obviously takes const or it wouldn't compile
> > writeln
On Friday, 17 August 2012 at 03:42:23 UTC, Mehrdad wrote:
Yes, I 100% realize 'pure' and 'immutable' are advantages over
C++.
The question was about 'const' by itself, though, because
otherwise that's not a fair comparison. (The goal is comparing
C++ const to D const, not C++ const to D const +
On Friday, 17 August 2012 at 03:42:23 UTC, Mehrdad wrote:
On Friday, 17 August 2012 at 03:36:28 UTC, Chris Cain wrote:
Combine const and pure
Yes, I 100% realize 'pure' and 'immutable' are advantages over
C++.
The question was about 'const' by itself, though, because
otherwise that's not a
On Friday, 17 August 2012 at 03:36:28 UTC, Chris Cain wrote:
Combine const and pure
Yes, I 100% realize 'pure' and 'immutable' are advantages over
C++.
The question was about 'const' by itself, though, because
otherwise that's not a fair comparison. (The goal is comparing
C++ const to D con
Well, since I'm not describing how const works anymore (although,
it's still different than C++ due to the mutable keyword in C++,
but I digress), I'll go ahead and jump in for this one...
On Friday, 17 August 2012 at 02:30:45 UTC, Mehrdad wrote:
So unless you're expecting the compiler to have
On Friday, 17 August 2012 at 02:49:45 UTC, Jonathan M Davis wrote:
But take this code for example:
auto i = new int;
*i = 5;
const c = i;
writeln(c);
func(c); //obviously takes const or it wouldn't compile
writeln(c);
The compiler _knows_ that c is the same before and after the
call to func, b
On Friday, 17 August 2012 at 02:33:46 UTC, Chris Cain wrote:
I've already responded to something that is equivalent to what
you just posted. I'm not sure if you're intentionally being
obtuse (I'll give you the benefit of the doubt)
Thanks... I promise I'm not >__< I'm just having trouble seein
On Friday, 17 August 2012 at 02:02:56 UTC, Jonathan M Davis wrote:
How is it a bug? The variable that you're altering is not part
of the object.
That's part of why having pure with const in so valuable. It
prevents stuff
like what you're doing here.
- Jonathan M Davis
Notice that I'm makin
On Friday, August 17, 2012 04:30:42 Mehrdad wrote:
> So unless you're expecting the compiler to have the
> implementation for the entire class available in order for it to
> be able to do any kind of optimization (in which case, it would
> have to do a whole bunch of inference to figure out the ali
On Friday, 17 August 2012 at 02:01:11 UTC, Mehrdad wrote:
...snip...
Are you sure?
I've already responded to something that is equivalent to what
you just posted. I'm not sure if you're intentionally being
obtuse (I'll give you the benefit of the doubt) or if your eyes
are glossing over whe
On Friday, 17 August 2012 at 02:25:22 UTC, Jonathan M Davis wrote:
Yeah. It's more than C++, but it's still pretty limited without
pure, and if even with pure, the optimizations can still be
pretty limited.
Yeah, I'm only worried about the language here, not the
implementation.
On Friday,
On Friday, August 17, 2012 04:12:10 Mehrdad wrote:
> On Friday, 17 August 2012 at 02:02:51 UTC, Jonathan M Davis wrote:
> > Because there are plenty of functions which take mutable
> > objects but don't actually alter them - particularly when
> > interacting with C code.
>
> Ah, so that explains t
On Friday, 17 August 2012 at 02:09:09 UTC, Mehrdad wrote:
On Friday, 17 August 2012 at 02:02:56 UTC, Jonathan M Davis
wrote:
How is it a bug? The variable that you're altering is not part
of the object.
It doesn't need to be.
Not to say it /can't/ be, of course... a const method can
certa
On Friday, 17 August 2012 at 02:02:51 UTC, Jonathan M Davis wrote:
Because there are plenty of functions which take mutable
objects but don't actually alter them - particularly when
interacting with C code.
Ah, so that explains that, thanks.
So to clarify, modifying a mutable object through
On Friday, August 17, 2012 02:32:01 Mehrdad wrote:
> On Friday, 17 August 2012 at 00:10:52 UTC, Jonathan M Davis wrote:
> > In C++, if you have
> >
> > const vector& getStuff() const;
> >
> > which returns a member variable, then as long as const isn't
> > cast away, you know that the container i
On Friday, August 17, 2012 03:59:01 Chris Cain wrote:
> If you're absolutely 100% completely totally certain that the
> data is mutable (i.e., you have confirmed either through good,
> sound reasoning OR you have some method of seeing exactly where
> it is stored in your RAM and you've checked that
On Friday, 17 August 2012 at 02:02:56 UTC, Jonathan M Davis wrote:
How is it a bug? The variable that you're altering is not part
of the object.
It doesn't need to be.
What you said was:
If you have a const object, then you have the guarantee that
none of what it contains or refers to __
On Friday, 17 August 2012 at 01:59:03 UTC, Chris Cain wrote:
On Friday, 17 August 2012 at 01:51:38 UTC, Mehrdad wrote:
So you're saying casting away a const _pointer_ is undefined,
even if the target was originally created as mutable.
(Otherwise, the code would certainly be "valid", just like i
On Friday, 17 August 2012 at 01:50:02 UTC, Chris Cain wrote:
On Friday, 17 August 2012 at 01:43:03 UTC, Mehrdad wrote:
Isn't that kinda useless, if it tells you nothing about the
object itself?
Not sure what your point is. It tells you enough about how you
work with that "object itself"
Ar
On Friday, August 17, 2012 03:00:34 Chris Cain wrote:
> On Friday, 17 August 2012 at 00:44:20 UTC, Chris Cain wrote:
> > Also, D's const is _not_ a guarantee that there are no mutable
> > references to something. That'd be immutable.
>
> And, by the way, I'd call this a bug (not sure if reported y
On Friday, August 17, 2012 03:51:36 Mehrdad wrote:
> On Friday, 17 August 2012 at 01:33:29 UTC, Chris Cain wrote:
> > Also, if the only view of the data you have is that const view,
> > it's effectively the same as immutable (it couldn't be changed
> > by any valid code).
>
> So you're saying cast
On Friday, August 17, 2012 03:52:38 Chris Cain wrote:
> On Friday, 17 August 2012 at 01:45:27 UTC, Mehrdad wrote:
> > He was clearly _not_ talking about modifying the pointer.
> > He said you cannot alter the "elements pointed TO".
> >
> >
> > Given that, I have no idea how that is supposed to be
On Friday, 17 August 2012 at 01:51:38 UTC, Mehrdad wrote:
So you're saying casting away a const _pointer_ is undefined,
even if the target was originally created as mutable.
(Otherwise, the code would certainly be "valid", just like in
C++.)
Which means you can effectively _never_ cast away
On Friday, 17 August 2012 at 01:33:29 UTC, Chris Cain wrote:
Also, if the only view of the data you have is that const view,
it's effectively the same as immutable (it couldn't be changed
by any valid code).
So you're saying casting away a const _pointer_ is undefined,
even if the target was
On Friday, 17 August 2012 at 01:45:27 UTC, Mehrdad wrote:
He was clearly _not_ talking about modifying the pointer.
He said you cannot alter the "elements pointed TO".
Given that, I have no idea how that is supposed to be saying
"you can't modify the const _view_". He's clearly talking about
On Friday, 17 August 2012 at 01:43:03 UTC, Mehrdad wrote:
Isn't that kinda useless, if it tells you nothing about the
object itself?
Not sure what your point is. It tells you enough about how you
work with that "object itself" and sets (real) boundaries which
is unlike C++'s const which tells
Also note that Jon __clearly__ said:
"you know that the elements aren't altered either anything which
the elements point to".
He was clearly _not_ talking about modifying the pointer.
He said you cannot alter the "elements pointed TO".
Given that, I have no idea how that is supposed to be
On Friday, 17 August 2012 at 01:25:18 UTC, Chris Cain wrote:
Yeah. Again, you can't modify __the const view__.
Isn't that kinda useless, if it tells you nothing about the
object itself?
Just to be abundantly clear about his point.
// v is a const vector, but holds pointers ...
*v[0] = 5; // legal in C++, illegal in D (except in constructors
which will allow this, ATM)
Transitivity gives you more information and guarantees about what
you can and can't do with your view. Also
On Friday, 17 August 2012 at 01:17:19 UTC, Mehrdad wrote:
How?
Jon said "you know that the elements aren't altered either - or
anything which the elements point to".
I just showed that the const-ness of getStuff() tells you
_nothing_ about that fact.
Did I miss something?
Yeah. Again,
On Friday, 17 August 2012 at 00:44:20 UTC, Chris Cain wrote:
On Friday, 17 August 2012 at 00:32:03 UTC, Mehrdad wrote:
On Friday, 17 August 2012 at 00:10:52 UTC, Jonathan M Davis
wrote:
In contrast, in D,
const ref Array!(T*) getStuff() const;
you would _know_ that not only is the container n
On Friday, 17 August 2012 at 00:51:55 UTC, Torarin wrote:
The C++ standard, section 7.1.6.1:
Except that any class member declared mutable (7.1.1) can be
modified, any attempt to modify a const object during its
lifetime (3.8) results in undefined behavior.
Torarin
+1 thanks for taking t
On Friday, 17 August 2012 at 00:44:20 UTC, Chris Cain wrote:
Also, D's const is _not_ a guarantee that there are no mutable
references to something. That'd be immutable.
And, by the way, I'd call this a bug (not sure if reported yet):
int yourGlobalCounter;
struct S
{
int*[] items;
2012/8/17 Jonathan M Davis
>
> On Friday, August 17, 2012 02:32:01 Mehrdad wrote:
> > > C++ makes no such guarantees, because you're free to cast away
> > > const and modifiy objects
> >
> > Not correct, as far as I understand.
> > C++ only lets you cast away _const references_ to _mutable_
> > ob
On Friday, 17 August 2012 at 00:32:03 UTC, Mehrdad wrote:
On Friday, 17 August 2012 at 00:10:52 UTC, Jonathan M Davis
wrote:
In contrast, in D,
const ref Array!(T*) getStuff() const;
you would _know_ that not only is the container not altered,
but you know that the elements aren't altered eith
On Friday, August 17, 2012 02:32:01 Mehrdad wrote:
> > C++ makes no such guarantees, because you're free to cast away
> > const and modifiy objects
>
> Not correct, as far as I understand.
> C++ only lets you cast away _const references_ to _mutable_
> objects.
> If the object happens to have been
On Friday, 17 August 2012 at 00:13:58 UTC, bearophile wrote:
Mehrdad:
On the note of casting away const, I don't believe that is
the operation which is undefined, however modifying const is
undefined as it could be pointing to immutable data.
Oh, then that's not what I'd understood. Seems ju
On Friday, 17 August 2012 at 00:32:03 UTC, Mehrdad wrote:
Not correct, as far as I understand.
C++ only lets you cast away _const references_ to _mutable_
objects.
If the object happens to have been const _itself_, then that's
undefined behavior.
Er, minor correction:
By "casting away const
On Friday, 17 August 2012 at 00:10:52 UTC, Jonathan M Davis wrote:
In C++, if you have
const vector& getStuff() const;
which returns a member variable, then as long as const isn't
cast away, you know that the container itself won't have any
elements added or removed from it, but you have _zer
Mehrdad:
On the note of casting away const, I don't believe that is the
operation which is undefined, however modifying const is
undefined as it could be pointing to immutable data.
Oh, then that's not what I'd understood. Seems just like C++
then.
Are you sure?
bye,
bearophile
On Friday, August 17, 2012 01:35:46 Mehrdad wrote:
> > The main thing given is transitivity.
>
> Sure, but what kind of an advantage does that provide compared to
> C++?
> (As in, a code sample would be awesome -- it's so much easier to
> explain with an example to compare, rather than with words.
On Thursday, 16 August 2012 at 14:58:23 UTC, R Grocott wrote:
C++'s fragile ABI makes it very difficult to write class
libraries without some sort of workaround. For example,
RapidXML and AGG are distributed as source code; GDI+ is a
header-only wrapper over an underlying C interface; and Qt
m
On Thursday, 16 August 2012 at 23:18:08 UTC, Jesse Phillips wrote:
Note that stronger guarentees does not translate to inferences
done by the compiler.
I remember being told (correct me if I'm wrong) that D's const
lets the compiler perform better optimizations than C++, which
i.e. means the
On Fri, 17 Aug 2012 00:20:10 +0200
"TJB" wrote:
> D Masters,
>
> I'm not a hardware guy at all, but I find myself needing to
> process a lot of data through some Monte Carlo statistical
> algorithms. I am considering general purpose GPU computing for
> this task. My question is how feasible
On Thu, 16 Aug 2012 23:15:14 +0200
Andrej Mitrovic wrote:
> On 8/16/12, ShestakoffVS wrote:
> > David, i read about LGPL and other nokia stupid ideas and now
> > want to know can i staticly link my programm with qtd.
>
> Laws aren't stupid ideas.
Just stupidly implemented ;)
On Thursday, 16 August 2012 at 22:14:31 UTC, Mehrdad wrote:
Something I'm having trouble undertanding/remembering (sorry,
you've probaby already explained it a billion times)...
I remember being told many times that D's 'const' provides
stronger guarantees than C++'s 'const'.
If it's the for
Am 17.08.2012 00:20, schrieb TJB:
D Masters,
I'm not a hardware guy at all, but I find myself needing to process a
lot of data through some Monte Carlo statistical algorithms. I am
considering general purpose GPU computing for this task. My question is
how feasible will it be to wrap the Nvidi
D Masters,
I'm not a hardware guy at all, but I find myself needing to
process a lot of data through some Monte Carlo statistical
algorithms. I am considering general purpose GPU computing for
this task. My question is how feasible will it be to wrap the
Nvidia cuBLAS and cuRAND libraries f
I remember being told many times that D's 'const' provides
stronger guarantees than C++'s 'const'.
I also remember being told that the compiler considers it UB to
cast away const-ness in references, unlike in C++, which gives
you more guarantees.
But I'm having trouble coming up with a piec
Something I'm having trouble undertanding/remembering (sorry,
you've probaby already explained it a billion times)...
I remember being told many times that D's 'const' provides
stronger guarantees than C++'s 'const'.
I just wanted to clarify, is that true for 'const' itself, or is
that refer
On 8/16/12, ShestakoffVS wrote:
> David, i read about LGPL and other nokia stupid ideas and now
> want to know can i staticly link my programm with qtd.
Laws aren't stupid ideas. If you want to make a commercial app,
regardless of any libraries, you better have a lawyer.
On 2012-08-16 22:32, ShestakoffVS wrote:
David, i read about LGPL and other nokia stupid ideas and now want to
know can i staticly link my programm with qtd.
As far as I know you need to link dynamically to Qt to avoid the LGPL
license.
--
/Jacob Carlborg
On Thursday, 16 August 2012 at 19:11:51 UTC, David Nadlinger
wrote:
On Thursday, 16 August 2012 at 19:07:20 UTC, ShestakoffVS wrote:
But i didn't understand how i can use qtd for commercial
project if i must use qt sources (that i cant use in
commercial project) when i'm building qtd.
You can
Le 09/08/2012 11:48, Johannes Pfau a écrit :
Am Wed, 08 Aug 2012 12:31:29 -0700
schrieb Walter Bright:
On 8/8/2012 12:14 PM, Martin Nowak wrote:
That hardly works for event based programming without using
coroutines. It's the classical inversion-of-control dilemma of
event based programming th
And yet that is what DirectX and WinRT are all about.
DirectX, yes: it's a good example of an OO library with a purely
interface-based API. The only DirectX plugin architecture I can
bring to mind, though (DirectShow filters), actually uses C++
classes (such as CSource) to hide a lot of the u
On Thursday, 16 August 2012 at 19:07:20 UTC, ShestakoffVS wrote:
But i didn't understand how i can use qtd for commercial
project if i must use qt sources (that i cant use in commercial
project) when i'm building qtd.
You can use Qt under the LGPL:
http://qt.nokia.com/products/licensing.
Da
On Thursday, 16 August 2012 at 18:24:51 UTC, David Nadlinger
wrote:
On Thursday, 16 August 2012 at 16:35:19 UTC, ShestakoffVS wrote:
Could you explicitly explain me can i use QtD bindings for
commercial project?
I am not a lawyer, but: Yes, you can, under the restriction
your Qt license manda
On Thursday, 16 August 2012 at 16:25:01 UTC, R Grocott wrote:
All of these are relatively minor issues, but taken together,
they make library development quite difficult. For example, I
think it would be almost impossible to develop a COM GUI
toolkit.
And yet that is what DirectX and WinRT
On Thursday, 16 August 2012 at 16:35:19 UTC, ShestakoffVS wrote:
Could you explicitly explain me can i use QtD bindings for
commercial project?
I am not a lawyer, but: Yes, you can, under the restriction your
Qt license mandates. The QtD libraries itself are Boost-licensed,
it's just the gene
Could you explicitly explain me can i use QtD bindings for
commercial project?
On 8/16/12 10:56 AM, Martin Majewski wrote:
Hi all,
while trying to download the dmd 2.060 OSX installer from the "Downloads
& Tools" section, I always get an error 404 message from the server.
Can anyone please fix this or give me a link to that installer?!
Bye!
Apologies for the oversight.
I'm aware that just exposing class interfaces (via COM or other
means) is an option, but that tends to cause many problems of its
own:
- You can no longer call new or delete on the underlying class;
you're obliged to use factory methods. This leads to issues with
templates and stack allocatio
Kagamin wrote:
You can also use C++ to develop COM components which have standardized ABI.
...only on Windows.
You can also use C++ to develop COM components which have
standardized ABI.
Hi all,
while trying to download the dmd 2.060 OSX installer from the
"Downloads & Tools" section, I always get an error 404 message
from the server.
Can anyone please fix this or give me a link to that installer?!
Bye!
http://michelf.ca/blog/2009/some-ideas-for-dynamic-vtables-in-d/
The above blog post, written in 2009, proposes a system for
solving the Fragile ABI Problem in D. Just wondering whether
anything like this is a planned feature for druntime.
C++'s fragile ABI makes it very difficult to write cl
On Thursday, 16 August 2012 at 11:47:56 UTC, Paulo Pinto wrote:
On Thursday, 16 August 2012 at 09:23:18 UTC, Thiez wrote:
On Thursday, 16 August 2012 at 00:48:44 UTC, Alexey Egorov
wrote:
I think there is no problems to make, for example, compiler
for Java Virtual Machine.
Think again. Like J
Haskell folks say that their strong types help clear up a bit
the meaning of the parts of the problem ("if it compiles it's
right" is one of their mottos); and they also say those strong
types help avoid introducing some bugs caused by changes in the
design, because they cause type errors. They
I had times when I missed the Java-style Exception handling.
First time I just the D sockets exceptions was thrown during
runtime. The Library Reference didn't tell my anything about
exceptions neither did the compiler.
This could've been avoided with documentation stating which
exceptions can
On Thursday, 16 August 2012 at 09:23:18 UTC, Thiez wrote:
On Thursday, 16 August 2012 at 00:48:44 UTC, Alexey Egorov
wrote:
I think there is no problems to make, for example, compiler
for Java Virtual Machine.
Think again. Like Java, the JVM does not have pointer
arithmetic, which means there
On Thu, 2012-08-16 at 12:09 +0200, Jordi Sayol wrote:
[…]
> I've built an special 64-bit dmd v2.060 deb package. It includes dmd,
> druntime and phobos compiled with "-g -g3" flags for gcc and cc, and "-gc"
> flag for dmd.
> Other binaries and 32-bit phobos library was removed.
>
> http://d-pack
On Wednesday, 15 August 2012 at 17:44:14 UTC, SomeDude wrote:
Or you could have told him HOW he messed up. By just throwing
an Exception, you are not helpful at all, you are just telling
that he is an ass and that he will be punished for that. Or
maybe he will curse you thinking that your progr
Al 16/08/12 09:35, En/na Iain Buclaw ha escrit:
> I would say rebuild druntime with debugging symbols so you can get the
> line where it crashes...
I've built an special 64-bit dmd v2.060 deb package. It includes dmd, druntime
and phobos compiled with "-g -g3" flags for gcc and cc, and "-gc" flag
On Thursday, 16 August 2012 at 00:48:44 UTC, Alexey Egorov wrote:
I think there is no problems to make, for example, compiler for
Java Virtual Machine.
Think again. Like Java, the JVM does not have pointer arithmetic,
which means there is no straightforward way to write a
D-to-JVM-bytecode co
On Thursday, 16 August 2012 at 00:48:44 UTC, Alexey Egorov wrote:
I think what D can be a perfect script language. Even more, i
think it will can become very popular language, if it will be
possible to use it as script language.
Try rdmd (http://dlang.org/rdmd.html)
It actually do compilation
On 7 August 2012 16:53, Alex Rønne Petersen wrote:
> On 07-08-2012 13:41, Jordi Sayol wrote:
>>
>> Al 07/08/12 02:12, En/na Alex Rønne Petersen ha escrit:
>>>
>>> Hi,
>>>
>>>
>>> Has anyone managed to get the 2.060 .deb working on Ubuntu 12.04? On all
>>> 12.04 systems I have access to, all D prog
82 matches
Mail list logo