On 25.12.2011 11:28, Denis Shelomovskij wrote:
OK. As I wrote: Yes, this allocation sometimes can be optimized out but
not always.. Consider this:
---
void main()
{
int[] a = new int[5];
void f(int[] b)
{
// Here we assume that b is unchanged a.
// As these array differ we need a copy.
25.12.2011 0:48, Mr. Anonymous пишет:
Actually, when I think of it:
int a_orig = a++;
int[] arr_orig = arr[]++;
Should be read as:
int a_orig = a;
++a;
int[] arr_orig = arr[];
++arr[];
(If I'm not mistaken, it was written in the TDPL book)
Which means no copy of arr is made, and both arrays
On 12/24/2011 02:02 AM, Jonathan M Davis wrote:
The core problem for a number of these situations is how types are handled
with regards to expressions. In an expression such as
char[] arr = s ~ '.';
the type of the value being assigned is determined _before_ the assignment is
done. So, even
23.12.2011 22:51, bearophile пишет:
++a[] works, but a[]++ doesn't.
Already known compiler bug.
Is it a joke? Array expression in D are for performance reasons to
generate x2-x100 faster code without any compiler optimisations. Link to
one of these epic comments (even x100 more epic because
On 24.12.2011 19:01, Denis Shelomovskij wrote:
23.12.2011 22:51, bearophile пишет:
++a[] works, but a[]++ doesn't.
Already known compiler bug.
Is it a joke? Array expression in D are for performance reasons to
generate x2-x100 faster code without any compiler optimisations. Link to
one of
Denis Shelomovskij:
IMHO, D should not have `a[]++` operator.
I see, and sorry.
(Those percentage comments are relative to tests done on large arrays, so they
are silly.)
Bye,
bearophile
2011/12/24 Mr. Anonymous mailnew4s...@gmail.com:
On 24.12.2011 19:01, Denis Shelomovskij wrote:
23.12.2011 22:51, bearophile пишет:
++a[] works, but a[]++ doesn't.
Already known compiler bug.
Is it a joke? Array expression in D are for performance reasons to
generate x2-x100 faster code
On Sat, Dec 24, 2011 at 9:50 AM, Timon Gehr timon.g...@gmx.ch wrote:
On 12/24/2011 06:18 PM, Andrew Wiley wrote:
2011/12/24 Mr. Anonymousmailnew4s...@gmail.com:
On 24.12.2011 19:01, Denis Shelomovskij wrote:
23.12.2011 22:51, bearophile пишет:
++a[] works, but a[]++ doesn't.
Already
On 12/24/2011 07:00 PM, Andrew Wiley wrote:
On Sat, Dec 24, 2011 at 9:50 AM, Timon Gehrtimon.g...@gmx.ch wrote:
On 12/24/2011 06:18 PM, Andrew Wiley wrote:
2011/12/24 Mr. Anonymousmailnew4s...@gmail.com:
On 24.12.2011 19:01, Denis Shelomovskij wrote:
23.12.2011 22:51, bearophile пишет:
On Sat, Dec 24, 2011 at 1:08 PM, Timon Gehr timon.g...@gmx.ch wrote:
On 12/24/2011 07:00 PM, Andrew Wiley wrote:
On Sat, Dec 24, 2011 at 9:50 AM, Timon Gehrtimon.g...@gmx.ch wrote:
On 12/24/2011 06:18 PM, Andrew Wiley wrote:
2011/12/24 Mr. Anonymousmailnew4s...@gmail.com:
On 24.12.2011
On 24.12.2011 21:22, Andrew Wiley wrote:
On Sat, Dec 24, 2011 at 1:08 PM, Timon Gehrtimon.g...@gmx.ch wrote:
On 12/24/2011 07:00 PM, Andrew Wiley wrote:
On Sat, Dec 24, 2011 at 9:50 AM, Timon Gehrtimon.g...@gmx.chwrote:
On 12/24/2011 06:18 PM, Andrew Wiley wrote:
2011/12/24 Mr.
On 12/24/2011 08:41 PM, Mr. Anonymous wrote:
On 24.12.2011 21:22, Andrew Wiley wrote:
On Sat, Dec 24, 2011 at 1:08 PM, Timon Gehrtimon.g...@gmx.ch wrote:
On 12/24/2011 07:00 PM, Andrew Wiley wrote:
On Sat, Dec 24, 2011 at 9:50 AM, Timon Gehrtimon.g...@gmx.ch wrote:
On 12/24/2011 06:18 PM,
On 12/24/2011 08:22 PM, Andrew Wiley wrote:
On Sat, Dec 24, 2011 at 1:08 PM, Timon Gehrtimon.g...@gmx.ch wrote:
On 12/24/2011 07:00 PM, Andrew Wiley wrote:
On Sat, Dec 24, 2011 at 9:50 AM, Timon Gehrtimon.g...@gmx.chwrote:
On 12/24/2011 06:18 PM, Andrew Wiley wrote:
2011/12/24 Mr.
On Sat, Dec 24, 2011 at 1:45 PM, Timon Gehr timon.g...@gmx.ch wrote:
On 12/24/2011 08:41 PM, Mr. Anonymous wrote:
On 24.12.2011 21:22, Andrew Wiley wrote:
On Sat, Dec 24, 2011 at 1:08 PM, Timon Gehrtimon.g...@gmx.ch wrote:
On 12/24/2011 07:00 PM, Andrew Wiley wrote:
On Sat, Dec 24, 2011
On 24.12.2011 19:18, Andrew Wiley wrote:
2011/12/24 Mr. Anonymousmailnew4s...@gmail.com:
On 24.12.2011 19:01, Denis Shelomovskij wrote:
23.12.2011 22:51, bearophile пишет:
++a[] works, but a[]++ doesn't.
Already known compiler bug.
Is it a joke? Array expression in D are for
Hi guys!
I'm mostly familiar with C (and a bit of PHP). I've stumbled upon the D
language, and I must say I really like it.
Now I'm reading the The D Programming Language book, and I have a
couple of questions:
1. Uninitialized Arrays and GC.
Am 23.12.2011 16:25, schrieb Mr. Anonymous:
Hi guys!
I'm mostly familiar with C (and a bit of PHP). I've stumbled upon the D
language, and I must say I really like it.
Now I'm reading the The D Programming Language book, and I have a
couple of questions:
[]
3. const and immutable.
Is
On 23.12.2011 19:47, Ali Çehreli wrote:
On 12/23/2011 07:25 AM, Mr. Anonymous wrote:
I have a couple of questions:
I prefer separate threads for each. :)
Should I resend the questions as separate messages?
1. Uninitialized Arrays and GC.
Mr. Anonymous:
With the given example of: byte[1024] buffer = void;
So does the GC really scan this byte array?
The current D GC is not precise, so I think the current DMD+GC scan this array.
Future better compilers/runtimes probably will be able to avoid it (with a
shadow stack the gives
5. Align attribute.
http://dlang.org/attribute.html#align
struct S {
align(4) byte a; // placed at offset 0
align(4) byte b; // placed at offset 1
}
Explain this please.
align is a huge mess imo.
It matches the corresponding C compiler behavior
So what's the point of align in the first
On 23.12.2011 19:47, Ali Çehreli wrote:
On 12/23/2011 07:25 AM, Mr. Anonymous wrote:
2. Setting Dynamic Array Length.
http://dlang.org/arrays.html#resize
A more practical approach would be to minimize the number of resizes
The solution works but is not as clean as just using array ~=
On 12/23/2011 11:51 AM, bearophile wrote:
Ali:
There is nothing in the language that makes me say the returned
object is unique; you can cast it to mutable or immutable freely.
The return value of strongly pure functions is implicitly castable to
immutable.
Is that working yet? The
On Friday, December 23, 2011 09:47:35 Ali Çehreli wrote:
- To be more useful, function parameters should not insist on immutable
data, yet we type string all over the place.
That depends. If they're going to have to idup the data anyway, then it's
better to require that the argument be
On Friday, December 23, 2011 20:19:28 Mr. Anonymous wrote:
I saw that std.string functions use assumeUnique from std.exception.
As for your example, it probably should be:
char[] endWithDot(const(char)[] s)
{
return s.dup ~ '.';
}
No, that allocates _two_ strings - one from dup and
On Friday, December 23, 2011 14:51:06 bearophile wrote:
And sometimes inout helps.
Yeah, good point. I keep forgetting about inout, since it didn't work properly
before. So, the best way to implement Ali's function would be
inout(char)[] endWithDot(inout(char)[] s)
{
return s ~ '.';
}
-
On Friday, December 23, 2011 14:51:21 Ali Çehreli wrote:
On 12/23/2011 11:51 AM, bearophile wrote:
Ali:
There is nothing in the language that makes me say the returned
object is unique; you can cast it to mutable or immutable freely.
The return value of strongly pure functions is
Jonathan M Davis:
The feature is new, so it doesn't
yet work in all of the cases that it should, and it's not entirely clear
exactly far it will go. IIRC, Daniel Murphy and Steven were discussing it a
while back,
I have very recently opened another thread about it, but unfortunately it
On 12/23/2011 03:16 PM, Jonathan M Davis wrote:
On Friday, December 23, 2011 09:47:35 Ali Çehreli wrote:
- To be more useful, function parameters should not insist on immutable
data, yet we type string all over the place.
That depends. If they're going to have to idup the data anyway, then
The core problem for a number of these situations is how types are handled
with regards to expressions. In an expression such as
char[] arr = s ~ '.';
the type of the value being assigned is determined _before_ the assignment is
done. So, even though in theory the compiler could make it work,
29 matches
Mail list logo
