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

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

Is Perl written in C?

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 1 of 2  [1] 2  Next page →

#14707 — Is Perl written in C?

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

[toc] | [next] | [standalone]

#14711

Man-wai Chang <toylet.toylet@gmail.com> wrote in news:jit924$bgq$1@dont-
email.me:

> 
> Just curious... :)
> 

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

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

#14713

> 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

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

#14714

> 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

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

#14718

[Multipart message — attachments visible in raw view] — view raw

Man-wai Chang writes:

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

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.

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

#14721

On 03/03/2012 15:23, Sam wrote:
> 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.

This turns out not to be the case.

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.

Andy

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

#14737

Andy Champ <no.way@nospam.invalid> wrote:
> 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.

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

#14725

On 3/3/2012 8:23 AM, Sam wrote:
> Man-wai Chang writes:
>
>>> 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?
>
> 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...).

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

#14726

Le 03/03/12 16:23, Sam a écrit :
> Man-wai Chang writes:
>
>>> 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?
>
> 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

:-)

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

#14732

jacob navia <jacob@spamsink.net> wrote:
> Le 03/03/12 16:23, Sam a écrit :
> > Man-wai Chang writes:
> >
> >>> 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?
> >
> > 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.

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.

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

#14738

On 3/3/2012 8:13 PM, William Ahern wrote:
> jacob navia<jacob@spamsink.net>  wrote:
>> Le 03/03/12 16:23, Sam a écrit :
>>> Man-wai Chang writes:
>>>
>>>>> 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?
>>>
>>> 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.
>
> 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.

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

#14739

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?

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

#14744

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

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

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

#14753

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.

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

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

#14756

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


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.


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

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

#14762

BGB <cr88192@hotmail.com> writes:
>> 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++.

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

-- 
「寒いね」と話しかければ「寒いね」と答える人のいるあったかさ [俵万智]

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

#14763

On 3/5/2012 4:38 PM, Miles Bader wrote:
> BGB<cr88192@hotmail.com>  writes:
>>> 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++.
>
> 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...


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

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.

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

#14765

BGB <cr88192@hotmail.com> writes:
>> [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

-- 
Fast, small, soon; pick any 2.

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

#14767

On 3/5/2012 6:00 PM, Miles Bader wrote:
> BGB<cr88192@hotmail.com>  writes:
>>> [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...

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

#14770

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.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web