Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > standard include files

Thread Tools

standard include files

Nick Keighley
Posts: n/a
On Feb 24, 1:30*pm, "io_x" <(E-Mail Removed)> wrote:
> "Robert Wessel" <(E-Mail Removed)> ha scritto nel messaggionews:8unek7d7up0l4c89rdi1itq4sie3p4se8b@4
> > On Fri, 24 Feb 2012 08:18:40 +0100, "io_x" <(E-Mail Removed)> wrote:

> >>"Kaz Kylheku" <(E-Mail Removed)> ha scritto nel messaggio
> >>news:(E-Mail Removed)...
> >>> If a translation unit includes no standard headers at all, should it be
> >>> defining ptrdiff_t, et cetera?

> >>> There is a case to be made for hosted implementations being free to define
> >>> all
> >>> the standard material even if no header is included at all.

> >>for resolve that problem one has to impose the names of standard .dll
> >>[where are all executable functions as printf malloc and all
> >>standard function]

> >>and rename all functions and variable of that file as
> >>thatStdFile_varibleOrFunctionName as thatStfFile_printf
> >>and nobody can use one file that has name thatStdFile...

> > Nonsense. *You're assuming the implementation has DLLs, and has the C
> > library in a DLL, and organized in a particular way. *None of which is
> > required.

> so you say standard C functions executable are not in any file
> [that has one name] of sys

they don't have to be in any particualr file. Which contary to what
you said earlier. Insisting that all library names are visible even if
header files aren't included imposes no particular implementation on
the implementor. he certainly doesn't have to use a DLL (some systems
don't ahve DLLs) and if does use a DLL he doesn't have to call it by a
standard name. he could just preload his symbol table with the
reserved library names.

Reply With Quote
Markus Wichmann
Posts: n/a
[Big snip]

And there I was hoping, you'd just misunderstand. But it's worse: You
don't want to understand. Maybe I didn't explain it good enough, but I
should at least have provided some incentive to research the matter. You
didn't do that but stubbornly remained at your position (which is very
close to "all the world is an x86 PC with MS Windows"). Well, scorefile

Reply With Quote
Kaz Kylheku
Posts: n/a
On 2012-03-01, Markus Wichmann <(E-Mail Removed)> wrote:
> And there I was hoping, you'd just misunderstand. But it's worse: You
> don't want to understand.

