On Friday, 4 July 2014 at 21:08:27 UTC, Walter Bright wrote:
rewriting what C++ "best practices" are. To characterize all this churn as "stablility" is awfully charitable.

Pfft, a lot of performance C++ code is roughly in 1998 land without exceptions and rtti.

Uh-huh. And how much professional code have you seen that had #ifdef's for Vax fp in it? IBM fp? Future CPUs that don't exist yet? How many developers have access to a Vax to test their #ifdef's on?

It is not uncommon for portable DSP code to have ifdefs. It is not uncommon to have ifdefs for extracting the mantissa etc. Heck, even for uints you might need ifdefs, to account for whether you have wrapping uints or not in phase counters. (wrapping over 31 bits or 32 bits)

Considering that denormal numbers being flushed to zero is non-standard and not uncommon, it would be wise to somehow support it with version{}, so you can specify what assumptions a particular function make. That way you might get "not implemented" as a compile time error when porting to a new platform.

What you're implying is saying that when a spec says "implementation defined" then voila! the code is portable!

No, it says "voila! the code is not portable" and then you can inject your own guards that might prevent it from compiling on nonconforming platforms and let you know what you need to look at.

Sadly, this also implies that there are no computer languages you believe in. You set an impossible standard. How can you possibly say you prefer C++, a classic design by committee language?

I don't prefer it. I think it sucks, but it is the only viable choice if you want to create a scalable game or virtual world server. And since C++ is the crappy shit it is, you usually have to build a language on top of it to keep the server stable and modifiable and stay sane. A key benefit of a tighter version of D would be to avoid that extra layer IMO.

I'm asking you to contribute. These posts do not accomplish anything. Exhorting me to do more (I already work on D 24/7) cannot work.

Maybe you and Andrei could consider having other people do the stuff you don't have to do, but that other people can take care of? Because I think you and Andrei are the only ones who can spec out the changes that would make D a clean delightful language to use and get acceptance for it in the community.

The alternative is to fork it, cut down on features, clean up the syntax for DSL purposes, rip out the GC and add transactional memory support. I think the current process is too slow for outsiders to get D to production level in the domains where speed and stability truly matters.

Reply via email to