Is Perl written in C?

[Man-wai Chang]

Just curious...

--
@~@ You have the right to remain silence.
/ v \ Simplicity is Beauty! May the Force and farces be with you!
/( _ )\ (Fedora 15 i686) Linux 3.2.6
^ ^ 22:12:02 up 8 days 9:09 0 users load average: 0.01 0.03 0.05
ä¸å€Ÿè²¸! ä¸è©é¨™! ä¸æ´äº¤! ä¸æ‰“交! ä¸æ‰“劫! ä¸è‡ªæ®º! è«‹è€ƒæ…®ç¶œæ´ (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa

 

[Man-wai Chang]

Why do you think a C++ group is the best place to ask about Perl and C?

OK, as I have nothing better to do at the moment, I copy-pasted your

Apologize for this.

question into google and now copy-pasting the result back: "Perl is
implemented as a core interpreter, written in C, together with a large
collection of modules, written in Perl and C."

Thanks.

--
@~@ You have the right to remain silence.
/ v \ Simplicity is Beauty! May the Force and farces be with you!
/( _ )\ (Fedora 15 i686) Linux 3.2.6
^ ^ 22:37:02 up 8 days 9:34 0 users load average: 0.07 0.08 0.05
ä¸å€Ÿè²¸! ä¸è©é¨™! ä¸æ´äº¤! ä¸æ‰“交! ä¸æ‰“劫! ä¸è‡ªæ®º! è«‹è€ƒæ…®ç¶œæ´ (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa

 

[Man-wai Chang]

Why do you think a C++ group is the best place to ask about Perl and C?

I figured out maybe 2 good reasons:

1. resources
2. security

I think C is the basic building blocks for a lot of high-level languages
like Perl. Python? Ruby? PHP?

--
@~@ You have the right to remain silence.
/ v \ Simplicity is Beauty! May the Force and farces be with you!
/( _ )\ (Fedora 15 i686) Linux 3.2.6
^ ^ 22:37:02 up 8 days 9:34 0 users load average: 0.07 0.08 0.05
ä¸å€Ÿè²¸! ä¸è©é¨™! ä¸æ´äº¤! ä¸æ‰“交! ä¸æ‰“劫! ä¸è‡ªæ®º! è«‹è€ƒæ…®ç¶œæ´ (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa

 

[BGB]

There are only two kinds of languages:

1. C/C++
2. Languages that are themselves written in C/C++

With one small exception being Apple, Inc.'s reality distortion field
where lots of stuff gets coded using the Objective-C oddity.

well, except that Objective-C still has a C core...
so, C isn't really escaped.


but, yeah, it is fairly rare to find an HLL which isn't itself
implemented using C or C++.

even the JVM / JDK: despite Java being competition to C and C++, doesn't
mean the core of their VM isn't written using it.


my own scripting VM is written mostly in C, apart from the parts written
in assembler (typically not directly, as there is an in-program
assembler and a lot of procedural code generation going on using ASM...).

 

[jacob navia]

Le 03/03/12 16:23, Sam a écrit :

There are only two kinds of languages:

1. C/C++

You can eliminate the C++ here since C++ compilers are written in C...



(Look at the gcc sources for instance)

The lcc C compiler is also written in C.

2. Languages that are themselves written in C/C++

For instance C itself. Since ages the portable c compiler
(pcc) was written in C and was the first c compiler ever written.

With one small exception being Apple, Inc.'s reality distortion field
where lots of stuff gets coded using the Objective-C oddity.

the Objective C language is much better than C++

And now, let the flame war start here

 

[BGB]

clang/llvm is a C++ compiler written in C++. There's not a line of C as far
as I can tell. Although, I haven't looked too hard because all the
inheritance and casting makes my eyes bleed. For every line of code that
builds or processes the AST there's 12 lines of C++ boilerplate. I'm
undecided on whether it's preferable to the macro nightmare that is GCC.

yeah.

I looked briefly at LLVM before, and it looked sort of like someone was
all like "C++ isn't like Java enough, we sort of need to do it more like
Java, but more badly...".

I didn't really like it all that much, and didn't really agree with the
architecture (I more like more clearly defined components and stages),
so mostly have been doing my own VM and code-generation stuff (with a
much smaller codebase as well, granted I don't support nearly so many
targets or features, but whatever...).

my stuff (in these areas) is nearly all C though.

 

[Juha Nieminen]

I have personally worked on a Pascal compiler that was written in
Pascal, and assemblers galore written in assembler. As C wasn't the
first HLL there will be a number of languages written in something else.
I'm pretty sure there are Ada compilers written in ADA.

I think it depends on the system too. For example on Linux (and many
unixes) there's probably not a single executable that doesn't depend on
(and use) libc.so. I wouldn't be surprised if an ADA executable compiled
with an ADA compiler wouldn't depend on libc.so on Linux.

 

[Juha Nieminen]

I looked briefly at LLVM before, and it looked sort of like someone was
all like "C++ isn't like Java enough, we sort of need to do it more like
Java, but more badly...".

What's the point in using C++ if you will be writing in Java anyways?

 

[Juha Nieminen]

clang/llvm is a C++ compiler written in C++. There's not a line of C as far
as I can tell.

I would be surprised if there wasn't a single line that's valid C.

Perhaps you meant something like "there's not a single source file that
would compile as C".

 

[BGB]

What's the point in using C++ if you will be writing in Java anyways?

I am not saying anyone was using Java, rather LLVM seemed to have been
written in a vaguely Java-like style, with one-class-per-file, large
numbers to includes to include each header file, ...

the contrast is to basically dump a bunch of class definitions into
shared headers, and maybe aggregate classes in source-files as well, ...

then, one breaks things up, like say when the files get longer than
1000-2000 lines and start getting unwieldy.


as well as probably doing the thing of making "compound headers", where
one includes a single header and gets all relevant headers for the
entire library, without having to include them individually (the
compound header includes all sub-headers).

the advantage to the above is that it only requires a single
include-line per source file (and helps keep everything more
consistent). a disadvantage though is that of typically longer build times.


going and looking back at the code though (quickly skimming some), I may
have been mistaken:
there are cases of multiple classes per file.

I had vaguely thought I also remembered a lack of include guards, but
checking again, the headers do seem to have them.


or such...

 

[Guest]

I am not saying anyone was using Java, rather LLVM seemed to have been
written in a vaguely Java-like style, with one-class-per-file, large
numbers to includes to include each header file, ...

one-class-per-file is quite a common way to package C++. I wouldn't describe it as Java-like.

the contrast is to basically dump a bunch of class definitions into
shared headers, and maybe aggregate classes in source-files as well, ...

then, one breaks things up, like say when the files get longer than
1000-2000 lines and start getting unwieldy.

as well as probably doing the thing of making "compound headers", where
one includes a single header and gets all relevant headers for the
entire library, without having to include them individually (the
compound header includes all sub-headers).

the advantage to the above is that it only requires a single
include-line per source file (and helps keep everything more
consistent). a disadvantage though is that of typically longer build times.

<snip>

 

[BGB]

one-class-per-file is quite a common way to package C++. I wouldn't describe it as Java-like.

it is found in some code-bases, but is far from universal.
for example, Doom3 is C++, and it doesn't follow this convention.
likewise for many other programs using C++.


Java mandates using one-class-per-file by its design, and people who
also follow this convention rarely use top-level functions, ...

C++ code using one-class-per-file tends to gain a vaguely Java-like
appearance, or at least brings up the annoyance of having to open up
lots of text editors in order to look over the code.


personally, I prefer currently around 1000-2000 lines of code per file
(as a limit, ideal IMO is maybe closer to 500-1000 lines), as this makes
it less annoying to deal with (when reading code).

much past 1000-2000 lines, scrolling gets a bit annoying.

 

[Miles Bader]

it is found in some code-bases, but is far from universal.
for example, Doom3 is C++, and it doesn't follow this convention.
likewise for many other programs using C++.

He didn't say it was universal, he said it was quite common.
Which is true... [obviously the existence of counter-examples doesn't
invalidate that!]

C++ code using one-class-per-file tends to gain a vaguely Java-like
appearance, or at least brings up the annoyance of having to open up
lots of text editors in order to look over the code.

I've found one-class-per-file style organization to be _vastly_ more
usable, actually, because you always have a pretty good idea where
things are.

By contrast, I've had miserable (and memborable) experiences trying to
browse code written in a "stuff tons of classes in each file" style,
because I could never really be sure where to find a given class.

Obviously the above is my personable experience, and maybe yours has
been different. Really the important thing is _some_ kind of consistent
and simple mapping between class and location. It doesn't have to be
one-class-per-file; if a source-base has coarser-grained units than
classes that can reasonably fit into files, those would work too. But
_something_....

[Beyond that, I guess it depends on your environment; if your text
editor is particularly bad at opening new files, but is good at
searching, then big files may seem nicer. Conversely, an editor that
is particularly good at file browsing may make smaller files seem more
pleasant.]

-miles

 

[BGB]

it is found in some code-bases, but is far from universal.
for example, Doom3 is C++, and it doesn't follow this convention.
likewise for many other programs using C++.

He didn't say it was universal, he said it was quite common.
Which is true... [obviously the existence of counter-examples doesn't
invalidate that!]

well, this comes down mostly to how common vs uncommon it is...

I've found one-class-per-file style organization to be _vastly_ more
usable, actually, because you always have a pretty good idea where
things are.

By contrast, I've had miserable (and memborable) experiences trying to
browse code written in a "stuff tons of classes in each file" style,
because I could never really be sure where to find a given class.

Obviously the above is my personable experience, and maybe yours has
been different. Really the important thing is _some_ kind of consistent
and simple mapping between class and location. It doesn't have to be
one-class-per-file; if a source-base has coarser-grained units than
classes that can reasonably fit into files, those would work too. But
_something_....

generally, one knows where things are, first by general location
(namely: which library/component owns it), followed by contextual
information (things go in files with names related to what they are doing).

I personally make fairly heavy use of naming conventions though, so
where something is, is often readily visible by what it is named (given
much of the code-base is plain C, namespaces are not really in common
use, so a naming convention is in use where typically the name of the
library and component is used for everything).

[Beyond that, I guess it depends on your environment; if your text
editor is particularly bad at opening new files, but is good at
searching, then big files may seem nicer. Conversely, an editor that
is particularly good at file browsing may make smaller files seem more
pleasant.]

Windows can only really conveniently have about 50 windows open, and
scrolls really slowly trying to access more, requiring closing editors
to close them.

one also typically doesn't really get "lost" in a 1000 line file (this
is more the domain of 10,000 line files (or larger), where one has to
start using the "find" feature to find stuff, rather than being able to
esily just scroll over to it). I am not exactly advocating using giant
files here.


however, wasting lots of time endlessly opening files and closing stale
editors can also get fairly annoying, and so it may be less annoying to
instead put things in preexisting files, if they make sense there.


stuff is generally split and merge, as-needed, based mostly on size.
if scrolling starts getting annoying, it may be time to split, and if
the files are tiny, merging may be considered.

or, at least, this is how I see it.
typically, "libraries" are similar, where I don't generally like having
much more than 25-50 kloc in a given library, as this starts making it
cumbersome (granted, I have a 150 kloc library, but this is mostly
because about 115 kloc of this is due to SQLite...).


granted, often if may not make a huge difference:
if the class contents are roughly 1000 lines, then they end up matching
fairly well.

if the class goes too much over, one can split the contents over
multiple files.

usually then, aggregation is used when things are getting small, like it
is annoying and wasteful to have a whole header file for a 10 line class
definition, or a source file for something like 50 lines of code.

 

[Ian Collins]

it is found in some code-bases, but is far from universal.
for example, Doom3 is C++, and it doesn't follow this convention.
likewise for many other programs using C++.

Never the less, it is still common and many small files more more
parallel/distributed build friendly.

Java mandates using one-class-per-file by its design, and people who
also follow this convention rarely use top-level functions, ...

C++ code using one-class-per-file tends to gain a vaguely Java-like
appearance, or at least brings up the annoyance of having to open up
lots of text editors in order to look over the code.

Ever heard of tabs? I have precisely one editor open.

personally, I prefer currently around 1000-2000 lines of code per file
(as a limit, ideal IMO is maybe closer to 500-1000 lines), as this makes
it less annoying to deal with (when reading code).

It's a lot quicker to font the SomeClass tab than look for the class in
a big file.

 

[Miles Bader]

[Beyond that, I guess it depends on your environment; if your text
editor is particularly bad at opening new files, but is good at
searching, then big files may seem nicer. Conversely, an editor that
is particularly good at file browsing may make smaller files seem more
pleasant.]

Windows can only really conveniently have about 50 windows open, and
scrolls really slowly trying to access more, requiring closing editors
to close them. ....
however, wasting lots of time endlessly opening files and closing
stale editors can also get fairly annoying, and so it may be less
annoying to instead put things in preexisting files, if they make
sense there.

See, your entire way of thinking about it is based on the particular
behavior of your editor(s).

Not all editors are so simplistic. In particular, there's no
need for each file to have it's own editor or window (or tab).

[I often have many hundreds of files open at once, and don't even really
_notice_ how many there are...]

-Miles

 

[BGB]

Never the less, it is still common and many small files more more
parallel/distributed build friendly.

I think it depends some on the project.

some projects use it, some don't, and some are hit or miss (switching
between styles fairly inconsistently).


as for distributed builds:
there is no shortage of files in a project.


as noted, I am not advocating creating giant files, I am mostly saying
that one doesn't need a strict 1:1 mapping.

where this matters mostly is in the case of tiny classes, which is a
pattern which sometimes pops up (say, random class which maybe only has
a few members). does one really need a dedicated file for, say, 10 or 20
lines of code? I think it would be a waste.


more so, it can go the other way as well:
a particularly large class may well make sense being spread across
several files, vs being all like "well, this class source-file has 3000
lines, but one-class-per-file mandates I can't split up the code...".


for example, randomly going and looking at some files in Mozilla:
I have found a few small files;
I found a few others which were sufficiently large, where I would
probably split them (> 2000 lines);
the majority seem to be fairly well within the ideal range, so little
would likely be changed.

Ever heard of tabs? I have precisely one editor open.


It's a lot quicker to font the SomeClass tab than look for the class in
a big file.

I partly disagree, but it may depend on the editor.

the main editor I am using is Notepad2.

I also have Visual Studio, but don't often use it as much as an editor
as it is prone to lag slightly and be annoying. VS has tabs, but I don't
think they are really any more usable than the Windows task bar.

 

[BGB]

[Beyond that, I guess it depends on your environment; if your text
editor is particularly bad at opening new files, but is good at
searching, then big files may seem nicer. Conversely, an editor that
is particularly good at file browsing may make smaller files seem more
pleasant.]

Windows can only really conveniently have about 50 windows open, and
scrolls really slowly trying to access more, requiring closing editors
to close them. ...
however, wasting lots of time endlessly opening files and closing
stale editors can also get fairly annoying, and so it may be less
annoying to instead put things in preexisting files, if they make
sense there.

See, your entire way of thinking about it is based on the particular
behavior of your editor(s).

Not all editors are so simplistic. In particular, there's no
need for each file to have it's own editor or window (or tab).

[I often have many hundreds of files open at once, and don't even really
_notice_ how many there are...]

major editors I have used:
originally, MS Edit (MS-DOS);
Emacs, VIM, and GEdit on Linux (of which GEdit has tabs, but they don't
help much);
formerly, I mostly used Notepad on Windows, but later switched mostly to
Notepad2, mostly as it turns out that code highlighting can be helpful,
and it can be set to only open a single instance of a given file.

also tried using Notepad++ and SciTe, but didn't like them as much.

IMHO, these options generally beat out trying to do editing from within
Visual Studio, where apart from C# (where Intellisense actually tends to
work), it is annoying to deal with the editor lag (so, one may end up
switching back to VS mostly for sake of running stuff and using the
debugger and similar), except in the rare instances when doing something
with a GUI.


