[Issue 5347] New: Add constructors for primitive types to make pointers easier to use
http://d.puremagic.com/issues/show_bug.cgi?id=5347 Summary: Add constructors for primitive types to make pointers easier to use Product: D Version: unspecified Platform: Other OS/Version: Linux Status: NEW Severity: enhancement Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: jmdavisp...@gmx.com --- Comment #0 from Jonathan M Davis jmdavisp...@gmx.com 2010-12-13 00:10:50 PST --- I'd like to be able to do something like this: int* i = new int(7); It would create a new pointer to int where the int that it points to has a value of 7. But that code results in the compiler complaining that there is no constructor for int, and as far as I can tell the only way to do it so the far less elegant and definitely less compact: int* i = new int; *i = 7; Ideally, you'd be able to use the first syntax for all primitive types. As it is however, you can only use it for structs (and classes if you're using a reference rather than a pointer). This seems unnecessarily limiting. In fact, I thought that the first syntax _was_ legal, and it threw me off when it didn't work (just goes to show how rarely I use pointers, I guess). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5348] New: Variable Length Arrays
http://d.puremagic.com/issues/show_bug.cgi?id=5348
Summary: Variable Length Arrays
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2010-12-13 01:31:41 PST ---
This is an enhancement request for a new feature. It's a purely additive change
(fully backwards compatible with D2), so it may wait for later stages of D2
development, or even for D3.
I suggest to add the Variable Length Arrays (VLA) of C99 to D, using the same
syntax used in C99.
How D VLAs are represented on the stack: they are represented with an immutable
size_t length field followed by a (possibly aligned) contiguous block of data
(the pointer to the data is not necessary because the data is in-place). The
length field is necessary because the contents of the variable used to define
the array length may later change. Multi dimensional VLAs too are accepted.
When a VLA array is allocated the D compiler tests that there is enough free
stack left, and otherwise throws a runtime exception/error (like stack
overflow).
As in C99 VLAarray.sizeof is not a compile time constant, it returns the
length field * item.sizeof.
How VLAs are returned: they may be returned by value (creating a new VLA in the
function where the return value is received), or by reference as normal dynamic
array (by automatic copy on the heap). Both solutions have advantages and
disadvantages. The return by dynamic array is simpler for the programmer
because it changes less things in the language and it requires no syntax
changes.
Currently (DMD 2.050) this code:
void foo(int len) {
int[len] arr;
}
void main() {
foo(1);
}
DMD shows four times the same error:
test.d(2): Error: Integer constant expression expected instead of len
test.d(2): Error: Integer constant expression expected instead of cast(uint)len
test.d(2): Error: Integer constant expression expected instead of cast(uint)len
test.d(2): Error: Integer constant expression expected instead of cast(uint)len
Some of the disadvantages of this idea are:
- It adds some complexity to both the language and the compiler. The programmer
probably has to remember that there is another kind of array in D.
- It may encourage more usage of the stack, but the stack space is limited
compared to the heap space, so it may lead to more stack overflows. But see
below for an alternative view on this.
- Unlike C99, D already has dynamic arrays that cover part of the needs of
dynamic length arrays.
- It introduces a special case in the sizeof.
- Like fixed-sized arrays, the VLAs are managed by value, so a not careful
usage of them may lead to reduced performance caused by long array copies.
- D already allows to use alloca() for variable length stack allocation (unlike
C where alloca() is a common but non-standard function). alloca() usage is
probably uncommon in D code.
- I may have missed or underestimated some disadvantages of VLAs in D, in this
case please add a comment below.
Despite such disadvantages I think that the advantages outweigh them:
- VLAs lead more elegant and readable code.
- Both its syntax (and part of its semantics) is present in C99 already, and
it's a natural syntax, so programmers probably will have no significant
troubles in using them.
- VLAs cover most usage cases of alloca(), and the introduction of VLAs don't
removes the alloca() from Phobos, so this is a backward compatible change.
- It is safer than alloca() because its syntax is more clean than alloca().
- Compared to alloca() it leads to safer code because a VLA is a true array, so
the D compiler is able to enforce array bounds in non-release mode. This is
possible with alloca() too, taking a slice of the return value of alloca(), but
it requires explicit code, while in a VLA there is no need of this extra code.
- VLA require less code that may contain bugs. This is an important difference
for D, that's a language designed to be quite less bug-prone than C. There is
no need of pointer usage, cast(), sizeof, memset() (or assignment to .init),
slicing the stack pointer [], and the manual management of the situation when
alloca() returns a null. This is code that shows the difference, first using
alloca():
import core.stdc.stdlib: alloca;
import std.stdio: writeln;
import std.conv: to;
struct Foo {
int x = 10;
string toString() { return to!string(x); }
~this() { /* something here */ }
}
void bar(int len) {
Foo* ptr = cast(Foo*)alloca(len * Foo.sizeof);
if (ptr == null)
throw new Exception(alloca failed);
Foo[] arr = ptr[0 .. len];
foreach (ref item; arr)
item = Foo.init;
// some code here
writeln(arr);
foreach (ref item; arr)
item.__dtor();
}
void main() {
bar(20);
}
And then
[Issue 5347] Add constructors for primitive types to make pointers easier to use
http://d.puremagic.com/issues/show_bug.cgi?id=5347 Jonathan M Davis jmdavisp...@gmx.com changed: What|Removed |Added OS/Version|Linux |All --- Comment #2 from Jonathan M Davis jmdavisp...@gmx.com 2010-12-13 02:29:32 PST --- Not useful very often? How about every time that you create a pointer to an int (or any other primitive type) and want to immediately initialize the value that's pointed to? It seems like it would be _highly_ useful whenever dealing with pointers to primitives. If it's not useful very often, it's because pointers aren't used very often. And a syntax such as new int(7) or new bool(true) would be completely consistent with all of the other types. In fact, adding it would make the language _more_ consistent, not less. This would be particularly true when writing generic code. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5052] take!(Take!R) should return Take!R, not Take!(Take!R)
http://d.puremagic.com/issues/show_bug.cgi?id=5052 Lars T. Kyllingstad bugzi...@kyllingen.net changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4643] Shared values are unwritable
http://d.puremagic.com/issues/show_bug.cgi?id=4643 Lars T. Kyllingstad bugzi...@kyllingen.net changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@kyllingen.net Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5347] Add constructors for primitive types to make pointers easier to use
http://d.puremagic.com/issues/show_bug.cgi?id=5347
--- Comment #3 from yebblies yebbl...@gmail.com 2010-12-13 02:45:34 PST ---
(In reply to comment #2)
I agree it would be more consistent that way, for value types.
void f(T)(T v)
{
auto x = new T(v); // what if T is a class, array, static array etc?
}
A search of my own code doesn't come up with any instances of allocating a
single value type like this.
Searching phobos gives two instances, both in unittests.
If it's not used very often, what's the point of adding syntax for it?
Just saying.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5347] Add constructors for primitive types to make pointers easier to use
http://d.puremagic.com/issues/show_bug.cgi?id=5347 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #4 from bearophile_h...@eml.cc 2010-12-13 04:01:46 PST --- (In reply to comment #2) Not useful very often? How about every time that you create a pointer to an int (or any other primitive type) and want to immediately initialize the value that's pointed to? The syntax is supported for structs and unions. So please show some use cases for ints, floats, etc. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1513] try/catch/finally misbehavior on windows
http://d.puremagic.com/issues/show_bug.cgi?id=1513
--- Comment #10 from Don clugd...@yahoo.com.au 2010-12-13 13:20:36 PST ---
I'm not sure that this is a compiler bug. It may be druntime.
With this change:
deh.c, _d_framehandler(), line 210
+else if (prev_ndx == -1)
+{ // Exception didn't get caught.
+// Call all the finally blocks skipped in this frame
+_d_local_unwind(handler_table, frame, ndx);
+}
}
}
return ExceptionContinueSearch;
the finally clauses are called correctly. This isn't a correct patch,
but I think it demonstrates that the exception tables are set up reasonably
correctly. I couldn't find anything wrong with them.
My limited understanding of exception handling is based on this article:
http://www.microsoft.com/msj/0197/exception/exception.aspx
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
