Re: Running D in the Java VM
Am 22.11.2013 17:15, schrieb John Colvin: On Friday, 22 November 2013 at 13:36:08 UTC, Paulo Pinto wrote: I don't have any issue with Java and do like the language, but it has lost its place if you care about portable code across mobile platforms. Ironic, much? :p Sadly yes. There is hope with RoboVM, but that is community driven. Oracle seems more interested into pushing HTML5 frontends with Java running on the server side. Last year that made some PR announcements about Java support for iOS and Android. When what they actually had was an ADF web application! -- Paulo
Re: Programming in D book is about 95% translated
On Monday, 4 November 2013 at 18:22:03 UTC, Ali Çehreli wrote: On 11/04/2013 09:45 AM, Craig Dillabaugh wrote: do you have the book on GitHub or some such site where we can submit change requests to the text? This would be the best place: http://code.google.com/p/ddili/issues/list Unfortunately it is svn, not a distributed version control system. :-/ Perhaps you can put the diff in the issue tracker and I apply. I've seen some small grammar errors Thank you, Ali I made a copy of your repo in git if your interested. Preserved all of the history. https://github.com/mcginleyr1/ddili-read-only
Re: Mono-D v0.5.4.8 - DMD 2.064 Compatibility + Completion fixes
Alexander Bothe wrote: Hi everyone, I just released a new version of Mono-D which features quite all the new D magic that appeared in dmd 2.064 http://mono-d.alexanderbothe.com/dmd-2-064-compatibility-completion-fixes-v0-5-4-8/ Completion issues: https://github.com/aBothe/D_Parser/issues General/Other issues: https://github.com/aBothe/Mono-D/issues Gonna get some sleep now :) Cheers, Alex Mono-D rocks, as always! Thanks for everything! -- Dejan Lekic dejan.lekic (a) gmail.com http://dejan.lekic.org
bugzilla 'bounty' keyword added
To make it easy to see which bugs have bounties: https://d.puremagic.com/issues/buglist.cgi?keywords=bountyquery_format=advancedkeywords_type=allwordsbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENED
Re: Mono-D v0.5.4.8 - DMD 2.064 Compatibility + Completion fixes
On Sunday, 10 November 2013 at 04:31:20 UTC, Alexander Bothe wrote: I just released a new version of Mono-D which features quite all the new D magic that appeared in dmd 2.064 It's good, but what about stability? Last time that I try to use Mono-D it was completely broken. Probably, it's because you always support latest Mono Develop's version that contains a lot of bugs. So, I have to migrate to Eclipse/DDT even if it contains less functions.
Re: Mono-D v0.5.4.8 - DMD 2.064 Compatibility + Completion fixes
Am 24.11.2013 21:09, schrieb ilya-stromberg: On Sunday, 10 November 2013 at 04:31:20 UTC, Alexander Bothe wrote: I just released a new version of Mono-D which features quite all the new D magic that appeared in dmd 2.064 It's good, but what about stability? Last time that I try to use Mono-D it was completely broken. Probably, it's because you always support latest Mono Develop's version that contains a lot of bugs. So, I have to migrate to Eclipse/DDT even if it contains less functions. On my case, I tend to see Alex's and Xamarin update channels offering the same plugin, which doesn't make Mono Develop too happy on my system. My main issue is that intelisense only works when it feels like it. -- Paulo
Re: Mono-D v0.5.4.8 - DMD 2.064 Compatibility + Completion fixes
Am 10.11.2013 05:31, schrieb Alexander Bothe: Hi everyone, I just released a new version of Mono-D which features quite all the new D magic that appeared in dmd 2.064 http://mono-d.alexanderbothe.com/dmd-2-064-compatibility-completion-fixes-v0-5-4-8/ Completion issues: https://github.com/aBothe/D_Parser/issues General/Other issues: https://github.com/aBothe/Mono-D/issues Gonna get some sleep now :) Cheers, Alex Many thanks for your work. -- Paulo
Re: bugzilla 'bounty' keyword added
On Sunday, 24 November 2013 at 19:51:48 UTC, Walter Bright wrote: To make it easy to see which bugs have bounties: https://d.puremagic.com/issues/buglist.cgi?keywords=bountyquery_format=advancedkeywords_type=allwordsbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENED I'm waiting for someone to close issue 1832. So I can claim my bounty! :)
Re: typedef, Typedef
24-Nov-2013 00:55, bearophile пишет: This works if you compile with the -d switch: Can this situation be fixed/improved? Use an alias? -- Dmitry Olshansky
Re: dmd-concurrency
On 2013-11-20 07:34:36 +, Chris Williams said:
On Wednesday, 20 November 2013 at 04:24:14 UTC, Daniel Murphy wrote:
This is the correct forum to post phobos proposals on.
Well then, here's what I had written:
A few applications I've considered implementing seem like they would be
easier if there was a channel-based messaging system in
std.concurrency. I'm happy to do this implementation, but I thought I
would try to get some sort of sign-off before doing so. Following, I
will lay out my argument for the addition, and then the API that I am
considering.
---
One fairly common task is thread-pooling. With the standard
send/receive model currently implemented, you have to choose a specific
thread to target when you send a task. While it's true that you can
simply iterate through your list of threads over and over, to spread
the load evenly over them, that presumes that all tasks take even
processing time. It makes more sense to be able to push data into a
shared channel (secretly a work queue), and the first thread that
finishes its previous task will be able to immediately pull the task
before everyone else. This also means that the necessity of passing
around references to your threads so that they can be looped over goes
away.
I haven't tested it, but it looks like this sort of thing might be
quasi-possible using the register/unregister/locate methods. As each
thread starts, it can register itself with a named group (i.e.
channel), and then anyone who wants to send an item to an arbitrary
thread in that group can call locate() to retrieve one thread and call
send() against the Tid. The target thread would then need to unregister
itself while it is doing work, then re-register itself. My complaint
against this is the need to unregister and re-register. If the thread
issuing commands sends a large number of tasks all at once, they will
all go to the same thread (if coded poorly) or the caller will need to
use yield() or sleep() to allow the target thread to receive the task
and unregister, so that locate() can find a different thread. That's
not terribly efficient. I am also concerned that there's the chance
that all threads will be unregistered when we call locate(), whereas a
channeling system would be able to expand the mailbox during the times
that all threads are busy.
The actual implementation within concurrency.d also concerns me as (if
I read it correctly), the most recent item to register() will be the
one which locate() finds, rather than the thread which has been
registered the longest. While I suppose it's probably not too large of
an issue if the same two threads keep taking all the tasks - that means
that your load can't exceed two threads worth of processing power - it
still seems like a LIFO system would be better. The registry is also
based on an array rather than a set, which can make removal an O(n)
operation, if the contents of the registry have to be shifted left, to
fill an empty spot.
Overall, I think that adding a shared message box system would be a
straightforward way to improve the handling of thread pooling via the
actor model.
---
A less common use-case but I was also considering some world-simulators
(e.g. for studying economics or building a game map) and here the
ability to broadcast messages to a large set of other actors, based on
location, interest, etc. seems useful. In this case, messages would
need to be copied out to each subscriber in the channel rather than
having an existence as a point to point connection. For a networked
game, most likely you would want to break each channel into two, where
locally all senders on a channel push to a single listener that pipes
the messages over the network, and then remotely the messages would be
broadcast to many listeners again, but that's a reasonably
straightforward task for someone to implement on top of the channel
functionality. I don't think that such functionality is needed in
Phobos itself. Mostly, the presence of the broadcasting functionality
in the standard library allows them to use the easy and safe actor
model for more creative uses than a straight one-to-one pipe.
---
Overall, my hope would be to develop something that is conceptually no
more difficult to deal with than the current send()/receive() model,
but also able to be used in a wide variety of ways. The API that I
would propose to develop is:
interface Channel {
void send(T...)(T vals);
void prioritySend(T...)(T vals);
void receive(T...)(out Tid sender, T ops);
receiveOnlyRet!(T) receiveOnly(T...)();
bool receiveTimeout(T...)(Duration d, T ops);
void setMaxMailboxSize(Tid tid, size_t messages, OnCrowding doThis);
void setMaxMailboxSize(Tid tid, size_t messages, bool function(Tid)
doThisFunc);
}
class SingleChannel : Channel {} // Send inserts a message into a
shared message box. Receive removes message
class
Re: D vs Go in real life
On 11/22/13 1:49 PM, Max Samukha wrote: On Wednesday, 6 November 2013 at 19:42:21 UTC, Andrei Alexandrescu wrote: Go's team was unable to add generics to the language. Not adding generics was Go's deliberate decision. http://golang.org/doc/faq#generics We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it. For that matter, D got its type system all wrong compared to Haskell. So why won't we all move there? Move where? Andrei
Re: dmd-concurrency
On Friday, 22 November 2013 at 22:35:47 UTC, Shammah Chancellor wrote: On 2013-11-22 22:34:19 +, Shammah Chancellor said: Edit, I see that you have receiveAll.. I didn't notice that. However, that still doesn't satisfy the problem when you want to do receive() for your Tid, and receiveAll() from your channels. receiveAll() could pull from the thread's personal message box as well as all of its subscribed channels, so that it truly was a receive ALL. My thoughts for reasons to avoid that, however, are: 1. Threads always have their own message box allocated - even if it's empty - whereas with channels, at most you only have as many message boxes as you subscribed to. So my thinking was that if people are unlikely to mix channels-based systems and direct-sends in the same application, then every call to receiveAll() is having to spend an extra cycle checking the direct-send message box. 2. Since a Channel is just an interface, the implementation of which can vary, anyone who wanted to implement a NetworkedDuplicateChannel() class would be able to do so and pass it into a module that only includes std.concurency. This allows the actual implementation of any given channel to behave completely different from one another and quickly port code from one type to the other. send()/receive() are just innate to threads, however, and can't be replaced except by changing the import in each file to something else. Knowing that and also knowing that any direct-messaging system would probably be built like a channel (so that it had a constructor/init function where an IP and port could be configured, and perhaps an explicit startListening() method to call), I don't see anyone trying to override send()/receive() as their method for receiving direct messages over the network. They would still use the Channel interface, so there's not much value in trying to tie the two together.
Re: dmd-concurrency
On 2013-11-22 22:34:19 +, Shammah Chancellor said: How does one receive from multiple channels out-of-order? I would rather this sent it to the subscribed Tid via send, rather than having an additional queue. It could possible send a ChannelMessage which has a reference to the sending channel and the message. I understand this is a different model than what Go and whatnot use, but I think it's more pratical in some circumstances. Maybe both ways would be good? I personally use this method in my vibe-d server. Edit, I see that you have receiveAll.. I didn't notice that. However, that still doesn't satisfy the problem when you want to do receive() for your Tid, and receiveAll() from your channels.
Re: typedef, Typedef
Dmitry Olshansky: Use an alias? Don't be silly, please :) Bye, bearophile
Re: Function sets as definable type
On Saturday, 23 November 2013 at 20:49:00 UTC, Xinok wrote: On Saturday, 23 November 2013 at 18:41:23 UTC, Xinok wrote: ... Consider internally, such a type would be a set of two or more functions / delegates. Internally, this is exactly what interfaces are as well. Actually, could somebody elaborate on this for me please? With a little more thought, I realize that I'm probably wrong about this. This is doable as library now, with a struct, opDispatch and compile time reflection.
Re: D vs Go in real life
On Friday, 22 November 2013 at 15:52:31 UTC, Andrei Alexandrescu wrote: Ary Borenszweig a...@esperanto.org.ar wrote: On 11/21/13 6:36 PM, Andrei Alexandrescu wrote: On 11/21/13 1:16 PM, Gary Willoughby wrote: On Thursday, 21 November 2013 at 16:23:07 UTC, Andrei Alexandrescu wrote: Fortunately a lot has changed since :o). Please, do tell. ;) Not much that people don't know already. We have one solid D project installed and a couple of heavy-hitting engineers have started using D for scripts and tools (e.g. replacing Python for a 2x speedup for the same source code size/complexity). I would have expected a lot more speedup than just 2x, D being a compiled language. Amdahl's law. Andrei BTW, D needs a multithreading example here: http://saml.rilspace.org/moar-languagez-gc-content-in-python-d-fpc-c-and-c
Why is it that no one writes with portability in mind in druntime?
https://github.com/D-Programming-Language/druntime/pull/663
Initializing two-dimensional compile-time enum
Greetings! I have a problem in my code and I need an advice. I
need possibility of creating two-dimensional AA in module scope
that I can access at compile-time. I considered that it should be
marked as enum to do this but I get strange error. There is a
piece of code to test.
//---
import std.stdio;
enum string[int][string] pohodEnumValues = [
vid: [ 3: skiing, 5: rafting, 7: jumping ],
ks: [ 1: first, 2: second, 3: third ],
prepare: [ 1:planning, 3:preparing, 5:complete ]
];
void main()
{
writeln(pohodEnumValues);
}
//END OF CODE -
In dmd 2.064.2 I get following output:
Compilation output:
/d521/f517.d(4): Error: not an associative array initializer
Elements of AA are used as template arguments so I need them at
compile-time. I need help, please))
Re: Initializing two-dimensional compile-time enum
Compiling following code makes another strange error message.
import std.stdio;
enum string[int][string] pohodEnumValues = [
vid: [ 3: skiing, 5: rafting, 7: jumping ].dup,
ks: [ 1: first, 2: second, 3: third ].dup,
prepare: [ 1:planning, 3:preparing, 5:complete ].dup
];
void main()
{
writeln(pohodEnumValues);
}
//---
Compilation output:
/opt/compilers/dmd2/include/object.di(435): Error: _aaApply2
cannot be interpreted at compile time, because it has no
available source code
/opt/compilers/dmd2/include/object.di(458):called from
here: this.opApply(delegate int(ref int __applyArg0, ref string
__applyArg1) = 0)
/d895/f161.d(5):called from here: [3:skiing,
5:rafting, 7:jumping].dup()
Need help making minimal bare metal ARM Cortex-M D program
I am very new to D, but I finally got my toolchain compiled and
working. I'm using LDC. I failed with GDC and eventually gave
up.
I am trying to get an _extremely_ minimal bare metal ARM Cortex-M
HelloWorld-type program compiled and executed on my STM32F4-based
hardware. I know the toochain is buggy for arm right now, but
I'm hoping I can do something about that if I can just get
started.
Here's the basic C code and linker script for my hardware. It
doesn't actually print hello world. I intend to add that after
I get the following basic code compiled and downloaded to my
hardware.
/***
* start.c
/
// defined in linker script
extern unsigned long _stack_end;
void handler_reset(void)
{
//Print hello world using SWI
}
__attribute__ ((section(.interrupt_vector)))
void (* const table_interrupt_vector[])(void) =
{
(void *) _stack_end,
handler_reset
};
/***
* linkerscript.ld
/
MEMORY
{
CCRAM(rxw) : ORIGIN = 0x1000, LENGTH = 64k
SRAM (rxw) : ORIGIN = 0x2000, LENGTH = 128k
FLASH(rx) : ORIGIN = 0x0800, LENGTH = 1024k
}
SECTIONS
{
.ccm (NOLOAD) :
{
. = ALIGN(4);
*(.ccm)
. = ALIGN(4);
} CCRAM
stackTop = ORIGIN(CCRAM) + LENGTH(CCRAM);
Re: Need help making minimal bare metal ARM Cortex-M D program
On Sunday, 24 November 2013 at 12:43:01 UTC, Mike wrote: I am very new to D, but I finally got my toolchain compiled and working. I'm using LDC. I failed with GDC and eventually gave up. I know Johannes has some patches yet to trickle down into gdc. And druntime is does not support ARM fully in 2.063, but it would be helpful if you could take some time to let people know what went wrong when you tried things, rather than just giving up. Otherwise, nothing will get fixed.
Re: Need help making minimal bare metal ARM Cortex-M D program
On Sunday, 24 November 2013 at 12:45:19 UTC, Mike wrote: Please delete this thread. I hit a tab and a space while typing my code, resulting in a premature submit. I will make a separate complete post. Sorry, Mike This is a mailing list, not a forum. We can't delete things here. :o)
Need help making minimal bare metal ARM Cortex-M D program
I am very new to D, but I finally got my toolchain compiled and
working. I'm using LDC. I failed with GDC and eventually gave
up.
I am trying to get an _extremely_ minimal bare metal ARM Cortex-M
HelloWorld-type program (no phobos, no runtime, nothing but what
I type myself) compiled and executed on my STM32F4-based
hardware. I know the toolchain is buggy for arm right now, but
I'm hoping I can do something about that if I can just get
started.
Here's the basic C code and linker script for my hardware. It
doesn't actually print hello world. I intend to add that after
I get the following code compiled and downloaded to my hardware.
/***
* start.c
/
// defined in linker script
extern unsigned long _stack_end;
void handler_reset(void)
{
//Print hello world using SWI
}
__attribute__ ((section(.interrupt_vector)))
void (* const table_interrupt_vector[])(void) =
{
(void *) _stack_end,
handler_reset
};
/***
* linkerscript.ld
/
MEMORY
{
CCRAM(rxw) : ORIGIN = 0x1000, LENGTH = 64k
SRAM (rxw) : ORIGIN = 0x2000, LENGTH = 128k
FLASH(rx) : ORIGIN = 0x0800, LENGTH = 1024k
}
_stack_end = ORIGIN(CCRAM) + LENGTH(CCRAM);
SECTIONS
{
.isr_vector :
{
. = ALIGN(4);
KEEP(*(.isr_vector))
. = ALIGN(4);
} FLASH
.text :
{
. = ALIGN(4);
KEEP(*(.interrupt_vector))
*(.text)
*(.text*)
*(.rodata)
*(.rodata*)
. = ALIGN(4);
} flash
}
Can anyone out them tell me if/how this can be accomplished in D?
Is there some syntax equivalent to __attribute__
((section(.interrupt_vector)))?
Would the following give me a minimal reset_handler?
// compile with: ldc2 -c -nodefaultlib -noruntime
module reset_handler;
extern(C) __gshared void * _Dmodule_ref;
extern(C) void reset_handler()
{ }
I've seen some examples out on the web, but they all either use
C, or are written specifically for an x86/x86_64 platform. So
any help you could provide would be great to help me get started.
Re: Need help making minimal bare metal ARM Cortex-M D program
On Sunday, 24 November 2013 at 12:53:42 UTC, Iain Buclaw wrote: On Sunday, 24 November 2013 at 12:43:01 UTC, Mike wrote: I am very new to D, but I finally got my toolchain compiled and working. I'm using LDC. I failed with GDC and eventually gave up. I know Johannes has some patches yet to trickle down into gdc. And druntime is does not support ARM fully in 2.063, but it would be helpful if you could take some time to let people know what went wrong when you tried things, rather than just giving up. Otherwise, nothing will get fixed. I don't think the problems I encountered with GDC were the fault of GDC. They were my fault. I have more to learn about the Linux platform. It seems the GCC toolchain is highly dependent on the host platform and if things aren't set up just right, you get errors that have nothing to do with the actual problem. Also, when I tried to follow the crosstools instructions here (http://wiki.dlang.org/GDC/Cross_Compiler) I found that the latest crosstools was missing some of the options that are needed. I have been quite successful using the GNU Tools for ARM Embedded Processors here (https://launchpad.net/gcc-arm-embedded), and I hope to merge this with the GDC code and give it another try. I tried it this weekend, but I wasn't even able to get the shell scripts to run without errors. And, I didn't JUST give up. I worked on it all weekend, every weekend, for the past 3 weeks. I'm tired of the platform dependencies, and I'm anxious to just get started. Once I get more familiar with D and have some working code, I'll give GDC another try.
Re: Need help making minimal bare metal ARM Cortex-M D program
On Sunday, 24 November 2013 at 13:00:39 UTC, Mike wrote: Is there some syntax equivalent to __attribute__ ((section(.interrupt_vector)))? There isn't right now, but it would be entirely feasible to implement this in an LDC-specific extension. Could you open an issue on our GitHub tracker? David
DMD can implicitly convert class pointer to the bool. Is it bug or terrible feature?
Code examle:
import std.stdio;
class Foo
{
}
void main()
{
Foo f;
if(f)
{
writeln(f is true);
}
else
{
writeln(f is false);
}
f = new Foo();
if(f)
{
writeln(f is true);
}
else
{
writeln(f is false);
}
}
Programm output:
f is false
f is true
So, pointer implicitly converts to false if pointer is null and
to true if pointer is not null. Is it bug or terrible feature?
Note that we have `f is null` syntax for these cases.
Re: Initializing two-dimensional compile-time enum
Geez, I just spent 15' trying to make this work! AA + Compile-time are
like oil and water.
You can use CTFE and an initializing function. It's a bit cumbersome,
but it works.
module main;
import std.stdio;
string[int][string] initializePohod()
{
string[int][string] result;
result[vid] = [ 3: skiing, 5: rafting, 7: jumping ];
result[ks] = [ 1: first, 2: second, 3: third ];
result[prepare] = [ 1:planning, 3:preparing, 5:complete ];
return result;
}
enum string[int][string] pohodEnumValues = initializePohod();
void main()
{
writeln(pohodEnumValues);
pragma(msg, pohodEnumValues); // there, accessible during compilation.
}
On Sun, Nov 24, 2013 at 1:01 PM, Uranuz neura...@gmail.com wrote:
Greetings! I have a problem in my code and I need an advice. I need
possibility of creating two-dimensional AA in module scope that I can
access at compile-time. I considered that it should be marked as enum to do
this but I get strange error. There is a piece of code to test.
//---
import std.stdio;
enum string[int][string] pohodEnumValues = [
vid: [ 3: skiing, 5: rafting, 7: jumping ],
ks: [ 1: first, 2: second, 3: third ],
prepare: [ 1:planning, 3:preparing, 5:complete ]
];
void main()
{
writeln(pohodEnumValues);
}
//END OF CODE -
In dmd 2.064.2 I get following output:
Compilation output:
/d521/f517.d(4): Error: not an associative array initializer
Elements of AA are used as template arguments so I need them at
compile-time. I need help, please))
Re: DMD can implicitly convert class pointer to the bool. Is it bug or terrible feature?
On Sunday, 24 November 2013 at 13:49:25 UTC, ilya-stromberg wrote: So, pointer implicitly converts to false if pointer is null and to true if pointer is not null. Is it bug or terrible feature? Note that we have `f is null` syntax for these cases. This is neither bug not a terribale feature. Have you coded in C?
Re: DMD can implicitly convert class pointer to the bool. Is it bug or terrible feature?
On Sunday, 24 November 2013 at 13:57:22 UTC, Maxim Fomin wrote: This is neither bug not a terribale feature. Have you coded in C? Yes, only a little. I like D because it dissallow most of dangerous abbilities. We already have `is` operator for pointer comparison. Class doesn't provide cast to bool. So, why it's allowed?
Re: Need help making minimal bare metal ARM Cortex-M D program
On Sunday, 24 November 2013 at 13:30:10 UTC, David Nadlinger wrote: On Sunday, 24 November 2013 at 13:00:39 UTC, Mike wrote: Is there some syntax equivalent to __attribute__ ((section(.interrupt_vector)))? There isn't right now, but it would be entirely feasible to implement this in an LDC-specific extension. Could you open an issue on our GitHub tracker? David https://github.com/ldc-developers/ldc/issues/547
Re: DMD can implicitly convert class pointer to the bool. Is it bug or terrible feature?
On Sunday, 24 November 2013 at 14:02:43 UTC, ilya-stromberg wrote: On Sunday, 24 November 2013 at 13:57:22 UTC, Maxim Fomin wrote: This is neither bug not a terribale feature. Have you coded in C? Yes, only a little. I like D because it dissallow most of dangerous abbilities. We already have `is` operator for pointer comparison. Class doesn't provide cast to bool. So, why it's allowed? void* ptr; if(ptr) was a shortcut for 'if(ptr != NULL)' probably since C was created. There is no problem with classes or pointers convertion to booleans in condition statements, it is not a dangerous ability. Is operator is not restricted to pointer comparison, you can use it to bitwise compare any objects.
Re: DMD can implicitly convert class pointer to the bool. Is it bug or terrible feature?
So, pointer implicitly converts to false if pointer is null and to true if pointer is not null. Is it bug or terrible feature? Note that we have `f is null` syntax for these cases. Not exactly. It is all about if condition. AFAIK, D defines that condition `if(X)` get re-written to `if(cast(bool)X)` before semantic pass. So it is kind of implicit explicit conversion :)
Re: DMD can implicitly convert class pointer to the bool. Is it bug or terrible feature?
Maxim Fomin: This is neither bug not a terribale feature. I think the implicit question of ilya-stromberg was: how much bug-prone is this language feature? Bye, bearophile
Re: DMD can implicitly convert class pointer to the bool. Is it bug or terrible feature?
On Sunday, 24 November 2013 at 14:12:18 UTC, Maxim Fomin wrote:
void* ptr;
if(ptr)
was a shortcut for 'if(ptr != NULL)' probably since C was
created.
Small code change:
import std.stdio;
class Foo
{
}
void main()
{
Foo f;
if(f == null)
{
writeln(f is true);
}
if(f != null)
{
writeln(f is false);
}
}
DMD output:
Error: use 'is' instead of '==' when comparing with null
Error: use '!is' instead of '!=' when comparing with null
So, C style 'if(ptr != NULL)' isn't allowed in D.
Re: Need help making minimal bare metal ARM Cortex-M D program
Am Sun, 24 Nov 2013 14:19:43 +0100 schrieb Mike n...@none.com: On Sunday, 24 November 2013 at 12:53:42 UTC, Iain Buclaw wrote: On Sunday, 24 November 2013 at 12:43:01 UTC, Mike wrote: I am very new to D, but I finally got my toolchain compiled and working. I'm using LDC. I failed with GDC and eventually gave up. I know Johannes has some patches yet to trickle down into gdc. And druntime is does not support ARM fully in 2.063, but it would be helpful if you could take some time to let people know what went wrong when you tried things, rather than just giving up. Otherwise, nothing will get fixed. Cortex-M is the 'bare metal' branch of ARM where you usually don't run linux so druntime won't work anyway. There are some compiler fixes in my branch that could be interesting though: https://github.com/jpf91/GDC/commits/arm BTW: I'll start merging back the fixes to gdc master this week. Some fixes have to be merged into phobos upstream though so it might take some time. I don't think the problems I encountered with GDC were the fault of GDC. They were my fault. I have more to learn about the Linux platform. It seems the GCC toolchain is highly dependent on the host platform and if things aren't set up just right, you get errors that have nothing to do with the actual problem. Also, when I tried to follow the crosstools instructions here (http://wiki.dlang.org/GDC/Cross_Compiler) I found that the latest crosstools was missing some of the options that are needed. You mean options for bare metal builds or options described in the wiki? I'm not sure if crosstool-NG works well with bare metal builds. I have been quite successful using the GNU Tools for ARM Embedded Processors here (https://launchpad.net/gcc-arm-embedded), and I hope to merge this with the GDC code and give it another try. I tried it this weekend, but I wasn't even able to get the shell scripts to run without errors. And, I didn't JUST give up. I worked on it all weekend, every weekend, for the past 3 weeks. I'm tired of the platform dependencies, and I'm anxious to just get started. Once I get more familiar with D and have some working code, I'll give GDC another try. GCC build scripts can be annoying, especially when cross-compiling. Your best bet is still crosstool-NG though, what exactly are the missing options?
Re: DMD can implicitly convert class pointer to the bool. Is it bug or terrible feature?
On Sunday, 24 November 2013 at 14:17:50 UTC, Dicebot wrote: Not exactly. It is all about if condition. AFAIK, D defines that condition `if(X)` get re-written to `if(cast(bool)X)` before semantic pass. So it is kind of implicit explicit conversion :) Not exactly. Code: bool b = f; DMD output: Error: cannot implicitly convert expression (f) of type Foo to bool But code: bool b = !f; compiles.
Re: DMD can implicitly convert class pointer to the bool. Is it bug or terrible feature?
On Sunday, 24 November 2013 at 14:18:50 UTC, ilya-stromberg wrote:
On Sunday, 24 November 2013 at 14:12:18 UTC, Maxim Fomin wrote:
void* ptr;
if(ptr)
was a shortcut for 'if(ptr != NULL)' probably since C was
created.
Small code change:
import std.stdio;
class Foo
{
}
void main()
{
Foo f;
if(f == null)
{
writeln(f is true);
}
if(f != null)
{
writeln(f is false);
}
}
DMD output:
Error: use 'is' instead of '==' when comparing with null
Error: use '!is' instead of '!=' when comparing with null
So, C style 'if(ptr != NULL)' isn't allowed in D.
Yes, because D is separate language, and its comparison operator
does something special when operands are class references. This
is not the same story as in 'if(f)' which is purely bitwise
comparison.
I think your question is more appropriate for d.learn.
Re: DMD can implicitly convert class pointer to the bool. Is it bug or terrible feature?
On Sunday, 24 November 2013 at 14:16:39 UTC, bearophile wrote: Maxim Fomin: This is neither bug not a terribale feature. I think the implicit question of ilya-stromberg was: how much bug-prone is this language feature? Bye, bearophile OK. What are the problems with converting class references to true when they are not null and false when they are null?
Re: DMD can implicitly convert class pointer to the bool. Is it bug or terrible feature?
On Sunday, 24 November 2013 at 14:16:39 UTC, bearophile wrote:
Maxim Fomin:
This is neither bug not a terribale feature.
I think the implicit question of ilya-stromberg was: how much
bug-prone is this language feature?
Yes, exactly. I personally was VERY surprised. My code example
from real life:
class Foo
{
}
class Bar
{
Foo f;
void bar()
{
//variable was wrongly commented here
//bool f = true;
if(f)
{
//Oops!
}
}
}
Re: Need help making minimal bare metal ARM Cortex-M D program
On Sunday, 24 November 2013 at 14:21:57 UTC, Johannes Pfau wrote: Cortex-M is the 'bare metal' branch of ARM where you usually don't run linux so druntime won't work anyway. There are some compiler fixes in my branch that could be interesting though: https://github.com/jpf91/GDC/commits/arm I'm aware of the druntime will not work, which is why I'm trying to find a way to write and compile code _without_ the druntime or phobos. See my re-post. Also, when I tried to follow the crosstools instructions here (http://wiki.dlang.org/GDC/Cross_Compiler) I found that the latest crosstools was missing some of the options that are needed. You mean options for bare metal builds or options described in the wiki? I'm not sure if crosstool-NG works well with bare metal builds. GCC build scripts can be annoying, especially when cross-compiling. Your best bet is still crosstool-NG though, what exactly are the missing options? A couple of the options don't seem to exist in crosstools. Specifically Go to C compiler, select Other languages and enter d. Pretty hard to tell the compiler to support D without this option. The GNU Tools for ARM scripts are specifically written for cross-compiling, and even Canadian cross compiling. When I run the build scripts, I get: cat ~/mylongdir/src/gcc/gcc/BASE-VER: No such file or directory. I looked through the shell script, but code like this GCC_VER=`cat $SRCDIR/$GCC/gcc/BASE-VER` GCC_VER_NAME=`echo $GCC_VER | cut -d'.' -f1,2 | sed -e 's/\./_/g'` is a little hard for me to figure out. Again, the problem here is not with GDC; it's that I don't know enough about the Linux tools to know what its trying to do here and what I can do about it. LLVM, clang, and LDC built on the first try after 3 weekends struggling with GCC.
Re: DMD can implicitly convert class pointer to the bool. Is it bug or terrible feature?
On Sunday, 24 November 2013 at 14:24:09 UTC, ilya-stromberg wrote: On Sunday, 24 November 2013 at 14:17:50 UTC, Dicebot wrote: Not exactly. It is all about if condition. AFAIK, D defines that condition `if(X)` get re-written to `if(cast(bool)X)` before semantic pass. So it is kind of implicit explicit conversion :) Not exactly. Code: bool b = f; DMD output: Error: cannot implicitly convert expression (f) of type Foo to bool But code: bool b = !f; compiles. Because '!' operator provides boolean context. It is written in the spec, although not explicitly. By the way, the same happens with objects with pretty many types (except structs which do not provide necessary operator overloads), so classes are not exceptional here. UnaryExpression: UnaryExpression ++ UnaryExpression -- UnaryExpression * UnaryExpression - UnaryExpression + UnaryExpression ! UnaryExpression ComplementExpression ( Type ) . Identifier ( Type ) . TemplateInstance DeleteExpression CastExpression PowExpression
Re: DMD can implicitly convert class pointer to the bool. Is it bug or terrible feature?
On Sunday, 24 November 2013 at 14:32:16 UTC, ilya-stromberg wrote:
On Sunday, 24 November 2013 at 14:16:39 UTC, bearophile wrote:
Maxim Fomin:
This is neither bug not a terribale feature.
I think the implicit question of ilya-stromberg was: how much
bug-prone is this language feature?
Yes, exactly. I personally was VERY surprised. My code example
from real life:
class Foo
{
}
class Bar
{
Foo f;
void bar()
{
//variable was wrongly commented here
//bool f = true;
if(f)
{
//Oops!
}
}
}
This is identifiers shadowing issue. In best case you could not
define boolean f, so the problem would not arise in a first
place. Anyway, many artifical examples can be provided which
shows that some features behave in unexpected ways which is not a
reason that they are bad.
Re: DMD can implicitly convert class pointer to the bool. Is it bug or terrible feature?
On Sunday, 24 November 2013 at 14:45:31 UTC, Maxim Fomin wrote: Because '!' operator provides boolean context. Yes, but it's ambiguously. What should compiler to use: 1) pointer comparing `is null` or 2) bool comparing `cast(bool)` What happens if `cast(bool)` operator will be added or removed?
Re: DMD can implicitly convert class pointer to the bool. Is it bug or terrible feature?
On Sunday, 24 November 2013 at 14:50:28 UTC, Maxim Fomin wrote:
This is identifiers shadowing issue. In best case you could not
define boolean f, so the problem would not arise in a first
place.
Yes, I agree that it's also can be identifiers shadowing issue.
But we allow code like this:
class Foo
{
int i;
this(int i)
{
this.i = i;
}
}
Anyway, many artifical examples can be provided which shows
that some features behave in unexpected ways which is not a
reason that they are bad.
I repeat, this is REAL LIFE example. I just reduce it because it
have unnecessary details for this case.
Re: Why is it that no one writes with portability in mind in druntime?
On 2013-11-24 11:38:25 +, Iain Buclaw said: https://github.com/D-Programming-Language/druntime/pull/663 A link to pages of a pull extension for CTFE hashes. Care to clarify?
Re: Need help making minimal bare metal ARM Cortex-M D program
A couple of the options don't seem to exist in crosstools. Specifically Go to C compiler, select Other languages and enter d. Pretty hard to tell the compiler to support D without this option. Have you set 'Try features marked as EXPERIMENTAL'? Are you using a recent version of crosstool-NG? And in case this isn't clear, there isn't a 'D' option to choose from, you need to type 'D' into the field.
Re: DMD can implicitly convert class pointer to the bool. Is it bug or terrible feature?
Maxim Fomin:
This is identifiers shadowing issue. In best case you could not
define boolean f, so the problem would not arise in a first
place.
See also the discussion here:
http://d.puremagic.com/issues/show_bug.cgi?id=9521
Is it right for with to not give an error here?
struct Foo { int x; }
int x;
void main() {
Foo f;
with (f) {
x++;
}
}
Silent shadowing of global (module-level in both Python and D)
names has caused me many problems along the years.
Bye,
bearophile
Re: DMD can implicitly convert class pointer to the bool. Is it bug or terrible feature?
On Sunday, 24 November 2013 at 15:01:34 UTC, ilya-stromberg wrote:
On Sunday, 24 November 2013 at 14:50:28 UTC, Maxim Fomin wrote:
This is identifiers shadowing issue. In best case you could
not define boolean f, so the problem would not arise in a
first place.
Yes, I agree that it's also can be identifiers shadowing issue.
But we allow code like this:
class Foo
{
int i;
this(int i)
{
this.i = i;
}
}
Anyway, many artifical examples can be provided which shows
that some features behave in unexpected ways which is not a
reason that they are bad.
I repeat, this is REAL LIFE example. I just reduce it because
it have unnecessary details for this case.
Many people complain about language features which are really
broken, misfunctiong, or both. Sometimes they point out on cases
like:
assert(Unexpected error occured);
which do not show feature failure, but language can be improved
by rejecting or at least warning in such cases. However your case
class Foo
{
}
class Bar
{
Foo f;
void bar()
{
//variable was wrongly commented here
//bool f = true;
if(f)
{
//Oops!
}
}
}
has nothing to do with either of these two types of
defficiencies. No way compiler could guess that you have bool f
in mind. There is no way to improve the language because it
requires blocking class to bool conversion in boolean context
which is pretty nice feature and there are plenty of code which
has to be broken.
Re: Need help making minimal bare metal ARM Cortex-M D program
On Sunday, 24 November 2013 at 15:32:04 UTC, jerro wrote: A couple of the options don't seem to exist in crosstools. Specifically Go to C compiler, select Other languages and enter d. Pretty hard to tell the compiler to support D without this option. Have you set 'Try features marked as EXPERIMENTAL'? Are you using a recent version of crosstool-NG? And in case this isn't clear, there isn't a 'D' option to choose from, you need to type 'D' into the field. Yes, I tried experimental features, obsolete features, and number of other things. I know there isn't a D option to check. I was fully expecting a text field to type the letter 'D' into, but the Other languages option does not exist. It appears to have been replaced with a C++ check option. Give it a try yourself, and you'll see what I mean.
Re: DMD can implicitly convert class pointer to the bool. Is it bug or terrible feature?
On Sunday, 24 November 2013 at 15:35:40 UTC, bearophile wrote:
Maxim Fomin:
This is identifiers shadowing issue. In best case you could
not define boolean f, so the problem would not arise in a
first place.
See also the discussion here:
http://d.puremagic.com/issues/show_bug.cgi?id=9521
Is it right for with to not give an error here?
struct Foo { int x; }
int x;
void main() {
Foo f;
with (f) {
x++;
}
}
Silent shadowing of global (module-level in both Python and D)
names has caused me many problems along the years.
Bye,
bearophile
Yes, it is confusing. It is especially confusing in an unstable
language with absent adequate spec. For example, I can learn C
namespace rules, but in D case it is useless. Unfortunately what
is right in cases like above depends on what Walter Andrei
think so we stuck with their opinions on the subject.
(I think emitting at least warning would be good)
Re: std.complex
On Saturday, 23 November 2013 at 15:13:22 UTC, Shammah Chancellor wrote: I disagree. I was using them for physics simulations. They are very useful for the computational physics community. Just because most people are still using FORTRAN does not mean they won't switch eventually. Would it cause you any particular disadvantage to use the library std.complex rather than the built-in complex type?
Re: DMD can implicitly convert class pointer to the bool. Is it bug or terrible feature?
On Sunday, 24 November 2013 at 15:39:20 UTC, Maxim Fomin wrote: No way compiler could guess that you have bool f in mind. Sorry if I didn't explain the example properly. The `bool f` variable was in my code and it works correctly, but compiler didn't put attention that I have identifiers shadowing issue. After big code refactoring I wrongly commented the `bool f` variable. So, nothing happens if compiler provides identifier shadowing error - I'll just rename variable. Is it possible to implement?
Re: DMD can implicitly convert class pointer to the bool. Is it bug or terrible feature?
On Sunday, 24 November 2013 at 15:55:25 UTC, ilya-stromberg wrote: On Sunday, 24 November 2013 at 15:39:20 UTC, Maxim Fomin wrote: No way compiler could guess that you have bool f in mind. Sorry if I didn't explain the example properly. The `bool f` variable was in my code and it works correctly, but compiler didn't put attention that I have identifiers shadowing issue. After big code refactoring I wrongly commented the `bool f` variable. OK, root of the issue is identifier shadowing. So, nothing happens if compiler provides identifier shadowing error - I'll just rename variable. Is it possible to implement? Yes, it is possible, but AFAIK Walter is opposite because he 1) thinks shadowing is OK (and taking into account compability with C, this is dabatable), 2) does not like warnings.
Re: Initializing two-dimensional compile-time enum
Thanks! I'll try it. Another question is can I use immutable variables in compile time or they are just runtime variables that are once initialized and can't be modified? Is it only way to use manifest constants (enum). And what is semantics of enum constants? In D we have a lot of modifiers: static, enum, const, immutable. So sometimes I get stuck with question what to use? Could someone briefly explain the purpose of each one of these?
Re: Why is it that no one writes with portability in mind in druntime?
Am Sun, 24 Nov 2013 10:34:36 -0500 schrieb Shammah Chancellor anonym...@coward.com: On 2013-11-24 11:38:25 +, Iain Buclaw said: https://github.com/D-Programming-Language/druntime/pull/663 A link to pages of a pull extension for CTFE hashes. Care to clarify? A guess: Everything using floating point is probably assuming real is 80 bit. This and floating point unit tests always show up as the main problems when porting druntime / phobos. We have one type in D which has a different size depending on platform and it's the number one source for platform-specific problems... https://github.com/D-Programming-Language/druntime/pull/663/files#diff-d07f1a3835b1d391d103490da285999dR183
Re: Initializing two-dimensional compile-time enum
On Sunday, 24 November 2013 at 13:58:11 UTC, Philippe Sigaud
wrote:
You can use CTFE and an initializing function. It's a bit
cumbersome,
but it works.
Lambda's to the rescue!
//
enum string[int][string] pohodEnumValues =
(){
string[int][string] result;
result[vid] = [ 3: skiing, 5: rafting, 7: jumping ];
result[ks] = [ 1: first, 2: second, 3: third ];
result[prepare] = [ 1:planning, 3:preparing,
5:complete ];
return result;
}();
//
This is cleaner, IMO.
Re: Initializing two-dimensional compile-time enum
On Sun, Nov 24, 2013 at 5:14 PM, Uranuz neura...@gmail.com wrote: Thanks! I'll try it. Another question is can I use immutable variables in compile time or they are just runtime variables that are once initialized and can't be modified? Is it only way to use manifest constants (enum). And what is semantics of enum constants? In D we have a lot of modifiers: static, enum, const, immutable. So sometimes I get stuck with question what to use? Could someone briefly explain the purpose of each one of these? A named enum has no 'real' existence: you cannot take its address (it has none), for example. It's a glorified literal, which is just replaced by its value every time it's used. Which means using enum` in conjunction with dynamic arrays and associative arrays is prone to drastically limit your code speed, because there will be an allocation for each instance. An immutable value is much more standard: it's allocated once, you can take its address and so on. It can be allocated at runtime and once it's allocated, no one can change it. It A const value cannot be modified in the current scope, but someone else, elsewhere, might. See: http://ddili.org/ders/d.en/const_and_immutable.html And also: http://ddili.org/ders/d.en/const_member_functions.html
Re: Initializing two-dimensional compile-time enum
On Sun, Nov 24, 2013 at 5:19 PM, monarch_dodra monarchdo...@gmail.com wrote: This is cleaner, IMO. Well, in an ideal world, we wouldn't have to fall back to these contortions.
Re: Need help making minimal bare metal ARM Cortex-M D program
It seems languages other than C are disabled for bare metal builds. You could try searching for cc.ini in your crosstool-ng installation and commenting out the line if ! BARE_METAL and endif # ! BARE_METAL
Re: DMD can implicitly convert class pointer to the bool. Is it bug or terrible feature?
On 11/24/13 6:32 AM, ilya-stromberg wrote:
On Sunday, 24 November 2013 at 14:16:39 UTC, bearophile wrote:
Maxim Fomin:
This is neither bug not a terribale feature.
I think the implicit question of ilya-stromberg was: how much
bug-prone is this language feature?
Yes, exactly. I personally was VERY surprised. My code example from real
life:
class Foo
{
}
class Bar
{
Foo f;
void bar()
{
//variable was wrongly commented here
//bool f = true;
if(f)
{
//Oops!
}
}
}
If uncommented that would make for a shadow definition error. In brief I
think you'll have a hard time finding evidence that if (p) is dangerous.
Andrei
Re: Checking function parameters in Phobos
On 22.11.2013 02:55, Simen Kjærås wrote:
On 22.11.2013 00:50, Meta wrote:
On Thursday, 21 November 2013 at 22:51:43 UTC, inout wrote:
What if you have more that just one validation, e.g. Positive and
LessThan42?
Is Positive!LessThan42!int the same type as LessThan42!Positive!int?
Implicitly convertible?
Allow multiple validation functions. Then a Validated type is only valid
if validationFunction1(val) validationFunction2(val) ...
Validated!(isPositive, lessThan42, int) validatedInt =
validate!(isPositive, lessThan42)(34);
//Do stuff with validatedInt
I believe inout's point was this, though:
Validated!(isPositive, lessThan42, int) i = foo();
Validated!(isPositive, int) n = i; // Fails.
Validated!(lessThan42, isPositive, int) r = i; // Fails.
This is of course less than optimal.
If a type such as Validate is to be added to Phobos, these problems need
to be fixed first.
Or just pass a function that validates that the int is both positive and
less than 42, which would be much simpler.
I've created a version of Validated now that takes 1 or more
constraints, and where a type whose constraints are a superset of
another's, is implicitly convertible to that. Sadly, because of D's lack
of certain implicit conversions, there are limits.
Attached is source (validation.d), and some utility functions that are
necessary for it to compile (utils.d).
Is this worth working more on? Should it be in Phobos? Other critique?
Oh, sorry about those stupid questions, we have a term for that:
Detroy!
--
Simen
module biotronic.utils;
import std.typetuple : TypeTuple, NoDuplicates, staticIndexOf;
import std.traits : Unqual, ParameterTypeTuple;
void staticEnforce(bool criteria, string msg)() {
static if (!criteria) {
pragma(msg, msg);
static assert(false);
}
}
void staticEnforce(bool criteria, string msg, string file, int line)() {
staticEnforce!(criteria, file ~ ( ~ line.stringof ~ ): Error: ~ msg);
}
auto sum( R )( R range ) if ( isInputRange!R ) {
ElementType!R tmp = 0;
return reduce!( (a,b)=a+b )( tmp, range );
}
template arrayToTuple( alias name ) {
static if ( name.length ) {
alias arrayToTuple = TypeTuple!( name[0], arrayToTuple!( name[1..$] ) );
} else {
alias arrayToTuple = TypeTuple!( );
}
}
template Repeat( size_t n, T... ) {
static if ( n ) {
alias Repeat = TypeTuple!( T, Repeat!( n-1, T ) );
} else {
alias Repeat = TypeTuple!();
}
}
template hasFloatBehavior( T ) {
static if ( __traits( compiles, { T t; t = 1; return (t/2)*2 == t; } ) ) {
enum hasFloatBehavior = { T t; t = 1; return (t/2)*2 == t; }();
} else {
enum hasFloatBehavior = false;
}
} unittest {
assert( hasFloatBehavior!float );
assert( hasFloatBehavior!double );
assert( hasFloatBehavior!real );
assert( !hasFloatBehavior!int );
assert( !hasFloatBehavior!char );
assert( !hasFloatBehavior!string );
}
template hasNumericBehavior( T ) {
template hasNumericBehaviorImpl( U... ) {
static if ( U.length ) {
enum hasNumericBehaviorImpl = is( Unqual!T == U[0] ) ||
hasNumericBehaviorImpl!( U[1..$] );
} else {
enum hasNumericBehaviorImpl = false;
}
}
enum hasNumericBehavior = hasNumericBehaviorImpl!( byte, short, int, long,
ubyte, ushort, uint, ulong, float, double, real );
} unittest {
foreach ( Type; TypeTuple!( byte, short, int, long, ubyte, ushort, uint,
ulong, float, double, real ) ) {
assert( hasNumericBehavior!Type );
}
foreach ( Type; TypeTuple!( string, char, dchar, int[], void, void*) ) {
assert( !hasNumericBehavior!Type );
}
}
template StaticFilter(alias pred, T...) {
static if (T.length == 0) {
alias StaticFilter = TypeTuple!();
} else static if (T.length == 1) {
static if (pred!(T[0])) {
alias StaticFilter = T;
} else {
alias StaticFilter = TypeTuple!();
}
} else {
alias StaticFilter = TypeTuple!(
StaticFilter!(pred, T[0..$/2]),
StaticFilter!(pred, T[$/2..$]));
}
}
struct CMP(T...){}
template sortPred(T...) if (T.length == 2) {
static if ( TypeTuple!(T[0]).stringof TypeTuple!(T[1]).stringof ) {
enum sortPred = -1;
} else static if ( TypeTuple!(T[0]).stringof TypeTuple!(T[1]).stringof ) {
enum sortPred = 1;
} else {
enum sortPred = 0;
}
} unittest {
assert( sortPred!(int, string) == -sortPred!( string, int ) );
}
template StaticSort(alias pred, T...) {
static if (T.length == 0) {
alias StaticSort = TypeTuple!();
} else static if (T.length == 1) {
alias StaticSort = T;
} else {
template lessPred(U...) {
enum lessPred = pred!(T[0], U[0]) == 1;
}
template equalPred(U...) {
enum equalPred = pred!(T[0], U[0]) == 0;
}
template
Re: DMD can implicitly convert class pointer to the bool. Is it bug or terrible feature?
Andrei Alexandrescu:
class Foo
{
}
class Bar
{
Foo f;
void bar()
{
//variable was wrongly commented here
//bool f = true;
if(f)
{
//Oops!
}
}
}
If uncommented that would make for a shadow definition error.
Are you saying this code gives or should give errors?
class Foo {}
class Bar {
Foo f;
void bar() {
bool f = true;
if (f) {}
}
}
void main() {}
Bye,
bearophile
Re: std.complex
On 2013-11-24 15:50:46 +, Joseph Rushton Wakeling said: On Saturday, 23 November 2013 at 15:13:22 UTC, Shammah Chancellor wrote: I disagree. I was using them for physics simulations. They are very useful for the computational physics community. Just because most people are still using FORTRAN does not mean they won't switch eventually. Would it cause you any particular disadvantage to use the library std.complex rather than the built-in complex type? It would if the they don't work correctly. There needs to be an Imaginary type and some proper operations between complex and imaginary types. That doesn't seem to be the case currently. I personally think having the built-in type is very helpful. However, I can understand from a language perspective that having i around is hard for the parser. Also, the argument If complex/imaginary is built-in, why not have quaterions also seems to imply that it should be a library type. -Shammah
Re: Need help making minimal bare metal ARM Cortex-M D program
On 11/24/2013 06:21 AM, Johannes Pfau wrote: Am Sun, 24 Nov 2013 14:19:43 +0100 schrieb Mike n...@none.com: On Sunday, 24 November 2013 at 12:53:42 UTC, Iain Buclaw wrote: On Sunday, 24 November 2013 at 12:43:01 UTC, Mike wrote: I am very new to D, but I finally got my toolchain compiled and working. I'm using LDC. I failed with GDC and eventually gave up. I know Johannes has some patches yet to trickle down into gdc. And druntime is does not support ARM fully in 2.063, but it would be helpful if you could take some time to let people know what went wrong when you tried things, rather than just giving up. Otherwise, nothing will get fixed. Cortex-M is the 'bare metal' branch of ARM where you usually don't run linux so druntime won't work anyway. There are some compiler fixes in my branch that could be interesting though: https://github.com/jpf91/GDC/commits/arm BTW: I'll start merging back the fixes to gdc master this week. Some fixes have to be merged into phobos upstream though so it might take some time. I actually tried to get a gdc build a week or two ago for a cortex-a8 using ng-crosstools-linaro. I managed to get up to compiling druntime, which then was pointing to a commit prior to https://github.com/D-Programming-Language/druntime/commit/541e7ba00d5e75426bb677d7f7548a47a904551f so it failed. Then I figured I'd wait for your fixes.
Static Foreach
It seems that DMD already interprets some foreach's at compiletime if
the argument is known at compile time:
eg:
string FooString()
{
string stuff = ;
foreach(member, __traits( allMembers, moduleName)
{
stuff ~= member;
}
return stuff;
}
mixin(FooString());
However, for non-string templates. They have to be written in a
recursive form, which can be particularly difficult in some cases.
template FooTemplate() //This code is totally made up and not meant
to do anything useful, or necessarily be valid.
{
auto FooTemplate = TypeTuple!()
static foreach(member, __traits( allMembers, someClass)
{
FooTemplate = TypeTuple!(FooTemplate, __traits(getMember, someClass,
member));
}
}
What's the consensis on something like this?
Re: Why is it that no one writes with portability in mind in druntime?
On 11/24/13, Johannes Pfau nos...@example.com wrote: We have one type in D which has a different size depending on platform and it's the number one source for platform-specific problems... It seems any time a language defines something as implementation-specific or platform-specific it ends up giving everyone headaches. I don't know why D chose to use reals like that, after enforcing the sizes of long/int/etc. types.
Re: Why is it that no one writes with portability in mind in druntime?
On 2013-11-24 17:47:49 +, Andrej Mitrovic said: On 11/24/13, Johannes Pfau nos...@example.com wrote: We have one type in D which has a different size depending on platform and it's the number one source for platform-specific problems... It seems any time a language defines something as implementation-specific or platform-specific it ends up giving everyone headaches. I don't know why D chose to use reals like that, after enforcing the sizes of long/int/etc. types. Having 80-bit reals on platforms that support them are helpful for numerical simulations. There use to be an article about this decision. However, phobos should never use real for this reason. It should only be used by application developers. Maybe a compiler flag to error when compiling code that includes real to make sure portable libraries don't use it? -Shammah
Re: std.complex
On 23/11/13 08:43, Ali Çehreli wrote:
import std.stdio;
import std.complex;
void main()
{
writeln(complex(1.0L, -real.infinity) * complex(0.0, 1.0L));
writeln((1L - ireal.infinity) * 1i);
}
The output:
inf-nani-- incorrect according to the quoted page
inf+1i -- correct
It's because 0.0L * (-real.infinity) evaluates to nan.
Re: std.complex
On 11/24/13 9:54 AM, Joseph Rushton Wakeling wrote:
On 23/11/13 08:43, Ali Çehreli wrote:
import std.stdio;
import std.complex;
void main()
{
writeln(complex(1.0L, -real.infinity) * complex(0.0, 1.0L));
writeln((1L - ireal.infinity) * 1i);
}
The output:
inf-nani-- incorrect according to the quoted page
inf+1i -- correct
It's because 0.0L * (-real.infinity) evaluates to nan.
Has this been submitted as a bug report?
Andrei
Re: std.complex
On 2013-11-24 18:00:45 +, Andrei Alexandrescu said:
On 11/24/13 9:54 AM, Joseph Rushton Wakeling wrote:
On 23/11/13 08:43, Ali Çehreli wrote:
import std.stdio;
import std.complex;
void main()
{
writeln(complex(1.0L, -real.infinity) * complex(0.0, 1.0L));
writeln((1L - ireal.infinity) * 1i);
}
The output:
inf-nani-- incorrect according to the quoted page
inf+1i -- correct
It's because 0.0L * (-real.infinity) evaluates to nan.
Has this been submitted as a bug report?
Andrei
It's more a fundamental problem with a complex type in general. C++
has this issue as well. You need a purely imaginary type with the
appropiate operations between Complex and Imaginary defined.
Re: std.complex
24-Nov-2013 22:03, Shammah Chancellor пишет:
On 2013-11-24 18:00:45 +, Andrei Alexandrescu said:
On 11/24/13 9:54 AM, Joseph Rushton Wakeling wrote:
On 23/11/13 08:43, Ali Çehreli wrote:
import std.stdio;
import std.complex;
void main()
{
writeln(complex(1.0L, -real.infinity) * complex(0.0, 1.0L));
writeln((1L - ireal.infinity) * 1i);
}
The output:
inf-nani-- incorrect according to the quoted page
inf+1i -- correct
It's because 0.0L * (-real.infinity) evaluates to nan.
Has this been submitted as a bug report?
Andrei
It's more a fundamental problem with a complex type in general. C++
has this issue as well. You need a purely imaginary type with the
appropiate operations between Complex and Imaginary defined.
Can't it just check for the real part being exactly zero and special-
case multiplication for that?
--
Dmitry Olshansky
Re: Why is it that no one writes with portability in mind in druntime?
On 11/24/2013 9:47 AM, Andrej Mitrovic wrote: I don't know why D chose to use reals like that, Because more precision is better.
Re: DMD can implicitly convert class pointer to the bool. Is it bug or terrible feature?
On 11/24/2013 9:45 AM, Andrei Alexandrescu wrote:
Sorry, I misread the example - thought it's a function local variable. I'm not
sure whether shadowing globals or members would be a good idea. gcc has a -W
flag for that, and someone tried to turn it on at Facebook but with debatable
results. We ended up not using that warning.
Shadowing globals is definitely a bad idea. Shadowing members, it's debatable.
In any case, I don't think it is some sort of terrible bug generator. In fact,
I'll often write:
struct S {
int m;
this(int m) { this.m = m; }
}
because I like to make it clear I am initializing m. I find code like this to be
unduly wretched:
struct S {
int m;
this(int _m) { m = _m; }
}
Re: std.complex
Shammah Chancellor: It's more a fundamental problem with a complex type in general. C++ has this issue as well. You need a purely imaginary type with the appropiate operations between Complex and Imaginary defined. Can't you add a new name to std.complex to implement the purely imaginary type? Bye, bearophile
Re: DMD can implicitly convert class pointer to the bool. Is it bug or terrible feature?
Andrei Alexandrescu: I'm not sure whether shadowing globals or members would be a good idea. I understand. It's not a clear cut topic. There are real reasons both for and against this idea. But surely it should be considered. I have not yet (re)opened an enhancement request on this. gcc has a -W flag for that, and someone tried to turn it on at Facebook but with debatable results. We ended up not using that warning. In the example I have shown it's with() that is uncovering a struct field with the same name of a module-level name. So it's not exactly the same as a local variable shadowing a module-level name (and currently with has anti-hijacking for local variables). I think that shadowing module-level names with with() is not good. Also because of this idea: https://d.puremagic.com/issues/show_bug.cgi?id=6917 Regarding Facebook, I presume that Gcc flag was applied to plenty of already written code. If you apply it since the start of a new project perhaps (probably) its effects are different. This detail is important, because lot of D code is yet to be written. Regarding more generally the topic of shadowing module-level names with local names, the attribute pure helps avoid some cases, because you can only shadow immutable global names, and this is a little less dangerous/troublesome. Time ago I suggested an optional @outer() attribute, that's useful to specify what names from outer scopes a function/method is allowed to see and use. It looks a bit excessive, but it shows that I have hated bugs caused by shadowing globals silently. An IDE could underline the shadowing variables, turning the silent shadowing into a visible one, without giving warnings (it's a kind of much noisy warning), but unfortunately a compiler like dmd can't do that. Another problem is that a command like import std.algorithm imports lot of names in the current module, and this could cause many false alarms. But this could be a good thing, and it can push Phobos devs to add more private tags to Phobos names, and D developers to add more qualified imports in their programs. Bye, bearophile
Re: Need help making minimal bare metal ARM Cortex-M D program
Am Sun, 24 Nov 2013 18:18:22 +0100 schrieb jerro a...@a.com: It seems languages other than C are disabled for bare metal builds. You could try searching for cc.ini in your crosstool-ng installation and commenting out the line if ! BARE_METAL and endif # ! BARE_METAL Good to know. I'll prepare a patch ( I'm currently implementing cross-native builds for crosstool-NG anyway)
Re: std.complex
On 11/24/13 10:03 AM, Shammah Chancellor wrote:
On 2013-11-24 18:00:45 +, Andrei Alexandrescu said:
On 11/24/13 9:54 AM, Joseph Rushton Wakeling wrote:
On 23/11/13 08:43, Ali Çehreli wrote:
import std.stdio;
import std.complex;
void main()
{
writeln(complex(1.0L, -real.infinity) * complex(0.0, 1.0L));
writeln((1L - ireal.infinity) * 1i);
}
The output:
inf-nani-- incorrect according to the quoted page
inf+1i -- correct
It's because 0.0L * (-real.infinity) evaluates to nan.
Has this been submitted as a bug report?
Andrei
It's more a fundamental problem with a complex type in general. C++
has this issue as well. You need a purely imaginary type with the
appropiate operations between Complex and Imaginary defined.
But that originates as a call to multiplication between two Complex
numbers. Can't the problem be addressed at that level?
Andrei
Re: DMD can implicitly convert class pointer to the bool. Is it bug or terrible feature?
On 11/24/13 10:31 AM, bearophile wrote: Regarding Facebook, I presume that Gcc flag was applied to plenty of already written code. If you apply it since the start of a new project perhaps (probably) its effects are different. This detail is important, because lot of D code is yet to be written. This is just speculation. It would have been helpful if enabling -Wshadow uncovered at least a few bugs. Instead, it just asked for a lot of code to be changed for no visible benefit. Andrei
Re: DMD can implicitly convert class pointer to the bool. Is it bug or terrible feature?
On Sunday, 24 November 2013 at 18:23:51 UTC, Walter Bright wrote:
Shadowing globals is definitely a bad idea. Shadowing members,
it's debatable. In any case, I don't think it is some sort of
terrible bug generator. In fact, I'll often write:
struct S {
int m;
this(int m) { this.m = m; }
}
We can allow shadowing members only for function parameters or,
maybe, only for constructor. Probably, your example is the most
often case usage of shadowing members. In other hand, I can
always rename local function variable because it isn't part of
public API and should not confuse any users.
Re: std.complex
On 2013-11-24 18:37:51 +, Andrei Alexandrescu said: But that originates as a call to multiplication between two Complex numbers. Can't the problem be addressed at that level? Andrei I don't believe so because IEEE floats define inf*0 to be NaN. You would have to check to see if rhs.re == 0 || lhs.re == 0 and then just return zero. Somewhat unfortunate. You really do need an imaginary type for reasons specified in the original page here: http://digitalmars.com/d/1.0/cppcomplex.html -Shammah
Re: Initializing two-dimensional compile-time enum
As far as I understand I can't use immutable values as template
arguments. It's what I need in my code. I'll give an example.
//---
import std.stdio;
immutable(string[int][string]) pohodEnumValues;
shared static this()
{
pohodEnumValues = [
vid: [ 3: skiing, 5: rafting, 7: jumping ],
ks: [ 1: first, 2: second, 3: third ],
prepare: [ 1:planning, 3:preparing, 5:complete ]
];
}
//Some template method
void foo(string arg)()
{ //Some actions here
}
void main()
{
foreach( name, item; pohodEnumValues )
{ foo!(name)(); //I need name at compile time here
}
}
//-
Because we have only compile time foreach over tuple this is not
working. Can someone give an advice, please?
Re: DMD can implicitly convert class pointer to the bool. Is it bug or terrible feature?
On Sunday, 24 November 2013 at 18:41:32 UTC, Andrei Alexandrescu wrote: This is just speculation. It would have been helpful if enabling -Wshadow uncovered at least a few bugs. Instead, it just asked for a lot of code to be changed for no visible benefit. No, isn't just speculation. If you already have working and tested code without `-Wshadow` flag it's really doesn't provide any solid benefits. But in my case it helps because compiler prints error about missing identifier and I have to uncomment `bool` variable.
Re: DMD can implicitly convert class pointer to the bool. Is it bug or terrible feature?
On 11/24/2013 10:52 AM, ilya-stromberg wrote: We can allow shadowing members only for function parameters or, maybe, only for constructor. We could, but at the cost of D becoming more of a mass of special cases that nobody can remember.
Re: Initializing two-dimensional compile-time enum
This example above will not compile because name is not a compile time expression. But I can't undersatnd how to make some kind of compile-time variable. If we have advanced metaprogramming features I think possibility of defining compile-time variables is needed. Am I right or not? I think defining compile-time array as Tuple!(first, second, third) looking sophisticated.
Re: DMD can implicitly convert class pointer to the bool. Is it bug or terrible feature?
Walter Bright:
Shadowing globals is definitely a bad idea. Shadowing members,
it's debatable.
So are you saying D here should give an error for the shadowing
of the module-level x?
struct Foo { int x; }
int x;
void main() {
Foo f;
with (f) {
x++;
}
}
In any case, I don't think it is some sort of terrible bug
generator. In fact, I'll often write:
struct S {
int m;
this(int m) { this.m = m; }
}
because I like to make it clear I am initializing m.
From my experience that's quite bug-prone:
http://d.puremagic.com/issues/show_bug.cgi?id=3878
Bye,
bearophile
Re: Static Foreach
On Sun, Nov 24, 2013 at 6:40 PM, Shammah Chancellor
anonym...@coward.com wrote:
However, for non-string templates. They have to be written in a recursive
form, which can be particularly difficult in some cases.
template FooTemplate() //This code is totally made up and not meant
to do anything useful, or necessarily be valid.
{
auto FooTemplate = TypeTuple!()
static foreach(member, __traits( allMembers, someClass)
{
FooTemplate = TypeTuple!(FooTemplate,
__traits(getMember, someClass, member));
}
}
What's the consensis on something like this?
The consensus might well be 'use recursion' :) That's what I'd do in
your case. CT computation on types is a lot like functional
programming: recursion and immutability.
Another solution would be to construct you type as a string, and then mix it in.
Re: DMD can implicitly convert class pointer to the bool. Is it bug or terrible feature?
On Sunday, 24 November 2013 at 19:18:18 UTC, Walter Bright wrote:
On 11/24/2013 10:52 AM, ilya-stromberg wrote:
We can allow shadowing members only for function parameters
or, maybe, only for
constructor.
We could, but at the cost of D becoming more of a mass of
special cases that nobody can remember.
See also:
http://d.puremagic.com/issues/show_bug.cgi?id=9801
Short description: disallow shadowing members, but provide
special syntax for constructors like this:
struct S {
int m;
this(this.m) { }
}
Should be the same as your example above.
Other languages like Scala, CoffeeScript and TypeScript support a
related but different syntax. So, not only I had problems with
shadowing members.
Re: Static Foreach
On Sunday, 24 November 2013 at 19:42:21 UTC, Philippe Sigaud
wrote:
On Sun, Nov 24, 2013 at 6:40 PM, Shammah Chancellor
anonym...@coward.com wrote:
However, for non-string templates. They have to be written
in a recursive
form, which can be particularly difficult in some cases.
template FooTemplate() //This code is totally made up
and not meant
to do anything useful, or necessarily be valid.
{
auto FooTemplate = TypeTuple!()
static foreach(member, __traits( allMembers,
someClass)
{
FooTemplate = TypeTuple!(FooTemplate,
__traits(getMember, someClass, member));
}
}
What's the consensis on something like this?
The consensus might well be 'use recursion' :) That's what I'd
do in
your case. CT computation on types is a lot like functional
programming: recursion and immutability.
However, the current set of tools is a bit lacking in that
department. Hopefully I'll be able to rectify this with my
attempt at a proper std.meta package :) Unfortunately, it's
proving to a bit of a stress-test on some dustier parts of the
compiler (not to mention my brain), so progress is a bit slower
than I would have hoped.
Re: Static Foreach
On Sunday, 24 November 2013 at 17:40:14 UTC, Shammah Chancellor wrote: What's the consensis on something like this? https://d.puremagic.com/issues/show_bug.cgi?id=1642
auto-tester results 403
Just got this when trying to look at the auto-tester here: https://d.puremagic.com/test-results/pull-history.ghtml?projectid=1repoid=1pullid=2757 Forbidden You don't have permission to access /test-results/pull-history.ghtml on this server. Apache/2.4.6 (Ubuntu) Server at d.puremagic.com Port 443
Re: Static Foreach
On Sun, Nov 24, 2013 at 8:46 PM, John Colvin john.loughran.col...@gmail.com wrote: However, the current set of tools is a bit lacking in that department. Hopefully I'll be able to rectify this with my attempt at a proper std.meta package :) Unfortunately, it's proving to a bit of a stress-test on some dustier parts of the compiler (not to mention my brain), so progress is a bit slower than I would have hoped. You can have a look there: https://github.com/PhilippeSigaud/dranges/blob/master/tuple.d and https://github.com/PhilippeSigaud/dranges/blob/master/typetuple.d (this one was fun: regex on type tuples!) https://github.com/PhilippeSigaud/dranges/blob/master/typepattern.d
Re: DMD can implicitly convert class pointer to the bool. Is it bug or terrible feature?
On 11/24/2013 11:17 AM, bearophile wrote:
Walter Bright:
Shadowing globals is definitely a bad idea. Shadowing members, it's debatable.
So are you saying D here should give an error for the shadowing of the
module-level x?
struct Foo { int x; }
int x;
void main() {
Foo f;
with (f) {
x++;
}
}
I meant bad as in bad, not as in good :-)
From my experience that's quite bug-prone:
http://d.puremagic.com/issues/show_bug.cgi?id=3878
I posted an objection there :-)
Re: Need help making minimal bare metal ARM Cortex-M D program
On Sunday, 24 November 2013 at 14:10:54 UTC, Mike wrote: On Sunday, 24 November 2013 at 13:30:10 UTC, David Nadlinger wrote: On Sunday, 24 November 2013 at 13:00:39 UTC, Mike wrote: Is there some syntax equivalent to __attribute__ ((section(.interrupt_vector)))? There isn't right now, but it would be entirely feasible to implement this in an LDC-specific extension. Could you open an issue on our GitHub tracker? David https://github.com/ldc-developers/ldc/issues/547 A full working example for gdc and cortex-m4 (stm32f4) is in my repo at https://bitbucket.org/timosi/minlibd I have used startup file from st and have no need to put interrupt vectors in d code.
Re: Static Foreach
On Sunday, 24 November 2013 at 19:57:06 UTC, Philippe Sigaud wrote: On Sun, Nov 24, 2013 at 8:46 PM, John Colvin john.loughran.col...@gmail.com wrote: However, the current set of tools is a bit lacking in that department. Hopefully I'll be able to rectify this with my attempt at a proper std.meta package :) Unfortunately, it's proving to a bit of a stress-test on some dustier parts of the compiler (not to mention my brain), so progress is a bit slower than I would have hoped. You can have a look there: https://github.com/PhilippeSigaud/dranges/blob/master/tuple.d and https://github.com/PhilippeSigaud/dranges/blob/master/typetuple.d (this one was fun: regex on type tuples!) https://github.com/PhilippeSigaud/dranges/blob/master/typepattern.d I've been looking at that stuff recently :-) It's pretty cool, in particular the regex stuff. I'm wary of going overboard though, it's very tempting to keep adding functionality that is too obscure for a standard library.
Re: Static Foreach
On Sun, Nov 24, 2013 at 9:06 PM, John Colvin john.loughran.col...@gmail.com wrote: You can have a look there: https://github.com/PhilippeSigaud/dranges/blob/master/tuple.d and https://github.com/PhilippeSigaud/dranges/blob/master/typetuple.d (this one was fun: regex on type tuples!) https://github.com/PhilippeSigaud/dranges/blob/master/typepattern.d I've been looking at that stuff recently :-) It's pretty cool, in particular the regex stuff. I'm wary of going overboard though, it's very tempting to keep adding functionality that is too obscure for a standard library. That's why I never tried to get it into Phobos :) And, truth is, I used almost none of it, even when most of this code is 4 years old. Mapping/filtering/reducing tuples is the most useful part. The regex-on-types stuff was purely for fun.
Re: DMD can implicitly convert class pointer to the bool. Is it bug or terrible feature?
On Sunday, 24 November 2013 at 19:59:51 UTC, Walter Bright wrote: On 11/24/2013 11:17 AM, bearophile wrote: From my experience that's quite bug-prone: http://d.puremagic.com/issues/show_bug.cgi?id=3878 I posted an objection there :-) But we can provide a syntax sugar for this case as was suggested in #9801.
Re: Static Foreach
On Sunday, 24 November 2013 at 20:22:05 UTC, Philippe Sigaud wrote: On Sun, Nov 24, 2013 at 9:06 PM, John Colvin john.loughran.col...@gmail.com wrote: You can have a look there: https://github.com/PhilippeSigaud/dranges/blob/master/tuple.d and https://github.com/PhilippeSigaud/dranges/blob/master/typetuple.d (this one was fun: regex on type tuples!) https://github.com/PhilippeSigaud/dranges/blob/master/typepattern.d I've been looking at that stuff recently :-) It's pretty cool, in particular the regex stuff. I'm wary of going overboard though, it's very tempting to keep adding functionality that is too obscure for a standard library. That's why I never tried to get it into Phobos :) And, truth is, I used almost none of it, even when most of this code is 4 years old. Mapping/filtering/reducing tuples is the most useful part. Yeah I'm mostly working around porting std.range and std.algorithm. They're a pretty good subset of useful things to do with sequences of things. Even so, I suspect come review people will want it pruned a little.
Re: Initializing two-dimensional compile-time enum
On Sun, Nov 24, 2013 at 8:09 PM, Uranuz neura...@gmail.com wrote:
As far as I understand I can't use immutable values as template arguments.
Indeed not. They are not defined at compile-time.
//Some template method
void foo(string arg)()
{ //Some actions here
}
void main()
{
foreach( name, item; pohodEnumValues )
{ foo!(name)(); //I need name at compile time here
}
}
//-
Because we have only compile time foreach over tuple this is not working.
Can someone give an advice, please?
I see some possibilities, but they might be a bit overkill. In
increasing order of coding effort:
1) use a tuple (as you suggest in another post)
2) use functions to build the code you want (as a string) and then mix
it in. Using functions, you can use iterative code as much as you
wish.
3) Another, more far-fetched, option is to use a struct. Since your AA
is defined at compile-time, I would not create an AA, but a struct,
crafting it to mimic your AA.
Re: DMD can implicitly convert class pointer to the bool. Is it bug or terrible feature?
On Sunday, 24 November 2013 at 14:12:18 UTC, Maxim Fomin wrote: On Sunday, 24 November 2013 at 14:02:43 UTC, ilya-stromberg wrote: On Sunday, 24 November 2013 at 13:57:22 UTC, Maxim Fomin wrote: This is neither bug not a terribale feature. Have you coded in C? Yes, only a little. I like D because it dissallow most of dangerous abbilities. We already have `is` operator for pointer comparison. Class doesn't provide cast to bool. So, why it's allowed? void* ptr; if(ptr) was a shortcut for 'if(ptr != NULL)' probably since C was created. No, it is a comparaison with 0. If NULL is 0 on all modern architectures I know of, this wasn't always the case. There is no problem with classes or pointers convertion to booleans in condition statements, it is not a dangerous ability. Is operator is not restricted to pointer comparison, you can use it to bitwise compare any objects. I'd like to know why this feature is dangerous as well.
Re: Initializing two-dimensional compile-time enum
But I can't undersatnd how to make some kind of compile-time variable. If we have advanced metaprogramming features I think possibility of defining compile-time variables is needed. Am I right or not? That's what we all want, but it's more or less impossible. If your variable do not change type, then you can at least build an array and store its successive values in the array. Then you use the last value for the rest of your computation. Or, as I said in another post, use Compile-Time Function Evaluation: using standard functions, you can be as iterative/imperative as you want.
