www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - core.cpuid

reply Manu <turkeyman gmail.com> writes:
--0016364271143e490404b0797d26
Content-Type: text/plain; charset=UTF-8

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...?

--0016364271143e490404b0797d26
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

What&#39;s the deal with core.cpuid?<div>I realise it is an x86 opcode, but=
 is that something that you really want totally bare in core like that?</di=
v><div>I&#39;m experimenting with other architectures, and some sort of cor=
e.processorInfo would be really nice, surely an API for this stuff should b=
e more generalised...?</div>

--0016364271143e490404b0797d26--
Oct 29 2011
next sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
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...?

That module was probably designed around the assumption that D would never run on !x86 architectures, which is clearly not the case with GDC existing... - Alex
Oct 29 2011
parent reply Dejan Lekic <dejan.lekic gmail.com> writes:
Manu wrote:

 Seems like a horrible assumption to make when inventing a systems
 programming language that intends to go head to head with C/C++ :)
 

FYI, C/C++ also have cpuid, and it is also pretty low-level like in D (ie. developers rarely use cpuid.h directly). You should not (in practice) use "core" modules anyway.
Nov 04 2011
next sibling parent Dejan Lekic <dejan.lekic gmail.com> writes:
Jonathan M Davis wrote:

 
 And why not? Thread is in core. So are other modules that it's perfectly

- Mostly because You may end-up writing non-portable code unless you are realy careful (and you must be if you use core modules! ;). It is similar to the asm{} block - you should not use it at all unless you know what you are doing... Does that make sense?
Nov 04 2011
prev sibling parent Don <nospam nospam.com> writes:
On 04.11.2011 18:27, Jonathan M Davis wrote:
 On Friday, November 04, 2011 08:11 Dejan Lekic wrote:
 Manu wrote:
 Seems like a horrible assumption to make when inventing a systems
 programming language that intends to go head to head with C/C++ :)

FYI, C/C++ also have cpuid, and it is also pretty low-level like in D (ie. developers rarely use cpuid.h directly). You should not (in practice) use "core" modules anyway.

And why not? Thread is in core. So are other modules that it's perfectly normal and acceptable to use. There's nothing wrong with using core modules. Many of them are _intended_ to be used. Stuff generally ends up in core because the D runtime needs it, not because it's something that the common programmer shouldn't be using.

That's largely true, but I would agree with Manu that you shouldn't be using core very often. By its nature of being close to the runtime, it's typically low-level stuff, and so it's only your low-level code which should be using it. Probably there is some stuff in there which should be moved out of core, or possibly with a safer wrapper in std. I'm particularly thinking of core.bitop, which currently has a mixture of safe and subtly dangerous functions, and only a small part of it is actually required by the runtime.
Nov 04 2011
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--001636427114624e6404b0799af4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Seems like a horrible assumption to make when inventing a systems
programming language that intends to go head to head with C/C++ :)

On 30 October 2011 03:51, Alex R=C3=B8nne Petersen <xtzgzorex gmail.com> wr=
ote:

 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...?

That module was probably designed around the assumption that D would neve=

 run on !x86 architectures, which is clearly not the case with GDC
 existing...

 - Alex

--001636427114624e6404b0799af4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Seems like a horrible assumption to make when inventing a systems programmi= ng language that intends to go head to head with C/C++ :)<br><br><div class= =3D"gmail_quote">On 30 October 2011 03:51, Alex R=C3=B8nne Petersen <span d= ir=3D"ltr">&lt;<a href=3D"mailto:xtzgzorex gmail.com">xtzgzorex gmail.com</= a>&gt;</span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;"><div><div></div><div class=3D"h5">On 30-10-= 2011 02:49, Manu wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> What&#39;s the deal with core.cpuid?<br> I realise it is an x86 opcode, but is that something that you really<br> want totally bare in core like that?<br> I&#39;m experimenting with other architectures, and some sort of<br> core.processorInfo would be really nice, surely an API for this stuff<br> should be more generalised...?<br> </blockquote> <br></div></div> That module was probably designed around the assumption that D would never = run on !x86 architectures, which is clearly not the case with GDC existing.= ..<br><font color=3D"#888888"> <br> - Alex<br> </font></blockquote></div><br> --001636427114624e6404b0799af4--
Oct 29 2011
prev sibling next sibling parent reply "Chante" <udontspamme never.will.u> writes:
"Manu" <turkeyman gmail.com> wrote in message 
news:mailman.586.1319935753.24802.digitalmars-d puremagic.com...

 What's the deal with core.cpuid?

