core contains the stuff that is intrinsic to the D language. It's separate from std for a number of reasons, but one practical reason is to help prevent large portions of the standard library being pulled into all apps simply because something in the runtime code wanted to do formatted IO, for example. Think of core like java.lang.
Sent from my iPhone On Oct 31, 2011, at 1:34 AM, Manu <turkey...@gmail.com> wrote: > in std? what's the story with core? is it being deprecated? > I would think that cpuid should be a subset of a generalised sysinfo (or > processorinfo perhaps)... something you can optionally obtain if you first > identify that you're on an x86. > > Why would there be a 'higher level' module? I'd like a low level query like > that for all processors. It just seems weird having an x86-only feature > exposed directly in core. > > On 31 October 2011 09:11, Don <nos...@nospam.com> wrote: > On 30.10.2011 02:49, Manu wrote: > What's the deal with core.cpuid? > I realise it is an x86 opcode, but is that something that you really > want totally bare in core like that? > I'm experimenting with other architectures, and some sort of > core.processorInfo would be really nice, surely an API for this stuff > should be more generalised...? > > core.cpuid exists *because the runtime needs it*. It's deliberately _very_ > low level. For example, it is essential that it does NOT perform any memory > allocation. The information it provides is CPU-dependent. > > Basically -- don't use core.cpuid unless you're programming in asm. > > Indeed, there should be a higher level module (std.sysinfo ?) for more > general use. > > > > > >