And thus squarely belongs here.
Reply With Quote
Posts: n/a
On 2/27/2012 5:06 PM, Robert Wessel wrote:
> On Mon, 27 Feb 2012 01:20:48 -0700, BGB<(E-Mail Removed)> wrote:
>> On 2/26/2012 9:39 PM, Robert Wessel wrote:
>>> On Sun, 26 Feb 2012 16:53:28 -0700, BGB<(E-Mail Removed)> wrote:
>>>> On 2/26/2012 3:15 PM, Keith Thompson wrote:
>>>>> Quentin Pope<(E-Mail Removed)> writes:
>>>>>> On Sun, 26 Feb 2012 10:31:50 -0700, BGB wrote:
>>>>>>> On 2/26/2012 12:17 AM, Robert Wessel wrote:
>>>>> [...]
>>>>>>>> zOS (IBM mainframe) C/C++ developers often use PDSs to store header
>>>>>>>> files - these make names longer than eight characters problematic, at
>>>>>>>> best. In fact C header files are often stored in a PDS dedicated to
>>>>>>>> headers, and the header name does not include the ".h".
>>>>>>> hmm... I had overlooked / was not aware of this.
>>>>>>> but, yes, IBM and their sometimes strangely arcane systems.
>>>>>> You are in good company with Mr Navia, who seems to believe that anyone
>>>>>> not running an x86 with blazing-fast hardware is unworthy to use the C
>>>>>> language.
>>>>> I fail to see how your criticism relates in any way to what BGB
>>>>> actually wrote.
>>>> yeah... the issue was not saying that IBM mainframes are slow, but more
>>>> the PDS thing, with 8 character name limits. nevermind things like
>>>> EBCDIC and similar. along with such things as "Token Ring" and "Twinax"
>>>> cabling.
>>>> and where COBOL is still alive and well...
>>>> nevermind fixed-field form and menu-driven systems (with absurd color
>>>> schemes) accessed via terminal emulators, ... all on presumably fairly
>>>> modern (PowerPC based) HW... (I had brief exposure to some this once
>>>> before...).
>>> IBM Mainframes (the S/360 line, "System z" now), is not at all PPC
>>> based.
>>> PPC (POWER) runs both of IBM's midrange lines, the *nix based System p
>>> (formerly RS/6000, pSeries, etc.), and now the System i (the old S/38,
>>> AS/400 minis). IIRC, IBM is rebranding both of those as "IBM Power
>>> Systems". The System i still has a fair bit of green screen support
>>> (5250's, rather than the 3270s seen on the mainframe systems).

>> well, yes, but will anyone try to disagree with me that it is all a bit
>> strange, if considered from the POV of Windows or Linux based PCs or
>> servers?...

> I don't know. An AIX or Linux based pSeries box is certainly no
> stranger than a Solaris, HP-UX, or any other *nix box. Sure it has
> some unique attributes, but then so does Solaris, HP-UX...
> Admittedly something running OS/400 ("IBM i" - hideous name) or zOS
> will look pretty strange to someone with a *nix or Windows background.
> But my major point was that mainframes aren't PPC/POWER.

ok, I just thought they were, for whatever reason.

IBM sells PPC, and IBM sells mainframes, one could infer them using the
same chips. can't seem to find much information on just what sort of CPU
they run though.

>>>> doesn't mean it is necessarily old or slow, but more the sorts of things
>>>> which would likely make most "sane" computer users (assuming they know
>>>> enough to understand it) to be all like "WTF is this?!" (like the
>>>> computer equivalent of some strange/alien landscape or something...).
>>>> hence, "arcane"...
>>>> and is maybe also part of why PowerPC is popular on game consoles: makes
>>>> it harder to pirate the games and run them on a PC in an emulator,
>>>> because they would run slowly (if it were x86 based, they could
>>>> potentially use partial OS or HW emulation via virtualization or
>>>> similar, but given it is a different ISA, it makes tolerable-performance
>>>> emulation much harder, so no one can just play pirated XBox360 or PS3
>>>> games on a desktop PC in an emulator, but have to go for the potentially
>>>> much more painful and expensive route of getting a "modded" game
>>>> console...).
>>> PPC has a considerable presence in embedded systems. Macs used to be
>>> PPC based as well. The three main console vendors all chose PPC, but
>>> for different reasons, and I don't think incompatibility with x86 was
>>> a major reason in any case. FWIW, the original xBox, was Pentium III
>>> based.

>> well, yes.
>> the XBox was also well known for being fairly easy to hack, and if one
>> got the right software, IIRC it was also possible to emulate XBox games
>> on the PC at reasonably decent performance (and with slight
>> wire-splicing, one could do so using the XBox controller as well, since
>> it was basically just a USB gamepad with a special connector).
>>> But PPC is anything but arcane.

>> probably depends on who you ask, or what it is compared to...
>> probably the most commonly well-understood architecture around is x86.
>> ARM systems are fairly common, but far fewer people in total probably
>> develop for them (and, IMHO, the Thumb/Thumb2 instruction codings are a
>> bit dubious, looking a fair amount like ad-hoc bit twiddly magic).
>> PPC is sort of in the background, as an architecture relatively few
>> people really deal with directly or develop for, more existing as a
>> piece of mystery hardware sitting in their PS3 or XBox360 or similar.
>> granted, yes, at the C level it probably doesn't look too much different
>>from one to the other, but the ASM is notably different.

> To be sure there's more x86 and ARM development, than say MIPS or PPC,
> but just because *you* aren't seeing them, doesn't mean that MIPS and
> PPC CPUs aren't in tens of thousands of devices. It's certain that
> there are far more ARM CPUs in the world than x86, and it wouldn't
> surprise me if there were more MIPS and PPC CPUs (than x86) as well.
> And lets not even talk about smaller stuff, like 8051s, PICs, and
> AVRs, that ship billions of units.

yes, but the issue is:
how many people develop for them;
vs, how many devices there are.

the thing is with most embedded devices, that maybe only a few
programmers write the software for a given device, and large numbers of
the units are sold to large numbers of people.

so, despite the large number of units, fewer people likely develop for
them in total.

x86 PC's, and more recently, and OS's running on ARM based devices (such
as Android and iOS), have probably a much larger pool of developers,
given that the architecture is much more open.

also, most PC code-bases tend towards being much larger, and hence more
people and more man-hours go into making them.

likewise, although some embedded systems run things like Linux, and game
consoles may use 3D engines like Unreal Engine and similar, both were
originally written for the PC, so their use on embedded systems and
similar doesn't really count.

Reply With Quote
Posts: n/a
On 3/3/2012 6:26 PM, William Ahern wrote:
> BGB<(E-Mail Removed)> wrote:
> <snip>
>> ok, I just thought they were, for whatever reason.
>> IBM sells PPC, and IBM sells mainframes, one could infer them using the
>> same chips. can't seem to find much information on just what sort of CPU
>> they run though.


interesting to note.

I was aware of an ISA being in use since the IBM System/360, but for
whatever reason had also thought it was a VM, rather than the actual ISA.

ok then.

Reply With Quote

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
/* #include <someyhing.h> */ => include it or do not include it?That is the question .... Andreas Bogenberger C Programming 3 02-22-2008 10:53 AM
#include headers that include this header Aguilar, James C++ 2 07-16-2004 05:56 PM
Re: the use of #include <a_file.h> v/s #include"a_file.cpp" Elie Nader C++ 1 11-28-2003 03:12 PM
Re: the use of #include <a_file.h> v/s #include"a_file.cpp" Rolf Magnus C++ 2 11-28-2003 12:26 PM
#include "bar" negates #include <string> ; how to fix? Danny Anderson C++ 5 08-15-2003 06:38 PM