I think they just want the "mainstream" ("sheeple"/"followers"/"believers"/"90210_ers"/"younsters", etc.). If you don't fit into their petri-dish and aren't cog to add to their self-aggrandizement, they won't let you log in anymore.
Oct 29 2011
parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 30-10-2011 06:05, Andrew Wiley wrote:
 On Sat, Oct 29, 2011 at 10:55 PM, Chante <udontspamme never.will.u> wrote:


     "Manu" <turkeyman gmail.com <mailto:turkeyman gmail.com>> wrote in
     message
     news:mailman.586.1319935753.24802.digitalmars-d puremagic.com...

      > What's the deal with core.cpuid?

     I think they just want the "mainstream"
     ("sheeple"/"followers"/"believers"/"90210_ers"/"younsters", etc.).
     If you
     don't fit into their petri-dish and aren't cog to add to their
     self-aggrandizement, they won't let you log in anymore.



 There are a few things like this around, and if you look far enough
 back, it's quite simple why things like this happened. Originally, when
 D was new, DMD essentially was the definition of D, x86 was the only
 real architecture around, with x86_64 starting to come into play. Now we
 have more compilers, and x86/64 isn't looking quite like the monopoly it
 used to be, so this interface will probably need to change.

 There's no conspiracy here, it's just "what worked" back in the day, and
 either it's unused or unimportant such that no one has tried to update
 it thus far. Since this is in core, it's mostly Sean's territory, but
 I'm sure he'd welcome ideas.

I actually do use core.cpuid and find it very useful. I think what we need to do is have separate modules for the various architectures, and then have some central wrapper module that wraps the common stuff that most archs share (i.e. "are we using 64-bit pointers?", etc...). We still need to keep the modules with more arch-specific checks public, because someone might actually need to use that information (in my case, I need it to decide which instructions I can emit in my JIT compiler). Speaking of all this, we really need to standardize version identifiers for !x86 architectures in the web site... - Alex
Oct 30 2011
parent "Chante" <udontspamme never.will.u> writes:
Alex Rønne Petersen wrote:
 On 30-10-2011 06:05, Andrew Wiley wrote:
 On Sat, Oct 29, 2011 at 10:55 PM, Chante <udontspamme never.will.u>
 wrote: "Manu" <turkeyman gmail.com <mailto:turkeyman gmail.com>> wrote
     in message
     news:mailman.586.1319935753.24802.digitalmars-d puremagic.com...

      > What's the deal with core.cpuid?

     I think they just want the "mainstream"
     ("sheeple"/"followers"/"believers"/"90210_ers"/"younsters",
     etc.). If you
     don't fit into their petri-dish and aren't cog to add to their
     self-aggrandizement, they won't let you log in anymore.



 There are a few things like this around, and if you look far enough
 back, it's quite simple why things like this happened. Originally,
 when D was new, DMD essentially was the definition of D, x86 was the 
 only
 real architecture around, with x86_64 starting to come into play.
 Now we have more compilers, and x86/64 isn't looking quite like the
 monopoly it used to be, so this interface will probably need to
 change. There's no conspiracy here, it's just "what worked" back in 
 the day,
 and either it's unused or unimportant such that no one has tried to
 update it thus far. Since this is in core, it's mostly Sean's 
 territory, but
 I'm sure he'd welcome ideas.

I actually do use core.cpuid and find it very useful.

You are a stupid man. She is an old hag.
Oct 30 2011
prev sibling next sibling parent reply Andrew Wiley <wiley.andrew.j gmail.com> writes:
--00151774036ab3402004b07d1135
Content-Type: text/plain; charset=ISO-8859-1

On Sat, Oct 29, 2011 at 10:55 PM, Chante <udontspamme never.will.u> wrote:

 "Manu" <turkeyman gmail.com> wrote in message
 news:mailman.586.1319935753.24802.digitalmars-d puremagic.com...

 What's the deal with core.cpuid?

I think they just want the "mainstream" ("sheeple"/"followers"/"believers"/"90210_ers"/"younsters", etc.). If you don't fit into their petri-dish and aren't cog to add to their self-aggrandizement, they won't let you log in anymore.

