safeD
jerro
a at a.com
Sat Mar 9 12:47:03 PST 2013
On Saturday, 9 March 2013 at 19:47:12 UTC, Mark T wrote:
> On Saturday, 9 March 2013 at 19:07:31 UTC, jerro wrote:
>>> Is this suitable for embedded targets such as ARM Cortex 32
>>> bit?
>>
>> For ARM, your best bet is to follow this guide to build a GDC
>> cross-compiler (probably easiest to build on a Linux host):
>>
>> http://gdcproject.org/wiki/Cross%20Compiler/crosstool-NG
>>
>> I don't know what kind of ARM Cortex you have in mind and what
>> OS do you need to use. If you mean Cortex A8, A9 or A15 and if
>> your target OS is GNU/Linux, then you can use Druntime and
>> Phobos. I haven't used GDC on ARM enough to know if everything
>> in Druntime and Phobos works, but the parts that I have used
>> did work. In this case you should be able to SafeD too, as
>> it's just a subset of D.
>
> Thanks for the input - but where is SafeD defined?
It is described in "The D programming language book". There's
also something about it in "Programming in D" book, but that part
hasn't been translated to English yet. People have written about
SafeD in other places too, but I can't remember any.
> Is there a compiler switch?
There are attributes @safe, @trusted and @system, that are used
like this:
void foo() @safe
{
//some code
}
or
@safe
{
void foo() @safe{}
void bar() @safe{}
}
or (this will affect all the functions from @safe: to the end of
the scope):
@safe:
void foo(){}
void bar(){}
The code that is marked as safe can't use certain language
features (For example
pointer arithmetic and casting pointers - I haven't used @safe
enough to know all the restrictions) or call functions that are
marked @system. Also, some new restrictions (related to returning
by reference) will need to be added to @safe, because it was
recently discovered that it is currently possible to write @safe
code that is not actually memory safe.
@system and @trusted code can use all D features and call all
functions. The difference between them is that @trusted functions
can be called by @safe code and @system functions can not.
For templates, safety is inferred from implementation if there
are no attributes, and ordinary functions are considered @system
by default.
> I haven't looked at D in a while, it was just too big for ARM
> Cortex M, smaller PowerPC and similar targets - a google search
> got me to the SafeD topic.
If D needs to much memory or if the executables are too large for
your use case,
SafeD will not make it any better. It will actually make it
worse, because it makes manual memory management impossible (it
prohibits calling malloc or casting between pointer types), if
used consistently.
More information about the Digitalmars-d
mailing list