Re: Properties don't work as expected
D is being used productively by some companies, so I guess we can call it production-ready. This doesn't meant there are not rough corners. The language is being actively developed, and I see that some work is being done on those rough corners. However, keep in mind that: 1) Maybe what you perceive as a strong deficiency isn't seen as a top priority for the D developers. This issue with properties, for instance, is annoying (I agree with you!), but most of the time (if not ever) it can be easily circumvented (as Satoshi has shown). 2) Sometimes, changing language features have subtle side effects, and the devs must take everything into account. A fix that looks obvious for us mere mortals can actually open a can of worms and introduce many new issues. Hope this answers your quesiton, LMB On Tue, Jul 5, 2016 at 10:14 AM, zodd via Digitalmars-d-learn < digitalmars-d-learn@puremagic.com> wrote: > On Tuesday, 5 July 2016 at 12:45:33 UTC, ketmar wrote: > >> Is there a chance, that this weird behavior will be fixed in the near >>> future? What can I do to help fix it? >>> >> >> almost as much as you can expect snowfall in hell. >> > > Why do you have so pessimistic opinion? Is D a perspective language to > learn or it's stagnating and never be production ready? >
Re: blog.dlang.org
Try http://dlang.org/blog/ But, indeed, I would expect blog.dlang.org to work... Cheers, LMB On Tue, Jun 21, 2016 at 6:47 PM, Christian Köstlin < digitalmars-d-learn@puremagic.com> wrote: > I just wanted to have a look at the new blog post about ldc, and entered > blog.dlang.org without thinking into the browser. > > This does not lead to the official blog anymore, but to the old > digitalmars website. > >
Re: OpenGL Setup?
I have been using Textadept ( http://foicica.com/textadept/ ) with Textadept-d ( https://github.com/Hackerpilot/textadept-d ). I use mostly on Linux for development, but I've recently spent two or three days on Windows and things worked well enough for me. (Coming for someone who has used Emacs for everything int he last 15+ years, this must mean something :-) ) Hope this helps, LMB On Fri, Jun 17, 2016 at 8:51 AM, OpenJelly via Digitalmars-d-learn < digitalmars-d-learn@puremagic.com> wrote: > On Thursday, 16 June 2016 at 19:52:58 UTC, OpenJelly wrote: > >> >> Trying to get VS Code to work with code-d... can't get dcd to work with > it. It says it's failed to kill the dcd server when I try to reload it. It > wasn't appearing in task manager (but dcd-client was) and manually starting > it up didn't make it work in vs code. Trying to restart it in cmd freezes > that window and the task refuses to kill. I'm trying to fix it now but I > don't even know why it's not working... > > The arsd stuff just gives me a thick list of internal errors when I try to > import it through dub. But I might almost have GLFW working... I can't > really tell yet, but I did finally find the right dll to link to (files in > the Windows x64 binaries kept giving me an error, but the one x64 dll in > the x86 download ended up working). > > Not keen to try vim if it doesn't have the features I need to compensate > for being a shitty programmer. >
Re: Coverage
I had one case these days in which I also had a lot of data to use in the
test. I was able to put the data as very large regular D arrays, but this
increased my compilation times a lot (not to mention the time to run the
unit tests).
I decided to enclose this specific unit test (including the `import
test_data` statement) in `version ExtraUnitTests { ... }`. This way, I can
run the bulk of my unit tests very frequently without wasting time with
this special case I want to run only sometimes.
I can't say I am 100% happy with this, but it worked for me and didn't
require any additional dependency.
LMB
On Tue, Feb 16, 2016 at 4:58 PM, Sebastiaan Koppe via Digitalmars-d-learn <
digitalmars-d-learn@puremagic.com> wrote:
> On Tuesday, 16 February 2016 at 12:35:38 UTC, Leandro Motta Barros wrote:
>
>> You probably already though of it, but: can't you create a unittest that
>> calls your code as many times as desired, passing different input each time?
>>
>
> That is a viable option yes. I will probably end up doing it like that.
>
> I don't like it though. Since the input is pretty big, it would need to be
> kept in an external file. And I don't like my unittests reading files. Plus
> they aren't really unittests either. Oh well. Moving on.
>
Re: Coverage
You probably already though of it, but: can't you create a unittest that calls your code as many times as desired, passing different input each time? LMB On Tue, Feb 16, 2016 at 10:16 AM, Sebastiaan Koppe via Digitalmars-d-learn < digitalmars-d-learn@puremagic.com> wrote: > I currently run dmd's coverage on my unittests. > > But now I also want to execute my program with different inputs and then > merge all that coverage info from each run. > > Any chance there is something for that? >
Re: Module-level attributes and unit tests
Thanks, this was helpful!
LMB
On Sat, Aug 23, 2014 at 1:22 PM, monarch_dodra via Digitalmars-d-learn <
digitalmars-d-learn@puremagic.com> wrote:
> On Saturday, 23 August 2014 at 15:26:02 UTC, Leandro Motta Barros via
> Digitalmars-d-learn wrote:
>
>> Hello,
>>
>> I have a module which is completelly @nogc, and as such I'd like to just
>> say
>>
>>@nogc:
>>
>> at the top of the file and be happy.
>>
>> However, my unit tests for this same module do some GC allocation, so the
>> module fails to compile.
>>
>> Is there a way to disable @nogc for the unit tests only? Would this be a
>> bad idea in some way I cannot see?
>>
>
> Nope. At best, you might be able to *declare* a function that is GC, but
> even then, you wouldn't be able to call it.
>
>
> I suppose the same question is valid for other attributes, like 'nothrow'
>> and '@safe'.
>>
>
> Actually, you can "undo" @safe with an explicit @system. nothrow (and
> pure) are in the same boat as @nogc
>
> Thank you,
>>
>> LMB
>>
>
> Solutions I can see would be to:
> a) Put your unittests in a separate module.
> b) Place your unittests before your "@nogc:"
> c) Instead of using "@nogc:", use "@nogc {}": This will make @nogc run
> until the end of the block.
>
Module-level attributes and unit tests
Hello, I have a module which is completelly @nogc, and as such I'd like to just say @nogc: at the top of the file and be happy. However, my unit tests for this same module do some GC allocation, so the module fails to compile. Is there a way to disable @nogc for the unit tests only? Would this be a bad idea in some way I cannot see? I suppose the same question is valid for other attributes, like 'nothrow' and '@safe'. Thank you, LMB
Re: pointer array?
Can't you call it directly?
extern(C)
{
int add (int a, int b)';
}
// ...
auto ret = add(123, 456);
LMB
On Wed, Jul 30, 2014 at 2:55 PM, seany via Digitalmars-d-learn <
digitalmars-d-learn@puremagic.com> wrote:
>
>
>> Can you post the signatures of some of the C functions you're trying to
>> interface with?
>>
>
> let us take a simple function :
>
> int add (int a, int b)
>
Re: pointer array?
Justin's answers seems correct to me, and I don't know anything about your specific use case, but I cannot resist to add: Think twice before doing this kind of things. I know that sometimes this is necessary or handy, but one of the great things about D is that it provides so many higher-level abstractions that we should feel ashamed to not use them. So, yes, an array of void* will work in D, as will many of the classic lower-level tricks used in, say, C. But when using them, the compiler will not be able to help you much finding errors and such. As rule I'd say that, if you can (and we usually can), try using something higher level. (In your case, perhaps an array of objects of some base class, or implementing a certain interface? Or some more radical redesign?) Cheers, LMB On Wed, Jul 30, 2014 at 11:33 AM, seany via Digitalmars-d-learn < digitalmars-d-learn@puremagic.com> wrote: > In Ali's excllent book, somehow one thing has escaped my attention, and > that it the mentioning of pointer arrays. > > Can pointers of any type of pointed variable be inserted in an int array? > Using to!(int) perhaps? If not directly, then what else would achieve the > same effect? >
Re: Any GPL video games in D2
Hi, Some time ago I wrote this Tetris-like game: https://bitbucket.org/lmb/anytris (also on GitHub: https://github.com/lmbarros/Anytris) Nothing fancy. I am sure there are better examples out there. And maybe this is not the best code to show to students ;-) Also, license is ZLib -- I assume it will be good for your purposes. LMB On Wed, Jun 25, 2014 at 11:24 AM, Binarydepth via Digitalmars-d-learn < digitalmars-d-learn@puremagic.com> wrote: > I would like to show D in "action" to other programmers/students. > > Anyone knows of a Video Game coded in D2 ? > > Thank you >
Re: package.d imports
Hi! I made similar questions here a month ago, but also couldn't get definitive answers. I just sent a message about this to the main D forum. Let's see if we have better luck there :-) Cheers, LMB On Fri, Jan 17, 2014 at 5:39 PM, Lemonfiend wrote: > I think this is what you are looking for: http://dlang.org/changelog. >> html#import_package >> > > What an odd place to put it.. > > Too bad, it doesn't mention anything about calling the functions like in > my example, and why some do/don't work. I'd hoped for more. > >
Re: package.d
On Wed, Dec 18, 2013 at 6:56 AM, Joseph Rushton Wakeling < joseph.wakel...@webdrake.net> wrote: > On 17/12/13 01:51, Leandro Motta Barros wrote: > >> I have some code using the old "all.d" idiom, which I am changing to use >> the new >> "package.d" feature. >> > > Related question -- it seems like rdmd doesn't like package-based code, > and can't resolve dependencies as it can with regular modules. Is there > any kind of timeframe/roadmap for fixing this? > With these simple examples I sent, rdmd seem to resolve dependecies correctly. For example, with this last example I sent (which prints the class name): $ rdmd main.d mylib.util.Foo $ dmd main.d main.o: In function `_Dmain': main.d:(.text._Dmain+0xb): undefined reference to `_D5mylib4util3Foo7__ClassZ' collect2: error: ld returned 1 exit status --- errorlevel 1 $ dmd main.d mylib/util.d $ ./main mylib.util.Foo In this case, at least, rdmd correctly resolved, compiled and linked mylib/util.d, which was imported through a package. LMB
Re: package.d
Here's another rather interesting case:
// mylib/util.d
module mylib.util;
class Foo { }
// mylib/package.d
module mylib;
public import mylib.util;
// main.d
import std.stdio;
import mylib;
void main()
{
auto f = new mylib.Foo;
writefln("%s", f.classinfo.name);
}
This prints 'mylib.util.Foo'. So far so good, that's the name I originally
expected.
Then I try to instantiate a 'Foo' using this very fully-qualified name the
compiler told me:
auto f = new mylib.util.Foo;
And DMD doesn't like it anymore:
main.d(6): Error: undefined identifier 'util'
main.d(6): Error: mylib.util.Foo is used as a type
Fishy, isn't it? Maybe I should report this as a bug?
Cheers,
LMB
On Wed, Dec 18, 2013 at 6:09 AM, Andrej Mitrovic wrote:
> On 12/17/13, Leandro Motta Barros wrote:
> > Is there any documentation describing the expected to behavior in regard
> to
> > the fully-qualified names of the publicly imported symbols in package.d?
>
> It might have been an oversight, but we'll have to wait for (I think
> Kenji) to reply since he implemented packages.
>
Re: package.d
Hello again,
Reading DIP 37 ( http://wiki.dlang.org/DIP37 ) shed some light on the
issue, I think.
The motivation for package.d was to allow the split of a large module into
a package. From this perspective, the difference between package.d and
all.d regarding the fully-qualified names seems to make sense. But then,
the same DIP 37 says that "[using package.d] is identical to what some
projects have been doing with *all.d*, where they have a
*foo/bar/all.d*which publicly imports all of the
*bar* package, except that this provides additional syntactic sugar for it."
Is there any documentation describing the expected to behavior in regard to
the fully-qualified names of the publicly imported symbols in package.d? (
http://dlang.org/module.html doesn't mention package imports;
http://dlang.org/changelog.html#import_package doesn't mention
fully-qualified names).
Thank again,
LMB
On Mon, Dec 16, 2013 at 10:51 PM, Leandro Motta Barros wrote:
> Hello,
>
> I have some code using the old "all.d" idiom, which I am changing to use
> the new "package.d" feature.
>
> Originally, I had something like this:
>
> // mylib/util.d:
> module mylib.util;
> class Foo { }
>
> // mylib/all.d:
> module mylib.all;
> public import mylib.util;
>
> // main.d:
> import mylib.all;
> void main()
> {
>auto f = new mylib.util.Foo;
> }
>
> And this used to work. Now, I added a new file:
>
> // package.d
> module mylib;
> public import mylib.util;
>
> And changed the 'import' in the main one:
>
> // main.d
> import mylib;
>
> void main()
> {
>auto f = new mylib.util.Foo;
> }
>
> Now, the compiler complains:
>
> main.d(5): Error: undefined identifier 'util'
> main.d(5): Error: mylib.util.Foo is used as a type
>
> Isn't this 'package.d' feature supposed to work just as the old 'all.d'
> and '_,d' we used before?
>
> (I see that I can use 'mylib.Foo' instead of 'mylib.util.Foo', but
> http://dlang.org/module.html is clear saying that "[a]ll symbols from a
> publicly imported module are also aliased in the importing module. This
> means that if module D imports module C, and module C *publicly* imports
> module B which has the symbol *bar*, in module D you can access the
> symbol via bar, B.bar, and C.bar.")
>
> I am using DMD 2.064 here.
>
> Thanks,
>
> LMB
>
>
package.d
Hello,
I have some code using the old "all.d" idiom, which I am changing to use
the new "package.d" feature.
Originally, I had something like this:
// mylib/util.d:
module mylib.util;
class Foo { }
// mylib/all.d:
module mylib.all;
public import mylib.util;
// main.d:
import mylib.all;
void main()
{
auto f = new mylib.util.Foo;
}
And this used to work. Now, I added a new file:
// package.d
module mylib;
public import mylib.util;
And changed the 'import' in the main one:
// main.d
import mylib;
void main()
{
auto f = new mylib.util.Foo;
}
Now, the compiler complains:
main.d(5): Error: undefined identifier 'util'
main.d(5): Error: mylib.util.Foo is used as a type
Isn't this 'package.d' feature supposed to work just as the old 'all.d' and
'_,d' we used before?
(I see that I can use 'mylib.Foo' instead of 'mylib.util.Foo', but
http://dlang.org/module.html is clear saying that "[a]ll symbols from a
publicly imported module are also aliased in the importing module. This
means that if module D imports module C, and module C *publicly* imports
module B which has the symbol *bar*, in module D you can access the symbol
via bar, B.bar, and C.bar.")
I am using DMD 2.064 here.
Thanks,
LMB
Re: TypeInfo.compare is not implemented
I am terribly sorry, this was a completely lazy question. So far, I couldn't reproduce the problem in a small example. I'll look deeper into this before posting again about it. LMB On Sat, Nov 30, 2013 at 12:07 PM, Shammah Chancellor wrote: > On 2013-11-30 13:39:15 +0000, Leandro Motta Barros said: > > Hello, >> >> I my FewDee game prototyping library (https://bitbucket.org/lmb/fewdee) >> I ignored most of the usual reccomendations like "be careful with the GC, >> it's slow" and "associative arrays are buggy in D, so avoid them". I just >> used whatever I found convenient to have my stuff running with minimal >> effort. >> >> So, I did something that may be an abuse of D's associative arrays: >> >> alias >> Tuple!(const(GameState), ALLEGRO_EVENT_TYPE) >> stateTypePair; >> >> // GameState is a class, ALLEGRO_EVENT_TYPE is >> // some integral data type >> >> EventHandler[EventHandlerID][stateTypePair] >>_eventHandlers; >> >> // EventHandler is a delegate. EventHandlerID is >> // an integral type. >> >> This used to work (surprisingly? :-) ) until very recently (when I >> upgraded to DMD 2.064, it seems). >> >> Now, I am getting this >> >>object.Error: TypeInfo.compare is not implemented >> >> when I try to use my '_eventHandlers' AA. >> >> So, any suggestions? >> >> Thanks a lot! >> >> LMB >> > > DMD version? Can you post a reduced example which produces the error. I > can't tell where a typeinfo would be getting used from that example. > > -Shammah > >
TypeInfo.compare is not implemented
Hello, I my FewDee game prototyping library (https://bitbucket.org/lmb/fewdee) I ignored most of the usual reccomendations like "be careful with the GC, it's slow" and "associative arrays are buggy in D, so avoid them". I just used whatever I found convenient to have my stuff running with minimal effort. So, I did something that may be an abuse of D's associative arrays: alias Tuple!(const(GameState), ALLEGRO_EVENT_TYPE) stateTypePair; // GameState is a class, ALLEGRO_EVENT_TYPE is // some integral data type EventHandler[EventHandlerID][stateTypePair] _eventHandlers; // EventHandler is a delegate. EventHandlerID is // an integral type. This used to work (surprisingly? :-) ) until very recently (when I upgraded to DMD 2.064, it seems). Now, I am getting this object.Error: TypeInfo.compare is not implemented when I try to use my '_eventHandlers' AA. So, any suggestions? Thanks a lot! LMB
Re: InExpression with custom type?
Thanks!
LMB
On Fri, Aug 23, 2013 at 4:59 PM, Namespace wrote:
> On Friday, 23 August 2013 at 19:57:42 UTC, Leandro Motta Barros wrote:
>
>> Hello!
>>
>> Is it possible to make an InExpression work with a used-defined type?
>>
>> struct MyCollection { ... }
>>
>> MyCollection mc;
>>
>> auto p = 123 in mc;
>> if (p) { ... }
>>
>> Thanks!
>>
>> LMB
>>
>
> Yes, use opBinaryRight:
>
> T* opBinaryRight(stirng op : "in")(...)
>
InExpression with custom type?
Hello!
Is it possible to make an InExpression work with a used-defined type?
struct MyCollection { ... }
MyCollection mc;
auto p = 123 in mc;
if (p) { ... }
Thanks!
LMB
Re: How to disable the DOS window at the start of my program on D
For Win32/OPTLINK, I passed the following flag to dmd in a lil' project of mine:
-L/SUBSYSTEM:WINDOWS:4.0
Worked for me.
LMB
On Wed, Jul 24, 2013 at 5:24 AM, Rikki Cattermole
wrote:
> On Wednesday, 24 July 2013 at 08:16:39 UTC, MGW wrote:
>>
>> On Wednesday, 24 July 2013 at 08:08:19 UTC, Rikki Cattermole wrote:
>>>
>>> version(Windows) {
>>>import core.sys.windows.windows : FreeConsole;
>>>FreeConsole();
>>> }
>>
>>
>> DOS window flashes at the start, and that's bad.
>
>
> Take a look at DLL def files. I believe from memory that they will help with
> that.
>
> For Microsofts linker (64bit) take a look at
> http://msdn.microsoft.com/en-us/library/vstudio/fcc1zstk.aspx and
> /SUBSYSTEM:Windows.
> For an example .def file (thats has been made for a dll but should work ok)
> look at http://dlang.org/dll.html at mydll.def.
>
> The later should work for both 64bit and 32bit I believe.
Re: Reference to D class instance with a C library
The documentation of GC.addRoot() (mentioned by Simen), contains this interesting piece of example code: // Also ensure that a moving collector does not relocate // the object. GC.setAttr(cast(void*)context, GC.BlkAttr.NO_MOVE); Looks like we *already* have the way to pin objects to their current memory location. (This compiles and is running without errors so far, though I didn't try to look if it is actually doing something under the hood -- which currently doesn't matter much, since the current GC doesn't move objects). (And yes, a GC.clrAttr() call does exist, too.) LMB On Sun, Jul 14, 2013 at 6:29 AM, Jacob Carlborg wrote: > On 2013-07-13 20:53, Leandro Motta Barros wrote: >> >> Hey, thanks! This makes sense :-) >> >> Am I now wondering... how safe, portable and future proof would this >> be? If some future version of D implements a garbage collector capable >> of moving objects around the heap, I could get in trouble, right? > > > Walter has always said that there's nothing in the language (D) that stops > it from having moveable GC. In this case we would hope there would be way to > pin objects. > > -- > /Jacob Carlborg
Re: Reference to D class instance with a C library
> Also note that if the pointer in C land is the only reference to the > class, the garbage collector will destroy the instance when it gets > around to it. Yup, I am aware of this. I mentioned that I can guarantee that my object will outlive the C struct... > There's a function GC.addRoot[1] in core.memory that can > make the C struct keep the reference alive. ...but this may be useful anyway! Thanks :-) LMB PS: The community is a big plus for D. I hope to give something back in the future :-)
Re: Reference to D class instance with a C library
Good. Thanks again! LMB On Sat, Jul 13, 2013 at 4:01 PM, Adam D. Ruppe wrote: > On Saturday, 13 July 2013 at 18:54:18 UTC, Leandro Motta Barros wrote: >> >> If some future version of D implements a garbage collector capable of >> moving objects around the heap, I could get in trouble, right? > > > Maybe, but I don't think D would do that because a lot of D code uses C > libraries. At the least, I'm sure it would offer a function to pin the > object so the gc doesn't move it.
Re: Reference to D class instance with a C library
Hey, thanks! This makes sense :-) Am I now wondering... how safe, portable and future proof would this be? If some future version of D implements a garbage collector capable of moving objects around the heap, I could get in trouble, right? LMB On Sat, Jul 13, 2013 at 3:35 PM, Adam D. Ruppe wrote: > On Saturday, 13 July 2013 at 18:30:24 UTC, Leandro Motta Barros wrote: >> >> So, is there some way to store a reference to a D class instance in that >> 'user_data' field? > > > Should be ok to cast the reference itself to that type - don't take the > address of it, since that would be the address of a local, but just cast it: > > MyObject foo = new MyObject(); > > c_struct.user_data = cast(intptr_t) foo; > > And when you get it back: > > foo = cast(MyObject) c_struct.user_data; > > > In D, MyObject is already basically a MyObject*, so if you did &foo, the > type would be more like MyObject** which is probably why you didn't have > luck doing it before.
Reference to D class instance with a C library
Hello,
TL;DR: Can I somehow store a reference to a D class instance in a
field of a struct from a C library I am using with my D code?
The long story:
I am writing some D code that uses a C library. This C library
provides an event handling mechanism in which events are represented
by (plain C) structs that look like this:
struct event
{
// ...lots of event stuff...
intptr_t user_data;
}
I would like to create an event struct that contains a reference to a
D class instance in that 'user_data' field.
As I understand (and from bad experiences in the past), object
references in D are not exactly the same thing as pointers, so I
cannot simply take the address of the class instance and stash it in
that 'user_data' field.
So, is there some way to store a reference to a D class instance in
that 'user_data' field? (I can guarantee that the D object will be
alive whenever that 'event' struct is used.)
Thanks!
LMB
Re: Finalizing GC
On Mon, Apr 1, 2013 at 1:45 PM, H. S. Teoh wrote:
> On Mon, Apr 01, 2013 at 01:07:56AM -0700, Jonathan M Davis wrote:
>> On Sunday, March 31, 2013 20:51:52 H. S. Teoh wrote:
>> > On Sun, Mar 31, 2013 at 06:29:21PM -0700, Jonathan M Davis wrote:
>> > [...]
> Seems to me like dtors should be removed from the language. Well, except
> struct dtors, which I believe do work when the struct goes out of scope?
I believe that destructors are also guaranteed to be called for "scope
classes" and "scope objects".
Anyway, I had the same feeling when I first learned that destructors
are not guaranteed to be called. I am still trying to find idioms to
do proper resource management in D when trying "class-heavy" designs.
BTW, I think that C# behaves similarly, so I guess these idioms do
exist.
("scope" statements are great when they can be used, and RefCounted
works for other cases, but they don't seem to solve all my problems.)
LMB
Re: Passing revision tag to the compiler
On Sun, Mar 31, 2013 at 10:09 AM, Tobias Pankrath wrote:
> On Sunday, 31 March 2013 at 02:00:46 UTC, Leandro Motta Barros wrote:
>>
>> Hello,
>>
>>
>> I'd like to include the version control revision tag in a program. In
>> the C/C++ world I'd make my build system call the compiler like this:
>>
>>g++ -D .
>>
>
> D has no preprocessor and no way to define global variables via a cmdline
> switch. The -version switch can be used conditionally compile in blocks of
> code but wont help you to "import" a value into your program. You can
> however use import expressions for this.
>
> See http://dlang.org/expression.html search import expression.
>
> ---
> immutable Revision = import("revision.data");
> ---
> And tell your VCS to always keep the revision in that file. DMD looks for
> imports in directories specified by the -J option.
Hello Tobias,
I have (miss)used import expressions before, but I forgot I could use them here.
Thanks a lot!
LMB
Passing revision tag to the compiler
Hello, I'd like to include the version control revision tag in a program. In the C/C++ world I'd make my build system call the compiler like this: g++ -D . so that the revision is available as a preprocessor symbol. Is there an easy way to achieve the same in D? I can think of convoluted solutions, like making the build system generate a .d file containing a constant with the revision tag, but I'd naturally prefer a simpler solution. I am using DMD, but a solution that works for other D compilers gets extra credit :-) Thanks! LMB
Re: Why is null lowercase?
Hi, In C, NULL is a #define, and #defines are typically all-caps. In D, null is real keyword recognized by the compiler, and those are typically lowercase. I am just guessing here, but I'd say the choice for 'null' instead of 'NULL' is just to be coherent with this. Personally, I kinda like 'null'. :-) LMB On Thu, Jan 24, 2013 at 10:56 AM, Matthew Caron wrote: > This is probably a question for Walter, but maybe others know. > > Of all of the differences between C and D, the one which I have the most > difficulty adapting to is null being lowercase. Does anyone know why this > decision was made? > -- > Matthew Caron, Software Build Engineer > Sixnet, a Red Lion business | www.sixnet.com > +1 (518) 877-5173 x138 office
Re: Global variables read at compile time?
Another option is to use "module constructors", as shown below. (But
somehow this all looks a bit fishy for me...)
LMB
import std.stdio;
string a = "a";
string b;
static this()
{
b = a;
}
void main()
{
writeln(b);
}
On Wed, Aug 15, 2012 at 11:03 AM, d_follower wrote:
> On Wednesday, 15 August 2012 at 13:36:26 UTC, Stefan wrote:
>>
>> Hi there, I'm having trouble getting the following code to compile:
>>
>> import std.stdio;
>>
>> string a = "a";
>> string b = a;// line 4
>>
>> void main()
>> {
>> writeln(b); // line 8
>>
>> }
>>
>> DMD spits out the error "test.d(4): Error: variable a cannot be read at
>> compile time". Is there any way to tell the compiler I want b evaluated at
>> runtime, or am I missing something obvious here?
>
>
> You must understand that your problem lies in line 4, not in line 8, i.e.
> the following doesn't work either:
>
>
> string a = "a";
> string b = a;
>
> I don't really know why, but it seems that you can only initialize globals
> with constants.
>
> What you could do is something like this (I guess):
>
> enum value = "a";
> string a = value;
> string b = value;
>
> void main()
> {
> writeln(b);
> b = "b";
> writeln(b);
> }