it's quite simple why things like this happened. Originally, when D was new, DMD essentially was the definition of D, x86 was the only real architecture around, with x86_64 starting to come into play. Now we have more compilers, and x86/64 isn't looking quite like the monopoly it used to be, so this interface will probably need to change. There's no conspiracy here, it's just "what worked" back in the day, and either it's unused or unimportant such that no one has tried to update it thus far. Since this is in core, it's mostly Sean's territory, but I'm sure he'd welcome ideas. --00151774036ab3402004b07d1135 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On Sat, Oct 29, 2011 at 10:55 PM, Chante <span d= ir=3D"ltr">&lt;udontspamme never.will.u&gt;</span> wrote:<br><blockquote cl= ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p= adding-left:1ex;"> <br> &quot;Manu&quot; &lt;<a href=3D"mailto:turkeyman gmail.com">turkeyman gmail= .com</a>&gt; wrote in message<br> news:mailman.586.1319935753.24802.digitalmars-d puremagic.com...<br> <div class=3D"im"><br> &gt; What&#39;s the deal with core.cpuid?<br> <br> </div>I think they just want the &quot;mainstream&quot;<br> (&quot;sheeple&quot;/&quot;followers&quot;/&quot;believers&quot;/&quot;9021= 0_ers&quot;/&quot;younsters&quot;, etc.). If you<br> don&#39;t fit into their petri-dish and aren&#39;t cog to add to their<br> self-aggrandizement, they won&#39;t let you log in anymore.<br> <br> <br></blockquote><div><br></div><div>There are a few things like this aroun= d, and if you look far enough back, it&#39;s quite simple why things like t= his happened. Originally, when D was new, DMD essentially was the definitio= n of D, x86 was the only real architecture around, with x86_64 starting to = come into play. Now we have more compilers, and x86/64 isn&#39;t looking qu= ite like the monopoly it used to be, so this interface will probably need t= o change.</div> <div><br></div><div>There&#39;s no conspiracy here, it&#39;s just &quot;wha= t worked&quot; back in the day, and either it&#39;s unused or unimportant s= uch that no one has tried to update it thus far. Since this is in core, it&= #39;s mostly Sean&#39;s territory, but I&#39;m sure he&#39;d welcome ideas.= =A0</div> </div> --00151774036ab3402004b07d1135--
Oct 29 2011
parent "Chante" <udontspamme never.will.u> writes:
"Andrew Wiley" <wiley.andrew.j gmail.com> wrote in message 
news:mailman.591.1319951129.24802.digitalmars-d puremagic.com...
 On Sat, Oct 29, 2011 at 10:55 PM, Chante <udontspamme never.will.u> 
 wrote:

 "Manu" <turkeyman gmail.com> wrote in message
 news:mailman.586.1319935753.24802.digitalmars-d puremagic.com...

 What's the deal with core.cpuid?

I think they just want the "mainstream" ("sheeple"/"followers"/"believers"/"90210_ers"/"younsters", etc.). If you don't fit into their petri-dish and aren't cog to add to their self-aggrandizement, they won't let you log in anymore.

back, it's quite simple why things like this happened. Originally, when D was new, DMD essentially was the definition of D, x86 was the only real architecture around, with x86_64 starting to come into play. Now we have more compilers, and x86/64 isn't looking quite like the monopoly it used to be, so this interface will probably need to change. There's no conspiracy here, it's just "what worked" back in the day, and either it's unused or unimportant such that no one has tried to update it thus far. Since this is in core, it's mostly Sean's territory, but I'm sure he'd welcome ideas.

I didn't call you anything.
Oct 30 2011
prev sibling next sibling parent reply Don <nospam nospam.com> writes:
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.
Oct 31 2011
parent Don <nospam nospam.com> writes:
On 31.10.2011 09:34, Manu 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.

It isn't entirely x86 specific. There are some stubs for other processors (and there's a few things in there which are Itanium-specific).
 On 31 October 2011 09:11, Don <nospam nospam.com
 <mailto:nospam 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.

Oct 31 2011
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--0016e648ffa408b38904b0941d9b
Content-Type: text/plain; charset=UTF-8

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 <nospam 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.

--0016e648ffa408b38904b0941d9b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable in std? what&#39;s the story with core? is it being deprecated?<div>I would= think that cpuid should be a subset of a generalised sysinfo (or processor= info perhaps)... something you can optionally obtain if you first identify = that you&#39;re on an x86.</div> <div><br></div><div>Why would there be a &#39;higher level&#39; module? I&#= 39;d like a low level query like that for all processors. It just seems wei= rd having an x86-only feature exposed directly in core.</div><div><br><div = class=3D"gmail_quote"> On 31 October 2011 09:11, Don <span dir=3D"ltr">&lt;<a href=3D"mailto:nospa= m nospam.com">nospam nospam.com</a>&gt;</span> wrote:<br><blockquote class= =3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd= ing-left:1ex;"> <div class=3D"im">On 30.10.2011 02:49, Manu wrote:<br> </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex"><div class=3D"im"> What&#39;s the deal with core.cpuid?<br></div><div class=3D"im"> I realise it is an x86 opcode, but is that something that you really<br> want totally bare in core like that?<br> I&#39;m experimenting with other architectures, and some sort of<br> core.processorInfo would be really nice, surely an API for this stuff<br> should be more generalised...?<br> </div></blockquote> <br> core.cpuid exists *because the runtime needs it*. It&#39;s deliberately _ve= ry_ low level. For example, it is essential that it does NOT perform any me= mory allocation. The information it provides is CPU-dependent.<br> <br> Basically -- don&#39;t use core.cpuid unless you&#39;re programming in asm.= <br> <br> Indeed, there should be a higher level module (std.sysinfo ?) for more gene= ral use.<br> <br> <br> <br> <br> <br> </blockquote></div><br></div> --0016e648ffa408b38904b0941d9b--
Oct 31 2011
prev sibling next sibling parent Sean Kelly <sean invisibleduck.org> writes:
--Apple-Mail-DB04D2FA-B316-453D-BDD1-29A3C10999E6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

