Mark Evans wrote:

> The embedded market is pretty huge but the tools are bad.  Typically embedded development tools are half-baked at best.  I've done lots of C embedded work and would love to have D at my disposal.

That's the nail.  We want D to be the hammer!

Long ago in this newsgroup I described my adventures as a minor participant in the EC++ (Embedded C++) standardization effort.  The initial spec was sensational, and a couple vendors implemented it, as did GCC.  But the spec didn't evolve as new ways to make efficient implementations of previously costly C++ features became available.  EC++ never became more than a "slightly better C", and is now used only by Japanese automakers, in conjunction with the uITRON OS (IIRC).

D is well on the path to becoming what EC++ should have been, what C++ itself could have been, and what Java or C# never could be:  "The killer OO language for embedded systems".

I feel it is important to go the extra mile to make it so.

BTW, embedded tools are indeed "half-baked".  They also tend to be quite expensive, both to acquire and maintain.  Yet most embedded compiler and tool vendors are starving (unless you happen to be WindRiver).  Why?  They are all shipping products that differ only slightly.  The main differences are who is "first" on a new processor, and they have to "buy in" with the chip maker to get preferential early access.  It is the nature of a "me too" market.

D is a whole new market.

Even if GCC-D takes off like a rocket, there will always be a significant embedded market for a complete and supported D tool set.  We're talking about a significant income opportunity for Digital Mars here!

But it won't exist if D don't do deep embedded!

And for now, that means a usable volatile and (hopefully) smarter bitfields.  You already have reasonably tight code that can get only tighter as the compiler evolves.

Other features for the embedded market:

1. Choice of output executable format ("naked binary", ELF, COFF, etc.)
2. Integration with other vendors tool suites (WindRiver, iLogix, etc.) and with as
much of the GNU suite as possible.
3. Targeted to lots and lots and lots and lots and lots and lots of processors!
(Start with ARM, MIPS and SH.)


-BobC

Amen to all of that.  D could be the killer app for the embedded market which still suffers tools that scarcely rise above K&R C...or even assembly.

Aren't the various processors just a back-end issue (though admittedly extra work)?  Walter might sell back-ends for various chips while the D front-end goes it merry open-source way.

Happy things to contemplate!

Mark

I certainly don't think of D so much of as a successor to C++ as it is a younger sibling rival to it.

Sean

"Mark Evans" <Mark_member@pathlink.com> wrote in message news:am7ri5$2i9d$1@digitaldaemon.com...
> OK so long as this technique distinguishes between templated classes with
bytes
> and bools as the template parameters.  I dislike the enum method, it's
just a
> shade better than #define TRUE 1.
>
> Maybe the thing to do is revisit the C++ standards committee's decision to incorporate bools into C++, and see whether the same arguments don't also
apply
> to D (which is a "better C++").
>
> Mark

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:am7njm$2dqf$1@digitaldaemon.com...
> Strangely, that's exactly my argument against making enum values have a scope that's inside the enum name.  We cannot make a user defined enum that's *not* scope-qualified, and I think that sucks.

It is possible by making them anonymous:

    enum { false, true }

Ok, awesome!

But then they don't have a distinct type;  at least not one you can access by name?

Maybe we can make a named enum and then a public accessor for it:

// has to be scope qualified
enum BoolType { false, true };
// anonymous enum with base type of BoolType
enum : BoolType { false = BoolType::false, true = BoolType::true };

Or maybe we could have a way to control whether the enum must be scope qualified or not.  It would save repetitive cut-n-paste.

Sean

"Walter" <walter@digitalmars.com> wrote in message news:amacma$2amr$1@digitaldaemon.com...
>
> "Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:am7njm$2dqf$1@digitaldaemon.com...
> > Strangely, that's exactly my argument against making enum values have a scope that's inside the enum name.  We cannot make a user defined enum that's *not* scope-qualified, and I think that sucks.
>
> It is possible by making them anonymous:
>
>     enum { false, true }

