Is Perl written in C?

Discussion in 'C++' started by Man-wai Chang, Mar 3, 2012.

  1. 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, Mar 3, 2012
    #1
    1. Advertising

  2. > 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, Mar 3, 2012
    #2
    1. Advertising

  3. > 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
    Man-wai Chang, Mar 3, 2012
    #3
  4. Man-wai Chang

    BGB Guest

    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...).
    BGB, Mar 3, 2012
    #4
  5. Man-wai Chang

    jacob navia Guest

    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

    :)
    jacob navia, Mar 3, 2012
    #5
  6. Man-wai Chang

    BGB Guest

    On 3/3/2012 8:13 PM, William Ahern wrote:
    > jacob navia<> 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.
    BGB, Mar 4, 2012
    #6
  7. Andy Champ <> 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.
    Juha Nieminen, Mar 4, 2012
    #7
  8. BGB <> 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?
    Juha Nieminen, Mar 4, 2012
    #8
  9. 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".
    Juha Nieminen, Mar 4, 2012
    #9
  10. Man-wai Chang

    BGB Guest

    On 3/4/2012 2:56 AM, Juha Nieminen wrote:
    > BGB<> 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...
    BGB, Mar 4, 2012
    #10
  11. Man-wai Chang

    Guest

    On Sunday, March 4, 2012 4:48:35 PM UTC, BGB wrote:
    > On 3/4/2012 2:56 AM, Juha Nieminen wrote:
    > > BGB<> 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>
    , Mar 5, 2012
    #11
  12. Man-wai Chang

    BGB Guest

    On 3/5/2012 1:53 AM, wrote:
    > On Sunday, March 4, 2012 4:48:35 PM UTC, BGB wrote:
    >> On 3/4/2012 2:56 AM, Juha Nieminen wrote:
    >>> BGB<> 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>
    BGB, Mar 5, 2012
    #12
  13. Man-wai Chang

    Miles Bader Guest

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

    --
    「寒ã„ã­ã€ã¨è©±ã—ã‹ã‘ã‚Œã°ã€Œå¯’ã„ã­ã€ã¨ç­”ãˆã‚‹äººã®ã„ã‚‹ã‚ã£ãŸã‹ã• [俵万智]
    Miles Bader, Mar 5, 2012
    #13
  14. Man-wai Chang

    BGB Guest

    On 3/5/2012 4:38 PM, Miles Bader wrote:
    > BGB<> 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.
    BGB, Mar 6, 2012
    #14
  15. Man-wai Chang

    Ian Collins Guest

    On 03/ 6/12 04:08 AM, BGB wrote:
    > On 3/5/2012 1:53 AM, wrote:
    >> On Sunday, March 4, 2012 4:48:35 PM UTC, BGB wrote:
    >>> On 3/4/2012 2:56 AM, Juha Nieminen wrote:
    >>>> BGB<> 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
    Ian Collins, Mar 6, 2012
    #15
  16. Man-wai Chang

    Miles Bader Guest

    BGB <> 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.
    Miles Bader, Mar 6, 2012
    #16
  17. Man-wai Chang

    BGB Guest

    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, wrote:
    >>> On Sunday, March 4, 2012 4:48:35 PM UTC, BGB wrote:
    >>>> On 3/4/2012 2:56 AM, Juha Nieminen wrote:
    >>>>> BGB<> 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.
    BGB, Mar 6, 2012
    #17
  18. Man-wai Chang

    BGB Guest

    On 3/5/2012 6:00 PM, Miles Bader wrote:
    > BGB<> 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...
    BGB, Mar 6, 2012
    #18
  19. Miles Bader <> 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.
    Juha Nieminen, Mar 6, 2012
    #19
  20. Man-wai Chang

    BGB Guest

    On 3/6/2012 2:29 AM, Juha Nieminen wrote:
    > Miles Bader<> 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
    BGB, Mar 6, 2012
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Steve C. Orr, MCSD
    Replies:
    1
    Views:
    556
    reaway lee
    Aug 24, 2003
  2. KaiWen
    Replies:
    102
    Views:
    2,709
    Jorgen Grahn
    Sep 15, 2011
  3. iris
    Replies:
    1
    Views:
    97
    Gunnar Hjalmarsson
    Jul 17, 2003
  4. wana

    new commands written in perl

    wana, Sep 21, 2004, in forum: Perl Misc
    Replies:
    17
    Views:
    254
    Eric Schwartz
    Sep 28, 2004
  5. Replies:
    18
    Views:
    168
    William Herrera
    Oct 31, 2005
Loading...

Share This Page