Quote:Original post by Aldacron D has had support for DLLs for several compiler versions now. Initially, the implementation required that each DLL have its own GC, but that has been remedied. I'm not sure where the shared library support stands on Linux right now, though.
OK, I am downloading the latest version now to see whether this can be made to work on a Mac ;)
Do you have any idea how they managed this? I mean that there was no way to make sure a function would be virtual, this was decided by the compiler.
Quote:Original post by swiftcoder OK, I am downloading the latest version now to see whether this can be made to work on a Mac ;)
DMD is only implemented on Windows and Linux. To compile D programs on Mac you will need GDC, an implementation built on top of GCC. GDC is usually a few versions behind DMD. I have no idea if it supports shared libraries. You can get precompiled binaries for the Mac at http://gdcmac.sourceforge.net/.
Quote:Do you have any idea how they managed this? I mean that there was no way to make sure a function would be virtual, this was decided by the compiler.
Sorry, I haven't a clue. I'm not at all interested in the internals of the compiler, though there are a lot of people who are, as evidenced by the NG posts. Perhaps if you ask in digitialmars.d you will get an informed answer. But I'm not quite sure what you mean about virtual functions. In D, all member methods are virtual by default, as in Java, and can be made non-virtual with the 'final' keyword. Inlining is decided by the compiler, but not virtualization.
Its like a summery documentation of all your classes and methods, instead of having to see the structure of the class with all the implementation inside, which is confusing. Because over information is usually bad, and you want to hide some information from yourself so you wont get confused.
Quote:Original post by Lode I too am disappointed in D because I hoped it would be an improved C++. But in fact it's an entirely new programming language, so many advantages of C++ are left out.
I'd like to see a programming language that is -C++ -without headers, and isntead an alternative way to link source files together -with you never needing to duplicate function declarations/definitions (this is part of the "remove header" plan) -with binary literals (0b01011101001) -with nested functions -with backwards compatibility to C removed -with an improved standard library, including standard libraries for simple graphics, GUI, audio, network, file management, mouse, realtime keyboard input, printing, terminal and multithreading -with easier support for making vectors pointers to a mix of parent and child classes with virtual functions, like pointer containers that automatically destroy objects, note that pointer containers aren't in the standard at the moment -with a programmer NEVER needing to use "new" and "delete", with all situations that could require the use of those having a replacement that auto-deletes (for example the vectors and pointer containers) -with binary literals -with a MUCH simpeler form to use iterators to elements of containers, I'm sorry but I dislike a variable type with a name like std::vector<int>::iterator, there has to be a better way to handle this, if needed make containers and iterators part of the language itself, for example the type int+ could be an iterator to containers of ints -with more operators that can be overloaded -with the ability to use the ` character instead of the " character for strings (I took this idea from D) -with array literals -without the inline keyword, it's not needed anymore -with certain undefined things defined, like some special operator orderings there are and cases with the % operator -with 64-bit integers, 128-bit integers, 128 floating point numbers (variable types that are defined to have at least that amount of bits) -with an extra modulo operator that will turn (-1 % 3) into 2 instead of -1 -with an extra division operator that will turn (-1 / 2) into -1 instead of 0 -with more logical names for variable types, a int with at least 32 bits is now called "long", what's longer than a long, a "long long", what's longer than a "long long"? a "long long long" or "super long"? This might bet pathetic in the future, a naming sheme of the form "sint16", "uint64", "float128", ... would be a better alternative -with UTF-8, UTF-16 and UTF-32 characters -with a variable type that is encouraged to be used to represent 8-bit bytes and that is unsigned, many people have had confusions with chars being used for files and them being signed -with "nan" and "inf" values being part of the language instead of part of the library -with fixed point types -...
It's all about the wheel.Never blindly trust technoligy.I love my internal organs.Real men don't shower.Quote:Original post by Toolmaker Quote:Original post by The C modest godHow is my improoved signature?It sucks, just like you.
Not sure if this is going to interest anyone, but I'd like to share my D story with fellow gamedevers.
When I first read an article about D, I realized that it had some very nice features and I liked some of its design ideas. But then I thought to myself "hey, C++ gives me everything already, I don't need a language that tries to be 1% better while having instability issues, small user base and poor standard library". So I dismissed it and for some time forgot about it.
Some time later, I was looking for a scripting language that could enhance some of my C++ programs. I asked around #gamedev and have been told to try Python. So I gave it a try and after some time, fell in love in the language as my brain was forced to expand beyond my little C++ world. In a very short time I realized that C++ wasn't so perfect as I thought it was and my previous "I love C++" statements became outdated. I programmed in Python for about a year and after some time I realized that C++ had some advantages I haven't been aware of before - static typing that is. I hated fixing errors at runtime. That and Python's poor relative runtime performance made me wish for a statically compiled, statilally typed language. Then at one time I magically recalled the D language. I decided to give it a try again.
I downloaded the D compiler, some basic IDE for it and started playing around. At first it seemed like a weird mix of Java, C++ and Python. It had C-like structs, Java-like classes, Python's easy way of dealing with strings, but also some weird C++-like templates. Initially I was quite lost when coding in it, I posted in the newsgroups asking about some C++ features that I couldn't find in D - I considered D to be flawed because it removed some of the C++ stuff that I got used to. Yet after some time, I got a better view of the language, I knew it wasn't just C++ with enhancements, it had its very own style, one in which the earlier problems seemed to dimnish - and the extra features, each of which were really tiny, when added up, made a huge difference to the programming experience.
When I was placing my very first steps in D, it still had inconsistent Unicode support, weak template system with an awkward instantiation system (literally, you had to use the 'instance' keyword) and it was generally quite messy. Yet with time, D's weaknesses started to fade away, as Walter kept adding new features and squashing bugs. For instance, now D's got better template metaprogramming support than C++; e.g. I've seen one thread today about a guy trying to use 'if' inside templates to control which fields would be instantiated. D's got just that - 'static if'. And it's got more - delegates, very neat builtin arrays with slicing, GC, foreach (that's a solution for easy iteration in containers), built-in associative arrays, Unicode strings, inner classes, nested functions, and so on.
To be fair - I've had moments when I wanted to screw D altogether. These were mainly back when the D compiler's version sill had two digits after the decimal point (now it.s 0.161). I've seen dozens of internal compiler errors and filled lots of bugreports on the newsgroups. But this is because, as one guy said... 'I rape the compiler'. I make it do things which I wouldn't dare to accomplish in C++. And D's got the power to make complex code - e.g. I've coded a library with functionality similar to Boost::bind - with function composition and all the whistles. I don't want to cheat anyone, if you play with D, expect seeing some undocumented behaviour and compiler problems. The thing is that these hardly ever are issues that make development impossible. And Walter has shown that he cares about commercial developers e.g. by sending them specially patched versions of the compiler before its official release.
How does D present itself for game development ? You won't find any engines waiting for you like you would in C++. There are a few being developed, but don't expect Unreal3. Yet if you're a developer willing to code that internals by yourself, some groundwork has already been done for you. D's got bindings to many game-related APIs. Aldacron's Derelict binds libs like OpenGL, OpenAL, DevIL, SDL, libvorbis and some more.
I haven't written very much gamedev-related code in D due to various RealWorld(tm) issues ( yeah, evolutional - I was supposed to show some cool 3d stuff ;) ). I've been working a bit on a simple game engine dubbed 'Heresy'. Eventually it turned out into a lame photon-mapping and GUI playground, but I've experimeted with other stuff as well (and I'm going to continue). Some (a bit outdated) info can be found here: http://codeinsane.info.tm/projects.spy If you wanted to check some D and do some GL stuff in it, I've got a site with instructions about how to set up Derelict and open a GL window thru SDL: http://dmedia.dprogramming.com/
Anyway, I've been coding in D for about 2.5f years now and I'm not going back to C++. D is highly addictive.
Quote:Original post by The C modest god Actually I think headers are really good.
They violate the principle of DRY, or Don't Repeat Yourself. Better to have documentation autogenerated from the implementation source with the function signatures and synopsis than to be forced to manually write header files.
I've fooled around with D before. I wrote a cute little scenegraph using the [forgot the name] OpenGL bindings. It wasn't half bad. I had two primary concerns though while working with it. One was that the language was still pretty young, and was subject to change. The other was that even though it is garbage collected and strings are nicer, I still felt like I was programming in C++. I hate C++. I prefer high-level, dynamic languages such as python (yay!) and more recently Boo, which is doing a pretty good job of approximating a dynamic language while staying compatible with the .NET cli.
One major plus to D however is that even though the default paradigm for instance destruction is non-deterministic, you can use the auto attribute to use RAII. I _hate_ .NET's method - IDisposable - which essentially forces you back into managing your resources manually.
Quote:Original post by kSquared There is absolutely nothing wrong with learning another language. Anyone who thinks that broadening your horizons is a bad thing needs a clue-by-four upside the head.
I'm not saying that, i'm saying he's not going truely learn something new since these languages are very very similar. The only way he will truely learn something new and actually broaden his view on problem solving is by learning languages based on completely different programming paradigms.
Quote:Original post by smr ... you can use the auto attribute to use RAII. I _hate_ .NET's method - IDispose - which essentially forces you back into managing your resources manually. Isn't that why we created garbage collectors in the first place?
I'm not agreeing and disagreeing with you but highlighting the fact that the dispose pattern is inspiried by the RAII idiom and i wouldn't be surprised if this auto attribute works exactly the same as C#'s using construct, which automatically invokes Dispose at the end of it's scope.
Quote:Original post by smr ... you can use the auto attribute to use RAII. I _hate_ .NET's method - IDispose - which essentially forces you back into managing your resources manually. Isn't that why we created garbage collectors in the first place?
I'm not agreeing and disagreeing with you but highlighting the fact that the dispose pattern is inspiried by the RAII idiom and i wouldn't be surprised if this auto attribute works exactly the same as C#'s using construct, which automatically invokes Dispose at the end of it's scope.
It is similar to using. My opinion is that using is a wart. First, "using" is does not indicate the keyword's intention at all, not to mention is the same keyword used to import a namespace. Secondly in order to use multiple RIAA resources in C# you have to NEST the using blocks. You can't simply give it a list of declarations.
I guess this isn't so bad... using(SomeClass x = new SomeClass()) using(SomeClass y = new SomeClass()) using(SomeClass z = new SomeClass()) { // do stuff }
But something like this is much better: auto SomeClass x = new SomeClass(); auto SomeClass y = new SomeClass(); auto SomeClass z = new SomeClass();
Quote:Original post by smr It is similar to using. My opinion is that using is a wart. First, "using" is does not indicate the keyword's intention at all, not to mention is the same keyword used to import a namespace. Secondly in order to use multiple RIAA resources in C# you have to NEST the using blocks. You can't simply give it a list of declarations.
Well i'm not disagreeing with, i only suggested it just in case you where unaware of it and where the pattern came from.
