Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c++ > #14707 > unrolled thread

Is Perl written in C?

Started byMan-wai Chang <toylet.toylet@gmail.com>
First post2012-03-03 22:15 +0800
Last post2012-03-04 09:58 +0000
Articles 4 on this page of 24 — 11 participants

Back to article view | Back to comp.lang.c++


Contents

  Is Perl written in C? Man-wai Chang <toylet.toylet@gmail.com> - 2012-03-03 22:15 +0800
    Re: Is Perl written in C? Paavo Helde <myfirstname@osa.pri.ee> - 2012-03-03 08:38 -0600
      Re: Is Perl written in C? Man-wai Chang <toylet.toylet@gmail.com> - 2012-03-03 22:41 +0800
      Re: Is Perl written in C? Man-wai Chang <toylet.toylet@gmail.com> - 2012-03-03 22:43 +0800
        Re: Is Perl written in C? Sam <sam@email-scan.com> - 2012-03-03 09:23 -0600
          Re: Is Perl written in C? Andy Champ <no.way@nospam.invalid> - 2012-03-03 17:08 +0000
            Re: Is Perl written in C? Juha Nieminen <nospam@thanks.invalid> - 2012-03-04 07:02 +0000
          Re: Is Perl written in C? BGB <cr88192@hotmail.com> - 2012-03-03 12:08 -0700
          Re: Is Perl written in C? jacob navia <jacob@spamsink.net> - 2012-03-03 20:45 +0100
            Re: Is Perl written in C? William Ahern <william@wilbur.25thandClement.com> - 2012-03-03 19:13 -0800
              Re: Is Perl written in C? BGB <cr88192@hotmail.com> - 2012-03-04 00:01 -0700
                Re: Is Perl written in C? Juha Nieminen <nospam@thanks.invalid> - 2012-03-04 09:56 +0000
                  Re: Is Perl written in C? BGB <cr88192@hotmail.com> - 2012-03-04 09:48 -0700
                    Re: Is Perl written in C? nick_keighley_nospam@hotmail.com - 2012-03-05 00:53 -0800
                      Re: Is Perl written in C? BGB <cr88192@hotmail.com> - 2012-03-05 08:08 -0700
                        Re: Is Perl written in C? Miles Bader <miles@gnu.org> - 2012-03-06 08:38 +0900
                          Re: Is Perl written in C? BGB <cr88192@hotmail.com> - 2012-03-05 17:06 -0700
                            Re: Is Perl written in C? Miles Bader <miles@gnu.org> - 2012-03-06 10:00 +0900
                              Re: Is Perl written in C? BGB <cr88192@hotmail.com> - 2012-03-05 19:35 -0700
                          Re: Is Perl written in C? Juha Nieminen <nospam@thanks.invalid> - 2012-03-06 09:29 +0000
                            Re: Is Perl written in C? BGB <cr88192@hotmail.com> - 2012-03-06 09:20 -0700
                        Re: Is Perl written in C? Ian Collins <ian-news@hotmail.com> - 2012-03-06 13:35 +1300
                          Re: Is Perl written in C? BGB <cr88192@hotmail.com> - 2012-03-05 19:24 -0700
              Re: Is Perl written in C? Juha Nieminen <nospam@thanks.invalid> - 2012-03-04 09:58 +0000

Page 2 of 2 — ← Prev page 1 [2]


#14781

FromBGB <cr88192@hotmail.com>
Date2012-03-06 09:20 -0700
Message-ID<jj5dih$bds$1@news.albasani.net>
In reply to#14770
On 3/6/2012 2:29 AM, Juha Nieminen wrote:
> Miles Bader<miles@gnu.org>  wrote:
>> 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.

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

[toc] | [prev] | [next] | [standalone]


#14764

FromIan Collins <ian-news@hotmail.com>
Date2012-03-06 13:35 +1300
Message-ID<9rl4eeFg0kU4@mid.individual.net>
In reply to#14756
On 03/ 6/12 04:08 AM, BGB wrote:
> On 3/5/2012 1:53 AM, nick_keighley_nospam@hotmail.com wrote:
>> On Sunday, March 4, 2012 4:48:35 PM UTC, BGB wrote:
>>> On 3/4/2012 2:56 AM, Juha Nieminen wrote:
>>>> BGB<cr88192@hotmail.com>    wrote:
>>
>>>>> 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?
>>>
>>> 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.
>>
>
> 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.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]


#14766

FromBGB <cr88192@hotmail.com>
Date2012-03-05 19:24 -0700
Message-ID<jj3sj1$b1h$1@news.albasani.net>
In reply to#14764
On 3/5/2012 5:35 PM, Ian Collins wrote:
> On 03/ 6/12 04:08 AM, BGB wrote:
>> On 3/5/2012 1:53 AM, nick_keighley_nospam@hotmail.com wrote:
>>> On Sunday, March 4, 2012 4:48:35 PM UTC, BGB wrote:
>>>> On 3/4/2012 2:56 AM, Juha Nieminen wrote:
>>>>> BGB<cr88192@hotmail.com> wrote:
>>>
>>>>>> 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?
>>>>
>>>> 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.
>>>
>>
>> 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.
>

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.


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

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.

[toc] | [prev] | [next] | [standalone]


#14740

FromJuha Nieminen <nospam@thanks.invalid>
Date2012-03-04 09:58 +0000
Message-ID<4f533cbd$0$3068$7b1e8fa0@news.nbl.fi>
In reply to#14732
William Ahern <william@wilbur.25thandclement.com> wrote:
> 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".

[toc] | [prev] | [standalone]


Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c++


csiph-web