Re: Coming Soon: Stable D Releases!
On Monday, 16 July 2012 at 19:35:47 UTC, Andrei Alexandrescu wrote: I agree this would be more direct. But I fail to see how Walter cherry-picking stuff is basically no additional work, whereas Adam doing essentially the same is an unenviable amount of labor. Well, if things go well, there is a system that could make things much simpler. But my thought would that Walter wouldn't need to touch the stable branch. The only benefit for the new org is a separate set of contributes and separate pull requests. If this system takes off, while still having a cost to Walter, there would be a stable branch which get all the bug fixes and the new feature branch. When adding a bug fix just merge the stable branch into the feature branch. This won't always be a clean merge. Good luck Adam.
Re: Coming Soon: Stable D Releases!
Just curious, if Walter is too busy to make DMD more stable, then what does he spend most of his time on? I thought we were done with adding new features to the language (at least for now)? On Mon, Jul 16, 2012 at 1:29 PM, Jonathan M Davis jmdavisp...@gmx.com wrote: On Monday, July 16, 2012 13:18:55 Caligo wrote: What?! All he has to do is create a branch and call it stable, or whatever, and use cherry-pick to move small stables patches from other branches to the stable branch. What's so difficult about that? I don't get it. It takes up his time for him to do it, and I don't think that there's any chance whatsoever of him giving someone else commit access to the main dmd repository to do this (certainly not at this point). He wasn't interested in changing the versioning or branching stuff at all. He agreed to this plan (which should be minimally disruptive to him) as an experiment. Depending on how it goes, we may change how we deal with the main repo, but for now, we're trying this. And since the likely alternative was that we would continue on exactly as we have been, this is presumably an improvement for the folks who wanted a branch with bug fixes with more frequent releases. - Jonathan M Davis
Re: KR-style variadic functions
On Tuesday, 17 July 2012 at 18:37:54 UTC, H. S. Teoh wrote: I guess you predate me. ;-) When I started learning C, it was already in the ANSI syntax, though there were enough KR style code floating around that I've at least _seen_ KR syntax. I'm guessing nowadays most people don't even know what KR syntax is. T I started coding in C around 1993 with Turbo C 2.0, but was exposed to KR code from different sources, specially when we needed to make use of a System V based system for some OS classes. Plus as a language geek, I had the pleasure to have access a lots of books and papers since the late 70's in our university library. That is a reason why I tend to have a good background in what languages introduced which paradigm. Maybe it is the historian in me. :) -- Paulo
Re: Need runtime reflection?
On Tuesday, 17 July 2012 at 15:08:18 UTC, David Piepgrass wrote:
I want to imitate golang's interface in D, to study D's
template. I wrote
some code: https://gist.github.com/3123593
Now we can write code like golang:
--
interface IFoo {
void foo(int a, string b, float c);
}
struct Foo {
void foo(int a, string b, float c) {
writeln(Foo.foo: , a, , , b, , , c);
}
}
struct FooFoo {
void foo(int a, string b, float c) {
writeln(FooFoo.foo: , a, , , b, , , c);
}
}
GoInterface!(IFoo) f = new Foo;
f.foo(3, abc, 2.2);
f = new FooFoo;
f.foo(5, def, 7.7);
--
It is also very naive, does not support some features, like
out/ref
parameters, free functions *[1]* and so on. The biggest
problem is downcast
not supported. In golang, we can write code like*[2]*:
--
var p IWriter = NewB(10)
p2, ok := p.(IReadWriter)
--
Seems [p.(IReadWriter)] dynamically build a virtual table
*[3]*，because the
type of p is IWriter, it is *smaller* than IReadWriter, the
cast
operation must search methods and build vtbl at run time.
In D, GoInterface(T).opAssign!(V)(V v) can build a rich
runtime information
to *V* if we need. But if *V* is interface or base class, the
type
information not complete. So, seems like I need runtime
reflection? and how
can I do this in D? I did not find any useful information in
the TypeInfo*.
--
[1] free functions support, e.g.
--
interface IFoo {
void foo(int a, string b, float c);
}
void foo(int self, int a, string b, float c) {
writefln(...);
}
GoInterface!(int) p = 1;
p.foo(4, ccc, 6.6);
--
In theory no problem.
I, too, was enamored with Go Interfaces and implemented them
for .NET:
http://www.codeproject.com/Articles/87991/Dynamic-interfaces-in-any-NET-language
Interesting article, but why not just make use of dynamic
interfaces?
--
Paulo
Re: Need runtime reflection?
On 2012-07-18 06:10, lijie wrote: Free functions support is hard, with runtime cast, I just think compile time. It's possibly to implement runtime reflection by loading the running executable and inspecting the symbol table. It's an ugly hack but it should work. http://flectioned.kuehne.cn/ I am trying to support free functions at compile time, is also hard, since the generator in gointerface module, but other modules are only visible in the module that used these modules. I have an ugly implementation used compile time string mixin, trying to simplify it. Fighting. I think you can pass a module to a template via an alias parameter. Then the template should be able to inspect all free functions using something like __traits(allMembers). -- /Jacob Carlborg
Re: Rust updates
Am Tue, 17 Jul 2012 21:39:33 +0200 schrieb SomeDude lovelyd...@mailmetrash.com: On Friday, 13 July 2012 at 14:58:57 UTC, bearophile wrote: A blog post about one of the Rust pointers, the borrowed ones: http://smallcultfollowing.com/babysteps/blog/2012/07/10/borrowed-pointer-tutorial/ Bye, bearophile Rust is a much more interesting language than Go. At least they are taking some innovative paths and that's good. The irony is: Rust intentionally does not include any novel or untested ideas. - Wikipedia -- Marco
Re: reference to 'self' inside a function
You could always use __FUNCTION__ in a string mixin, but that
_is_ rather ugly.
Like this ?
auto fac = delegate(int n) {
if (n = 1)
return 1;
return n * mixin(__FUNCTION__)(n - 1);
};
Well, there are a few problems with this:
- it _is_ ugly
- some 'automatic' name should be generated internally (possibly
it is in any case)
- it doesn't currently work
Possibly more streamlined approach would be:
thisFunc (or 'self', or whatever)
thisFunc.stringof istead of __FUNCTION__
Re: Need runtime reflection?
On Wed, Jul 18, 2012 at 2:59 PM, Jacob Carlborg d...@me.com wrote: On 2012-07-18 06:10, lijie wrote: Free functions support is hard, with runtime cast, I just think compile time. It's possibly to implement runtime reflection by loading the running executable and inspecting the symbol table. It's an ugly hack but it should work. http://flectioned.kuehne.cn/ It is an optional way. I want to do all thing in D code. I am trying to support free functions at compile time, is also hard, since the generator in gointerface module, but other modules are only visible in the module that used these modules. I have an ugly implementation used compile time string mixin, trying to simplify it. Fighting. I think you can pass a module to a template via an alias parameter. Then the template should be able to inspect all free functions using something like __traits(allMembers). I didn't know this usage, I will try it. Thanks.
Re-thinking D's modules
There are several places for D module system to improve. One thing we discussed in the past is the versioning, and as far as I remember, we did not come to any constructive conclusion. Java has been criticised often for not having modules. Apparently Java 9 SE will have them, and in my humble opinion, Java 9 module system is going to be far more powerful (or perhaps better word would be USEFUL) than what D currently has. More about Java Jigsaw: http://cr.openjdk.java.net/~mr/jigsaw/notes/jigsaw-big-picture-01 Why is this better? - Speaking from a (senior) software engineer point of view, Java Jigsaw is engineered for large systems where versioning, module-dependency, and module-restrictions are very important. I do not like few things about Jigsaw, but most of the things they plan there simply make sense, especially the versioning and module-restrictions, which I urge D developers to take a look and come up with something similar for D2 or D3... This is extremely useful, and will be even more useful once we have shared libraries where we can have N different shared libraries that contain the same module, but different version of it... Kind regards
Re: Need runtime reflection?
On 2012-07-18 09:26, lijie wrote: It is an optional way. I want to do all thing in D code. You can do this in D. -- /Jacob Carlborg
Re: Re-thinking D's modules
On Wednesday, 18 July 2012 at 08:08:21 UTC, Dejan Lekic wrote: There are several places for D module system to improve. One thing we discussed in the past is the versioning, and as far as I remember, we did not come to any constructive conclusion. Java has been criticised often for not having modules. Apparently Java 9 SE will have them, and in my humble opinion, Java 9 module system is going to be far more powerful (or perhaps better word would be USEFUL) than what D currently has. More about Java Jigsaw: http://cr.openjdk.java.net/~mr/jigsaw/notes/jigsaw-big-picture-01 Why is this better? - Speaking from a (senior) software engineer point of view, Java Jigsaw is engineered for large systems where versioning, module-dependency, and module-restrictions are very important. I do not like few things about Jigsaw, but most of the things they plan there simply make sense, especially the versioning and module-restrictions, which I urge D developers to take a look and come up with something similar for D2 or D3... This is extremely useful, and will be even more useful once we have shared libraries where we can have N different shared libraries that contain the same module, but different version of it... Kind regards Jigsaw has just been dropped from Java 8. http://mreinhold.org/blog/late-for-the-train Still I would say this is so relevant that most current build systems have versions as first class concept. For those that don't know .NET, due to the DLL Hell experience, Microsoft has built version support in the CLR from day 1. -- Paulo
Re: Re-thinking D's modules
On 2012-07-18 10:08, Dejan Lekic wrote: There are several places for D module system to improve. One thing we discussed in the past is the versioning, and as far as I remember, we did not come to any constructive conclusion. Java has been criticised often for not having modules. Apparently Java 9 SE will have them, and in my humble opinion, Java 9 module system is going to be far more powerful (or perhaps better word would be USEFUL) than what D currently has. More about Java Jigsaw: http://cr.openjdk.java.net/~mr/jigsaw/notes/jigsaw-big-picture-01 Why is this better? - Speaking from a (senior) software engineer point of view, Java Jigsaw is engineered for large systems where versioning, module-dependency, and module-restrictions are very important. I do not like few things about Jigsaw, but most of the things they plan there simply make sense, especially the versioning and module-restrictions, which I urge D developers to take a look and come up with something similar for D2 or D3... This is extremely useful, and will be even more useful once we have shared libraries where we can have N different shared libraries that contain the same module, but different version of it... Kind regards Something like: https://github.com/jacob-carlborg/orbit/wiki/Orbit-Package-Manager-for-D -- /Jacob Carlborg
Re: Re-thinking D's modules
Dejan Lekic: I do not like few things about Jigsaw, but most of the things they plan there simply make sense, especially the versioning and module-restrictions, which I urge D developers to take a look and come up with something similar for D2 or D3... Keep in mind that D language seems designed for its parts to be minimal (this means the simplest thing that works), and that the D module system is not yet fully implementing its current simple design. In past I have asked for those Entry points (that it's an unsolved problem in D), and I appreciate those Exports. The versioning too seems useful. Bye, bearophile
Re: Re-thinking D's modules
On Wed, 2012-07-18 at 11:00 +0200, Paulo Pinto wrote: […] Java has been criticised often for not having modules. In the beginning there was WORA which assumed so much that was unrealistic. It's consequence has been that artefact versioning is a complete mess in Java. OK so the Maven repository and build frameworks like Gradle and Maven are getting close to defeating the problem. Sadly transitive dependencies are still a nightmare. Of course I have probably violated a Sun/Oracle patent by even mentioning the acronym WORA. Apparently Java 9 SE will have them, and in my humble opinion, Java 9 module system is going to be far more powerful (or perhaps better word would be USEFUL) than what D currently has. More about Java Jigsaw: http://cr.openjdk.java.net/~mr/jigsaw/notes/jigsaw-big-picture-01 Assuming that it doesn't get bounced to Java 10. It already got bounced from Java 7 to Java 8 and now Java 8 to Java 9. Why is this better? - Speaking from a (senior) software engineer point of view, Java Jigsaw is engineered for large systems where versioning, module-dependency, and module-restrictions are very important. I do not like few things about Jigsaw, but most of the things they plan there simply make sense, especially the versioning and module-restrictions, which I urge D developers to take a look and come up with something similar for D2 or D3... This is extremely useful, and will be even more useful once we have shared libraries where we can have N different shared libraries that contain the same module, but different version of it... Isn't the real question why is the same dynamic library linking problem happening again. Has nothing been learned from UNIX shared objects and Windows DLLs? Go solves the problem by refusing all notion of dynamic linking and insisting on static linking of all applications. Kind regards Jigsaw has just been dropped from Java 8. http://mreinhold.org/blog/late-for-the-train That is because to all intents and purposes Jigsaw is vapourware. The competition, that the Jigsaw folks are studiously ignoring, is OSGi. I know there are some slight differences in overall aim and goal between the two, but in the end the effect is the same: being able to run different versions of the same artefact on the same JVM in the same application. Still I would say this is so relevant that most current build systems have versions as first class concept. Certainly Gradle and Maven support this idea very well. Sadly Make, CMake, Autotools, SCons, Waf,… tend to delegate the problem to someone else. For those that don't know .NET, due to the DLL Hell experience, Microsoft has built version support in the CLR from day 1. But, as ever, Microsoft see things like this as a way to try and get everyone to use Windows via proprietary lock-in rather than by trying to educate people about possible solutions. Otherwise we would already have solved the problem rather than have the shared object mess we currently have, OSGi, Jigsaw, the mess that is Debian and Fedora support for multiple versions of dynamically linked libraries and Java artefacts. Sadly I have nothing constructive to say except that which stems from the above: in a large system comprising subsystems with transitive dependencies, if I cannot use different versions of the same subsystem in the overall system then everything will break. Especially in the face of dependency injection. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Re-thinking D's modules
Am Wed, 18 Jul 2012 10:08:19 +0200 schrieb Dejan Lekic dejan.le...@gmail.com: There are several places for D module system to improve. One thing we discussed in the past is the versioning, and as far as I remember, we did not come to any constructive conclusion. Java has been criticised often for not having modules. Apparently Java 9 SE will have them, and in my humble opinion, Java 9 module system is going to be far more powerful (or perhaps better word would be USEFUL) than what D currently has. More about Java Jigsaw: http://cr.openjdk.java.net/~mr/jigsaw/notes/jigsaw-big-picture-01 Why is this better? - Speaking from a (senior) software engineer point of view, Java Jigsaw is engineered for large systems where versioning, module-dependency, and module-restrictions are very important. I do not like few things about Jigsaw, but most of the things they plan there simply make sense, especially the versioning and module-restrictions, which I urge D developers to take a look and come up with something similar for D2 or D3... This is extremely useful, and will be even more useful once we have shared libraries where we can have N different shared libraries that contain the same module, but different version of it... Kind regards Shared library versioning and dependency management is traditionally done at the OS level (WinSxS, soname, package managers). That may also apply to what is exported aka visible from a library aka module (e.g. export-all policy). Unlike byte code languages like Java or C#, native compiled languages must also consider the target platform in addition to the module version. In addition to this, the scope of a Java module can be anything, up to a complete tomcat web server, whereas the scope of a D module is a single file. A Java module can contain several packages, a D module cannot. The main difference is in the eco system, in my opinion. Java or .NET are platforms on their own while systems languages integrate with the hardware and OS (starting with calling conventions, up to high-level dependency management). Java is free to innovate here, it is 'their' platform. Maybe you can elaborate a bit more on what module-restrictions are useful for. I think they are the only feature that I haven't seen in package managers or programming languages. Also the compiler doesn't currently scan shared libraries or even require them to exist. The resolution of symbols is deferred to the linking stage where there are existing mechanisms to hide symbols from a library. And some people like the export-all policy with no hidden symbols, so we are in for a hot discussion on details. :D P.S.: I am all for a D package manager for developers, that can pull source code and bindings from the web. -- Marco
Re: KR-style variadic functions
On 7/16/2012 11:56 PM, Jacob Carlborg wrote:
To my understanding this is legal C :
int foo ();
It's a KR-style variadic functions, while their use is discouraged, they're
still legal C.
Variadic functions, in order to work in C, need at least one parameter so that
varargs can work.
int foo();
declares a function with an unspecified parameter list, not a variadic one. It
is specified by a definition somewhere:
int foo(a,b)
int a;
int b;
{ ... }
somewhere.
If Dstep encounters the first declaration form, your options are to:
1. reject it (a perfectly reasonable approach)
2. treat it as:
int foo(void);
I suggest option 2, which is what C++ does.
Re: Re-thinking D's modules
On Wednesday, 18 July 2012 at 09:25:03 UTC, Russel Winder wrote: […] Isn't the real question why is the same dynamic library linking problem happening again. Has nothing been learned from UNIX shared objects and Windows DLLs? Go solves the problem by refusing all notion of dynamic linking and insisting on static linking of all applications. As I already mentioned a few times in Gonuts, static linking makes it hard to implement certain types of applications. Plus, the Go folks seem to live in open source land, where the code for all 3rd party libraries is available, and no one has any issues with licenses that forbade static linking. Their attitude to keep versioning out of go get is a reflection of this. For those that don't know .NET, due to the DLL Hell experience, Microsoft has built version support in the CLR from day 1. But, as ever, Microsoft see things like this as a way to try and get everyone to use Windows via proprietary lock-in rather than by trying to educate people about possible solutions. To be fair to Microsoft, I am yet to see a commercial vendor that does not do that. The ones that do, usually have some consulting agenda, certifications, whatever, to sell along their free and standard solution. -- Paulo
Re: Re-thinking D's modules
Jigsaw has just been dropped from Java 8. http://mreinhold.org/blog/late-for-the-train Erm, read my original post - I did not mention Java 8, i wrote Java 9 SE...
Re: Re-thinking D's modules
On Wednesday, 18 July 2012 at 09:43:09 UTC, Marco Leise wrote: [..] Unlike byte code languages like Java or C#, native compiled languages must also consider the target platform in addition to the module version. [...] Last time I checked, I could compile Java and C# to native code if I wished to do so. -- Paulo
Re: Re-thinking D's modules
Am Wed, 18 Jul 2012 10:24:36 +0100 schrieb Russel Winder rus...@winder.org.uk: Go solves the problem by refusing all notion of dynamic linking and insisting on static linking of all applications. ... not possible? While I learned a while back that system calls exist and are not dynamically linked, I wonder how Go goes about: * basic system libraries (static linking to kernel32.dll?) * executable bloat from large OO toolkits like Qt * increased memory footprint by not allowing shared instances of DLLs/SOs * modular development (e.g. separating server and client code in games) * dynamically loadable plugins/extensions * security and bug fixes to libraries used in dozens of programs (- recompile of all library users ?) -- Marco signature.asc Description: PGP signature
Orbit (Was: Re-thinking D's modules)
On Wed, 18 Jul 2012 11:12:22 +0200 Jacob Carlborg d...@me.com wrote: Something like: https://github.com/jacob-carlborg/orbit/wiki/Orbit-Package-Manager-for-D Speaking of, how's that coming along?
Re: reference to 'self' inside a function
On 07/18/12 01:05, Kevin Cox wrote:
On Jul 17, 2012 6:50 PM, Era Scarecrow rtcv...@yahoo.com
mailto:rtcv...@yahoo.com wrote:
On Tuesday, 17 July 2012 at 22:13:13 UTC, Eyyub wrote:
On Tuesday, 17 July 2012 at 16:56:17 UTC, angel wrote:
I propose to introduce a reference to the current function, much like
'this' in a class method. Call it 'self' or 'thisFunc', or whatever ...
What might this be good for ?
For implementing recursion in a lambda function. Writing in functional
style, one creates many functions, and looking for reasonable names for
these functions becomes unnecessarily painful.
Good idea !
self is a cute keyword, or lambda but this could break existing code.
Mmm.. Why not an inner function to represent the recursive function? True a
'self' reference may resolve the issue,
What about how JavaScript does it. Anonymous functions can still have a
name that can be used from inside of a function to refer to itself.
And the most useless example ever.
var f = function func ( i ) {
return func(7);
};
I think that this is nice because there is no name space pollution, no new
keywords needed and it is pretty.
Sadly, this collides with the return-type syntax already in place.
auto f = function int(int i) { return 0; };
Re: KR-style variadic functions
On Tue, 17 Jul 2012 20:31:19 +0100, Jacob Carlborg d...@me.com wrote: On 2012-07-17 17:11, Regan Heath wrote: Ahh, I've been looking at the ANSI C spec and assuming that is what you're basing things off, KR C was pre-ANSI C and may have different rules. I think you should probably aim to be ANSI C compliant and above, and ignore KR. This page says otherwise: http://en.wikipedia.org/wiki/ANSI_C#Compliance_detectability ...while an obsolescent non-prototype declaration is used otherwise. Those are still ANSI-compliant as of C99 and C90, but their use is discouraged. The full quote: In the above example, a prototype is used in a function declaration for ANSI compliant implementations, while an obsolescent non-prototype declaration is used otherwise. Those are still ANSI-compliant as of C99 and C90, but their use is discouraged. 1) a prototype is used in a function declaration for ANSI compliant implementations implies an ANSI compliant compiler /requires/ the full prototype. 2) obsolescent non-prototype declaration is used otherwise implies non-prototype forms are /obsolete/ 3) Those are still what is being referred to by the word those in that sentence, it's not immediately clear to me. It could mean the non-prototype (as you've assumed) but it might also mean the entire construct (using #if __STDC__). R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: KR-style variadic functions
On Tue, 17 Jul 2012 19:39:25 +0100, H. S. Teoh hst...@quickfur.ath.cx
wrote:
On Tue, Jul 17, 2012 at 08:07:08PM +0200, Paulo Pinto wrote:
On Tuesday, 17 July 2012 at 15:16:56 UTC, Regan Heath wrote:
[...]
So all KR function declarations were name() with no parameters.
R
KR was more than that.
This modern C declaration:
int main(int argc, char **argv) {
exit(1);
}
is written thus in KR:
int main(argc, argv)
int argc;
char **argv;
{
exit(1);
}
Clarification.
The /definition/ is as you have above, the /declaration/ is not. The
declaration is what goes in the header file, and in KR (and ANSI C for
that matter) looks like:
int main();
parameters are not required for the declaration, only the definition.
R
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Re-thinking D's modules
Something like: https://github.com/jacob-carlborg/orbit/wiki/Orbit-Package-Manager-for-D I am aware of the Orbit project, but what Jigsaw will do for Java, and what similar built-in module versioning in other languages do, is to give control of pieces of large software systems. Having module version as part of the language will give tools like Orbit a nice, standardized way to know what is the module version of a D source file it is currently processing. Later on, it may help compilers create SO/DLL version information if a certain module becomes a library... Say you have a product, and you want to provide support for all legacy versions. One way to that is to put all old(er) versions of a module into a single library. If the module is not versioned, you would have to use external module information, typically stored in bunch of config files, and what is worse is quite often, if you lose these files, you have no idea what module version it was... (Unless you are pedantic, and write that information in the header comment of the module) I use Maven a lot, every day, Jigsaw is not a replacement for Maven, it is a help to Maven, coming from the language itself.
Re: Re-thinking D's modules
Go solves the problem by refusing all notion of dynamic linking and insisting on static linking of all applications. God, I feel sorry for programmers who use Go, in that case...
Re: KR-style variadic functions
In any case. It think the practical solution to this problem is to assume you're working with modern code, and have a command line option to make it assume KR or old-style declarations. In the old-style mode you would have to assume a function with an empty () could have any number of parameters and the best you can do is produce: extern (C) ret name(/* fill in the blanks please*/); R
Re: KR-style variadic functions
On Tue, 17 Jul 2012 20:42:09 +0100, Jacob Carlborg d...@me.com wrote: On 2012-07-17 17:13, Regan Heath wrote: Is Clang open source, can we see the code for that function? Perhaps it's a bug.. ANSI C may have made () without void obsolete, but no compiler I've ever used has actually enforced that - or perhaps C++ made old-style function definition/declarations obsolete and allowed () back again. Sure: https://llvm.org/svn/llvm-project/cfe/trunk/tools/libclang/CXType.cpp Just search for clang_isFunctionTypeVariadic. It certainly seems intentional: if (T-getAsFunctionNoProtoType()) return 1; I wonder if it's a case of we can't be certain, so lets assume it is or similar. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: reference to 'self' inside a function
On Jul 18, 2012 6:20 AM, FeepingCreature default_357-l...@yahoo.de
wrote:
On 07/18/12 01:05, Kevin Cox wrote:
What about how JavaScript does it. Anonymous functions can still have
a name that can be used from inside of a function to refer to itself.
Sadly, this collides with the return-type syntax already in place.
auto f = function int(int i) { return 0; };
True, but the concept could still be used, we just need some syntax.
Re: Re-thinking D's modules
On Wednesday, 18 July 2012 at 09:59:03 UTC, Marco Leise wrote: Am Wed, 18 Jul 2012 10:24:36 +0100 schrieb Russel Winder rus...@winder.org.uk: Go solves the problem by refusing all notion of dynamic linking and insisting on static linking of all applications. ... not possible? While I learned a while back that system calls exist and are not dynamically linked, I wonder how Go goes about: * basic system libraries (static linking to kernel32.dll?) * executable bloat from large OO toolkits like Qt Don't flame me, just giving the typical set of answers in gonuts, which you can easily find when searching for .so/.dll discussions. Use strip to reduce executable size. * increased memory footprint by not allowing shared instances of DLLs/SOs * modular development (e.g. separating server and client code in games) Separate code in common packages, while generating separate executables. * dynamically loadable plugins/extensions From the security point of view loadable plugins are not good. Better make use of IPC to communicate between plugins. If you need performance, make use of shared memory as IPC mechanism, which incidentally invalidates the security reasons. * security and bug fixes to libraries used in dozens of programs (- recompile of all library users ?) yes
Re: Orbit (Was: Re-thinking D's modules)
On 2012-07-18 12:07, Nick Sabalausky wrote: Speaking of, how's that coming along? I haven't been working on that for a while. I've been working on DStep. The most basic functionality is there: * Creating packages * Installing packages * Downloading packages * Uploading packages Although no real dependency algorithm is implemented yet. I think there's a really simple one, if I recall correctly. https://github.com/jacob-carlborg/dstep -- /Jacob Carlborg
Re: KR-style variadic functions
On 2012-07-18 12:25, Regan Heath wrote: In any case. It think the practical solution to this problem is to assume you're working with modern code, and have a command line option to make it assume KR or old-style declarations. In the old-style mode you would have to assume a function with an empty () could have any number of parameters and the best you can do is produce: extern (C) ret name(/* fill in the blanks please*/); R Seems like this will be the solution. -- /Jacob Carlborg
Re: Re-thinking D's modules
On 2012-07-18 12:23, Dejan Lekic wrote: I am aware of the Orbit project, but what Jigsaw will do for Java, and what similar built-in module versioning in other languages do, is to give control of pieces of large software systems. Having module version as part of the language will give tools like Orbit a nice, standardized way to know what is the module version of a D source file it is currently processing. Later on, it may help compilers create SO/DLL version information if a certain module becomes a library... Say you have a product, and you want to provide support for all legacy versions. One way to that is to put all old(er) versions of a module into a single library. If the module is not versioned, you would have to use external module information, typically stored in bunch of config files, and what is worse is quite often, if you lose these files, you have no idea what module version it was... (Unless you are pedantic, and write that information in the header comment of the module) I use Maven a lot, every day, Jigsaw is not a replacement for Maven, it is a help to Maven, coming from the language itself. Yeah, sure. With language support we could do much more. Orbit is focused at working without language support, at least as a start. -- /Jacob Carlborg
Re: D versionning
On Tuesday, 17 July 2012 at 18:12:28 UTC, Iain Buclaw wrote: On 17 July 2012 12:05, Wouter Verhelst wou...@grep.be wrote: Chris NS ibisbase...@gmail.com writes: +1 for a 2.breaking.bugfix scheme. I've used this scheme on anything serious for years, and know many others who have; so it is not only popular but also quite tried and proven. Not for every project, of course (although I don't understand why the Linux kernel team dropped it with 3.x), but for the majority it seems to work wonders. They haven't, on the contrary. 3.x is a release with new features 3.x.y is a bugfix release. Before the move to 3.x, this was 2.6.x and 2.6.x.y -- which was confusing, because many people thought there was going to be a 2.8 at some point when there wasn't. The reason for the move to 3.x is in the announcement. http://lkml.org/lkml/2011/7/21/455 But yes, it simplifies the stable vs development kernel versioning. I don't recall where I first got my information, but clearly I was mistaken. And I'm happy to have been so. Maybe if I actually kept up more with the info on kernel releases I'd have known... alas. -- Chris NS
Re: KR-style variadic functions
On 2012-07-18 11:41, Walter Bright wrote:
Variadic functions, in order to work in C, need at least one parameter
so that varargs can work.
int foo();
declares a function with an unspecified parameter list, not a variadic
one. It is specified by a definition somewhere:
int foo(a,b)
int a;
int b;
{ ... }
somewhere.
I think I understand now.
If Dstep encounters the first declaration form, your options are to:
1. reject it (a perfectly reasonable approach)
2. treat it as:
int foo(void);
I suggest option 2, which is what C++ does.
Sounds reasonable. I will also provide a flag specifying how this should
be handled.
I actually found library that uses this style of declaration. It's used
in several places in libruby. For example:
void rb_define_virtual_variable(const
char*,VALUE(*)(ANYARGS),void(*)(ANYARGS));
ANYARGS is defined as:
#ifdef __cplusplus
#define ANYARGS ...
#else
#define ANYARGS
#endif
Does that mean that this C++ declaration:
void foo (...);
Is the same as this C declaration?
void foo ();
I'm wondering if the intention is to cast these function pointers to
their correct signature before calling them.
--
/Jacob Carlborg
Initialization of std.typecons.RefCounted objects
Hi, I looked at Bug #6153 (Array!(Array!int) failure) and found that the reason is the following behavior: Given some type T you wrap as RefCounted!T object, then proper use of the auto-initialization feature or manual initialization on demand ensures that no null-pointer dereference will happen. But the other problem is that as long as the wrapped object is uninitialized, the object behaves like a value type instead of a reference type. This exactly is what makes the following code fail: Array!(Array!int) array2d; array2d.length = 1; array2d[0].insert(1); The inner array array2d[0] was not initialized and hence the reference pointer is null. Since Array.opIndex returns by value, the 'insert' method is called on a temporary object and does not affect the inner array (still being empty) which is stored in the outer array. What do you think about this? Must the user ensure that the Array container is always initialized explicitly? If yes, how shall this happen since the only constructor takes a (non-empty) tuple of new elements. Or shall opIndex return by reference? The problem arises in the same way if Array was a class - but then the user typically knows that after enlarging the outer array, the inner array is a null pointer which must be created by new. Best regards, Matthias Walter
Re: reference to 'self' inside a function
True, but the concept could still be used, we just need some syntax. IMHO introducing a new keyword is the clearest solution. As for the danger of breaking existing code, let's face it, there is no whole world legacy written in D with extensive use of 'thisFunc' keyword.
Re: Initialization of std.typecons.RefCounted objects
Matthias Walter , dans le message (digitalmars.D:172673), a écrit : I looked at Bug #6153 (Array!(Array!int) failure) and found that the This exactly is what makes the following code fail: Array!(Array!int) array2d; array2d.length = 1; array2d[0].insert(1); The inner array array2d[0] was not initialized and hence the reference pointer is null. Since Array.opIndex returns by value, the 'insert' method is called on a temporary object and does not affect the inner array (still being empty) which is stored in the outer array. What do you think about this? Must the user ensure that the Array container is always initialized explicitly? If yes, how shall this happen since the only constructor takes a (non-empty) tuple of new elements. Or shall opIndex return by reference? I think opIndex should return by reference. opIndexAssign is of no help when the user want to use a function that takes a reference (here Array.insert). It is normal that Array uses default construction when someone increases the array's length. Besides that point, I don't see why default-constructed Array have an uninitialised Payload. This makes uninitialised Array behaves unexpectedly, because making a copy and using the copy will not affect the original, which is not the intended reference value behavior. Correcting default-initialization of Array would correct your bug, but would not correct the wrong behavior of Array when the value returned by opIndex is used with a non-const method with other objects (dynamic arrays?). So both have to be changed in my opinion. -- Christophe
Re: Initialization of std.typecons.RefCounted objects
I see you found the appropriate entry to discuss this bug: http://d.puremagic.com/issues/show_bug.cgi?id=6153
Re: KR-style variadic functions
On Wed, Jul 18, 2012 at 11:23:33AM +0100, Regan Heath wrote:
On Tue, 17 Jul 2012 19:39:25 +0100, H. S. Teoh
hst...@quickfur.ath.cx wrote:
[...]
This modern C declaration:
int main(int argc, char **argv) {
exit(1);
}
is written thus in KR:
int main(argc, argv)
int argc;
char **argv;
{
exit(1);
}
Clarification.
The /definition/ is as you have above, the /declaration/ is not.
The declaration is what goes in the header file, and in KR (and
ANSI C for that matter) looks like:
int main();
parameters are not required for the declaration, only the definition.
[...]
You are right.
And also, under KR syntax, the 'int' can be omitted from before main. I
*think* the entire argc line can be omitted as well (undeclared
variables default to int, IIRC). 'Tis a strange world they used to live
in. :-)
T
--
Almost all proofs have bugs, but almost all theorems are true. -- Paul Pedersen
Re: Re-thinking D's modules
Am Wed, 18 Jul 2012 11:56:45 +0200 schrieb Paulo Pinto pj...@progtools.org: Last time I checked, I could compile Java and C# to native code if I wished to do so. -- Paulo Forum.getUserByName(Paulo Pinto).addAttribute(nit-picky); ;) -- Marco
Re: Re-thinking D's modules
On Wednesday, 18 July 2012 at 13:55:10 UTC, Marco Leise wrote: Am Wed, 18 Jul 2012 11:56:45 +0200 schrieb Paulo Pinto pj...@progtools.org: Last time I checked, I could compile Java and C# to native code if I wished to do so. -- Paulo Forum.getUserByName(Paulo Pinto).addAttribute(nit-picky); ;) Yeah, I guess I deserve it. :)
Re: Octal Literals
On Tuesday, 17 July 2012 at 22:35:48 UTC, Nick Sabalausky wrote: On Tue, 17 Jul 2012 23:53:47 +0200 Dave X. dxuhu...@gmail.com wrote: I'm a fresh college graduate who just got a job as a software developer, and I have been enthusiastically watching D for a while now (I program primarily in Java and C). I have some functional programming experience in Haskell and Scala as well. I wish D had been as far along as it is now back when I was in college! I like using octal numbers, and I've always been interested in D's octal literals. I'm glad to see that the traditional syntax of C's octal literals is being replaced by a more readable one. However, I can't help but think that the template solution (octal!nnn) is a little too roundabout; is there a reason that that the 0o prefix, which is already well established in languages like Haskell, OCaml, and Python, is not used? It was suggested a few times, but there was a lot of bikeshedding over it. Some people liked it, some hated it. One of the bigger objections was that octal literals were too rarely-needed to justify adding a new syntax into the language (this was at a time when D was far enough along that we were trying to start stabalizing the langauge rather than tossing in more stuff). The bikeshedding went around and around like that for awhile, during which time the awful old 0123 octal syntax remained. So when it was discovered that D's templates made it possible to implement octal literals in the library (octal!123), instead of in the language itself (0o123), that solved the deadlock and we went with it. Thanks! I guess I'll get used to it. Not that this really matters, but out of curiosity, how does this template work?
Random sampling in D -- blog post
Hello all, My patches to RandomSample were accepted earlier this month (thanks to both Jonathan and Andrei:-) so I thought I'd write a short blog post (which turned into a very long blog post...) about random sampling, the algorithms concerned, and its implementation in D. http://braingam.es/2012/07/sampling-d/ If anyone's interested I may write up something more extended on the algorithms (if I can find a decent maths-notation solution for WordPress...) and on the D framework for random sampling (it could be fun to put up some creative examples of how to use it with different kinds of input). Best wishes, -- Joe
Re: Need runtime reflection?
On Wed, Jul 18, 2012 at 2:59 PM, Jacob Carlborg d...@me.com wrote:
I think you can pass a module to a template via an alias parameter. Then
the template should be able to inspect all free functions using something
like __traits(allMembers).
Have a problem.
--
// file: A.d
module A;
// functions and classes
--
--
// file: testtraits.d
import std.stdio;
import A;
void main() {
writeln(__traits(allMembers, A));
}
--
There is a compilation error:
testtraits.d(6): Error: import A has no members
If module is under a package name, it is OK, is that a bug?
Re: Octal Literals
Dave X. , dans le message (digitalmars.D:172680), a écrit : Not that this really matters, but out of curiosity, how does this template work? By looking at the sources, if the template argument is a string, the program just compute the octal value as a human would do, that is it makes the sum of the digits multiplied by their respective power of 8. If the template argument is not a string, it is transformed into a string and the previous algorithm is used. -- Christophe
Re: std.algorithm imporvments
On Tuesday, 17 July 2012 at 17:19:31 UTC, Jonathan M Davis wrote: On Tuesday, July 17, 2012 10:47:50 Andrei Alexandrescu wrote: On 7/17/12 4:41 AM, monarch_dodra wrote: On Monday, 16 July 2012 at 22:42:47 UTC, Andrei Alexandrescu wrote: Wow, this is awesome. Did you discover that by inspection or by testing? I think a malicious input range would be a great tool for assessing which algorithms fail on input ranges. Andrei The first I discovered testing with a ConsumableRange, actually. The second, I found by inspection. I'll correct those two issues myself, but I don't feel comfortable with the other issues. You may want to submit them as bug requests. Thanks! Yes. Please do. It's on my todo list to improve std.algorithm and std.range's tests (particularly for reference type ranges), and I've gotten started on it, but it could take a while to get it all done, and anything that you find will be valuable in not only figuring out what needs fixing but also in figuring out what needs better testing. bugzilla: http://d.puremagic.com/issues - Jonathan M Davis Hi Jonathan, I've made changes to algorithm to the best of my abilities. If it does not meet requirements, please tell me what is wrong, and all work on it as I can. I've put an in-depth explanation of the changes in the pull request description. Slightly on topic, did you read my post about Definition of OutputRange insuficient? Would it be OK to add hasLength to range.d? This would be the first step to making outputRanges more useable, without directly changing the definition of an output range quite yet.
Re: Octal Literals
This article by Walter might be of an interest to you: http://www.drdobbs.com/tools/user-defined-literals-in-the-d-programmi/229401068 On Tue, Jul 17, 2012 at 4:53 PM, Dave X. dxuhu...@gmail.com wrote: I'm a fresh college graduate who just got a job as a software developer, and I have been enthusiastically watching D for a while now (I program primarily in Java and C). I have some functional programming experience in Haskell and Scala as well. I like using octal numbers, and I've always been interested in D's octal literals. I'm glad to see that the traditional syntax of C's octal literals is being replaced by a more readable one. However, I can't help but think that the template solution (octal!nnn) is a little too roundabout; is there a reason that that the 0o prefix, which is already well established in languages like Haskell, OCaml, and Python, is not used?
Formal request to remove put(OutRange, RangeOfElements)
I'm really very sorry that this is such a long post, but I'd like to make request for a serious change to Phobos, so I think it should be as complete as possible. Thank you to those who have the patience to read it and consider it. ** Abstract: This is a formal request for the deprecation of the the support for accepting ranges of elements for the function put ie (put(OutRange, RangeOfElements)). As convenient as this functionality may be is, it undermines the very definition of what constitutes an output range, and creates some fundamental problems when trying to deal with them. put(Range, RangeOfElements) doesn't actually bring anything to the table that would be missed. ** Explanation: The problem is not put in and out of itself, but rather that it is the fundamental definition of what constitutes an output range. In particular, because you cannot extract elements from output ranges, and because an output range can potentially support multiple types, you cannot write: ElementType!OutputRange = this will yield void on a 'true' output range. Rather, you have to individually query if the range is an output for specific types: isOutputRange!(OutputRange, SomeElement) The catch is that the definition of isOutputRange is just does put(range, element) compile. This means that essentially, as soon as a range is an output for elements, it becomes an output for ranges of elements, for ranges of ranges of elements, for ranges of ranges of ranges of elements, for ... For example: int[] is an outputRange of int (obviously), but it is also defined as an output range of int[], int[2], and int[][]... This is clearly not right. ** Problems put creates for template restrictions: At it simplest, it prevents any algorithm from properly working with outputRanges. This is the definition of copy: Range2 copy(Range1, Range2)(Range1 source, Range2 target) if (isInputRange!Range1 isOutputRange!(Range2, ElementType!Range1)) See the trap? This is perfectly legal code: int a[][][][]; int b[]; copy(a, b); Look bad? it gets worse. Imagine the function fill. It works the same as copy, but it can also take an element as an argument. One would be tempted to write this pair of signatures: void fill(Range1, Range2)(Range1 target, Element filler) if(isOutputRange(Range1, Element)) void fill(Range1, Range2)(Range1 target, Range2 filler) if(isInputRange!Range2 isOutputRange(Range1, ElementType!Range2)) You can try to write this, but if you do, the code will never work. ANYTHING that matches the range fill, will also match the element based fill, since the target range supports put from a range... For example: int[2] a = [1, 2]; int[] b = new int[](8); fill(b, a); //ambiguous call... //Are you copying a range or an element? //Answer: Who know! Honestly: if b is an output range of a, WHICH IS THE RIGHT CALL? The only way to really avoid this problem (as is currently done in algorithm.d) is to add: is(typeof(range.front = filler)), but this defeats the very requirement of outputRange (outputRange does not have front), and bumps the algorithm's requirements up to inputRange. Long story short, it is not currently possible to write templates that reliably support an outputRange restriction. ** Problems put creates for implementation: The big problem about put is that it makes outputRanges _lie_ about what they support. Here is an example at its simplest: alias int[] A; alias int[] B; A a = new int[](2); B b = new int[](1); assert(isOutputRange!(typeof(a), typeof(b))); if(!b.empty) b.put(a); In this code: *b is an output range of A. *b is not empty. *putting an A inside b creates a empty range exception !? While this example might look cute, it is also unacceptable behavior. if b is a non-empty range that supports elements A, then it _HAS_ to be able to support a put. In this case, b clearly does not support elements of type A. I'm sure you can imagine the kinds of problems this can caue for a template developer. ** Why we don't need put(Range): Quite simply: because we have the higher order function. The convenience put(Range) is nothing more than a glorified algorithm. Instead of using put, the user should make a call to copy. copy is designed specifically for copying an input range into an output range. Why duplicate this functionality into put? Calling copy is much more honest and accurate about what is actually happening. ** Problems regarding removing put(Range): In theory, the only problem this would create is breaking code which can be legitimately replaced by “copy” without any change. It *could* also break
Re: Formal request to remove put(OutRange, RangeOfElements)
That sounds reasonable and justified. Let's wait to know if people maintaining legacy code will not strongly oppose to this.
Re: Octal Literals
On Wed, 18 Jul 2012 16:45:58 +0200, Dave X. dxuhu...@gmail.com wrote:
Not that this really matters, but out of curiosity, how does this
template work?
It converts the passed number to a string, then works on a digit at a
time. Basically:
foreach ( digit; number ) {
if ( digit = '0' digit = '9' )
result = result * 8 + digit;
}
--
Simen
Re: Octal Literals
On Wed, Jul 18, 2012 at 05:06:21PM +0200, Simen Kjaeraas wrote:
On Wed, 18 Jul 2012 16:45:58 +0200, Dave X. dxuhu...@gmail.com wrote:
Not that this really matters, but out of curiosity, how does this
template work?
It converts the passed number to a string, then works on a digit at a
time. Basically:
foreach ( digit; number ) {
if ( digit = '0' digit = '9' )
result = result * 8 + digit;
}
[...]
And this is done at compile-time, so there is no runtime overhead (it
just becomes a constant like an actual literal).
T
--
640K ought to be enough -- Bill G., 1984. The Internet is not a primary goal
for PC usage -- Bill G., 1995. Linux has no impact on Microsoft's strategy
-- Bill G., 1999.
Re: Octal Literals
On Tuesday, 17 July 2012 at 21:53:50 UTC, Dave X. wrote: I'm a fresh college graduate who just got a job as a software developer, and I have been enthusiastically watching D for a while now (I program primarily in Java and C). I have some functional programming experience in Haskell and Scala as well. I like using octal numbers, and I've always been interested in D's octal literals. I'm glad to see that the traditional syntax of C's octal literals is being replaced by a more readable one. However, I can't help but think that the template solution (octal!nnn) is a little too roundabout; is there a reason that that the 0o prefix, which is already well established in languages like Haskell, OCaml, and Python, is not used? Coming from C++, the only time I've EVER seen octals used is by accident when developers try to 0-align his variables. Good riddance to the 0 prefix. Seriously :( That said, I did not know of this 0o prefix. It sounds like a good idea, and I see no reason not to add it, other than it is hard work for the compiler devs of course, who already have a lot of work. :)
Re: Octal Literals
On 7/18/12 10:29 AM, monarch_dodra wrote: I see no reason not to add it This is never a good argument for adding things to a language. Andrei
Re: Need runtime reflection?
On 2012-07-18 17:10, lijie wrote:
On Wed, Jul 18, 2012 at 2:59 PM, Jacob Carlborg d...@me.com
mailto:d...@me.com wrote:
I think you can pass a module to a template via an alias parameter.
Then the template should be able to inspect all free functions using
something like __traits(allMembers).
Have a problem.
--
// file: A.d
module A;
// functions and classes
--
--
// file: testtraits.d
import std.stdio;
import A;
void main() {
writeln(__traits(allMembers, A));
}
--
There is a compilation error:
testtraits.d(6): Error: import A has no members
If module is under a package name, it is OK, is that a bug?
Seems like it.
http://d.puremagic.com/issues/
--
/Jacob Carlborg
Re: KR-style variadic functions
On 7/18/2012 4:59 AM, Jacob Carlborg wrote: Does that mean that this C++ declaration: void foo (...); Not allowed in C or C++. Is the same as this C declaration? void foo (); That is void foo(void) in C++.
Re: KR-style variadic functions
On 2012-07-18 20:43, Walter Bright wrote: On 7/18/2012 4:59 AM, Jacob Carlborg wrote: Does that mean that this C++ declaration: void foo (...); Not allowed in C or C++. When compiling in C++ mode, both Clang and GCC accepts this. Is the same as this C declaration? void foo (); That is void foo(void) in C++. -- /Jacob Carlborg
DMD stuck at semantic analyze
I just encountered a strange thing. I'm compiling my project, DStep, using DMD 2.059 and it get stuck at the semantic analyze (semantic3) of the following file: https://github.com/jacob-carlborg/mambo/blob/43f7e8ffded8c50d6c1d864d472a8bcb511787e9/arguments/Arguments.d It seems to have something to do with line 40. If I comment out that line DMD seems to behave correctly. If I use latest git HEAD, DMD doesn't get stuck, it just exits at the same semantic analyze with exit code 0 and doesn't produce an executable. I've done some tries to get a reduced test case but failed to reduce the code. https://github.com/jacob-carlborg/dstep/tree/args -- /Jacob Carlborg
Re: KR-style variadic functions
On 7/18/2012 11:47 AM, Jacob Carlborg wrote: On 2012-07-18 20:43, Walter Bright wrote: On 7/18/2012 4:59 AM, Jacob Carlborg wrote: Does that mean that this C++ declaration: void foo (...); Not allowed in C or C++. When compiling in C++ mode, both Clang and GCC accepts this. How would you get the arguments inside foo?
Re: Octal Literals
On Wednesday, 18 July 2012 at 17:37:02 UTC, Andrei Alexandrescu wrote: On 7/18/12 10:29 AM, monarch_dodra wrote: I see no reason not to add it This is never a good argument for adding things to a language. Andrei Taken out of context, no it isn't. It sounds like a good idea, is a (relatively) good argument though.
Re: Octal Literals
On 7/18/12 1:39 PM, monarch_dodra wrote: On Wednesday, 18 July 2012 at 17:37:02 UTC, Andrei Alexandrescu wrote: On 7/18/12 10:29 AM, monarch_dodra wrote: I see no reason not to add it This is never a good argument for adding things to a language. Andrei Taken out of context, no it isn't. It sounds like a good idea, is a (relatively) good argument though. Yah, thought the same after posting, sorry. Nevertheless, 0o or whatnot does not deserve, I opine, any attention. Andrei
Re: reference to 'self' inside a function
On Tuesday, 17 July 2012 at 16:56:17 UTC, angel wrote: I propose to introduce a reference to the current function, much like 'this' in a class method. Call it 'self' or 'thisFunc', or whatever ... What might this be good for ? For implementing recursion in a lambda function. Writing in functional style, one creates many functions, and looking for reasonable names for these functions becomes unnecessarily painful. Recursive lambdas? o.O Instead of changing the language, I'd say your situation merits using the Y combinator... maybe define Y(f) to be (g = g(g))(g = f(x = g(g)(x))) then if you need to define factorial, just say... fact = Y(fact = n = n 0 ? n * fact(n - 1) : 1);
Re: Segmentation fault while creating a class object by dlsym-ed function
On 2012-07-18 06:51, Konstantin J. Chernov wrote: Hello. When I'm trying to create a class object by using a dlsym-ed function, I'm getting a segmentation fault after execution of program. However, if I'm deleting that object before 'return 0' in main (by using 'delete b'), everything is going fine. I'm just started to learn D after using C++ for more than 5 years, so some things look really strange for me (especially that 'new className()' doesn't return a pointer). Classes are always references. What am I doing wrong here? Is there any way to do what I'm trying to do right way? Dynamic libraries aren't properly supported by the runtime. -- /Jacob Carlborg
Re: ufcs and integer params
Am Sun, 15 Jul 2012 19:17:11 +0200 schrieb Philippe Sigaud philippe.sig...@gmail.com: On Sunday, July 15, 2012 05:30:55 Jay Norwood wrote: I see from this other discussions that it looks like 2.059 ( or maybe 2.060) does support something like 3.cm(). Not sure from the discussion if it would also accept 3.cm as in the xtext/xtend example. Hi Jay, I had a little fun with coding a units (SI units) system in D and pushed an incomplete version on Github a few weeks ago: https://github.com/PhilippeSigaud/Units It allows things like: auto distance = 100.km; auto speed = 120.km/hour; auto timeToDestination = distance/speed; // timeToDest is a time (seconds) The version on Github is grossly limited (it's just a sketch), but it gives an idea of what's possible. My goal is to code a generic unit system generator, given user inputs such as a list of units and sub-units. cheers, Philippe Sounds fun. I mean, it makes me happy to see code written like this instead of Distance distance = new Kilometers(100); Speed speed = Speed.fromDistanceByTime(new Kilometers(120), new Hours(1)); :D -- Marco
Re: Segmentation fault while creating a class object by dlsym-ed function
What am I doing wrong here? Is there any way to do what I'm trying to do right way? Dynamic libraries aren't properly supported by the runtime. That's terrible:( It's so nice to make an interface, and create classes that inherit this interface dynamically, without linking... Maybe there's another way?
is() and const
Run this code:
class PP {}
void what(T)(T val)
{
static if (is(T == int)) writeln (T == int);
static if (is(T == const(int))) writeln (T == const(int));
static if (is(T : int)) writeln (T : int);
static if (is(T == PP)) writeln (T == PP);
static if (is(T == const(PP))) writeln (T == const(PP));
static if (is(T : PP)) writeln (T : PP);
}
void main(string[] args)
{
const int aa = 10;
int ab;
const PP ba = new PP;
PP bb = new PP;
writeln(- Testing const(int));
what(aa);
writeln();
writeln(- Testing int);
what(ab);
writeln();
writeln(- Testing const(PP));
what(ba);
writeln();
writeln(- Testing PP);
what(bb);
writeln();
return;
}
It says:
- Testing const(int)
T == const(int)
T : int
- Testing int
T == int
T : int
- Testing const(PP)
T == const(PP)
- Testing PP
T == PP
T : PP
So:
const(int) : int -- true
const(PP) : PP -- false
Is this behaviour correct?
And how can I check if T is of a certain class ignoring consts (and
avoiding double checks)?
Re: is() and const
Andrea Fontana: const(int) : int -- true const(PP) : PP -- false Is this behaviour correct? I think it's correct, and it's caused by the difference between value types and reference types. And how can I check if T is of a certain class ignoring consts (and avoiding double checks)? There are some different ways to do it, one of them is to use something like (untested): is(Unqual!typeof(x) == PP) Where Unqual is in Phobos, std.traits.Unqual. Bye, bearophile
Re: Segmentation fault while creating a class object by dlsym-ed function
Konstantin J. Chernov:
testclass.di:
class testclass
{
this(const wstring loadmsg);
~this();
wstring foo();
};
And usually you don't need to write .di files in D.
Bye,
bearophile
Re: Segmentation fault while creating a class object by dlsym-ed function
On 2012-07-18 10:17, Konstantin J. Chernov wrote: What am I doing wrong here? Is there any way to do what I'm trying to do right way? Dynamic libraries aren't properly supported by the runtime. That's terrible:( It's so nice to make an interface, and create classes that inherit this interface dynamically, without linking... Maybe there's another way? No, not that I can think of for now. But it's a known problem that is being worked on: https://github.com/dawgfoto/druntime/tree/SharedRuntime -- /Jacob Carlborg
Re: is() and const
It seems to works (but i use Unqual!T directly) Thank you :) Il giorno mer, 18/07/2012 alle 11.13 +0200, bearophile ha scritto: Andrea Fontana: const(int) : int -- true const(PP) : PP -- false Is this behaviour correct? I think it's correct, and it's caused by the difference between value types and reference types. And how can I check if T is of a certain class ignoring consts (and avoiding double checks)? There are some different ways to do it, one of them is to use something like (untested): is(Unqual!typeof(x) == PP) Where Unqual is in Phobos, std.traits.Unqual. Bye, bearophile
Re: is() and const
On Wednesday, July 18, 2012 10:43:23 Andrea Fontana wrote: So: const(int) : int -- true const int is implicitly convertible to int, because it's a value type, and assigning a const int to an int (or vice versa) makes a copy. const(PP) : PP -- false const PP is not implicitly convertible to PP, because it's a reference type. So, assigning a PP to a PP doesn't make a copy. It just copies the reference. And a const PP can't be converted to a mutable PP, because that would be dropping the const, invalidating const's guarantees. If PP were a struct with no pointers, arrays, or reference types (or it had a postblit constructor), then it would be a value type, and const PP _would_ implicitly convert to PP. Is this behaviour correct? Yes. And how can I check if T is of a certain class ignoring consts (and avoiding double checks)? is(Unqual!T == T) Unqual is in std.traits. - Jonathan M Davis
Re: Segmentation fault while creating a class object by dlsym-ed function
On 18-07-2012 06:51, Konstantin J. Chernov wrote:
Hello. When I'm trying to create a class object by using a dlsym-ed
function, I'm getting a segmentation fault after execution of program.
However, if I'm deleting that object before 'return 0' in main (by using
'delete b'), everything is going fine.
I'm just started to learn D after using C++ for more than 5 years, so
some things look really strange for me (especially that 'new
className()' doesn't return a pointer).
What am I doing wrong here? Is there any way to do what I'm trying to do
right way?
Thanks.
test.d:
import std.c.linux.linux;
import std.stdio;
import testclass;
int main(string[] args)
{
void* handle = dlopen(./testclass.so, RTLD_LAZY | RTLD_LOCAL);
testclass function(wstring) a;
a = cast(testclass function(wstring))dlsym(handle, loadClass);
testclass b = a(test);
return 0;
}
testclass.di:
class testclass
{
this(const wstring loadmsg);
~this();
wstring foo();
};
testclass.d:
import std.stdio;
class testclass
{
private wstring msg;
this(const wstring loadmsg)
{
writeln(Class constructor);
this.msg = loadmsg;
}
~this()
{
}
wstring foo()
{
return msg;
}
};
extern(C) testclass loadClass(const wstring loadmsg)
{
return new testclass(loadmsg);
}
As Jacob said, the D runtime isn't quite ready for shared libraries yet.
What you can do, however, is provide a bit of inversion of control to
make the allocation happen from the runtime linked statically to your
application:
import std.conv;
alias extern (C) void* function(size_t) Allocator;
extern (C) testclass loadClass(Allocator allocator, const wstring loadmsg)
{
auto size = __traits(classInstanceSize, testclass);
auto mem = allocator(size);
return emplace!testclass(mem[0 .. size], loadmsg);
}
Then in the application:
import core.memory;
import core.sys.posix.dlfcn;
import std.stdio;
import testclass;
void* allocate(size_t size)
{
return GC.malloc(size);
}
int main(string[] args)
{
auto h = dlopen(./testclass.so, RTLD_LAZY | RTLD_LOCAL);
auto a = cast(testclass function(Allocator, wstring))dlsym(h,
loadClass);
auto b = a(allocate, test);
return 0;
}
This should make allocation work, but I haven't actually tested it. Note
also that even if it does work, things get more complicated when the
class you're allocating has a finalizer, for example (see
http://dlang.org/phobos/core_memory.html#FINALIZE).
--
Alex Rønne Petersen
a...@lycus.org
http://lycus.org
Re: Segmentation fault while creating a class object by dlsym-ed function
Thank you for your replies!
I've found a working solution - all I needed is to change wstring
to const wstring, and pass it not as func(something), but as
wstring tmp = something; func(tmp);
That's really odd, because I don't understand, how those changes
made segfault disappear.
Here's the working code:
test.d:
import std.c.linux.linux;
import std.stdio;
import testclass;
int main(string[] args)
{
void* handle = dlopen(./testclass.so, RTLD_LAZY |
RTLD_LOCAL);
testclass function(const wstring) a;
a = cast(testclass function(const wstring))dlsym(handle,
loadClass);
wstring tmp = Test;
testclass b = a(tmp);
return 0;
}
testclass.di:
class testclass
{
this(const wstring loadmsg);
~this();
wstring foo();
};
testclass.d:
import std.stdio;
class testclass
{
private wstring msg;
this(const wstring loadmsg)
{
writeln(Class constructor);
this.msg = loadmsg;
}
~this()
{
}
wstring foo()
{
return msg;
}
};
extern(C) testclass loadClass(const wstring loadmsg)
{
return new testclass(loadmsg);
}
dmd test.d -L-ldl
dmd testclass.d -fPIC -shared
Re: ufcs and integer params
On Monday, 16 July 2012 at 23:18:10 UTC, Adam D. Ruppe wrote: I'm another who is /vehemently/ against the utter idiocy that is the -property switch. Arguments! Yay!
Re: ufcs and integer params
On Wednesday, 18 July 2012 at 07:30:10 UTC, Marco Leise wrote: Am Sun, 15 Jul 2012 19:17:11 +0200 schrieb Philippe Sigaud philippe.sig...@gmail.com: […] auto distance = 100.km; auto speed = 120.km/hour; auto timeToDestination = distance/speed; // timeToDest is a time (seconds) The version on Github is grossly limited (it's just a sketch), but it gives an idea of what's possible. My goal is to code a generic unit system generator, given user inputs such as a list of units and sub-units. […] Sounds fun. I mean, it makes me happy to see code written like this instead of Distance distance = new Kilometers(100); Speed speed = Speed.fromDistanceByTime(new Kilometers(120), new Hours(1)); I find multiplication to read much more natural: --- enum km = kilo * meter; auto distance = 100.0 * km; auto speed = 100.0 * km / hour; auto timeToDest = distance / speed; --- See http://klickverbot.at/code/units/ for a slightly neglected implementation of this scheme. It supports stuff like defining new units with arbitrary (potentially runtime) conversion factors, properly typechecked affine units (think degrees celsius), etc. – but any error messages and symbol names will probably look like if the compiler had a seizure. David
Re: Compilation failure
On Wednesday, 11 July 2012 at 02:30:47 UTC, Timon Gehr wrote: On 07/11/2012 04:25 AM, ixid wrote: in some way it sees global immutables almost as enums This seems like a bad idea. Consistency of behaviour would seem to be a good principle to expect of a language. You are right; this is a bug. Has someone reported this bug? I can't seem to find it in the tracker. If not, how should I go about reporting it?
Re: ufcs and integer params
On Wednesday, 18 July 2012 at 11:37:43 UTC, David Nadlinger wrote: Arguments! Yay! I've gone over this a dozen times on the group and on bugzilla, and I'm kinda sick of repeating it. -property breaks craploads of code. That's a huge negative, and nobody has even come close to countering that. -property will be the standard is utterly worthless, yet that's really the only thing I see brought up again. The other most common thing is I don't like how writeln = 10 looks. Easy response: then don't write that. If you're going to break code because someone might write something you find ugly - note this is different than the arguments people like Crockford make about, say, Javascript's ==, which he argues is a bug 95% of the time you see it, this is just I don't like how that looks. But if we're going to let the possibility for subjective ugliness be justification for BREAKING CODE, I can't stress that enough, we might as well just nuke the whole language. BTW, a common fallacy I also here is bringing up the edge cases like returning a delegate in a property. Two points: 1) That has *nothing* to do with syntax. The @property decoration takes care of that, regardless of syntax. Why do we have to break a common case to fix an edge case especially when we /can/ have our cake and eat it too? 2) -property doesn't even get that right anyway. Not kidding, try it. -property might as well be renamed -break-my-code-and- give-me-ABSOLUTELY-NOTHING-in-return. Why, why would we ever consent to having that standard?
Re: ufcs and integer params
On Wednesday, 18 July 2012 at 12:30:46 UTC, Adam D. Ruppe wrote: 2) -property doesn't even get that right anyway. Not kidding, try it. -property might as well be renamed -break-my-code-and- give-me-ABSOLUTELY-NOTHING-in-return. Why, why would we ever consent to having that standard? I actually tend to agree with this part – I see -property more like an experiment help determining the behavior we want to make the default with real-world testing. We should definitely try to fix/improve the implementation of -property before we consider to make it the default. But without it, the discussion might have never gotten to the point where we are now, so I still consider it a success. David
Re: Compilation failure
On Wednesday, 18 July 2012 at 12:15:52 UTC, Lemonfiend wrote: On Wednesday, 11 July 2012 at 02:30:47 UTC, Timon Gehr wrote: On 07/11/2012 04:25 AM, ixid wrote: in some way it sees global immutables almost as enums This seems like a bad idea. Consistency of behaviour would seem to be a good principle to expect of a language. You are right; this is a bug. Has someone reported this bug? I can't seem to find it in the tracker. If not, how should I go about reporting it? Also, I don't think I'm clear enough about the differences between immutables, consts and enums to write a bug report about this.
Re: using GC needs particular skills?
18.07.2012 8:00, Mike Parker пишет:
Destructors are unreliable. There is no guarantee that a destructor will
be called before the garbage collector is terminated. When the program
exits, the runtime will call gc_term which will then call destructors on
any objects that haven't yet been cleaned up. But the order in which
those destructors are called is unpredictable. This is a recipe for all
sorts of problems.
Static class destructors and module destructors are more reliable in
that you know they will be called in a particular order. But, they are
called before the gc is terminated.
Your particular problem is this. Derelict-style bindings load shared
libraries dynamically via system calls. That means that every bound
function is actually a function pointer. The shared library is then
unloaded in a static module destructor. When DRuntime exits, it calls
all the module destructors *before* calling gc_term. So what's happening
is:
1. The module destructors are run
2. Derelict unloads the shared library, thereby causing all of the
function pointers into that library to become invalid.
3. gc_term is run
4. The destructor of one of your objects is called and it tries to call
a function from the Derelict binding, but since that function pointer is
no longer valid, you get a segfault.
When cleaning up resources in D, you should generally not rely on class
destructors to do so. You'll want to include some sort of process to
clean up everything yourself. What I tend to do is something like this:
void term()
{
// initiate cleanup here
}
void main()
{
scope(exit) term();
init();
run();
}
The scope(exit) will ensure that the cleanup is run regardless of how
the program exits. Every subsystem in my program will have term()
function or method that substitutes for a destructor. This works fine
and I have no problems with it.
Of course, you can still use destructors for scoped object instances in
cases where you want RAII inside a particular scope.
Thank you very much for your help! Now I undestand it - I've never used
gc before.
Re: Magic type return
class Known
{
void* data; // external data by c api
int type; // 0 for int, 1 for string, etc. ..
}
How can I implement a method like this?
Known known; // -- suppose known.type == 1;
string s = known.value(); // -- automatic
I just know how to do this:
string s = know.value!string();
As bearophile said, you cannot change a value's type (which is a
compile-time construct) with a runtime value, as is Known.type.
Second point, in D, the rhs is fully evaluated before being assigned to the
lhs, I think. So, known.value() must evaluate to *something*, without
knowing it will be assigned to a string.
In your example, what happens if known.type != 1?
You can use Phobos Variant, (or Algebraic if the range of types you plan to
use is known beforehand). Then, you should test typeid before using it.
Re: Is this actually supposed to be legal?
That being said, I have never used CRTP in D so far, since template
mixins seem to be the better choice in almost all situations.
FWIW, CRTP is the main reason I used classes in Pegged, to allow grammar
rules to refer to themselves. My earlier attempts with structs did not work.
So, given a grammar rule like:
Expr - '(' Expr ')' / ...
I use:
class Expr : Or! (Sequence!(Literal!((), Expr, Literal!())) , ...)
{ ... }
As you can see, class Expr refer to itself while it's not defined yet. It's
the main use I've found for this idiom. Many C++ parsers use the same trick
and I was particularly glad to see it worked in D too.
Most of the times I use mixins, but could not find a way to do the same
recursive rule definition with them.
IIRC, I talk a bit about the CRTP in my tutorial on D templates , on Github.
Philippe
Re: Magic type return
Yes I did it using Variant and it works fine
Il giorno mer, 18/07/2012 alle 16.42 +0200, Philippe Sigaud ha scritto:
class Known
{
void* data; // external data by c api
int type; // 0 for int, 1 for string, etc. ..
}
How can I implement a method like this?
Known known; // -- suppose known.type == 1;
string s = known.value(); // -- automatic
I just know how to do this:
string s = know.value!string();
As bearophile said, you cannot change a value's type (which is a
compile-time construct) with a runtime value, as is Known.type.
Second point, in D, the rhs is fully evaluated before being assigned
to the lhs, I think. So, known.value() must evaluate to *something*,
without knowing it will be assigned to a string.
In your example, what happens if known.type != 1?
You can use Phobos Variant, (or Algebraic if the range of types you
plan to use is known beforehand). Then, you should test typeid before
using it.
opDot == alias this?
First:
Why is opDot not listed here:
http://dlang.org/operatoroverloading.html ?
How much other operators exists which are not listed there?
And:
Is opDot the same as alias this? I think so.
This code
[code]
class Foo {
public:
void echo() const {
writeln(Foo);
}
}
class Test {
private:
Foo _f;
public:
this(ref Foo f) {
this._f = f;
}
@property
ref Foo opDot() {
return this._f;
}
}
[/code]
Works exactly as these:
[code]
class Test2 {
private:
Foo _f;
public:
this(ref Foo f) {
this._f = f;
}
@property
ref Foo Get() {
return this._f;
}
alias Get this;
}
[/code]
But with opDot it is shorter. What are the advantages and
disadvantages of both?
Which of them should i use? Will one of them disappear in the
future?
I think opDot is more flexible as alias this. You can have one
alias this for one class/struct, but various opDot's, as this
example shows:
[code]
class Foo {
public:
void echo() const {
writeln(Foo);
}
}
class Bar {
public:
void echo() const {
writeln(Bar);
}
}
class Test3 {
private:
Foo _f;
Bar _b;
public:
this(ref Foo f, ref Bar b) {
this._f = f;
this._b = b;
}
@property
ref Foo opDot() {
return this._f;
}
@property
const(Bar) opDot() const {
return this._b;
}
}
[/code]
If Test3 is unconst, it prints with Foo, otherwise with Bar.
Re: foreach for ranges?
Also, UFCS makes no sense on overloaded operators, because they
don't get
called with ., and all UFCS is is changing obj.func(params)
to func(obj,
params).
- Jonathan M Davis
Ok, that's basically what I was wondering. I had assumed
foreach(e; someThing) {} could possibly have been converted to
someThing.opApply() . Thanks for clarifying.
Re: Magic type return
On Tue, 17 Jul 2012 15:23:05 +0100, bearophile bearophileh...@lycos.com
wrote:
Andrea Fontana:
class Known
{
void* data; // external data by c api
int type; // 0 for int, 1 for string, etc. ..
}
How can I implement a method like this?
Known known; // -- suppose known.type == 1;
string s = known.value(); // -- automatic
To do this Known.value() needs to return different types according to
the run-time value of Known.type. This is not possible in a statically
typed language... You need to find other solutions.
Unless we had overload based on return type, right?
e.g.
class Known
{
string value()
{
if (type != 1)
throw..;
return cast(string)data;
}
int value()
{
if (type != 0)
throw ..;
return cast(int)data;
}
}
The compiler could produce the correct code/call for the line
string s = known.value();
then, but it's not a feature we're likely to see any time soon.
R
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: opDot == alias this?
On Wed, 18 Jul 2012 16:58:34 +0200, Namespace rswhi...@googlemail.com wrote: First: Why is opDot not listed here: http://dlang.org/operatoroverloading.html ? How much other operators exists which are not listed there? I believe it's being deprecated. As far as I know, no other operators are unmentioned. Is opDot the same as alias this? I think so. They are related, but not the same. opDot allows access to the returned type's members and functions, but not the type itself. What are the advantages and disadvantages of both? alias this allows implicit type conversions, opDot does not. That's about it, I think. Which of them should i use? Depends. Look above. If you want a type to be usable as if another type, use alias this. If you just want to be able to access members of the other type, use opDot. Will one of them disappear in the future? As stated above, I believe opDot is scheduled for deprecation, but I'm unsure if (not to mention when) it will happen. I think opDot is more flexible as alias this. You can have one alias this for one class/struct, but various opDot's, as this example shows: TDPL states that multiple alias this should be supported, but it has not yet been implemented in the compiler. -- Simen
Re: Segmentation fault while creating a class object by dlsym-ed function
Probably you mean the same problem that is described in the thread avobe, see using GC needs particular skills? Every time after execution my code I got very frustating access violation and the problem was misunderstanding garbage collector because I've never used it before.
Re: foreach for ranges?
On 07/18/2012 08:21 AM, Mike L. wrote:
Also, UFCS makes no sense on overloaded operators, because they
don't get
called with ., and all UFCS is is changing obj.func(params) to
func(obj,
params).
- Jonathan M Davis
Ok, that's basically what I was wondering. I had assumed foreach(e;
someThing) {} could possibly have been converted to someThing.opApply()
. Thanks for clarifying.
But that is still true and opApply receives the body of the foreach loop
as a delegate:
someThing.opApply(delegate int(/* loop variables */) {
// ... the body of foreach ...
return terminationCode; // whether the user did 'break;'
});
Also, the following bug (that is already fixed) is somewhat related to
this discussion:
http://d.puremagic.com/issues/show_bug.cgi?id=5605
Ali
Re: opDot == alias this?
On Wednesday, July 18, 2012 16:58:34 Namespace wrote: First: Why is opDot not listed here: http://dlang.org/operatoroverloading.html ? How much other operators exists which are not listed there? And: Is opDot the same as alias this? I think so. opDot is going to be deprecated and really should have been already ( http://d.puremagic.com/issues/show_bug.cgi?id=2327 ). Don't use it. alias this and opDispatch give you the same thing, only better. http://stackoverflow.com/questions/9880064/d2-what-are-semantics-of-opdot - Jonathan M Davis
Re: Object Pointer
Only for correctness: If i allocate memory on the GC Heap in e.g. a struct and don't free the memory in the DTor, then the GC free the memory automatically?
Re: opDot == alias this?
Understand. Many thanks to you both.
Re: Is this actually supposed to be legal?
On Tuesday, 17 July 2012 at 23:38:04 UTC, Jonathan M Davis wrote:
It's not that it makes the compiler's life hard. It's the fact
that
conditional compilation relies on state that doesn't exist yet.
It's messed up
to be checking whether an object defines something when you're
in the middle of
defining that object.
[snip]
- Jonathan M Davis
Well, while you can do it in C++ as the Curiously Recursive
Template Pattern (particularly popular way of implementing the
singleton pattern BTW), you can't just do anything you feel like
doing with it.
If I remember correctly, in C++, you can't access any of T's
members, or create any (stack) instances of T, or (I think) call
T's any of T's static members, because T is not correctly formed
yet.
Did you try anything more advanced? For example, this outright
_crashes_ my (r)dmd:
class MyBase(T)
{
int a = T.hello();
}
class MySubA : MyBase!MySubA
{
static int hello(){return 0;}
}
I'm not entirely sure how valid the comparison with C++'s CRTP
is, because D's classes are actually pointer to implementation,
but I think it is a safe bet that what C++ can't do, neither can
D.
Re: Is this actually supposed to be legal?
On 07/18/2012 11:08 PM, monarch_dodra wrote:
On Tuesday, 17 July 2012 at 23:38:04 UTC, Jonathan M Davis wrote:
It's not that it makes the compiler's life hard. It's the fact that
conditional compilation relies on state that doesn't exist yet. It's
messed up
to be checking whether an object defines something when you're in the
middle of
defining that object.
[snip]
- Jonathan M Davis
Well, while you can do it in C++ as the Curiously Recursive Template
Pattern (particularly popular way of implementing the singleton pattern
BTW), you can't just do anything you feel like doing with it.
If I remember correctly, in C++, you can't access any of T's members, or
create any (stack) instances of T, or (I think) call T's any of T's
static members, because T is not correctly formed yet.
Did you try anything more advanced? For example, this outright _crashes_
my (r)dmd:
class MyBase(T)
{
int a = T.hello();
}
class MySubA : MyBase!MySubA
{
static int hello(){return 0;}
}
Well, that is a bug.
I'm not entirely sure how valid the comparison with C++'s CRTP is,
because D's classes are actually pointer to implementation, but I think
it is a safe bet that what C++ can't do, neither can D.
Careful there. D allows forward references. This is all supposed to work
in D. (but DMD is poor when it comes to tricky symbol lookup tasks.)
Re: Is this actually supposed to be legal?
On 07/18/2012 01:37 AM, Jonathan M Davis wrote: On Tuesday, July 17, 2012 23:11:43 Timon Gehr wrote: This issue is unrelated to CRTP. (also, you probably want to negate that static if condition, otherwise the code is valid and poses no challenge to a compiler.) It's not that it makes the compiler's life hard. It's the fact that conditional compilation relies on state that doesn't exist yet. It's messed up to be checking whether an object defines something when you're in the middle of defining that object. ... Declarations in D are declarative. There is no notion of state.
Re: Compilation failure
Timon Gehr: You are right; this is a bug. This discussion is not about an obscure language detail, it's a common situation. So if you think this is a bug, then please Timon file it in Bugzilla. Bye, bearophile
Re: Object Pointer
On Wednesday, July 18, 2012 20:37:50 Namespace wrote: Only for correctness: If i allocate memory on the GC Heap in e.g. a struct and don't free the memory in the DTor, then the GC free the memory automatically? You don't normally _ever_ free memory from the GC heap. That's the GC's job. That's what garbage collectors _do_. There are cases where it may be valuable to explicitly free GC memory for performance reasons, but it's risky and opens yourself up to the possibility of accessing freed memory and the like. That's one of the reasons why delete is being deprecated. So, no, you don't have to free GC allocated memory in a struct's destructor. The GC takes care of it. - Jonathan M Davis
Re: Compilation failure
On 07/19/2012 12:42 AM, bearophile wrote: Timon Gehr: You are right; this is a bug. This discussion is not about an obscure language detail, it's a common situation. FWIW, I have never run across it before. So if you think this is a bug, then please Timon file it in Bugzilla. Usually bugs are reported by the guy who finds them, but here you go: http://d.puremagic.com/issues/show_bug.cgi?id=8400
Re: ufcs and integer params
On 7/18/2012 5:30 AM, Adam D. Ruppe wrote: On Wednesday, 18 July 2012 at 11:37:43 UTC, David Nadlinger wrote: Arguments! Yay! I've gone over this a dozen times on the group and on bugzilla, and I'm kinda sick of repeating it. -property breaks craploads of code. That's a huge negative, and nobody has even come close to countering that. -property will be the standard is utterly worthless, yet that's really the only thing I see brought up again. The clear argument for me is that it must be trivial to take an existing member variable and change it to a property function pair _and vice versa_. If someone has @property int foo() and @property void foo(int) as members of a class and call sites add (), then yanking those back to just int foo; will fail, badly. So that must be explicitly disallowed. THAT is the argument for enforcing the lack of parens after properties, imho. The other bits about non-@property functions is significantly less important as far as I'm concerned. My 2 cents, Brad
Re: ufcs and integer params
On Thursday, 19 July 2012 at 02:57:05 UTC, Brad Roberts wrote: The clear argument for me is that it must be trivial to take an existing member variable and change it to a property function pair _and vice versa_. I can see some value in that. The other bits about non-@property functions is significantly less important as far as I'm concerned. Question to everybody: how would you feel about this compromise: the strictness is opt in. So, if you don't use @property, you get the status quo. These functions can be called either way, but if there's ambiguity, it tends toward treating them as a function. If you do use @property, it becomes strict. This would cover your concerns while keeping the dual-syntax benefits, and it minimizes code breakage of existing stuff. It'd also discourage a lot of the questions of to @property or not to @property, since you can just ask is it a real property without falsely marking stuff for UFCS chaining or whatever. It'd save me a lot of headaches on my range.empty's too. If we switch to this compromise position, I'm about 98% sure I'd vote yes (would have to actually try it to be certain).