IMO, Windows Explorer is also more usable than the Solution Explorer as
well, since one can see a lot more files at a time (say, in "List" or
"Details" view).


or such...

 

[Juha Nieminen]

I've found one-class-per-file style organization to be _vastly_ more
usable, actually, because you always have a pretty good idea where
things are.

By contrast, I've had miserable (and memborable) experiences trying to
browse code written in a "stuff tons of classes in each file" style,
because I could never really be sure where to find a given class.

You do understand that there are other possibilities than the two
extremes?

It *is* possible to group small, very closely related classes in a
logical way into files.

 

[BGB]

You do understand that there are other possibilities than the two
extremes?

It *is* possible to group small, very closely related classes in a
logical way into files.

yeah, and also everyone seems to think I am advocating huge files or
something (rather than advocating instead trying to keep file sizes
within a certain range of "ideals").

I have looked around some, and thus far have not found any projects
which strictly adhere to 1-class-per-file.


LLVM mostly does, but has a few exception cases (several small classes
lumped together), but they are rare.

Mozilla sort of does, where (in C++ portions) it follows this rule for
the majority, but also violates it a fair amount as well (seems to
depend a lot on where in Mozilla one is looking, I have observed some
amount of inconsistency).

Doom3 rarely does, much more often lumping things together, but one
still does find it being followed on occasion. this seems to also vary
with region, being more typical in "game" (server-side monster/NPC
behaviors, weapons handling, physics, ...) than in the renderer (the
Doom3 renderer generally follows a more C-like style), for example.


my code does it less so still (of what little C++ code there is), but I
don't really usually bother, being mostly a C programmer (C code is the
majority of the code, at this point mostly due to technical
reasons/concerns, mostly with some of my tools being not entirely
friendly to C++).


it is also my tradition to put nearly all headers into separate
"include" directories, which again alters things (since the source code
and headers end up being in different locations).

in terms of lines-of-code, it seems to be more of a 20% header/source
relation. I have observed that many other codebases tend to have closer
to a 10% header/code relation, but I tend towards more numerous and
smaller functions (meaning more space is needed by headers for
prototypes and similar).

typically, also, headers are "per-library", so one includes the header
for the library to get everything in the library. typically, the library
contents will be spread over any number of individual header files
internally. sometimes there is also a split between "internal" and
"public" header contents (internal contents are only visible within the
library, whereas public contents are visible to other code which uses
the header).


so, yes, maybe different traditions and different styles.


typically project organization:
project_root:
subprojects*
libraries*
misc*
Makefiles
shared "include", headers shared between libs
shared "docs", documentation related to project
built binaries

subproject:
basically the same layout as project_root.

library (typical):
source-directories:
"base", default source directory
others, may exist per component.
"include", all headers go here.
"docs", library-specific documentation goes here.
Makefiles