core contains the stuff that is intrinsic to the D language. It's separate f=
rom 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 be=
cause something in the runtime code wanted to do formatted IO, for example. T=
hink of core like java.lang.=20

Sent from my iPhone

On Oct 31, 2011, at 1:34 AM, Manu <turkeyman 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 p=

entify that you're on an x86.
=20
 Why would there be a 'higher level' module? I'd like a low level query lik=

posed directly in core.
=20
 On 31 October 2011 09:11, Don <nospam 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...?
=20
 core.cpuid exists *because the runtime needs it*. It's deliberately _very_=

allocation. The information it provides is CPU-dependent.
=20
 Basically -- don't use core.cpuid unless you're programming in asm.
=20
 Indeed, there should be a higher level module (std.sysinfo ?) for more gen=

=20
=20
=20
=20
=20
=20

--Apple-Mail-DB04D2FA-B316-453D-BDD1-29A3C10999E6 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8 <html><head></head><body bgcolor="#FFFFFF"><div>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.&nbsp;<br><br>Sent from my iPhone</div><div><br>On Oct 31, 2011, at 1:34 AM, Manu &lt;<a href="mailto:turkeyman gmail.com">turkeyman gmail.com</a>&gt; wrote:<br><br></div><div></div><blockquote type="cite"><div>in std? what's the story with core? is it being deprecated?<div>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.</div> <div><br></div><div>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.</div><div><br><div class="gmail_quote"> On 31 October 2011 09:11, Don <span dir="ltr">&lt;<a href="mailto:nospam nospam.com">nospam nospam.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div class="im">On 30.10.2011 02:49, Manu wrote:<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"> What's the deal with core.cpuid?<br></div><div class="im"> I realise it is an x86 opcode, but is that something that you really<br> want totally bare in core like that?<br> I'm experimenting with other architectures, and some sort of<br> core.processorInfo would be really nice, surely an API for this stuff<br> should be more generalised...?<br> </div></blockquote> <br> 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.<br> <br> Basically -- don't use core.cpuid unless you're programming in asm.<br> <br> Indeed, there should be a higher level module (std.sysinfo ?) for more general use.<br> <br> <br> <br> <br> <br> </blockquote></div><br></div> </div></blockquote></body></html> --Apple-Mail-DB04D2FA-B316-453D-BDD1-29A3C10999E6--
Oct 31 2011
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, November 04, 2011 08:11 Dejan Lekic wrote:
 Manu wrote:
 Seems like a horrible assumption to make when inventing a systems
 programming language that intends to go head to head with C/C++ :)

FYI, C/C++ also have cpuid, and it is also pretty low-level like in D (ie. developers rarely use cpuid.h directly). You should not (in practice) use "core" modules anyway.

And why not? Thread is in core. So are other modules that it's perfectly normal and acceptable to use. There's nothing wrong with using core modules. Many of them are _intended_ to be used. Stuff generally ends up in core because the D runtime needs it, not because it's something that the common programmer shouldn't be using. - Jonathan M Davis
Nov 04 2011
prev sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, November 04, 2011 10:39 Dejan Lekic wrote:
 Jonathan M Davis wrote:
 And why not? Thread is in core. So are other modules that it's perfectly

- Mostly because You may end-up writing non-portable code unless you are realy careful (and you must be if you use core modules! ;). It is similar to the asm{} block - you should not use it at all unless you know what you are doing... Does that make sense?

Plenty of core is portable. True, very little in Phobos is non-portable, so there's less risk of portability issues with Phobos, but much of druntime is quite portable - Thread being one such example. It's primarily the C declarations which aren't necessarily portable. Most of the D code is. Now, it _is_ ultimately to the programmer to be smart about what they're doing, and more stuff in druntime is non-portable than in Phobos, but it's generally pretty clear about what's portable and what isn't. I really don't think that there's any need to tell people to stay away from core. If anything, they'll stay often away from it simply because much of its functionality is not directly necessary (if necessary at all) in your average program. But if you need it, there's nothing wrong with using it, and on the whole, portability isn't a huge issue. - Jonathan M Davis
Nov 04 2011