dmd 1.047 and 2.032 releases
This will probably be the last OSX 10.5 release, the next should be 10.6. http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.047.zip http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.032.zip Many thanks to the numerous people who contributed to this update.
Re: dmd 1.047 and 2.032 releases
M-M-M-MONSTER KILL! The serious bug splatting action continues. Thank you Walter and contributors.
Re: dmd 1.047 and 2.032 releases
Walter Bright wrote: This will probably be the last OSX 10.5 release, the next should be 10.6. http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.047.zip http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.032.zip Many thanks to the numerous people who contributed to this update. This is great! I can't wait to try out the compiler's new CTFE capabilities. :) Thanks, Walter, Don, Andrei, and other contributors, for putting in all the hard work! -Lars
Re: dmd 1.047 and 2.032 releases
Indeed, using CTFE will probably feel different after this release of D1/D2.
Good work.
I'd like to improve this Wikipedia page some more:
http://en.wikipedia.org/wiki/Compile_time_function_execution
So after all such bugfixes are there better ways to implement the following
code (better = simpler, more natural, etc)?
import std.stdio: writeln;
int[] genFactorials(int n) {
int factorial(uint n) {
int result = 1;
for (int i = 1; i n+1; i++)
result *= i;
return result;
}
int[] result;
for (; n = 0; --n)
result = factorial(n) ~ result;
return result;
}
const int N = 13;
static const auto factorials = cast(int[N])genFactorials(N - 1);
void main() {
writeln(factorials);
}
For me creating tables at compile-time is an important use case for CTFE. But
that CTFE code is/was fragile, if you change it a bit it stops compiling.
Bye,
bearophile
Re: dmd 1.047 and 2.032 releases
Leandro Lucarella wrote: Walter Bright, el 3 de septiembre a las 01:16 me escribiste: This will probably be the last OSX 10.5 release, the next should be 10.6. http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.047.zip http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.032.zip Many thanks to the numerous people who contributed to this update. These are a very good release, thanks for your work. Aren't the new CTFE capabilities new features? They're basically bug fixes. All that stuff should have worked. There are several other bugs which cannot be fixed without them. For example, bug 1461 couldn't be fixed without allowing nested functions. Bug 1950 couldn't be fixed without implementing almost everything required for member functions. Some bugs are so crippling that when they're fixed, it's pretty much a new feature. Don't get me wrong, as I stated before, I'm really glad D1 get some new features/improvements, I just think the changes should be a little more tested before hit D1 (and new aditions to D1 should be more planned, for example, leaving them in D2 for a few releases only, so you can get real feedback from users before puting them in D1, and having some version scheme to indicate when new features are added). I believe you will find the new CTFE very stable. In implementing the improvements, many structural problems were fixed. It turns out to be a very effective way of diagnosing bugs.
Re: dmd 1.047 and 2.032 releases
Don, el 3 de septiembre a las 17:30 me escribiste: Leandro Lucarella wrote: Walter Bright, el 3 de septiembre a las 01:16 me escribiste: This will probably be the last OSX 10.5 release, the next should be 10.6. http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.047.zip http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.032.zip Many thanks to the numerous people who contributed to this update. These are a very good release, thanks for your work. Aren't the new CTFE capabilities new features? They're basically bug fixes. All that stuff should have worked. Not all of them, I've seen the spacs have changed for D2: http://www.dsource.org/projects/phobos/changeset/1262 I'm just talking about the changes that relaxed the CTFE restrictions imposed in the specs. Again, that can be called simply a non-standard DMD extension to D1 and that would be fine with me. Don't get me wrong, as I stated before, I'm really glad D1 get some new features/improvements, I just think the changes should be a little more tested before hit D1 (and new aditions to D1 should be more planned, for example, leaving them in D2 for a few releases only, so you can get real feedback from users before puting them in D1, and having some version scheme to indicate when new features are added). I believe you will find the new CTFE very stable. In implementing the improvements, many structural problems were fixed. It turns out to be a very effective way of diagnosing bugs. You never know. People use features in extremely different ways, sometimes in ways you can't possibly foreseen (I think once Walter said that about the kind of magic you do with CTFE =). Maybe you break some code that relied on something that doesn't compile (as Bartoz shows in his last post =). I'm not saying that would happen, I'm just saying that there is a lot of D out there, and even a simple change should be taken with care. There are 2 versions of D, one stable and one in development, I think that should be used and put new features out there in the development version only for some time, just to be sure, and then move them to the stable version (some sort of Debian testing/stable =P). And I want to say again that all your contribution, in this release in the CTFE front specially, is really impressive, and I hope you keep doing what you're doing for a long time, even if changes are folded in D1 with blind trust =) -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) Y serán tiempos de vanos encuentros entre humano y humano; en que las fieras se comerán entre ellas y después del final; en que se abríran las tierras y los cielos... y en el medio de la nada Racing saldrá campeón. -- Ricardo Vaporeso
Re: dmd 1.047 and 2.032 releases
Andrei Alexandrescu wrote: Walter, could you please update changelog.dd from svn and then update the html changelog? done.
Re: OT - Which Linux?
On Thu, Sep 3, 2009 at 1:49 AM, Nick Sabalauskya...@a.a wrote: And if anyone knows how to edit a system-settings text file without dropping to the command-line and doing sudo gedit blahfile (and without having to start out with sudo pwd or sudo echo just so the sudo gedit does something useful instead of creating a background process that sits and waits for input that'll never come from a prompt that I'll never see), then *please*, let me know. That's what gksu - or on KDE, kdesu - is for. ;)
Re: Nullable or Optional? Or something else?
Andrei Alexandrescu wrote:
Rainer Deyke wrote:
You need some syntactic way to distinguish the contained value from the
container. Using alias this seems messy here. Optional!Optional!T is
both valid and likely to occur.
Interesting. I wonder whether it's better to fold Optional!(Optional!T)
into Optional!T.
That would be semantically incorrect. Optional!T must be able to hold
all possible values of T, plus a distinct null value.
Consider:
Optional!int upper_limit;
Optional!(Optional!int) config_limit = config_file.get(upper_limit);
if (isNull(config_limit)) {
upper_limit = default_upper_limit;
} else {
upper_limit = config_limit; // Could be null.
}
Then consider that this could be in a template function, with
Optional!int supplied as a template argument.
--
Rainer Deyke - rain...@eldwood.com
Re: Apple Blocks added to C++?
Walter Bright wrote: Nested functions do closures in a straightforward way, so by leaving off nested functions they were forced to make an ugly syntax g. This is why I shake my head in just not understanding the process that led to their design. That is because nested functions and block closures have different purposes. Block closures avoid delocalization of code. For example, in Smalltalk, you could write something like the following to calculate the sum of the first 100 integers: s := 0. 1 to: 100 do: [ :i | s := s + i ]. Packaging the 's := s + i' block inside a nested function instead would (aside from unnecessarily having to also pass 's' by reference or by value-result to the function) require you to move back and forth between the piece of code above and the nested function in order to comprehend it. More generally, it allows you to write custom control structures, such as map, fold, and filter to generate more compact an coherent code. This is especially prevalent in functional languages (Scheme, LISP, Haskell, the whole ML family) and Smalltalk or Ruby. Research seems to indicate [1] that there is indeed a measurable readability benefit to this style of programming. The benefit of nested functions is something different. In essence, a nested function allows you to share state with the parent function (absent shared state, there is little reason to not make the nested function a top-level function instead). However, nested functions are hidden inside their parent, which means that they are not reusable; on top of that, object-oriented languages already have means to share state between multiple methods (which is sometimes imperfect, but so are nested functions). So, there are perfectly good reasons to have block closures, but not nested functions. Obviously, there are trade-offs, which may not appeal to everybody, but the design is still a rational one. Reimer Behrends [1] http://infoscience.epfl.ch/record/138586
Re: Nullable or Optional? Or something else?
Andrei Alexandrescu wrote: I plan to add a Nullable struct to Phobos (akin to C#'s Nullable, Boost's Optional). Apparently a good design is to define Optional!T with a minimum of member functions (ideally none) and have it use the alias this feature to masquerade as a T. That way Optional!T looks and feels much like a T, except that it supports a function bool isNull(T)(Optional!T value); Am I on the right track? If so, what is the name you'd prefer for this artifact? Andrei I prefer Nullable. Will there be an isNull overload for types that are inherently nullable (class references, pointers, delegates, etc)? Probably, there should be an isNullable concept for checking any type for nullability along with a ValueOfNullable template for obtaining the type of the underlying value. Should we be able to generically construct a Nullable!T from a value of T? How to generically set a nullable to null? Do we need a requirement that assert(isNull(Nullable!(T).init)) pass for any T? Can 'to' be extended to correctly convert nullable types from and to null string? Should conversions from null be case-sensitive?
Re: Apple Blocks added to C++?
Reimer Behrends wrote: The benefit of nested functions is something different. In essence, a nested function allows you to share state with the parent function (absent shared state, there is little reason to not make the nested function a top-level function instead). The reason for nested functions are: 1. factoring out repeated code within the function into a nested function 2. locality - a nested function is adjacent to where it is used, rather than somewhere else 3. isolation - by scope rules, it is easy to see the nested function and all calls to it These may be mundane, but they make for the code being more readable than the clumsy workarounds necessary without them. They can also often be inlined by the compiler, making them a no-cost abstraction. However, nested functions are hidden inside their parent, which means that they are not reusable; That's actually a feature, see (3). on top of that, object-oriented languages already have means to share state between multiple methods (which is sometimes imperfect, but so are nested functions). Nested classes (Java) and functors (C++) are pretty ugly next to nested functions. One could argue that gcc has them as an extension but nobody uses them. My experience with adding extensions to DM C++ is that nobody uses them because it is non-standard, not because they are a bad idea. So, there are perfectly good reasons to have block closures, but not nested functions. Obviously, there are trade-offs, which may not appeal to everybody, but the design is still a rational one. Reimer Behrends [1] http://infoscience.epfl.ch/record/138586
Re: Apple Blocks added to C++?
Walter Bright wrote:
The reason for nested functions are:
1. factoring out repeated code within the function into a nested function
2. locality - a nested function is adjacent to where it is used, rather
than somewhere else
3. isolation - by scope rules, it is easy to see the nested function and
all calls to it
You don't actually need nested functions for that. Consider, for
example, Tarjan's algorithm [1] to find strongly connected components in
a directed graph. It's normally a prime example of where you would use
nested functions: It's got some scaffolding to set up temporary state,
then repeatedly calls a recursive helper algorithm that operates on the
temporary state. Without going into the details of the algorithm, you
can basically write it as follows (using Scala as an example, though of
course it would also work in D, OCaml, etc.):
class DirectedGraph[V] {
...
def stronglyConnectedComponents: Set[Set[V]] = {
def recursiveHelper(vertex: V) = { ... }
...
}
...
}
However, you could also factor out the algorithm into a class of it's own:
class StronglyConnectedComponents[V](val graph: DirectedGraph[V]) {
def findAll: Set[Set[V]] = { ... }
private def recursiveHelper(vertex: V) = { ... }
}
This satisfies all your three criteria above. The potentially repeated
code is factored out into its own function, the helper function is next
to where it is used, and you can see who call it since it is private.
However, unlike a nested function, you have additional benefits: You can
reuse the helper function, for starters. And since the algorithm isn't
an integral part of the DirectedGraph class anymore, you can furthermore
improve the refactoring, since the algorithm doesn't need the full
graph, but only a set of vertices and a successor function:
class StronglyConnectedComponents[V](val vertices: Set[V],
val successors: V = Set[V]) {
def findAll: Set[Set[V]] = { ... }
private def recursiveHelper(vertex: V) = { ... }
}
Now we can use the algorithm not only for directed graphs, but also for
other, similar data structures that do not need to be a subtype of
DirectedGraph.
However, nested functions are hidden inside their parent, which means
that they are not reusable;
That's actually a feature, see (3).
As I showed above, you can have both locality and reusability. These are
not mutually exclusive properties.
on top of that, object-oriented languages already have means to share
state between multiple methods (which is sometimes imperfect, but so
are nested functions).
Nested classes (Java) and functors (C++) are pretty ugly next to nested
functions.
I am not even talking about nested classes, just classes (see above).
Classes are the standard vehicle in most object-oriented languages for
having multiple functions operating on shared state.
Mind you, I'm not saying that this is the only approach to deal with
such issues (and it has imperfections of its own). Just that it is an
alternative, equally valid way of doing things.
Reimer Behrends
[1]
http://en.wikipedia.org/wiki/Tarjan%27s_strongly_connected_components_algorithm
Re: How Nested Functions Work, part 1
Edward Diener wrote: Jarrett Billingsley wrote: On Wed, Sep 2, 2009 at 9:45 AM, Andrei Alexandrescuseewebsiteforem...@erdani.org wrote: Jarrett Billingsley wrote: Well repeat should probably always take a delegate since most likely, you're going to be passing it a lambda. However I agree that it would be very, very nice to be able to make APIs take just delegates and allow functions to be implicitly cast to them. You can already make your own thunks, but they're not going to be as efficient as something that actually works on an ABI level. Did someone file a bug report on this? Surprisingly, it doesn't seem like it. Walter himself, in the spec, said that Function pointers and delegates may merge into a common syntax and be interchangeable with each other, so I just assume that no one has found it necessary to make a report. Maybe there should be. I suggested this a long time back on this NG, and I am sure many others have also. A function pointer should essentially be a delegate whose object is null. That is essentially the way delegates are in .Net. In C++, boost::Function can encompass any C++ callable type so there is little theoretical reason why D should not encompass all callable types into a delegate. Having to program for any callable type, in a functional callable or signal/slots library, by dealing with the two signature variations of a function pointer and a delegate rather than a single common signature is a real PITA in an advanced programming language. IMHO it's ok if there are two types, as long as function is implicitly convertible to delegate. Function pointers have the advantage that they are only one word in size, can be assigned to atomically, and help interfacing with C callback APIs. Andrei
Re: dmd 1.047 and 2.032 releases
Brad Roberts Wrote: Walter Bright wrote: This will probably be the last OSX 10.5 release, the next should be 10.6. http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.047.zip http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.032.zip Many thanks to the numerous people who contributed to this update. Nice.. looks like 5 of 27 regression bugs have been fixed: 2560 -- 2.x 2665 -- 2.x 3168 -- 1.x 3169 -- 2.x 3196 -- 1.x and 2.x http://d.puremagic.com/issues/buglist.cgi?product=Dbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDbug_severity=regression 68 ever filed 22 left after this round Coincidently meaning 68% of the regression bugs have been fixed. 32% left. Good stuff, Brad Awesome, I'm gonna install and update my code today :) This may be early, but what can we expect for 2.0.33? New features such as T[new] and working shared aggregates?
Re: Nullable or Optional? Or something else?
Andrei Alexandrescu, el 2 de septiembre a las 14:39 me escribiste: I plan to add a Nullable struct to Phobos (akin to C#'s Nullable, Boost's Optional). Apparently a good design is to define Optional!T with a minimum of member functions (ideally none) and have it use the alias this feature to masquerade as a T. That way Optional!T looks and feels much like a T, except that it supports a function bool isNull(T)(Optional!T value); Am I on the right track? If so, what is the name you'd prefer for this artifact? Maybe this is a very silly question, but what is exactly the difference between Optional!T o/isNull(o) and T* o/o is null? -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) Somos testigos de Jaimito, venimos a traer la salvación, el mundo va a desaparecer, somos testigos de Jaimito!. Nos enyoguizamos... Así que somos testigos? Te dejo el culo hecho un vino, y la conch'itumá, y la conch'itumá! -- Sidharta Kiwi
Re: Turkish 'I's can't D either
Daniel Keep daniel.keep.li...@gmail.com wrote in message news:h70aup$cj...@digitalmars.com... One thing I think the typesystem should be used more for is attaching more semantic information to data. So maybe the solution is to introduce something like a Text type that also stores the language of the text. Then the library methods WILL have the right context to know how to act. Just a thought. If I'm understanding you correctly, then the hash function would treat Turkish i's the same as any other letter i, because the focus is on internal processing, but writef and friends would make the distinction because the text is meant to be read. Am I right? Ameer
Re: Nullable or Optional? Or something else?
On Wed, 02 Sep 2009 16:54:30 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: grauzone wrote: Andrei Alexandrescu wrote: I plan to add a Nullable struct to Phobos (akin to C#'s Nullable, Boost's Optional). Apparently a good design is to define Optional!T with a minimum of member functions (ideally none) and have it use the alias this feature to masquerade as a T. That way Optional!T looks and feels much like a T, except that it supports a function I still don't understand how one can feel comfortable with the fact, that alias this can overshadow arbitrary members of the alias'ed type. That's why I want to add no member functions to Optional. The test for null will be a free function. How does Optional!valuetype support this: Optional!valuetype x; x = null; Don't you need opAssign? -Steve
Re: Nullable or Optional? Or something else?
On Thu, 03 Sep 2009 02:36:12 -0400, Rainer Deyke rain...@eldwood.com
wrote:
Andrei Alexandrescu wrote:
Rainer Deyke wrote:
You need some syntactic way to distinguish the contained value from the
container. Using alias this seems messy here. Optional!Optional!T
is
both valid and likely to occur.
Interesting. I wonder whether it's better to fold Optional!(Optional!T)
into Optional!T.
That would be semantically incorrect. Optional!T must be able to hold
all possible values of T, plus a distinct null value.
Consider:
Optional!int upper_limit;
Optional!(Optional!int) config_limit = config_file.get(upper_limit);
if (isNull(config_limit)) {
upper_limit = default_upper_limit;
} else {
upper_limit = config_limit; // Could be null.
}
Then consider that this could be in a template function, with
Optional!int supplied as a template argument.
How does one distinguish an Optional!(Optional!int) that is null from an
Optional!(Optional!int) whose Optional!int is null? If there's no way to
test for it, then they are not conceivably different.
I think Andrei is right here, for any type T that already is nullable
(including pointer and reference types), Optional!T should alias to T.
-Steve
Re: Nullable or Optional? Or something else?
On Thu, 03 Sep 2009 10:40:13 -0400, Leandro Lucarella llu...@gmail.com wrote: Andrei Alexandrescu, el 2 de septiembre a las 14:39 me escribiste: I plan to add a Nullable struct to Phobos (akin to C#'s Nullable, Boost's Optional). Apparently a good design is to define Optional!T with a minimum of member functions (ideally none) and have it use the alias this feature to masquerade as a T. That way Optional!T looks and feels much like a T, except that it supports a function bool isNull(T)(Optional!T value); Am I on the right track? If so, what is the name you'd prefer for this artifact? Maybe this is a very silly question, but what is exactly the difference between Optional!T o/isNull(o) and T* o/o is null? The difference is you don't have to store the T somewhere else. That is, an Optional!T contains both the value if it is not null AND whether it is null or not. With a T*, the value is stored elsewhere, and you may have aliasing problems. -Steve
Re: Nullable or Optional? Or something else?
Leandro Lucarella wrote: Andrei Alexandrescu, el 2 de septiembre a las 14:39 me escribiste: I plan to add a Nullable struct to Phobos (akin to C#'s Nullable, Boost's Optional). Apparently a good design is to define Optional!T with a minimum of member functions (ideally none) and have it use the alias this feature to masquerade as a T. That way Optional!T looks and feels much like a T, except that it supports a function bool isNull(T)(Optional!T value); Am I on the right track? If so, what is the name you'd prefer for this artifact? Maybe this is a very silly question, but what is exactly the difference between Optional!T o/isNull(o) and T* o/o is null? It's a good question. There are two differences: (a) Optional!T behaves almost like a T in expressions, and (b) Optional!T does not support most features of pointers, such as arithmetic and comparison. Andrei
Re: Nullable or Optional? Or something else?
Andrei Alexandrescu wrote: Leandro Lucarella wrote: Andrei Alexandrescu, el 2 de septiembre a las 14:39 me escribiste: I plan to add a Nullable struct to Phobos (akin to C#'s Nullable, Boost's Optional). Apparently a good design is to define Optional!T with a minimum of member functions (ideally none) and have it use the alias this feature to masquerade as a T. That way Optional!T looks and feels much like a T, except that it supports a function bool isNull(T)(Optional!T value); Am I on the right track? If so, what is the name you'd prefer for this artifact? Maybe this is a very silly question, but what is exactly the difference between Optional!T o/isNull(o) and T* o/o is null? It's a good question. There are two differences: (a) Optional!T behaves almost like a T in expressions, and (b) Optional!T does not support most features of pointers, such as arithmetic and comparison. Andrei The answer above is incorrect. I actually answered about OptionalRef!T. Steve's answer is correct. Andrei
Re: Nullable or Optional? Or something else?
Andrei Alexandrescu, el 3 de septiembre a las 10:34 me escribiste: Leandro Lucarella wrote: Andrei Alexandrescu, el 2 de septiembre a las 14:39 me escribiste: I plan to add a Nullable struct to Phobos (akin to C#'s Nullable, Boost's Optional). Apparently a good design is to define Optional!T with a minimum of member functions (ideally none) and have it use the alias this feature to masquerade as a T. That way Optional!T looks and feels much like a T, except that it supports a function bool isNull(T)(Optional!T value); Am I on the right track? If so, what is the name you'd prefer for this artifact? Maybe this is a very silly question, but what is exactly the difference between Optional!T o/isNull(o) and T* o/o is null? It's a good question. There are two differences: (a) Optional!T behaves almost like a T in expressions, and (b) Optional!T does not support most features of pointers, such as arithmetic and comparison. (a) And *o behaves *exactly* like T, that doesn't seems like an advantage So, judging for (b) I guess is just a safety meassure. I agree with some other mail in this thread that it would be better to have proper references if you don't want to allow pointer arithmetics... -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) Hey you, dont help them to bury the light Don't give in without a fight.
Re: Nullable or Optional? Or something else?
Steven Schveighoffer, el 3 de septiembre a las 11:22 me escribiste: On Thu, 03 Sep 2009 10:40:13 -0400, Leandro Lucarella llu...@gmail.com wrote: Andrei Alexandrescu, el 2 de septiembre a las 14:39 me escribiste: I plan to add a Nullable struct to Phobos (akin to C#'s Nullable, Boost's Optional). Apparently a good design is to define Optional!T with a minimum of member functions (ideally none) and have it use the alias this feature to masquerade as a T. That way Optional!T looks and feels much like a T, except that it supports a function bool isNull(T)(Optional!T value); Am I on the right track? If so, what is the name you'd prefer for this artifact? Maybe this is a very silly question, but what is exactly the difference between Optional!T o/isNull(o) and T* o/o is null? The difference is you don't have to store the T somewhere else. That doesn't seems like a big problem having a GC. That is, an Optional!T contains both the value if it is not null AND whether it is null or not. With a T*, the value is stored elsewhere, and you may have aliasing problems. Ok, this seems like a reasonable point. So Optional!T is a value type, right? -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) CONDUCTOR BORRACHO CASI PROVOCA UNA TRAGEDIA: BATMAN UNICO TESTIGO -- Crónica TV
Re: Nullable or Optional? Or something else?
On Thu, Sep 3, 2009 at 12:02 PM, Steven
Schveighofferschvei...@yahoo.com wrote:
On Wed, 02 Sep 2009 15:39:28 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
I plan to add a Nullable struct to Phobos (akin to C#'s Nullable, Boost's
Optional).
Apparently a good design is to define Optional!T with a minimum of member
functions (ideally none) and have it use the alias this feature to
masquerade as a T. That way Optional!T looks and feels much like a T, except
that it supports a function
bool isNull(T)(Optional!T value);
Am I on the right track? If so, what is the name you'd prefer for this
artifact?
I like nullable, but optional will work.
---
I noticed that in some of your responses, you refer to OptionalRef, Can you
elaborate on that? I looked up Nullable for C#, and it specifically says
that you can't apply the Nullable struct to a non-value type (because
reference types are nullable).
Since we are in D and not C# and have vastly better template mechanisms, I
was assuming that Optional!T would simply alias to T if T is a reference
type already (such as a class or pointer).
This is also going to be better looking if the compiler helps. Having to do
isNull(x) all the time instead of x !is null is going to be a pain when you
aren't sure whether x is an Optional!T or a true reference type (such as a
class).
It would also solve some other problems. For instance being able to test if
Rebindable is null...
I wonder if the compiler could do something nifty like this:
struct S
{
int n;
alias n this;
static S opNull() { return S(int.min); }
}
S s;
s = null; // translates to s = S.opNull();
if(s !is null); // translates to if(s !is S.opNull())
Now you have a nullable int type that works for most cases and only
requires an int storage space.
I don't understand the ramifications on the context-free grammar, but does
something like this seem feasible?
The semantics here have nothing to do with the grammar. It's not
really that different from operator overloading.
Re: Nullable or Optional? Or something else?
On Thu, 03 Sep 2009 11:50:55 -0400, Leandro Lucarella llu...@gmail.com wrote: Steven Schveighoffer, el 3 de septiembre a las 11:22 me escribiste: On Thu, 03 Sep 2009 10:40:13 -0400, Leandro Lucarella Maybe this is a very silly question, but what is exactly the difference between Optional!T o/isNull(o) and T* o/o is null? The difference is you don't have to store the T somewhere else. That doesn't seems like a big problem having a GC. There are performance concerns, you need 16 bytes minimum to store a value on the heap, so a 4-byte integer becomes 16 bytes on the heap. And the GC is way slower than storing on the stack. That is, an Optional!T contains both the value if it is not null AND whether it is null or not. With a T*, the value is stored elsewhere, and you may have aliasing problems. Ok, this seems like a reasonable point. So Optional!T is a value type, right? If T is a value type, yes. I'm not sure what Andrei has in mind if T is a reference type. -Steve
Re: Nullable or Optional? Or something else?
On Wed, 02 Sep 2009 15:39:28 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: I plan to add a Nullable struct to Phobos (akin to C#'s Nullable, Boost's Optional). Apparently a good design is to define Optional!T with a minimum of member functions (ideally none) and have it use the alias this feature to masquerade as a T. That way Optional!T looks and feels much like a T, except that it supports a function bool isNull(T)(Optional!T value); Am I on the right track? If so, what is the name you'd prefer for this artifact? I just thought of something else. If you use alias this, then what happens here? Optional!int i = null; int n = i; If you are counting on i to implicitly cast to the int using alias this, then this probably won't work right (I would think it should throw or require an explicit cast). I guess if you alias this to a function (is that possible yet?) which checks for null first, then you may have better behavior, but you still should probably require a cast. -Steve
Re: Apple Blocks added to C++?
Reimer Behrends wrote:
However, you could also factor out the algorithm into a class of it's own:
Yes, so instead of a nested function with everything right there next to
its use, I have to go elsewhere in the file looking for a class. While
this is doable, I don't think it's half as nice. I also think that
trying to force something that's naturally a function that simply
accesses the outer function's variables into a class with member
variables that have to be copied, etc., is less desirable.
I don't think you'll agree with me g, but take this example and
rewrite it using classes:
int foo(int a)
{
int bar(int i) { return a + 3; }
return bar(3) + bar(4);
}
and let's compare!
Re: Apple Blocks added to C++?
== Quote from Walter Bright (newshou...@digitalmars.com)'s article One could argue that gcc has them as an extension but nobody uses them. My experience with adding extensions to DM C++ is that nobody uses them because it is non-standard, not because they are a bad idea. And that's why I won't be using Apple's new closures, regardless of whether I'd actually find them useful.
The Linker is not a Magical Program
A rant I wrote a few months ago: http://programmer.97things.oreilly.com/wiki/index.php/The_Linker_Is_not_a_Magical_Program
Re: The Linker is not a Magical Program
That is probably because most books don't explain it properly. Heck my C++ book doesn't even mention it. And for the extern keyword there is only one very short explanation. extern: Storage class for objects declared outside the local block. Oh and I read your rant about linkers, ... and it still looks magical. And I bet Andrei's book will keep it short too. And Magic isn't always a bad thing. And the D shared libraries thing, very complex, no magic. C# assemblies. Everything just works, magic.
Re: Nullable or Optional? Or something else?
Steven Schveighoffer wrote: How does one distinguish an Optional!(Optional!int) that is null from an Optional!(Optional!int) whose Optional!int is null? If there's no way to test for it, then they are not conceivably different. That's the fatal flaw in Andrei's design that I was pointing out, yes. I think Andrei is right here, for any type T that already is nullable (including pointer and reference types), Optional!T should alias to T. Your conclusion is backwards here. In order for Optional!T to be useful, it must be able to hold all possible of T plus a distinct null value. If Optional!T cannot do that for T = Optional!T2, then Optional!T is useless in generic programming, bordering on useless in general. I think my example program demonstrated this amply. -- Rainer Deyke - rain...@eldwood.com
Re: Apple Blocks added to C++?
Walter Bright wrote: Nested functions do closures in a straightforward way, so by leaving off nested functions they were forced to make an ugly syntax g. This is why I shake my head in just not understanding the process that led to their design. Well, one problem would be that nested functions are already a feature in GCC, and they are not compatible (code would be broken by an introduction, at least the ABI, an ABI breaking modification of nested GCC function could have been controversial at least). Nested functions can usually not be called after the defining function have returned. You cannot return blocks directly (since they are located on the stack), but you can return a heap copy of the block. This is handled in D automatically. Have not looked at D's implementation of this, looks nice I think. In C this would mean stealing some extra keywords, adding _Delegate or whatever and then a file stddelegate.h that #define delegate _Delegate. Also, without forcing GC on the user, returning a delegate would be tricky to say the least (if efficiency is needed). So given the situation, they probably did a decent choice, a bit like patching an x86 CPU like AMD did for the AMD64. / Mattias
Re: Apple Blocks added to C++?
Sean Kelly wrote: == Quote from Walter Bright (newshou...@digitalmars.com)'s article One could argue that gcc has them as an extension but nobody uses them. My experience with adding extensions to DM C++ is that nobody uses them because it is non-standard, not because they are a bad idea. And that's why I won't be using Apple's new closures, regardless of whether I'd actually find them useful. Yeah, that is a problem. They did add them to GCC (not only Clang) though, and as far as using GCC extensions, most compilers adopt them one way or the other. Hopefully, they will be imported from the Apple branch of GCC to the mainline. Many things in GCC are just incredibly useful, including the vector_size attribute, and people are using them, it is not a matter of being non standard, but rather that the extensions are good enough that enough vendors implement them. I think that the blocks are crying out for standardisation, maybe not by ISO, but by some informal means between compiler vendors. / Mattias
Re: The Linker is not a Magical Program
I was wondering if the following is useful, probably not.
Reserve a spot on the vtable, which is automatically set to NULL.
class AClass
{
__virtualspot void caption(string text); //no implementation
__virtualspot string caption();
}
class BClass:AClass
{
}
BClass b = new BClass();
b.caption = test; //compiles
1. Would compile. But it would not run if the vtable spot
has not been filled up by some API.
2. Can derive from the class/interface, without providing
the implementation.
Re: Nullable or Optional? Or something else?
On Wed, 02 Sep 2009 23:39:28 +0400, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: I plan to add a Nullable struct to Phobos (akin to C#'s Nullable, Boost's Optional). Apparently a good design is to define Optional!T with a minimum of member functions (ideally none) and have it use the alias this feature to masquerade as a T. That way Optional!T looks and feels much like a T, except that it supports a function bool isNull(T)(Optional!T value); Am I on the right track? If so, what is the name you'd prefer for this artifact? Andrei Nullable, unless this feature is planned for value types only (please, no!)
Re: Apple Blocks added to C++?
On 2009-09-03 14:14:27 -0400, Sean Kelly s...@invisibleduck.org said: == Quote from Walter Bright (newshou...@digitalmars.com)'s article One could argue that gcc has them as an extension but nobody uses them. My experience with adding extensions to DM C++ is that nobody uses them because it is non-standard, not because they are a bad idea. And that's why I won't be using Apple's new closures, regardless of whether I'd actually find them useful. Even for OSX-specific code? I see no reason not to use them in a Cocoa app for instance, nor when you want to schedule tasks using Grand Central Dispatch. You're already bound to Apple-world anyway. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: The Linker is not a Magical Program
Walter Bright Wrote: A rant I wrote a few months ago: http://programmer.97things.oreilly.com/wiki/index.php/The_Linker_Is_not_a_Magical_Program Great read, reminded me of my first weeks in C/C++ land, back when I couldn't tell the compiler from the linker :) These days only the OMF format on Windows still seems magic because I can't find any decent documentation on its format. I had the hardest of times putting together a CodeView reader, finally got one working after consulting at least 10 different documents, looking at shitloads of codeview data in hex editors, and plenty of trial and error magic, and I still only support version 4.10, but I guess that makes me a magician! Now if I only can find enough documentation about OMF to write a COFF to OMF converter.. there are still a bunch of libraries I use in C which I'd like to compile to static libraries in VC++ and link in DMD. I tried compiling with DMC to generate static OMF libraries directly, but they always fail on missing files like xmmintrin.h and other misc issues. I also searched the web high and low for a coff2omf binary and only found one which generate broken libraries, dmd won't see any symbols in the converted files and the linker goes crazy on unresolved references. I tried link /CONVERT only to find out there is no /CONVERT option. So yeah, the linker is not a magical program, but it does operate in a magical world.
Re: Apple Blocks added to C++?
== Quote from Michel Fortin (michel.for...@michelf.com)'s article On 2009-09-03 14:14:27 -0400, Sean Kelly s...@invisibleduck.org said: == Quote from Walter Bright (newshou...@digitalmars.com)'s article One could argue that gcc has them as an extension but nobody uses them. My experience with adding extensions to DM C++ is that nobody uses them because it is non-standard, not because they are a bad idea. And that's why I won't be using Apple's new closures, regardless of whether I'd actually find them useful. Even for OSX-specific code? Yup. I always write code with portability in mind, because my target platforms have a way of changing. If I were writing user-mode applications for OSX this might be different, since I'd be using Cocoa or whatever anyway, but... I see no reason not to use them in a Cocoa app for instance, nor when you want to schedule tasks using Grand Central Dispatch. You're already bound to Apple-world anyway. Yeah exactly. That just isn't the realm that I work in.
Re: How Nested Functions Work, part 1
Andrei Alexandrescu wrote: Edward Diener wrote: Jarrett Billingsley wrote: On Wed, Sep 2, 2009 at 9:45 AM, Andrei Alexandrescuseewebsiteforem...@erdani.org wrote: Jarrett Billingsley wrote: Well repeat should probably always take a delegate since most likely, you're going to be passing it a lambda. However I agree that it would be very, very nice to be able to make APIs take just delegates and allow functions to be implicitly cast to them. You can already make your own thunks, but they're not going to be as efficient as something that actually works on an ABI level. Did someone file a bug report on this? Surprisingly, it doesn't seem like it. Walter himself, in the spec, said that Function pointers and delegates may merge into a common syntax and be interchangeable with each other, so I just assume that no one has found it necessary to make a report. Maybe there should be. I suggested this a long time back on this NG, and I am sure many others have also. A function pointer should essentially be a delegate whose object is null. That is essentially the way delegates are in .Net. In C++, boost::Function can encompass any C++ callable type so there is little theoretical reason why D should not encompass all callable types into a delegate. Having to program for any callable type, in a functional callable or signal/slots library, by dealing with the two signature variations of a function pointer and a delegate rather than a single common signature is a real PITA in an advanced programming language. IMHO it's ok if there are two types, as long as function is implicitly convertible to delegate. Function pointers have the advantage that they are only one word in size, can be assigned to atomically, and help interfacing with C callback APIs. Good point ! That would be fine also. The basic issue is to allow a single syntactical construct to encompass all callables in order to simplify code design. But I am still theoretically in favor of the single type, purely from KISS principles. The single delegate type subsumes the function pointer type. As far as the size savings, of course some small amount of memory can be saved. As far as the assigned speed, if the delegate type in D is as I suppose a language, and not a library, implementation, the language ( compiler ) can be smart enough to know that the programmer is assigning a function pointer to the delegate and make the speedier atomic assignment. What I imagine will happen in D is that when an updated delegate type allows itself to be initialized with a function pointer, the vast majority of D programmers will use delegate for all callables and the function pointer will remain simply an artefact of the language. Then D can eventually get rid of it g ! This is analogous to the transition that will happen in C++ from function pointers/member function pointers to std::function in C++0x. Of course I never expect C++ to get rid of anything because some person in 3009, going back to code 100 years old and still supported by C++30x, still uses function pointers/member function pointers and the C++ standard committee deems it impermissible to break that code gg !
Re: How Nested Functions Work, part 1
On Thu, Sep 3, 2009 at 6:48 PM, Edward Dienereddielee_no_spam_h...@tropicsoft.com wrote: What I imagine will happen in D is that when an updated delegate type allows itself to be initialized with a function pointer, the vast majority of D programmers will use delegate for all callables and the function pointer will remain simply an artefact of the language. Then D can eventually get rid of it g ! There's no real reason to get rid of function pointers. What type would the .funcptr property of a delegate be, if function pointers didn't exist? You also need them for C compatibility.
Re: The Linker is not a Magical Program
Jeremie Pelletier wrote: Now if I only can find enough documentation about OMF to write a COFF to OMF converter.. http://www.azillionmonkeys.com/qed/Omfg.pdf
Re: The Linker is not a Magical Program
Walter Bright wrote: Jeremie Pelletier wrote: Now if I only can find enough documentation about OMF to write a COFF to OMF converter.. http://www.azillionmonkeys.com/qed/Omfg.pdf What I always wanted to know: besides OPTLINK, is there an OMF linker that can link D programs? I couldn't find one.
Re: How Nested Functions Work, part 1
Jarrett Billingsley wrote: On Thu, Sep 3, 2009 at 6:48 PM, Edward Dienereddielee_no_spam_h...@tropicsoft.com wrote: What I imagine will happen in D is that when an updated delegate type allows itself to be initialized with a function pointer, the vast majority of D programmers will use delegate for all callables and the function pointer will remain simply an artefact of the language. Then D can eventually get rid of it g ! There's no real reason to get rid of function pointers. What type would the .funcptr property of a delegate be, if function pointers Probably the same type as .ptr? And by the way, I find it really strange, that .funcptr results into an incorrectly typed function pointer, that basically has the wrong calling convention for the destination code, which usually is a method. It'd be different if signature of the .funcptr included an explicit argument for the hidden pointers. So that you could write: dg.funcptr(dg.ptr, arguments); didn't exist? You also need them for C compatibility. And that's about the only reason to keep them. But wouldn't it be possible for the compiler to allow assignment of a function pointer to a delegate? All the compiler had to do is to generate a hidden dispatch method to translate the different calling conventions. The delegate's .funcptr points to that dispatch function, and the dispatch function call the actual function. If the assigned function pointer is not a statically known function (but from a variable), the function address could be stored in the delegate's .ptr. Would this work?
Re: The Linker is not a Magical Program
Walter Bright Wrote: Jeremie Pelletier wrote: Now if I only can find enough documentation about OMF to write a COFF to OMF converter.. http://www.azillionmonkeys.com/qed/Omfg.pdf Sweet, you're the man Walter!
Re: How Nested Functions Work, part 1
On Thu, Sep 3, 2009 at 7:10 PM, grauzonen...@example.net wrote: Probably the same type as .ptr? void*? That's just silly. Let's just throw all static typing out the window. :P And by the way, I find it really strange, that .funcptr results into an incorrectly typed function pointer, that basically has the wrong calling convention for the destination code, which usually is a method. It'd be different if signature of the .funcptr included an explicit argument for the hidden pointers. So that you could write: dg.funcptr(dg.ptr, arguments); Yeah. There probably needs to be an extern(this) or so for functions that take a context pointer, like __thiscall in VC++. The way it works now is rather unsafe. And that's about the only reason to keep them. But wouldn't it be possible for the compiler to allow assignment of a function pointer to a delegate? All the compiler had to do is to generate a hidden dispatch method to translate the different calling conventions. The delegate's .funcptr points to that dispatch function, and the dispatch function call the actual function. If the assigned function pointer is not a statically known function (but from a variable), the function address could be stored in the delegate's .ptr. Would this work? Of course it'd work. And D APIs would take delegates and everyone would be happy. But it still doesn't really justify getting rid of raw function pointers.
Re: How Nested Functions Work, part 1
Edward Diener wrote: Andrei Alexandrescu wrote: Edward Diener wrote: Jarrett Billingsley wrote: On Wed, Sep 2, 2009 at 9:45 AM, Andrei Alexandrescuseewebsiteforem...@erdani.org wrote: Jarrett Billingsley wrote: Well repeat should probably always take a delegate since most likely, you're going to be passing it a lambda. However I agree that it would be very, very nice to be able to make APIs take just delegates and allow functions to be implicitly cast to them. You can already make your own thunks, but they're not going to be as efficient as something that actually works on an ABI level. Did someone file a bug report on this? Surprisingly, it doesn't seem like it. Walter himself, in the spec, said that Function pointers and delegates may merge into a common syntax and be interchangeable with each other, so I just assume that no one has found it necessary to make a report. Maybe there should be. I suggested this a long time back on this NG, and I am sure many others have also. A function pointer should essentially be a delegate whose object is null. That is essentially the way delegates are in .Net. In C++, boost::Function can encompass any C++ callable type so there is little theoretical reason why D should not encompass all callable types into a delegate. Having to program for any callable type, in a functional callable or signal/slots library, by dealing with the two signature variations of a function pointer and a delegate rather than a single common signature is a real PITA in an advanced programming language. IMHO it's ok if there are two types, as long as function is implicitly convertible to delegate. Function pointers have the advantage that they are only one word in size, can be assigned to atomically, and help interfacing with C callback APIs. Good point ! That would be fine also. The basic issue is to allow a single syntactical construct to encompass all callables in order to simplify code design. But I am still theoretically in favor of the single type, purely from KISS principles. The single delegate type subsumes the function pointer type. As far as the size savings, of course some small amount of memory can be saved. As far as the assigned speed, if the delegate type in D is as I suppose a language, and not a library, implementation, the language ( compiler ) can be smart enough to know that the programmer is assigning a function pointer to the delegate and make the speedier atomic assignment. What I imagine will happen in D is that when an updated delegate type allows itself to be initialized with a function pointer, the vast majority of D programmers will use delegate for all callables and the function pointer will remain simply an artefact of the language. Then D can eventually get rid of it g ! This is analogous to the transition that will happen in C++ from function pointers/member function pointers to std::function in C++0x. Of course I never expect C++ to get rid of anything because some person in 3009, going back to code 100 years old and still supported by C++30x, still uses function pointers/member function pointers and the C++ standard committee deems it impermissible to break that code gg ! Actually it could be said that C++'s exercise with pointers to member functions, which unifies a variety of functions (virtual, nonvirtual, in a host of multiple inheritance scenario), although KISS-motivated for the user, was at the same time a departure from C++'s usual approach, and a disastrous one. Andrei
Re: How Nested Functions Work, part 1
Edward Diener wrote: Andrei Alexandrescu wrote: Edward Diener wrote: Jarrett Billingsley wrote: On Wed, Sep 2, 2009 at 9:45 AM, Andrei Alexandrescuseewebsiteforem...@erdani.org wrote: Jarrett Billingsley wrote: Well repeat should probably always take a delegate since most likely, you're going to be passing it a lambda. However I agree that it would be very, very nice to be able to make APIs take just delegates and allow functions to be implicitly cast to them. You can already make your own thunks, but they're not going to be as efficient as something that actually works on an ABI level. Did someone file a bug report on this? Surprisingly, it doesn't seem like it. Walter himself, in the spec, said that Function pointers and delegates may merge into a common syntax and be interchangeable with each other, so I just assume that no one has found it necessary to make a report. Maybe there should be. I suggested this a long time back on this NG, and I am sure many others have also. A function pointer should essentially be a delegate whose object is null. That is essentially the way delegates are in .Net. In C++, boost::Function can encompass any C++ callable type so there is little theoretical reason why D should not encompass all callable types into a delegate. Having to program for any callable type, in a functional callable or signal/slots library, by dealing with the two signature variations of a function pointer and a delegate rather than a single common signature is a real PITA in an advanced programming language. IMHO it's ok if there are two types, as long as function is implicitly convertible to delegate. Function pointers have the advantage that they are only one word in size, can be assigned to atomically, and help interfacing with C callback APIs. Good point ! That would be fine also. The basic issue is to allow a single syntactical construct to encompass all callables in order to simplify code design. But I am still theoretically in favor of the single type, purely from KISS principles. The single delegate type subsumes the function pointer type. As far as the size savings, of course some small amount of memory can be saved. As far as the assigned speed, if the delegate type in D is as I suppose a language, and not a library, implementation, the language ( compiler ) can be smart enough to know that the programmer is assigning a function pointer to the delegate and make the speedier atomic assignment. What I imagine will happen in D is that when an updated delegate type allows itself to be initialized with a function pointer, the vast majority of D programmers will use delegate for all callables and the function pointer will remain simply an artefact of the language. Then D can eventually get rid of it g ! This is analogous to the transition that will happen in C++ from function pointers/member function pointers to std::function in C++0x. Of course I never expect C++ to get rid of anything because some person in 3009, going back to code 100 years old and still supported by C++30x, still uses function pointers/member function pointers and the C++ standard committee deems it impermissible to break that code gg ! Actually it could be said that C++'s exercise with pointers to member functions, which unifies a variety of functions (virtual, nonvirtual, in a host of multiple inheritance scenario), although KISS-motivated for the user, was at the same time a departure from C++'s usual approach, and a disastrous one. Andrei
Re: How Nested Functions Work, part 1
Andrei Alexandrescu wrote: Edward Diener wrote: Andrei Alexandrescu wrote: Edward Diener wrote: Jarrett Billingsley wrote: On Wed, Sep 2, 2009 at 9:45 AM, Andrei Alexandrescuseewebsiteforem...@erdani.org wrote: Jarrett Billingsley wrote: Well repeat should probably always take a delegate since most likely, you're going to be passing it a lambda. However I agree that it would be very, very nice to be able to make APIs take just delegates and allow functions to be implicitly cast to them. You can already make your own thunks, but they're not going to be as efficient as something that actually works on an ABI level. Did someone file a bug report on this? Surprisingly, it doesn't seem like it. Walter himself, in the spec, said that Function pointers and delegates may merge into a common syntax and be interchangeable with each other, so I just assume that no one has found it necessary to make a report. Maybe there should be. I suggested this a long time back on this NG, and I am sure many others have also. A function pointer should essentially be a delegate whose object is null. That is essentially the way delegates are in .Net. In C++, boost::Function can encompass any C++ callable type so there is little theoretical reason why D should not encompass all callable types into a delegate. Having to program for any callable type, in a functional callable or signal/slots library, by dealing with the two signature variations of a function pointer and a delegate rather than a single common signature is a real PITA in an advanced programming language. IMHO it's ok if there are two types, as long as function is implicitly convertible to delegate. Function pointers have the advantage that they are only one word in size, can be assigned to atomically, and help interfacing with C callback APIs. Good point ! That would be fine also. The basic issue is to allow a single syntactical construct to encompass all callables in order to simplify code design. But I am still theoretically in favor of the single type, purely from KISS principles. The single delegate type subsumes the function pointer type. As far as the size savings, of course some small amount of memory can be saved. As far as the assigned speed, if the delegate type in D is as I suppose a language, and not a library, implementation, the language ( compiler ) can be smart enough to know that the programmer is assigning a function pointer to the delegate and make the speedier atomic assignment. What I imagine will happen in D is that when an updated delegate type allows itself to be initialized with a function pointer, the vast majority of D programmers will use delegate for all callables and the function pointer will remain simply an artefact of the language. Then D can eventually get rid of it g ! This is analogous to the transition that will happen in C++ from function pointers/member function pointers to std::function in C++0x. Of course I never expect C++ to get rid of anything because some person in 3009, going back to code 100 years old and still supported by C++30x, still uses function pointers/member function pointers and the C++ standard committee deems it impermissible to break that code gg ! Actually it could be said that C++'s exercise with pointers to member functions, which unifies a variety of functions (virtual, nonvirtual, in a host of multiple inheritance scenario), although KISS-motivated for the user, was at the same time a departure from C++'s usual approach, and a disastrous one. Why do you think pointer to member function was a departure from C++'s usual approach ? Bjarne mentioned in one of his books of having considered the C++ version of a delegate as a language construct ( taking the address of an object's member function ) sometime in the design of C++ and having rejected it. I can not remember the reason but it was evidently considered. I don't think pointer to member function is a disaster, just sometimes difficult to use, and of course very limiting. I agree I would have still liked a delegate to be part of the C++ language instead of pointer to member function, since the former is much more flexible. But std::function/std::bind ( boost::function/boost::bind or boost::lambda ) solves that problem nicely at the expense of a little more syntax but with great flexibility in binding.
Re: How Nested Functions Work, part 1
Edward Diener wrote: Andrei Alexandrescu wrote: Edward Diener wrote: Andrei Alexandrescu wrote: Edward Diener wrote: Jarrett Billingsley wrote: On Wed, Sep 2, 2009 at 9:45 AM, Andrei Alexandrescuseewebsiteforem...@erdani.org wrote: Jarrett Billingsley wrote: Well repeat should probably always take a delegate since most likely, you're going to be passing it a lambda. However I agree that it would be very, very nice to be able to make APIs take just delegates and allow functions to be implicitly cast to them. You can already make your own thunks, but they're not going to be as efficient as something that actually works on an ABI level. Did someone file a bug report on this? Surprisingly, it doesn't seem like it. Walter himself, in the spec, said that Function pointers and delegates may merge into a common syntax and be interchangeable with each other, so I just assume that no one has found it necessary to make a report. Maybe there should be. I suggested this a long time back on this NG, and I am sure many others have also. A function pointer should essentially be a delegate whose object is null. That is essentially the way delegates are in .Net. In C++, boost::Function can encompass any C++ callable type so there is little theoretical reason why D should not encompass all callable types into a delegate. Having to program for any callable type, in a functional callable or signal/slots library, by dealing with the two signature variations of a function pointer and a delegate rather than a single common signature is a real PITA in an advanced programming language. IMHO it's ok if there are two types, as long as function is implicitly convertible to delegate. Function pointers have the advantage that they are only one word in size, can be assigned to atomically, and help interfacing with C callback APIs. Good point ! That would be fine also. The basic issue is to allow a single syntactical construct to encompass all callables in order to simplify code design. But I am still theoretically in favor of the single type, purely from KISS principles. The single delegate type subsumes the function pointer type. As far as the size savings, of course some small amount of memory can be saved. As far as the assigned speed, if the delegate type in D is as I suppose a language, and not a library, implementation, the language ( compiler ) can be smart enough to know that the programmer is assigning a function pointer to the delegate and make the speedier atomic assignment. What I imagine will happen in D is that when an updated delegate type allows itself to be initialized with a function pointer, the vast majority of D programmers will use delegate for all callables and the function pointer will remain simply an artefact of the language. Then D can eventually get rid of it g ! This is analogous to the transition that will happen in C++ from function pointers/member function pointers to std::function in C++0x. Of course I never expect C++ to get rid of anything because some person in 3009, going back to code 100 years old and still supported by C++30x, still uses function pointers/member function pointers and the C++ standard committee deems it impermissible to break that code gg ! Actually it could be said that C++'s exercise with pointers to member functions, which unifies a variety of functions (virtual, nonvirtual, in a host of multiple inheritance scenario), although KISS-motivated for the user, was at the same time a departure from C++'s usual approach, and a disastrous one. Why do you think pointer to member function was a departure from C++'s usual approach ? Don't pay for what you don't use, low-key approach to under-the-wraps magic. The pointer to member type is the most elaborate of all C++ built-in types. Bjarne mentioned in one of his books of having considered the C++ version of a delegate as a language construct ( taking the address of an object's member function ) sometime in the design of C++ and having rejected it. I can not remember the reason but it was evidently considered. I'm not saying it was a decision made in ignorance. IMHO it was, however, a wrong decision, and experience with pointer to member functions (i.e., few even know how to write one down) supports that hypothesis. I don't think pointer to member function is a disaster, just sometimes difficult to use, and of course very limiting. I agree I would have still liked a delegate to be part of the C++ language instead of pointer to member function, since the former is much more flexible. But std::function/std::bind ( boost::function/boost::bind or boost::lambda ) solves that problem nicely at the expense of a little more syntax but with great flexibility in binding. Nice doesn't come to my mind when thinking of the above, but the significant runtime cost does :o). Andrei
Re: The Linker is not a Magical Program
grauzone wrote: Walter Bright wrote: Jeremie Pelletier wrote: Now if I only can find enough documentation about OMF to write a COFF to OMF converter.. http://www.azillionmonkeys.com/qed/Omfg.pdf What I always wanted to know: besides OPTLINK, is there an OMF linker that can link D programs? I couldn't find one. Maybe the watcom one. But I've never tried it.
Re: The Linker is not a Magical Program
Walter Bright wrote: grauzone wrote: Walter Bright wrote: Jeremie Pelletier wrote: Now if I only can find enough documentation about OMF to write a COFF to OMF converter.. http://www.azillionmonkeys.com/qed/Omfg.pdf What I always wanted to know: besides OPTLINK, is there an OMF linker that can link D programs? I couldn't find one. Maybe the watcom one. But I've never tried it. I know someone who tried sufficiently hard, but failed. But I don't remember what exactly was the problem.
Re: The Linker is not a Magical Program
grauzone wrote: Walter Bright wrote: grauzone wrote: Walter Bright wrote: Jeremie Pelletier wrote: Now if I only can find enough documentation about OMF to write a COFF to OMF converter.. http://www.azillionmonkeys.com/qed/Omfg.pdf What I always wanted to know: besides OPTLINK, is there an OMF linker that can link D programs? I couldn't find one. Maybe the watcom one. But I've never tried it. I know someone who tried sufficiently hard, but failed. But I don't remember what exactly was the problem. What originally motivated me to get our own linker was the erratic reliability of other ones.
Re: The Linker is not a Magical Program
在 Fri, 04 Sep 2009 04:39:28 +0800，Sclytrack id...@hotmail.com 写道:
I was wondering if the following is useful, probably not.
Reserve a spot on the vtable, which is automatically set to NULL.
class AClass
{
__virtualspot void caption(string text); //no implementation
__virtualspot string caption();
}
I think the above is designed for .di files. However, maybe we should
limit it to di only. If it's in .d, it probably a bug or workaround of dmd
bugs.
class BClass:AClass
{
}
BClass b = new BClass();
b.caption = test; //compiles
1. Would compile. But it would not run if the vtable spot
has not been filled up by some API.
2. Can derive from the class/interface, without providing
the implementation.
--
使用 Opera 革命性的电子邮件客户程序: http://www.opera.com/mail/
Re: The Linker is not a Magical Program
Walter Bright wrote: A rant I wrote a few months ago: http://programmer.97things.oreilly.com/wiki/index.php/The_Linker_Is_not_a_Magical_Program For reference, GNU ld has to be compiled with -linvisible-pink-unicorn.
Re: [OT] Haxe if context-sensitive? (Q for Grammar Experts)
Danny Wilson blueze...@gmail.com wrote in message news:op.uzpaihg5bmu...@danny-wilsons-ep45-ds4.local... Nick are you on freenode.org #haxe ? :-) No, I haven't really used IRC in ages. If you (or anyone) wanted to contact me privately though, my email is here ( http://www.semitwist.com/contact.html ) (yes, I'm overly paranoid about spam ;) ), and I'm on the AIM network as Abscissa256 (But I should point out, I'm frequently Away when I'm not really away and vice versa.)
Compiled dmd2.032 in VC++ 2009!
Well I've decided to get a look at the dmd2 source and see what I can contribute to it, only to notice it is very VC++ unfriendly. After a few hours of work, I finally got it to compile, and it works great, for the most part. VC++ has no real support for long double; it supports the syntax as distinct types but they are implemented as double precision, not extended precision. There are no stdint.h and fenv.h headers, I found isnan() in float.h but I had to leave out backend/strtold.c for now, there was no unresolved references from this. alloca() was also found in malloc.h, not stdlib.h. The joys of not using a C99 compliant compiler heh. I also couldn't get the compiler to compile *.c as C++, even with the /TP switch (Compile as C++), I had to rename every file to *.cpp. Other than that, it was standard compilation, I disabled a few warnings to not get my output flooded, defined MARS, __I86__ and _DH, generated the different table files, and compiled, all from within the IDE. Jumping back in C++ reminded me why I loved D so much, I will definitely start working on, or help developing it if already planned, a D port of dmd once the spec gets stable. In any ways, I am wondering where I can submit my changes for review, since I doubt there is any public access to the repository on dsource, and I would very much like to contribute to the D programming language.
Re: The Linker is not a Magical Program
Christopher Wright Wrote: Walter Bright wrote: A rant I wrote a few months ago: http://programmer.97things.oreilly.com/wiki/index.php/The_Linker_Is_not_a_Magical_Program For reference, GNU ld has to be compiled with -linvisible-pink-unicorn. How can you know its pink if its also invisible?
Re: The Linker is not a Magical Program
On Fri, Sep 4, 2009 at 12:15 AM, Jeremie Pelletierjerem...@gmail.com wrote: Christopher Wright Wrote: Walter Bright wrote: A rant I wrote a few months ago: http://programmer.97things.oreilly.com/wiki/index.php/The_Linker_Is_not_a_Magical_Program For reference, GNU ld has to be compiled with -linvisible-pink-unicorn. How can you know its pink if its also invisible? Colorless green dreams sleep furiously.
Re: The Linker is not a Magical Program
Jeremie Pelletier wrote: Christopher Wright Wrote: Walter Bright wrote: A rant I wrote a few months ago: http://programmer.97things.oreilly.com/wiki/index.php/The_Linker_Is_not_a_Magical_Program For reference, GNU ld has to be compiled with -linvisible-pink-unicorn. How can you know its pink if its also invisible? http://en.wikipedia.org/wiki/Invisible_pink_unicorn Quoteth: The Invisible Pink Unicorn (IPU) is the goddess of a parody religion used to satirize theistic beliefs, taking the form of a unicorn that is paradoxically both invisible and pink. This makes her a rhetorical illustration used by atheists and other religious skeptics. The IPU is used to argue that supernatural beliefs are arbitrary by, for example, replacing the word God in any theistic statement with Invisible Pink Unicorn. The mutually exclusive attributes of pinkness and invisibility, coupled with the inability to disprove the IPU's existence, is intended to satirize what IPU proponents claim are contradictions in properties that some theists attribute to a theistic deity. ... Invisible Pink Unicorns are beings of great spiritual power. We know this because they are capable of being invisible and pink at the same time. Like all religions, the Faith of the Invisible Pink Unicorns is based upon both logic and faith. We have faith that they are pink; we logically know that they are invisible because we can't see them. — Steve Eley
wchar* question
Given below code(Win32 SDK):
int /*LRESULT*/ wndProc(HWND hwnd, UINT msg, WPARAM wparam, LPARAM lparam)
{
switch(msg)
{
case WM_LBUTTONDOWN:
{
wchar* szFileName=cast(wchar*)(new
wchar[1024]);// ***questioned line
HINSTANCE hInstance=GetModuleHandleW(null);
GetModuleFileNameW(hInstance,szFileName,1024);
MessageBoxW(null,cast(const
wchar*)szFileName, Full Path:,
MB_ICONINFORMATION);
}
break;
}
My program runs OK and can print the exe path as expected.But if I change
wchar* szFileName=cast(wchar*)(new wchar[1024]);
to
wchar* szFileName;
The program runs also but prints blank.Why?
Thanks for your help in advance.
Regards,
Sam
Re: wchar* question
Sorry.Under dmd2.031 ,windows XP
Re: wchar* question
Sam Hu wrote:
Given below code(Win32 SDK):
int /*LRESULT*/ wndProc(HWND hwnd, UINT msg, WPARAM wparam, LPARAM lparam)
{
switch(msg)
{
case WM_LBUTTONDOWN:
{
wchar* szFileName=cast(wchar*)(new wchar[1024]);// ***questioned line
HINSTANCE hInstance=GetModuleHandleW(null);
GetModuleFileNameW(hInstance,szFileName,1024);
MessageBoxW(null,cast(const wchar*)szFileName, Full Path:,
MB_ICONINFORMATION);
}
break;
}
My program runs OK and can print the exe path as expected.But if I change
wchar* szFileName=cast(wchar*)(new wchar[1024]);
to
wchar* szFileName;
The program runs also but prints blank.Why?
Thanks for your help in advance.
Regards,
Sam
I guess MessageBox checks if the pointer to the message text is NULL. If it
is NULL, it prints nothing.
You should check the return value of GetModuleFileName. It may fail for
various reasons. I guess it fails if you pass a null pointer to it.
Also, you don't have to call GetModuleHandle to get the handle of the
calling process' module. Just pass NULL as first argument to
GetModuleFileName.
Re: wchar* question
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Max Samukha wrote:
Sam Hu wrote:
Given below code(Win32 SDK):
int /*LRESULT*/ wndProc(HWND hwnd, UINT msg, WPARAM wparam, LPARAM lparam)
{
switch(msg)
{
case WM_LBUTTONDOWN:
{
wchar* szFileName=cast(wchar*)(new wchar[1024]);// ***questioned line
HINSTANCE hInstance=GetModuleHandleW(null);
GetModuleFileNameW(hInstance,szFileName,1024);
MessageBoxW(null,cast(const wchar*)szFileName, Full Path:,
MB_ICONINFORMATION);
}
break;
}
My program runs OK and can print the exe path as expected.But if I change
wchar* szFileName=cast(wchar*)(new wchar[1024]);
to
wchar* szFileName;
The program runs also but prints blank.Why?
Thanks for your help in advance.
Regards,
Sam
I guess MessageBox checks if the pointer to the message text is NULL. If it
is NULL, it prints nothing.
You should check the return value of GetModuleFileName. It may fail for
various reasons. I guess it fails if you pass a null pointer to it.
Exactly; MSDN is your friend:
http://msdn.microsoft.com/en-us/library/ms683197(VS.85).aspx
The szFileName parameter is a pointer to a buffer that
GetModuleFileNameW *fills*. As you've passed a null pointer,
there is no buffer to fill.
The fact your program isn't crashing when you call MessageBox is because
windozes checks for it.
Which arguably it shouldn't. If it had crashed it would probably have
helped you work out what was wrong.
- --
My enormous talent is exceeded only by my outrageous laziness.
http://www.ssTk.co.uk
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iD8DBQFKoDNTT9LetA9XoXwRAiZ0AJ9ooxiI2JB4O8gRZGlNpuZlTecncwCePcVA
TwPQBMZ4QMhjn/dR7bw67kA=
=mtJ+
-END PGP SIGNATURE-
Re: wchar* question
Hi both: Thank you so much for your help! ps:just found other than write : wchar* szFileName=cast(wchar[])(new wchar[1024); It works also if I write: wchar[1024] szFileName; I am annoying everytime when pass D strings to/from OS API... Regards, Sam
[Issue 2437] ICE(tocsym.c, !needThis()) - default struct argument
http://d.puremagic.com/issues/show_bug.cgi?id=2437 Don clugd...@yahoo.com.au changed: What|Removed |Added Keywords|patch | --- Comment #3 from Don clugd...@yahoo.com.au 2009-09-03 00:28:53 PDT --- Aargh, patch is incorrect. I think the patch does fix a genuine problem (it seems to be necessary to allow you to evaluate a struct constructor in CTFE), but there's a second problem as well. It may be because a struct constructor such as aStruct(44) turns into ((aStruct __ctmp2;) , __ctmp2).this(44) And that __ctmp2 is a funny beast. Where is it stored? Its parent is the *MODULE*, not the function it's called from. But it's not a static variable. Weird. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2935] ICE(out.c) using struct with constructor as function default argument
http://d.puremagic.com/issues/show_bug.cgi?id=2935 Don clugd...@yahoo.com.au changed: What|Removed |Added Keywords|patch | --- Comment #2 from Don clugd...@yahoo.com.au 2009-09-03 00:29:40 PDT --- Not patched yet, see bug 2437 for details. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 102] Forward reference nested class wheel.
http://d.puremagic.com/issues/show_bug.cgi?id=102 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #4 from Don clugd...@yahoo.com.au 2009-09-03 00:53:52 PDT --- The original bug, and also the test case in bug 912, were fixed after 1.041 and before 1.047. They work in D2 as well. Only the 'enum' case in comment 2 remains unfixed! -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3284] New: snn linked programs never release memory back to the OS
http://d.puremagic.com/issues/show_bug.cgi?id=3284 Summary: snn linked programs never release memory back to the OS Product: D Version: 1.046 Platform: All OS/Version: Windows Status: NEW Severity: blocker Priority: P1 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: domi...@vga.hr Programs using GC or manual malloc/free never actually release memory back to the OS (Windows), which causes programs with heavy memory allocation / deallocation to utilize page swaps heavily and eventually crash. This is a blocking issue persistent in 1.047 release also (it was not available in version selection). You can trivially reproduce this effect by malloc'ing several MB's and subsequently freeing them - watch the process memory usage before and after it. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3283] glue.c assertion with no info
http://d.puremagic.com/issues/show_bug.cgi?id=3283 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #2 from Don clugd...@yahoo.com.au 2009-09-03 04:04:09 PDT --- Compile with -v, to get an idea of where it is happening. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3283] glue.c assertion with no info
http://d.puremagic.com/issues/show_bug.cgi?id=3283 --- Comment #3 from Alvaro alvcas...@yahoo.es 2009-09-03 04:49:16 PDT --- Ok thanks for your tips! The task doesn't seem obvious, as I get a huge list of functions, but at least I get something to work with. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3285] New: Struct's destructor not called
http://d.puremagic.com/issues/show_bug.cgi?id=3285
Summary: Struct's destructor not called
Product: D
Version: 2.032
Platform: All
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: yaocheng...@gmail.com
import std.stdio;
struct S
{
~this()
{
writefln(die!);
}
void fun(){}
}
S fun()
{
return S();
}
int main(char[][] args)
{
fun().fun();
...
return 0;
}
Struct's destructor not called .
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 102] Forward reference nested class wheel.
http://d.puremagic.com/issues/show_bug.cgi?id=102
--- Comment #5 from Don clugd...@yahoo.com.au 2009-09-03 06:49:57 PDT ---
This is the slightly reduced test case that still fails. It only needs one
file.
class X {
Y.NY t;
enum NX { BLA, BLA1 }
}
class Y {
enum NY { FOO, BAR }
X.NX nx;
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3132] std.string.split should be templated on mutable/const/immutable
http://d.puremagic.com/issues/show_bug.cgi?id=3132 David Simcha dsim...@yahoo.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #4 from David Simcha dsim...@yahoo.com 2009-09-03 07:56:25 PDT --- 1. You missed splitlines. 2. string[] words should be S[] words or S1[] words in split(). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3286] New: Default parameter prevents solution of inter-module circular dependency
http://d.puremagic.com/issues/show_bug.cgi?id=3286
Summary: Default parameter prevents solution of inter-module
circular dependency
Product: D
Version: 2.032
Platform: All
OS/Version: All
Status: NEW
Keywords: rejects-valid
Severity: major
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: hs...@inter7.jp
module a;
import b;
import c;
class A {
static __gshared A a;
void f(B b) {}
void g(C c) {} // - Error: identifier 'C' is not defined
}
module b;
import a;
class B { void f(A x = A.a) {} }
module c;
import a;
class C { void f(A x = A.a) {} }
There is no problem if class A, B and C are in the same module.
So this dependency is valid and the error is specific for inter-module circular
dependency.
If default parameter = A.a for B.f is removed, it goes well.
There is no problem if A.a appeared in the body of B.f.
It seems that the compiler tries to recognize the semantics of default
parameter A.a when it is reading declaration of B.f.
Default parameters are usually hint for the expressions which call the
functions with default parameters, this behavior is inexplicable.
This error is a regression between 2.031 and 2.032.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3286] Default parameter prevents solution of inter-module circular dependency
http://d.puremagic.com/issues/show_bug.cgi?id=3286 --- Comment #1 from HOSOKAWA Kenchi hs...@inter7.jp 2009-09-03 08:22:24 PDT --- Sorry, this error is NOT a regression between 2.031 and 2.032. This error is occur with 2.031. I found similar error which is a regression between 2.031 and 2.032, and I was confused. Sorry. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 259] Comparing signed to unsigned does not generate an error
http://d.puremagic.com/issues/show_bug.cgi?id=259 Ellery Newcomer ellery-newco...@utulsa.edu changed: What|Removed |Added CC||ellery-newco...@utulsa.edu --- Comment #12 from Ellery Newcomer ellery-newco...@utulsa.edu 2009-09-03 08:33:41 PDT --- This morning I've been tinkering with the DMD source, and I've made an edit to expression.c that appears to fix this issue. How do I submit? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3287] New: DANGER!! Generating wrong binaries by initializing of between different type structs
http://d.puremagic.com/issues/show_bug.cgi?id=3287
Summary: DANGER!! Generating wrong binaries by initializing of
between different type structs
Product: D
Version: 2.032
Platform: Other
OS/Version: Windows
Status: NEW
Keywords: accepts-invalid, wrong-code
Severity: normal
Priority: P1
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: rayerd@gmail.com
import std.stdio;
struct X
{
int a;
}
struct Y
{
string b;
}
void main()
{
Y v = X(1);
writeln(v.b);
}
// DANGER!! crash on running!!
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3132] std.string.split should be templated on mutable/const/immutable
http://d.puremagic.com/issues/show_bug.cgi?id=3132 Andrei Alexandrescu and...@metalanguage.com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #5 from Andrei Alexandrescu and...@metalanguage.com 2009-09-03 09:14:16 PDT --- (In reply to comment #4) 1. You missed splitlines. 2. string[] words should be S[] words or S1[] words in split(). 3. I'm a chowderhead. I fixed the above and added unittests for all string widths. If there are other functions in std.string to be modified, please open a new bugzilla entry. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3287] DANGER!! Generating wrong binaries by initializing of between different type structs
http://d.puremagic.com/issues/show_bug.cgi?id=3287 Jarrett Billingsley jarrett.billings...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||jarrett.billings...@gmail.c ||om Resolution||DUPLICATE --- Comment #1 from Jarrett Billingsley jarrett.billings...@gmail.com 2009-09-03 09:48:19 PDT --- *** This issue has been marked as a duplicate of issue 2469 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2469] ICE(cod1.c) arbitrary struct accepted as struct initializer
http://d.puremagic.com/issues/show_bug.cgi?id=2469 --- Comment #9 from Jarrett Billingsley jarrett.billings...@gmail.com 2009-09-03 09:48:19 PDT --- *** Issue 3287 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3288] New: conv.d : using to with cont int or long fails to compile.
http://d.puremagic.com/issues/show_bug.cgi?id=3288 Summary: conv.d : using to with cont int or long fails to compile. Product: D Version: 2.032 Platform: x86 OS/Version: Windows Status: NEW Keywords: patch Severity: regression Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: sandf...@jhu.edu The to!string conversion template doesn't handle const int or long values i.e. const h = 6; string s = to!string(h); // Error This seems to effect text, but not writeln. Patch: change u /= 10; to u = u / 10; inside /// Signed values ($(D int) and $(D long)). T to(T, S)(S value) if (staticIndexOf!(Unqual!S, int, long) = 0 isSomeString!T) Line# 2580 in dmd 2.032 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2790] std.path.join with version(Windows)
http://d.puremagic.com/issues/show_bug.cgi?id=2790 --- Comment #2 from Haruki Shigemori rayerd@gmail.com 2009-09-03 11:35:51 PDT --- This is very easily bug. I want to fix it next update. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3287] DANGER!! Generating wrong binaries by initializing of between different type structs
http://d.puremagic.com/issues/show_bug.cgi?id=3287 --- Comment #2 from Haruki Shigemori rayerd@gmail.com 2009-09-03 11:39:55 PDT --- Oh, sorry! I forgot the first commit. This is the second commit about the same issue. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3289] New: ICE (..\ztc\cod4.c) when using a delegate inside a foreach
http://d.puremagic.com/issues/show_bug.cgi?id=3289
Summary: ICE (..\ztc\cod4.c) when using a delegate inside a
foreach
Product: D
Version: 2.031
Platform: Other
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: 2kor...@gmail.com
Minimal testcase to reproduce:
struct Foo
{
int i;
}
void main()
{
Foo[] array;
foreach (ref foo; array) {
auto x = () {
foo.i = 42;
};
}
}
Internal error: ..\ztc\cod4.c 354
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 2569] static arrays in CTFE functions don't compile
http://d.puremagic.com/issues/show_bug.cgi?id=2569 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #11 from Walter Bright bugzi...@digitalmars.com 2009-09-03 13:24:02 PDT --- Fixed dmd 1.047 and 2.032 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3293] New: A few more bugs with template mixins with identifiers
http://d.puremagic.com/issues/show_bug.cgi?id=3293
Summary: A few more bugs with template mixins with identifiers
Product: D
Version: 2.031
Platform: Other
OS/Version: Windows
Status: NEW
Keywords: ice-on-valid-code, rejects-valid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: 2kor...@gmail.com
template ReferenceType(T)
{
alias T* ReferenceType;
}
struct SomeRange(T, alias Storage = 0)
{
bool foo()
{
return guard == guard;// bug 1: replace == with is and DMD crashes
with no output
}
enum guard = cast(ReferenceType!(T))SomeContainer!(T, Storage).guard;
}
struct SomeContainer(T, alias Storage = 0)
{
auto opSlice()// bug 2: replace auto with SomeRange!(T, Storage) and
get an ICE
{
return SomeRange!(T, Storage)();
}
enum ReferenceType!(T) guard =
cast(ReferenceType!(T))cast(void*)0xFEFEFEFE;// bug 3: remove guard type
and DMD crashes with no output
}
class A
{
SomeRange!(int, 0) test()// bug 4: 0 is not omissible
{
return SomeContainer!(int)()[];
}
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 1950] CTFE doesn't work correctly for structs passed by ref
http://d.puremagic.com/issues/show_bug.cgi?id=1950 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #4 from Walter Bright bugzi...@digitalmars.com 2009-09-03 13:23:39 PDT --- Fixed dmd 1.047 and 2.032 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1605] break in switch with goto breaks in ctfe
http://d.puremagic.com/issues/show_bug.cgi?id=1605 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #2 from Walter Bright bugzi...@digitalmars.com 2009-09-03 13:22:55 PDT --- Fixed dmd 1.047 and 2.032 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3165] What kind of integer division does D use?
http://d.puremagic.com/issues/show_bug.cgi?id=3165 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #3 from Walter Bright bugzi...@digitalmars.com 2009-09-03 13:25:32 PDT --- Fixed dmd 1.047 and 2.032 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3039] -vtls compiler flag not listed in man file
http://d.puremagic.com/issues/show_bug.cgi?id=3039 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #2 from Walter Bright bugzi...@digitalmars.com 2009-09-03 13:25:17 PDT --- Fixed dmd 1.047 and 2.032 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3205] CTFE: $ cannot be used in lvalues
http://d.puremagic.com/issues/show_bug.cgi?id=3205 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #2 from Walter Bright bugzi...@digitalmars.com 2009-09-03 13:27:36 PDT --- Fixed dmd 1.047 and 2.032 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3122] [patch] Adding support for fast and reliable build tools to the frontend
http://d.puremagic.com/issues/show_bug.cgi?id=3122 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #7 from Walter Bright bugzi...@digitalmars.com 2009-09-03 13:29:01 PDT --- Fixed dmd 1.047 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3264] -O causes wrong used before set error when using enum.
http://d.puremagic.com/issues/show_bug.cgi?id=3264 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Walter Bright bugzi...@digitalmars.com 2009-09-03 13:28:17 PDT --- Fixed dmd 1.047 and 2.032 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3294] New: forward reference to inferred return type of function call
http://d.puremagic.com/issues/show_bug.cgi?id=3294
Summary: forward reference to inferred return type of function
call
Product: D
Version: 2.031
Platform: Other
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: 2kor...@gmail.com
module Test;
struct SomeInfiniteRange
{
int front() { return 42; }
enum empty = false;
void popFront() {}
}
struct SomeContainer(T)
{
auto opSlice()
{
return SomeInfiniteRange();
}
}
class Test
{
void test()
{
foreach (int f; _foo[]) {
// do nothing
}
}
private SomeContainer!(int) _foo;
}
Test.d(23): Error: forward reference to inferred return type of function call
this._foo.opSlice()
Test.d(23): Error: foreach: int is not an aggregate type
Note that the code compiles just fine if SomeContainer is a concrete struct
(not a template)
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3196] Segfault(mtype.c) after almost any error involving a delegate literal
http://d.puremagic.com/issues/show_bug.cgi?id=3196 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #5 from Walter Bright bugzi...@digitalmars.com 2009-09-03 13:27:18 PDT --- Fixed dmd 1.047 and 2.032 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2277] array ops and const arrays incompatible
http://d.puremagic.com/issues/show_bug.cgi?id=2277 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Walter Bright bugzi...@digitalmars.com 2009-09-03 13:33:55 PDT --- Fixed dmd 2.032 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2560] ICE(cod4.c) on invoking method that takes ref const struct parameter
http://d.puremagic.com/issues/show_bug.cgi?id=2560 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #10 from Walter Bright bugzi...@digitalmars.com 2009-09-03 13:34:17 PDT --- Fixed dmd 2.032 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1972] Foreach range statement breaks CTFE
http://d.puremagic.com/issues/show_bug.cgi?id=1972 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Walter Bright bugzi...@digitalmars.com 2009-09-03 13:33:22 PDT --- Fixed dmd 2.032 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3100] ICE(cast.c) when a struct with members is shared
http://d.puremagic.com/issues/show_bug.cgi?id=3100 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #1 from Walter Bright bugzi...@digitalmars.com 2009-09-03 13:39:46 PDT --- Fixed dmd 2.032 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