You could look at the committee decisions for almost any language and ask why they support booleans or not, then determine which arguments may apply to D.

I look upon D as an opportunity to "get a language right" and greatly appreciate Walter's openness to our inputs.  It may well be that he has the correct design as regards booleans.  I would certainly defer to his judgment as a language designer.

My input is that I appreciate the standardization offered by a true boolean type.  Otherwise everyone invents his own boolean, and that game wears a person out after many years of C.  I've seen TRUE==1, TRUE==0, TRUE==0x01010101, FALSE==-1, all kinds of weird stuff.

Mark


In article <am9dhi$17js$1@digitaldaemon.com>, Sean L. Palmer says...
>
>I certainly don't think of D so much of as a successor to C++ as it is a younger sibling rival to it.
>
>Sean
>
>"Mark Evans" <Mark_member@pathlink.com> wrote in message news:am7ri5$2i9d$1@digitaldaemon.com...
>> OK so long as this technique distinguishes between templated classes with
>bytes
>> and bools as the template parameters.  I dislike the enum method, it's
>just a
>> shade better than #define TRUE 1.
>>
>> Maybe the thing to do is revisit the C++ standards committee's decision to incorporate bools into C++, and see whether the same arguments don't also
>apply
>> to D (which is a "better C++").
>>
>> Mark
>
>
>

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:amadt0$2bu0$1@digitaldaemon.com...
> Ok, awesome!
> But then they don't have a distinct type;  at least not one you can access
> by name?

Correct.

> Maybe we can make a named enum and then a public accessor for it:
>
> // has to be scope qualified
> enum BoolType { false, true };
> // anonymous enum with base type of BoolType
> enum : BoolType { false = BoolType::false, true = BoolType::true };
>
> Or maybe we could have a way to control whether the enum must be scope qualified or not.  It would save repetitive cut-n-paste.

"Robert W. Cunningham" <FlyPG@users.sourceforge.net> wrote in message news:3D87FAEE.851E7FF6@users.sourceforge.net...
> Other features for the embedded market:
>
> 1. Choice of output executable format ("naked binary", ELF, COFF, etc.)

Does that matter, or does it matter simply to have a locator that can read any of those formats?

> 2. Integration with other vendors tool suites (WindRiver, iLogix, etc.)
and with as
> much of the GNU suite as possible.
> 3. Targeted to lots and lots and lots and lots and lots and lots of
processors!
> (Start with ARM, MIPS and SH.)

Hopefully that will fall out of making GnuD.

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:amadt0$2bu0$1@digitaldaemon.com...
> Ok, awesome!
>
> But then they don't have a distinct type;  at least not one you can access by name?
>
> Maybe we can make a named enum and then a public accessor for it:
>
> // has to be scope qualified
> enum BoolType { false, true };
> // anonymous enum with base type of BoolType
> enum : BoolType { false = BoolType::false, true = BoolType::true };

No double-colon operator here.
enum : BoolType { false = BoolType.false, true = BoolType.true };

But enums also has implicit conversions with int, hasn't they? And bool
still shouldn't have.
And the problem with the expression is that comparsion still don't yield a
boolean:

void foo(int a) { . }
void foo(BoolType a) { . }

BoolType b = (a > c);  // error
foo(a > c);   // which of the overloaded functions will be called?

Either enum or typedef you still can not create a new distinct type withouth implicit conversions.

"Mark Evans" <Mark_member@pathlink.com> wrote in message news:amb14m$31a8$1@digitaldaemon.com...
> My input is that I appreciate the standardization offered by a true
boolean
> type.  Otherwise everyone invents his own boolean, and that game wears a
person
> out after many years of C.  I've seen TRUE==1, TRUE==0, TRUE==0x01010101, FALSE==-1, all kinds of weird stuff.

D already has true and false defined as keywords, and they resolve to being expressions of type bit.