give me some tips

Discussion in 'C Programming' started by Yuri CHUANG, Mar 12, 2006.

  1. Yuri CHUANG

    Yuri CHUANG Guest

    "No newline at the end of your output" is really a problem? I've never
    learned that before.
    So I desire to know some tips about writting a program perfectly.Can
    anyone give me some tips which are hardly learned from textbook or
    easily ignored?
    Thank you very much.
     
    Yuri CHUANG, Mar 12, 2006
    #1
    1. Advertising

  2. Yuri CHUANG

    pete Guest

    Yuri CHUANG wrote:
    >
    > "No newline at the end of your output" is really a problem? I've never
    > learned that before.
    > So I desire to know some tips about writting a program perfectly.Can
    > anyone give me some tips which are hardly learned from textbook or
    > easily ignored?
    > Thank you very much.


    http://c-faq.com/

    --
    pete
     
    pete, Mar 12, 2006
    #2
    1. Advertising

  3. Yuri CHUANG

    Albert Guest

    Well, your output will look much better if you have a practice of
    putting \n at the end of a printf argument, etc.
    Albert
     
    Albert, Mar 12, 2006
    #3
  4. On Sunday 12 March 2006 06:18, Albert opined (in
    <>):

    > Well, your output will look much better if you have a practice of
    > putting \n at the end of a printf argument, etc.
    > Albert


    Please quote who and what you're replying to. Read and follow advice
    from <http://cfaj.freeshell.org/google/>.

    Back to your reply... "look much better" really has nothing to do with
    this (as we all know, the beauty is in the eye of the be(er)holder).

    What has *everything* to do with it is that if you do not terminate your
    output with new line, or flush it with `fflush`, the compiler is not
    required to provide /any/ output whatsoever. It's in the Standard, if
    you're still wondering why.

    --
    BR, Vladimir

    After any salary raise, you will have less money at the end of the
    month than you did before.
     
    Vladimir S. Oka, Mar 12, 2006
    #4
  5. Yuri CHUANG

    Michael Mair Guest

    Albert schrieb:
    > Well, your output will look much better if you have a practice of
    > putting \n at the end of a printf argument, etc.


    Please, quote what you are replying to. If you are using
    google to post, have a look at
    http://www.clc-wiki.net/wiki/Introduction_to_comp.lang.c#googleposts
    please.

    Apart from that, your answer is not at all helpful as the OP
    was not asking for aesthetic reasons but for the language
    reasons; you could have pointed him or her to FAQ 12.4 or similar.

    Cheers
    Michael
    --
    E-Mail: Mine is an /at/ gmx /dot/ de address.
     
    Michael Mair, Mar 12, 2006
    #5
  6. "Yuri CHUANG" <> wrote in message
    news:...
    > So I desire to know some tips about writting a program perfectly.


    There are two assumptions made in that statement:
    1) that someone can always determine a method to solve every problem
    2) that someone can always write a program which implements a solution
    without errors

    I'd start by learning how to solve some problems and write some programs
    well. After solving and implementing
    a few problems, you'll know whether you are better at "top-down" or
    "bottoms-up" design. Each person has a
    biological preference for each one (FYI, those who prefer "top-down" are N,
    and "bottoms-up" are S, in Myers-Briggs personality Type Indicator).

    > Can
    > anyone give me some tips which are hardly learned from textbook or
    > easily ignored?


    The following are my opinions for the C language are really are _specific_
    to _my_ programming style. Others may not
    have problems with the same areas of C that I do, so they probably have
    their own list of issues. You'll need to develop
    your own list of "problem areas" over time:

    1) learn hexadecimal and the bit patterns for each value
    2) don't forget your algebra
    3) understand binary operations bitshifts, and, or, xor, one and two's
    complement, etc...
    4) use #define masks to extract bits from variables instead of using unions
    5) include all the necessary include files, especially stdio.h and stdlib.h
    6) avoid the use casts, except to ensure the type and precision of numerical
    conversions and where you know it is necessary
    7) avoid the use of type qualifiers (const, volatile, restrict), except
    where necessary, because they can hide programming errors
    8) avoid the use malloc(), except for dynamic data, because it leads to
    memory allocation errors
    8A) corollary: avoid the use pointers in main(), for the same reason
    9) typedef structs and give them file scope (i.e., "global"), it can simply
    certain problems


    Rod Pemberton
     
    Rod Pemberton, Mar 12, 2006
    #6
  7. Michael Mair <> writes:
    > Albert schrieb:
    >> Well, your output will look much better if you have a practice of
    >> putting \n at the end of a printf argument, etc.

    >
    > Please, quote what you are replying to. If you are using
    > google to post, have a look at
    > http://www.clc-wiki.net/wiki/Introduction_to_comp.lang.c#googleposts
    > please.
    >
    > Apart from that, your answer is not at all helpful as the OP
    > was not asking for aesthetic reasons but for the language
    > reasons; you could have pointed him or her to FAQ 12.4 or similar.


    Note that FAQ 12.4 recommends the use of fflush(stdout), which is a
    good idea for prompts, but isn't guaranteed to help if the very last
    thing your program writes to stdout doesn't end in a new-line.

    What the standard says is (C99 7.19.12p2):

    A text stream is an ordered sequence of characters composed into
    _lines_, each line consisting of zero or more characters plus a
    terminating new-line character. Whether the last line requires a
    terminating new-line character is implementation-defined.

    It's not clear what happens if the implementation requires a
    terminating new-line and the program doesn't provide one; I suppose
    it's undefined behavior. The most likely consequence, I suppose, is
    that the last line doesn't appear.

    I don't know of any implementations that actually require the trailing
    new-line, but on systems I use, if a program's stdout is directed to a
    terminal and there's no trailing new-line, the last line might be
    overwritten by the next shell prompt. Even if it isn't, having the
    prompt appear in the same line immediately following the program's
    output is ugly:

    prompt% ./hello
    hello, worldprompt %

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
     
    Keith Thompson, Mar 12, 2006
    #7
  8. "Rod Pemberton" <> wrote in message
    news:dv0uev$2hcl$...
    >
    > "Yuri CHUANG" <> wrote in message
    > news:...
    > > So I desire to know some tips about writting a program perfectly.

    >
    > There are two assumptions made in that statement:
    > 1) that someone can always determine a method to solve every problem
    > 2) that someone can always write a program which implements a solution
    > without errors
    >
    > I'd start by learning how to solve some problems and write some programs
    > well. After solving and implementing
    > a few problems, you'll know whether you are better at "top-down" or
    > "bottoms-up" design. Each person has a
    > biological preference for each one (FYI, those who prefer "top-down" are

    N,
    > and "bottoms-up" are S, in Myers-Briggs personality Type Indicator).
    >
    > > Can
    > > anyone give me some tips which are hardly learned from textbook or
    > > easily ignored?

    >
    > The following are my opinions for the C language are really are _specific_
    > to _my_ programming style. Others may not
    > have problems with the same areas of C that I do, so they probably have
    > their own list of issues. You'll need to develop
    > your own list of "problem areas" over time:
    >
    > 1) learn hexadecimal and the bit patterns for each value
    > 2) don't forget your algebra
    > 3) understand binary operations bitshifts, and, or, xor, one and two's
    > complement, etc...
    > 4) use #define masks to extract bits from variables instead of using

    unions
    > 5) include all the necessary include files, especially stdio.h and

    stdlib.h
    > 6) avoid the use casts, except to ensure the type and precision of

    numerical
    > conversions and where you know it is necessary
    > 7) avoid the use of type qualifiers (const, volatile, restrict), except
    > where necessary, because they can hide programming errors
    > 8) avoid the use malloc(), except for dynamic data, because it leads to
    > memory allocation errors
    > 8A) corollary: avoid the use pointers in main(), for the same reason
    > 9) typedef structs and give them file scope (i.e., "global"), it can

    simply
    > certain problems
    >


    I'd also add:
    10) use unsigned types whenever possible

    Rod Pemberton
     
    Rod Pemberton, Mar 12, 2006
    #8
  9. Yuri CHUANG

    Michael Mair Guest

    Rod Pemberton schrieb:
    > "Yuri CHUANG" <> wrote in message
    > news:...
    >
    >>So I desire to know some tips about writting a program perfectly.

    >
    > There are two assumptions made in that statement:
    > 1) that someone can always determine a method to solve every problem
    > 2) that someone can always write a program which implements a solution
    > without errors
    >
    > I'd start by learning how to solve some problems and write some programs
    > well. After solving and implementing
    > a few problems, you'll know whether you are better at "top-down" or
    > "bottoms-up" design. Each person has a
    > biological preference for each one (FYI, those who prefer "top-down" are N,
    > and "bottoms-up" are S, in Myers-Briggs personality Type Indicator).


    Hmmm, and what am I if I prefer one approach for some kinds of problems
    and the other for other kinds of problems and the
    midlevel-to-up-and-down and the come-from-top-and-bottom for yet
    other classes of problems?

    >>Can
    >>anyone give me some tips which are hardly learned from textbook or
    >>easily ignored?

    >
    > The following are my opinions for the C language are really are _specific_
    > to _my_ programming style. Others may not
    > have problems with the same areas of C that I do, so they probably have
    > their own list of issues. You'll need to develop
    > your own list of "problem areas" over time:
    >
    > 1) learn hexadecimal and the bit patterns for each value
    > 2) don't forget your algebra
    > 3) understand binary operations bitshifts, and, or, xor, one and two's
    > complement, etc...


    If you need them, learn something about floating point numbers
    and their shortcomings so you are not in for nasty surprises.

    > 4) use #define masks to extract bits from variables instead of using unions


    and use functions to wrap the semantics whenever the bit thing
    is only an implementation decision...

    > 5) include all the necessary include files, especially stdio.h and stdlib.h
    > 6) avoid the use casts, except to ensure the type and precision of numerical
    > conversions and where you know it is necessary
    > 7) avoid the use of type qualifiers (const, volatile, restrict), except
    > where necessary, because they can hide programming errors


    How can const lead to errors unless you violate (6)?

    > 8) avoid the use malloc(), except for dynamic data, because it leads to
    > memory allocation errors


    .... it _can_ lead ...

    > 8A) corollary: avoid the use pointers in main(), for the same reason


    Avoid implementing any functionality in main(); main() essentially
    just should call functions and assign to temps...
    This step usually makes it easier to structure the program and the
    tasks.

    > 9) typedef structs and give them file scope (i.e., "global"), it can simply
    > certain problems


    Are you talking about the type definition or about the instance?

    @OP: As Rod said, everyone has their own list.
    A look at a good textbook and the C FAQ before you start out
    implementing something may make you aware of potential problems.

    A couple of things which are not strictly C which I would add:
    i) Use your compiler in the strictest possible mode, i.e.
    a) use only standard C if you can get away with it
    b) turn the warning level to maximum
    ii) If sensible, use a lint-tool.
    iii) If you get warnings or error messages, understand them. Do
    not try to make them "go away" with tricks but by making sure
    the (potential) problem they point out does not occur or by
    changing the code so the problem cannot occur.
    If you decide that the warning is not critical and your compiler
    offers a #pragma to switch off a warning for a code section,
    then switch it off for the smallest possible code section and
    write a comment explaining why you switched it off.
    iv) If you get beyond one file or beyond a thousand lines of code
    or if you know beforehand that you might, then _plan_ahead_:
    a) Use make or similar tools to automate the build process
    b) Test every function or at least every module thoroughly and
    separately -- it is much easier to find bugs this way.
    If you design the test before writing the code, this may even
    save you some time because you know which pitfalls to avoid.
    c) Make tests that test the interaction of different software
    components/modules/functions.
    v) Do never ever take shortcuts in order to "optimise".
    If your code is too slow and you have found out by measuring
    which part it is that slows you down, then think about a better
    way of implementing it. Keep the slow function/group of functions
    so that you test whether the optimised code does the same. And
    measure whether the optimised part is actually faster/more memory
    efficient.

    Cheers
    Michael
    --
    E-Mail: Mine is an /at/ gmx /dot/ de address.
     
    Michael Mair, Mar 12, 2006
    #9
  10. Yuri CHUANG

    Michael Mair Guest

    Keith Thompson schrieb:
    > Michael Mair <> writes:
    >>Albert schrieb:
    >>
    >>>Well, your output will look much better if you have a practice of
    >>>putting \n at the end of a printf argument, etc.

    >>
    >>Please, quote what you are replying to. If you are using
    >>google to post, have a look at
    >> http://www.clc-wiki.net/wiki/Introduction_to_comp.lang.c#googleposts
    >>please.
    >>
    >>Apart from that, your answer is not at all helpful as the OP
    >>was not asking for aesthetic reasons but for the language
    >>reasons; you could have pointed him or her to FAQ 12.4 or similar.

    >
    > Note that FAQ 12.4 recommends the use of fflush(stdout), which is a
    > good idea for prompts, but isn't guaranteed to help if the very last
    > thing your program writes to stdout doesn't end in a new-line.
    >
    > What the standard says is (C99 7.19.12p2):

    <snip: explanation>

    I admit I was too lazy to search for the appropriate FAQ;
    I just assumed that somewhere around there, there should be
    an appropriate FAQ entry. Looking there, I don't find one...
    Considering that this is something corrected fairly often,
    I am surprised that one cannot find that in the FAQ.

    Cheers
    Michael
    --
    E-Mail: Mine is an /at/ gmx /dot/ de address.
     
    Michael Mair, Mar 12, 2006
    #10
  11. "Michael Mair" <> wrote in message
    news:...
    > Rod Pemberton schrieb:
    > > "Yuri CHUANG" <> wrote in message
    > > news:...
    > >
    > > I'd start by learning how to solve some problems and write some programs
    > > well. After solving and implementing
    > > a few problems, you'll know whether you are better at "top-down" or
    > > "bottoms-up" design. Each person has a
    > > biological preference for each one (FYI, those who prefer "top-down" are

    N,
    > > and "bottoms-up" are S, in Myers-Briggs personality Type Indicator).

    >
    > Hmmm, and what am I if I prefer one approach for some kinds of problems
    > and the other for other kinds of problems and the
    > midlevel-to-up-and-down and the come-from-top-and-bottom for yet
    > other classes of problems?


    For the MBTI, X is used when an individual is balanced between the two
    categories. Most people show a dominance for one category or the other.

    But, you bring up a very good point: people's preference or natural
    abilities can interfere with solving specific problems since certain
    problems can only be solved when started from a certain point. Frequently,
    both "top-down" and "bottoms up" programmers start having problems
    "in-the-middle". The "top-down" programmer didn't allow for any special
    cases (too generic) and has problems implementing the details, and the
    "bottoms up" programmer has too much unnecessary detail and can't grasp the
    "big-picture."


    RP
     
    Rod Pemberton, Mar 12, 2006
    #11
  12. "Rod Pemberton" <> writes:
    [...]
    > The following are my opinions for the C language are really are _specific_
    > to _my_ programming style. Others may not
    > have problems with the same areas of C that I do, so they probably have
    > their own list of issues. You'll need to develop
    > your own list of "problem areas" over time:
    >

    [...]
    > 7) avoid the use of type qualifiers (const, volatile, restrict), except
    > where necessary, because they can hide programming errors


    I don't see how "const" in particular can hide programming errors.

    Use type qualifiers whenever they're appropriate. (restrict is
    complex and seldom necessary; don't worry about it until you know what
    you're doing. restrict is also new in C99, so many compilers don't
    support it.)

    > 8) avoid the use malloc(), except for dynamic data, because it leads to
    > memory allocation errors


    What else would you use malloc() for?

    Corollary: avoid the use of any feature X, because it leads to X
    errors.

    Better advice: use malloc() carefully.

    > 9) typedef structs and give them file scope (i.e., "global"), it can simply
    > certain problems


    Typedefs for structs are usually unnecessary. You can just declare

    struct foo {
    ...
    };

    and refer to the type as "struct foo"; there's no real need to use a
    typedef to create a second name for the type. (This is a somewhat
    controversial point; many programmers prefer to be able to refer to
    the type using a single identifier.)

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
     
    Keith Thompson, Mar 12, 2006
    #12
  13. On 2006-03-12, Keith Thompson <> wrote:
    >> 9) typedef structs and give them file scope (i.e., "global"), it can simply
    >> certain problems

    >
    > Typedefs for structs are usually unnecessary. You can just declare
    >
    > struct foo {
    > ...
    > };
    >
    > and refer to the type as "struct foo"; there's no real need to use a
    > typedef to create a second name for the type. (This is a somewhat
    > controversial point; many programmers prefer to be able to refer to
    > the type using a single identifier.)
    >


    I'm glad this came up : personally I like the more "in your face"
    robustness of this as opposed to using the typedef. There seems to be
    just something "wrong" about the whole struct definition in
    conjunction with typedef : I cant quite place what it is, although if
    you look at the two examples below I think this is what has sometimes
    led me astray in an "at a glance" read of strange code:

    typedef struct point {
    int x;
    int y;
    } Dot;

    struct point {
    int x;
    int y;
    } upperLeft;


    Could only be me, but I like to see (in C) the struct keyword at the
    point of instantiation.
     
    Richard G. Riley, Mar 12, 2006
    #13
  14. On 2006-03-12, Yuri CHUANG <> wrote:
    > "No newline at the end of your output" is really a problem? I've never
    > learned that before.
    > So I desire to know some tips about writting a program perfectly.Can
    > anyone give me some tips which are hardly learned from textbook or
    > easily ignored?
    > Thank you very much.
    >


    Just reading some of the replies which may or may not have got tied ip
    on "\n" at the end of each output:

    Take a look at the exit(EXIT_SUCCESS) function. Its a start to
    understanding some issues/considerations when leaving a program.
     
    Richard G. Riley, Mar 12, 2006
    #14
  15. "Richard G. Riley" <> wrote in message
    news:...
    > On 2006-03-12, Keith Thompson <> wrote:
    > >> 9) typedef structs and give them file scope (i.e., "global"), it can

    simply
    > >> certain problems

    > >
    > > Typedefs for structs are usually unnecessary. You can just declare
    > >
    > > struct foo {
    > > ...
    > > };
    > >
    > > and refer to the type as "struct foo"; there's no real need to use a
    > > typedef to create a second name for the type. (This is a somewhat
    > > controversial point; many programmers prefer to be able to refer to
    > > the type using a single identifier.)
    > >

    >
    > I'm glad this came up : personally I like the more "in your face"
    > robustness of this as opposed to using the typedef. There seems to be
    > just something "wrong" about the whole struct definition in
    > conjunction with typedef : I cant quite place what it is, although if
    > you look at the two examples below I think this is what has sometimes
    > led me astray in an "at a glance" read of strange code:
    >
    > typedef struct point {
    > int x;
    > int y;
    > } Dot;
    >
    > struct point {
    > int x;
    > int y;
    > } upperLeft;
    >
    >
    > Could only be me, but I like to see (in C) the struct keyword at the
    > point of instantiation.


    Usually, there is no need for tye type-definition, i.e., 'point', in the
    structure declaration when using a typedef:

    typedef struct {
    int x;
    int y;
    } Dot;

    /*...*/

    /*...some function...*/
    {
    Dot dot_x1y1,dot_x2y2;
    }

    This has been beaten to death on other threads which was why I posted
    "The following are my opinions for the C language ... are _specific_
    to _my_ programming style," but Keith ignored...

    RP
     
    Rod Pemberton, Mar 12, 2006
    #15
  16. "Michael Mair" <> wrote in message
    news:...
    > Rod Pemberton schrieb:
    > > "Yuri CHUANG" <> wrote in message
    > > news:...


    > Michael
    > --
    > E-Mail: Mine is an /at/ gmx /dot/ de address.


    Although there are a number of "Michael Mair" 's, that leads me to:

    Professor (FH) Magister Michael Mair of FH-Modul, University of Innsbruck,
    and MCI Innsbruck, Wien(Vienna), Austria.

    Is that you? I'll assume that it is for the rest of this post.

    Which translates roughly as having a PHD and/or Masters with a university of
    applied sciences. I'm sure I botched that. But, since your English is very
    good for an Austrian, I'll let you correct that. All of which led to two
    pictures: one on FH-Modul and one on FH-Wien. Nice ties. FH-Modul appears
    to be a tourism and hospitality university (Fachhochschulstudiengänge für
    tourismus-management).

    You've mentioned teaching in your other posts. Assuming I've got the
    correct person: "Doc", what exactly are you degreed in? Tourism management?


    Rod Pemberton
     
    Rod Pemberton, Mar 12, 2006
    #16
  17. Yuri CHUANG

    Michael Mair Guest

    Rod Pemberton schrieb:
    > "Michael Mair" <> wrote in message
    > news:...
    >>Rod Pemberton schrieb:
    >>>"Yuri CHUANG" <> wrote in message
    >>>news:...

    >
    >> Michael
    >>--
    >>E-Mail: Mine is an /at/ gmx /dot/ de address.

    >
    >
    > Although there are a number of "Michael Mair" 's, that leads me to:
    >
    > Professor (FH) Magister Michael Mair of FH-Modul, University of Innsbruck,
    > and MCI Innsbruck, Wien(Vienna), Austria.
    >
    > Is that you? I'll assume that it is for the rest of this post.


    No, that is not me.
    I have a University Diploma in "Technomathematik" which essentially is
    maths sprinkled with computer science and one engineering discipline.
    In my case that is engineering mechanics but I also had a look into
    electrical engineering. This course appealed to me because you get
    to understand the respective "languages" and are open to specialize
    as you feel like.
    I did some research in numerical mathematics (simulation and
    optimization of dynamic mechanical systems) afterwards, in the course
    of which I also gave a C course to relieve other people at our chair
    and in order to have students who actually learnt the basics of C so
    that we could hire them. In addition, I like teaching as it helps me
    learn the stuff I thought I knew that much better.

    Right now, I am working in an area where I need knowledge about
    compiler construction and discrete mathematics -- an area I am more
    enamoured with than numerical mathematics.


    Cheers
    Michael
    --
    E-Mail: Mine is an /at/ gmx /dot/ de address.
     
    Michael Mair, Mar 12, 2006
    #17
  18. "Michael Mair" <> wrote in message
    news:...
    > Rod Pemberton schrieb:
    > > "Michael Mair" <> wrote in message
    > > news:...
    > >>Rod Pemberton schrieb:
    > >>>"Yuri CHUANG" <> wrote in message
    > >>>news:...

    > >
    > >> Michael
    > >>--
    > >>E-Mail: Mine is an /at/ gmx /dot/ de address.

    > >
    > >
    > > Although there are a number of "Michael Mair" 's, that leads me to:
    > >
    > > Professor (FH) Magister Michael Mair of FH-Modul, University of

    Innsbruck,
    > > and MCI Innsbruck, Wien(Vienna), Austria.
    > >
    > > Is that you? I'll assume that it is for the rest of this post.

    >
    > No, that is not me.


    Darn, and thanks for not taking any offense. :) Hopefully, it was a cheap
    thrill. I found at least five "Rod Pemberton" 's in the US. I could
    understand that one was black (must have been a Pemberton slave owner).
    But, it was interesting to find a Vietnamese individual with that name! Go
    figure...

    > I have a University Diploma in "Technomathematik" which essentially is
    > maths sprinkled with computer science and one engineering discipline.
    > In my case that is engineering mechanics but I also had a look into
    > electrical engineering. This course appealed to me because you get
    > to understand the respective "languages" and are open to specialize
    > as you feel like.


    Ah, okay, I thought you seemed a bit more like an EE than a CS.

    > I did some research in numerical mathematics (simulation and
    > optimization of dynamic mechanical systems) afterwards, in the course
    > of which I also gave a C course to relieve other people at our chair
    > and in order to have students who actually learnt the basics of C so
    > that we could hire them.


    "who actually learnt the basics of C"

    I find that comment humorous. I knew quite a few degreed CS majors who
    couldn't program. Of course, I knew a few EE who didn't know what an
    electron was either...

    > In addition, I like teaching as it helps me
    > learn the stuff I thought I knew that much better.
    >
    > Right now, I am working in an area where I need knowledge about
    > compiler construction and discrete mathematics -- an area I am more
    > enamoured with than numerical mathematics.


    "compiler construction"

    Yes, not coming from a CS background. I could _really_ use a huge amount of
    good public information in this area. I've found stuff at a PHD level and
    or ideas which perhaps are patented. I can't use information like that. I
    need things like: whether it's easier to use stacks or binary trees. How to
    identify when to use an optimization in the compiler backend. Is it better
    to use tokens (abstract syntax tree) or string processing of text (concrete
    syntax tree)? I could really use Necula's et. al. CIL (C Intermediate
    Language) if it only had a flex and bison grammar...


    Rod Pemberton
     
    Rod Pemberton, Mar 12, 2006
    #18
  19. Yuri CHUANG

    Michael Mair Guest

    [OT] Re: give me some tips

    Rod Pemberton schrieb:
    > "Michael Mair" <> wrote in message
    > news:...
    >
    >> in the course
    >>of which I also gave a C course to relieve other people at our chair
    >>and in order to have students who actually learnt the basics of C so
    >>that we could hire them.

    >
    > "who actually learnt the basics of C"
    >
    > I find that comment humorous. I knew quite a few degreed CS majors who
    > couldn't program. Of course, I knew a few EE who didn't know what an
    > electron was either...


    There was nothing humorous at the time. We even considered
    banning applicants from a certain information technology
    course for our job offers as they made up ninety percent of
    the applications (with the shiniest certificates) and about
    three percent of the knowledge.


    >>Right now, I am working in an area where I need knowledge about
    >>compiler construction and discrete mathematics -- an area I am more
    >>enamoured with than numerical mathematics.

    >
    > "compiler construction"


    I am not sure whether this is the correct translation.
    Essentially, whatever you can learn from the Dragon Book or
    Muchnick's book.

    > Yes, not coming from a CS background. I could _really_ use a huge amount of
    > good public information in this area. I've found stuff at a PHD level and
    > or ideas which perhaps are patented. I can't use information like that. I
    > need things like: whether it's easier to use stacks or binary trees. How to
    > identify when to use an optimization in the compiler backend. Is it better
    > to use tokens (abstract syntax tree) or string processing of text (concrete
    > syntax tree)? I could really use Necula's et. al. CIL (C Intermediate
    > Language) if it only had a flex and bison grammar...


    Some of the en.wikipedia.org pages are a decent starting point
    if it comes to basic concepts.

    Apart from that: Have a look at graph theory; there is much nice
    stuff on the web and, as discrete maths goes, it is a fun subject
    as you can state really deep problems on a sheet of paper within
    five minutes so that everyone understands the problem but the
    proof took a hundred years to be found and conversely can prove
    things in an easily understandable way. If you understand graph
    theory and get an intermediate representation of some code, you
    are ready to do general (not target specific) optimisations.

    I am not actually writing a traditional compiler but am involved
    in the optimisation of an intermediate representation of code;
    the output of the product is C.
    More about that only via PM and only as far as I am allowed to
    tell about it.


    Cheers
    Michael
    --
    E-Mail: Mine is an /at/ gmx /dot/ de address.
     
    Michael Mair, Mar 12, 2006
    #19
  20. Re: [OT] Re: give me some tips

    "Michael Mair" <> wrote in message
    news:...
    > Rod Pemberton schrieb:
    > > "Michael Mair" <> wrote in message
    > > news:...
    > >

    > There was nothing humorous at the time. We even considered
    > banning applicants from a certain information technology
    > course for our job offers as they made up ninety percent of
    > the applications (with the shiniest certificates) and about
    > three percent of the knowledge.
    >
    > >>Right now, I am working in an area where I need knowledge about
    > >>compiler construction and discrete mathematics -- an area I am more
    > >>enamoured with than numerical mathematics.

    > >
    > > "compiler construction"

    >
    > I am not sure whether this is the correct translation.
    > Essentially, whatever you can learn from the Dragon Book or
    > Muchnick's book.


    I've not heard of these, but will look.

    > > Yes, not coming from a CS background. I could _really_ use a huge

    amount of
    > > good public information in this area. I've found stuff at a PHD level

    and
    > > or ideas which perhaps are patented. I can't use information like that.

    I
    > > need things like: whether it's easier to use stacks or binary trees.

    How to
    > > identify when to use an optimization in the compiler backend. Is it

    better
    > > to use tokens (abstract syntax tree) or string processing of text

    (concrete
    > > syntax tree)? I could really use Necula's et. al. CIL (C Intermediate
    > > Language) if it only had a flex and bison grammar...

    >
    > Apart from that: Have a look at graph theory; there is much nice
    > stuff on the web and, as discrete maths goes, it is a fun subject
    > as you can state really deep problems on a sheet of paper within
    > five minutes so that everyone understands the problem but the
    > proof took a hundred years to be found and conversely can prove
    > things in an easily understandable way. If you understand graph
    > theory and get an intermediate representation of some code, you
    > are ready to do general (not target specific) optimisations.


    Hmm, graph theory. I'll _definately_ have a look at this. It'll probably
    be a big time saver for me since my spatial relationship abilities are
    (supposedly) off the charts.

    > I am not actually writing a traditional compiler but am involved
    > in the optimisation of an intermediate representation of code;
    > the output of the product is C.
    > More about that only via PM and only as far as I am allowed to
    > tell about it.


    Well, you don't have to talk about that. I'm sure you've looked at other
    stuff like:

    GCC's RTL
    TenDRA's ANDF
    LCC's DAGs
    Necula's CIL

    So far, the only "C" compiler I've found that uses both a yacc and lex
    grammar is Lutz Hamel's "C Subset Compiler" WCC for VMS.


    Rod Pemberton
     
    Rod Pemberton, Mar 12, 2006
    #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. Jeff

    Newbie: I need some tips

    Jeff, May 16, 2005, in forum: ASP .Net
    Replies:
    1
    Views:
    334
    Karl Seguin
    May 16, 2005
  2. yuyazhang
    Replies:
    14
    Views:
    735
    yuyazhang
    Apr 29, 2006
  3. grocery_stocker
    Replies:
    10
    Views:
    653
    Keith Thompson
    May 25, 2005
  4. Emmanuel Oga
    Replies:
    2
    Views:
    155
    Emmanuel Oga
    Mar 10, 2008
  5. Replies:
    1
    Views:
    3,427
    Arne Vajhøj
    Jul 31, 2012
Loading...

Share This Page