Stroustrup's talk on C++0x

[0ffh]

Ingo Oeser wrote:
> 0ffh wrote:
> But they had quite different properties/semantics. You should have noticed,
> that some architectures don't even have them and threat all IO as special
> memory accesses.

Sure did. Doesn't prevent the compiler from supporting it.
Some compilers support FP on architectures without FP. Good thing, too!

> Oh and some port i/o needs to slowed down, byte swapped, include barriers.
> How should a intrinsic handle that?

You normally use them as primitives and build more complex funs around.

> I mean special API for ENABLING port i/o for your task. How does the
> intrinsic know, whether you can actually DO port i/o in that task?

It can't and why should it?
BTW not all architectures (and all modes) need any special enabling.

> Inline assembler functions are much more suited to that task.

I have to use inline asm every time?
IIRC DMD doesn't inline funs with inline asm, so no good.

> That stuff isn't fast anyway, so the class overhead might not be
> too significant here, as long as it is bounded.

I wouldn't count on it.

Anyways my basic point is:

Why throw it out just because "99% don't need it anyway"?
It's there already, and some people are quite happy about it!

It does not in any way make DMD less usable for the "99%",
so why do you insist on treading on the "1%" minority?

Regards, Frank