return the start of a substring in a string in c

Discussion in 'C Programming' started by yinglcs@gmail.com, Jul 14, 2007.

  1. Guest

    Hi,
    In java, there is an 'indexOf' function in String which does this:

    indexOf(String str)
    Returns the index within this string of the first occurrence
    of the specified substring.

    is there anything like that in c?

    The closest thing I can find is strchr, but it check for a character,
    not a substring?

    Thank you.
    , Jul 14, 2007
    #1
    1. Advertising

  2. said:

    > Hi,
    > In java, there is an 'indexOf' function in String which does this:
    >
    > indexOf(String str)
    > Returns the index within this string of the first occurrence
    > of the specified substring.
    >
    > is there anything like that in c?
    >
    > The closest thing I can find is strchr, but it check for a character,
    > not a substring?


    strstr returns a pointer to the substring - if this is non-NULL,
    subtract the address of the main string from it to get the index.

    --
    Richard Heathfield <http://www.cpax.org.uk>
    Email: -www. +rjh@
    Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
    "Usenet is a strange place" - dmr 29 July 1999
    Richard Heathfield, Jul 14, 2007
    #2
    1. Advertising

  3. "Richard Heathfield" <> wrote in message
    news:...
    > said:
    >
    >> Hi,
    >> In java, there is an 'indexOf' function in String which does this:
    >>
    >> indexOf(String str)
    >> Returns the index within this string of the first occurrence
    >> of the specified substring.
    >>
    >> is there anything like that in c?
    >>
    >> The closest thing I can find is strchr, but it check for a character,
    >> not a substring?

    >
    > strstr returns a pointer to the substring - if this is non-NULL,
    > subtract the address of the main string from it to get the index.
    >

    ie;

    char *str = "astring";
    char *substring = "in";
    char *ptr;
    ptrdiff_t index; /* should be an int. Horrid horrid horrid */

    ptr = strstr(str, substring);
    if(ptr)
    {
    index = ptr - str;
    printf("your substring was found at postion %d (0-based)\n", (int)
    index);
    }

    As an exercise to the regs, why do we need that horrid, horrid cast in the
    call to printf?

    --
    Free games and programming goodies.
    http://www.personal.leeds.ac.uk/~bgy1mm
    Malcolm McLean, Jul 14, 2007
    #3
  4. Malcolm McLean wrote:
    > char *str = "astring";
    > char *substring = "in";
    > char *ptr;
    > ptrdiff_t index; /* should be an int. Horrid horrid horrid */
    >
    > ptr = strstr(str, substring);
    > if(ptr)
    > {
    > index = ptr - str;
    > printf("your substring was found at postion %d (0-based)\n", (int)
    > index);
    > }
    >
    > As an exercise to the regs, why do we need that horrid, horrid cast in the
    > call to printf?


    You don't. You're already assuming that index will fit in an int, so you can
    just change the declaration of index to match.
    Harald van =?UTF-8?B?RMSzaw==?=, Jul 14, 2007
    #4
  5. Ralf Kunz Guest

    schrieb:
    > Hi,
    > In java, there is an 'indexOf' function in String which does this:
    >
    > indexOf(String str)
    > Returns the index within this string of the first occurrence
    > of the specified substring.
    >
    > is there anything like that in c?
    >
    > The closest thing I can find is strchr, but it check for a character,
    > not a substring?
    >
    > Thank you.
    >


    hello,

    you can use instead the function
    char * strstr(const char *s1, const char *s2)

    from string.h

    Ralf
    Ralf Kunz, Jul 14, 2007
    #5
  6. "Harald van D?k" <> wrote in message
    news:f79r9j$uaq$1.ov.home.nl...
    > Malcolm McLean wrote:
    >> char *str = "astring";
    >> char *substring = "in";
    >> char *ptr;
    >> ptrdiff_t index; /* should be an int. Horrid horrid horrid */
    >>
    >> ptr = strstr(str, substring);
    >> if(ptr)
    >> {
    >> index = ptr - str;
    >> printf("your substring was found at postion %d (0-based)\n", (int)
    >> index);
    >> }
    >>
    >> As an exercise to the regs, why do we need that horrid, horrid cast in
    >> the
    >> call to printf?

    >
    > You don't. You're already assuming that index will fit in an int, so you
    > can
    > just change the declaration of index to match.
    >

    My point exactly. We fill the language with gibberish types, which don't
    actually gain anything because eventually some fucntion somewhere will
    expect an int.
    Join the campaign for 64 bit ints and this nonsense will fade away.

    --
    Free games and programming goodies.
    http://www.personal.leeds.ac.uk/~bgy1mm
    Malcolm McLean, Jul 14, 2007
    #6
  7. Malcolm McLean wrote:
    > "Harald van D?k" <> wrote in message
    > news:f79r9j$uaq$1.ov.home.nl...
    >> Malcolm McLean wrote:
    >>> char *str = "astring";
    >>> char *substring = "in";
    >>> char *ptr;
    >>> ptrdiff_t index; /* should be an int. Horrid horrid horrid */
    >>>
    >>> ptr = strstr(str, substring);
    >>> if(ptr)
    >>> {
    >>> index = ptr - str;
    >>> printf("your substring was found at postion %d (0-based)\n", (int)
    >>> index);
    >>> }
    >>>
    >>> As an exercise to the regs, why do we need that horrid, horrid cast in
    >>> the
    >>> call to printf?

    >>
    >> You don't. You're already assuming that index will fit in an int, so you
    >> can
    >> just change the declaration of index to match.
    >>

    > My point exactly. We fill the language with gibberish types, which don't
    > actually gain anything because eventually some fucntion somewhere will
    > expect an int.


    Which function is that, here? You don't need to assume index will fit in an
    int, you just chose to for convenience.
    Harald van =?UTF-8?B?RMSzaw==?=, Jul 14, 2007
    #7
  8. <> wrote in message
    news:...
    > Hi,
    > In java, there is an 'indexOf' function in String which does this:
    >
    > indexOf(String str)
    > Returns the index within this string of the first occurrence
    > of the specified substring.
    >
    > is there anything like that in c?
    >
    > The closest thing I can find is strchr, but it check for a character,
    > not a substring?


    If you know strchr() searches a string for a char, did it not occur to you
    to check if strstr() searches a string for a string?

    However, both return a pointer to the first instance found (or NULL, if
    none) instead of an index. If the returned value was non-NULL, subtract the
    pointer to the original string from the returned value to get the index.

    S

    --
    Stephen Sprunk "Those people who think they know everything
    CCIE #3723 are a great annoyance to those of us who do."
    K5SSS --Isaac Asimov


    --
    Posted via a free Usenet account from http://www.teranews.com
    Stephen Sprunk, Jul 14, 2007
    #8
  9. "Harald van Dijk" <> wrote in message
    news:f7a29h$bd$1.ov.home.nl...
    > Malcolm McLean wrote:
    >> "Harald van D?k" <> wrote in message
    >> news:f79r9j$uaq$1.ov.home.nl...
    >>> Malcolm McLean wrote:
    >>>> char *str = "astring";
    >>>> char *substring = "in";
    >>>> char *ptr;
    >>>> ptrdiff_t index; /* should be an int. Horrid horrid horrid */
    >>>>
    >>>> ptr = strstr(str, substring);
    >>>> if(ptr)
    >>>> {
    >>>> index = ptr - str;
    >>>> printf("your substring was found at postion %d (0-based)\n", (int)
    >>>> index);
    >>>> }
    >>>>
    >>>> As an exercise to the regs, why do we need that horrid, horrid cast in
    >>>> the
    >>>> call to printf?
    >>>
    >>> You don't. You're already assuming that index will fit in an int, so you
    >>> can
    >>> just change the declaration of index to match.
    >>>

    >> My point exactly. We fill the language with gibberish types, which don't
    >> actually gain anything because eventually some fucntion somewhere will
    >> expect an int.

    >
    > Which function is that, here? You don't need to assume index will fit in
    > an
    > int, you just chose to for convenience.
    >

    printf(). There probably is a specifier for ptrdiff_t in C99, but I doubt
    you can guarantee its presence.

    --
    Free games and programming goodies.
    http://www.personal.leeds.ac.uk/~bgy1mm
    Malcolm McLean, Jul 14, 2007
    #9
  10. Army1987 Guest

    On Sat, 14 Jul 2007 07:29:35 +0100, Malcolm McLean wrote:

    >
    > "Richard Heathfield" <> wrote in message
    > news:...
    >> said:
    >>
    >>> Hi,
    >>> In java, there is an 'indexOf' function in String which does this:
    >>>
    >>> indexOf(String str)
    >>> Returns the index within this string of the first occurrence
    >>> of the specified substring.
    >>>
    >>> is there anything like that in c?
    >>>
    >>> The closest thing I can find is strchr, but it check for a character,
    >>> not a substring?

    >>
    >> strstr returns a pointer to the substring - if this is non-NULL,
    >> subtract the address of the main string from it to get the index.
    >>

    > ie;
    >
    > char *str = "astring";
    > char *substring = "in";
    > char *ptr;
    > ptrdiff_t index; /* should be an int. Horrid horrid horrid */
    >
    > ptr = strstr(str, substring);
    > if(ptr)
    > {
    > index = ptr - str;
    > printf("your substring was found at postion %d (0-based)\n", (int)
    > index);
    > }
    >
    > As an exercise to the regs, why do we need that horrid, horrid cast in the
    > call to printf?

    Because you feared enough that the magnitude of (ptr - str) could
    ever be > 32767, that you didn't declare index as an int.
    Otherwise you could declare it as a long and use "%ld" in printf.
    --
    Army1987 (Replace "NOSPAM" with "email")
    "Never attribute to malice that which can be adequately explained
    by stupidity." -- R. J. Hanlon (?)
    Army1987, Jul 14, 2007
    #10
  11. Malcolm McLean wrote:
    > "Harald van Dijk" <> wrote in message
    > news:f7a29h$bd$1.ov.home.nl...
    >> Malcolm McLean wrote:
    >>> "Harald van D?k" <> wrote in message
    >>> news:f79r9j$uaq$1.ov.home.nl...
    >>>> Malcolm McLean wrote:
    >>>>> char *str = "astring";
    >>>>> char *substring = "in";
    >>>>> char *ptr;
    >>>>> ptrdiff_t index; /* should be an int. Horrid horrid horrid */
    >>>>>
    >>>>> ptr = strstr(str, substring);
    >>>>> if(ptr)
    >>>>> {
    >>>>> index = ptr - str;
    >>>>> printf("your substring was found at postion %d (0-based)\n", (int)
    >>>>> index);
    >>>>> }
    >>>>>
    >>>>> As an exercise to the regs, why do we need that horrid, horrid cast in
    >>>>> the
    >>>>> call to printf?
    >>>>
    >>>> You don't. You're already assuming that index will fit in an int, so
    >>>> you can
    >>>> just change the declaration of index to match.
    >>>>
    >>> My point exactly. We fill the language with gibberish types, which don't
    >>> actually gain anything because eventually some fucntion somewhere will
    >>> expect an int.

    >>
    >> Which function is that, here? You don't need to assume index will fit in
    >> an
    >> int, you just chose to for convenience.
    >>

    > printf(). There probably is a specifier for ptrdiff_t in C99,


    Indeed there is.

    > but I doubt
    > you can guarantee its presence.


    #if __STDC_VERSION__ >= 199901L
    ptrdiff_t index = ptr - str;
    printf("your substring was found at postion %td (0-based)\n", index);
    #else
    long index = ptr - str;
    printf("your substring was found at postion %ld (0-based)\n", index);
    #endif

    C99 has a specifier for ptrdiff_t. C90 has a guarantee that ptrdiff_t is no
    wider than long. If neither applies, you're not dealing with an
    implementation of standard C. (Yes, I'm aware that there are real-world
    C-like implementations that do not conform to any standard.)
    Harald van =?UTF-8?B?RMSzaw==?=, Jul 14, 2007
    #11
  12. Flash Gordon Guest

    Malcolm McLean wrote, On 14/07/07 09:34:
    >
    > "Harald van D?k" <> wrote in message
    > news:f79r9j$uaq$1.ov.home.nl...
    >> Malcolm McLean wrote:
    >>> char *str = "astring";
    >>> char *substring = "in";
    >>> char *ptr;
    >>> ptrdiff_t index; /* should be an int. Horrid horrid horrid */
    >>>
    >>> ptr = strstr(str, substring);
    >>> if(ptr)
    >>> {
    >>> index = ptr - str;
    >>> printf("your substring was found at postion %d (0-based)\n", (int)
    >>> index);
    >>> }
    >>>
    >>> As an exercise to the regs, why do we need that horrid, horrid cast
    >>> in the
    >>> call to printf?

    >>
    >> You don't. You're already assuming that index will fit in an int, so
    >> you can
    >> just change the declaration of index to match.
    >>

    > My point exactly. We fill the language with gibberish types,


    You may consider them gibberish, but others don't.

    > which don't
    > actually gain anything because eventually some fucntion somewhere will
    > expect an int.


    Only if you make the choice to do that.

    > Join the campaign for 64 bit ints and this nonsense will fade away.


    As has been pointed out before, it seems to be a one man campaign
    which has been started after all the key decisions have been made and
    the key implementations have selected 32 bit ints. To statnd a chance
    you need to work on what will be done with 128 bit processors, not 64
    bit processors where it is done and dusted.
    --
    Flash Gordon
    Flash Gordon, Jul 14, 2007
    #12
  13. "Flash Gordon" <> wrote in message
    news:-gordon.me.uk...
    > Malcolm McLean wrote, On 14/07/07 09:34:
    >>
    >> "Harald van D?k" <> wrote in message
    >> news:f79r9j$uaq$1.ov.home.nl...
    >>> Malcolm McLean wrote:
    >>>> char *str = "astring";
    >>>> char *substring = "in";
    >>>> char *ptr;
    >>>> ptrdiff_t index; /* should be an int. Horrid horrid horrid */
    >>>>
    >>>> ptr = strstr(str, substring);
    >>>> if(ptr)
    >>>> {
    >>>> index = ptr - str;
    >>>> printf("your substring was found at postion %d (0-based)\n", (int)
    >>>> index);
    >>>> }
    >>>>
    >>>> As an exercise to the regs, why do we need that horrid, horrid cast in
    >>>> the
    >>>> call to printf?
    >>>
    >>> You don't. You're already assuming that index will fit in an int, so you
    >>> can
    >>> just change the declaration of index to match.
    >>>

    >> My point exactly. We fill the language with gibberish types,

    >
    > You may consider them gibberish, but others don't.
    >
    > > which don't
    >> actually gain anything because eventually some fucntion somewhere will
    >> expect an int.

    >
    > Only if you make the choice to do that.
    >
    >> Join the campaign for 64 bit ints and this nonsense will fade away.

    >
    > As has been pointed out before, it seems to be a one man campaign
    > which has been started after all the key decisions have been made and the
    > key implementations have selected 32 bit ints. To statnd a chance you need
    > to work on what will be done with 128 bit processors, not 64 bit
    > processors where it is done and dusted.
    >

    It is still a one-man campaign. I am anxious to turn it into a 2-man
    campaign.
    It is not obvious what to do with 128 bits. The point is that integers
    usually count things, but it is unlikely that there will ever be enough
    memory in a machine to overflow a 64 bit int. I almost said enough memory
    manufactured, but in fact a world of 4 billion machines with 4GB each is
    perfectly foreseeable.

    --
    Free games and programming goodies.
    http://www.personal.leeds.ac.uk/~bgy1mm
    Malcolm McLean, Jul 14, 2007
    #13
  14. "Malcolm McLean" <> writes:

    > "Flash Gordon" <> wrote in message
    > news:-gordon.me.uk...
    >> Malcolm McLean wrote, On 14/07/07 09:34:
    >>> Join the campaign for 64 bit ints and this nonsense will fade away.

    >>
    >> As has been pointed out before, it seems to be a one man campaign
    >> which has been started after all the key decisions have been made
    >> and the key implementations have selected 32 bit ints. To statnd a
    >> chance you need to work on what will be done with 128 bit
    >> processors, not 64 bit processors where it is done and dusted.
    >>

    > It is still a one-man campaign. I am anxious to turn it into a 2-man
    > campaign.
    > It is not obvious what to do with 128 bits. The point is that integers
    > usually count things, but it is unlikely that there will ever be
    > enough memory in a machine to overflow a 64 bit int.


    Why do say integers usually count things? Don't you ever calculate
    things with integers? I used to work on projects (cryptography stuff)
    where calculating was more common than counting and ints were
    always too short. Counting is usually done with integers, but you
    can't turn that round the other way.

    --
    Ben.
    Ben Bacarisse, Jul 14, 2007
    #14
  15. Flash Gordon Guest

    Ben Bacarisse wrote, On 14/07/07 13:43:
    > "Malcolm McLean" <> writes:
    >
    >> "Flash Gordon" <> wrote in message
    >> news:-gordon.me.uk...
    >>> Malcolm McLean wrote, On 14/07/07 09:34:
    >>>> Join the campaign for 64 bit ints and this nonsense will fade away.
    >>> As has been pointed out before, it seems to be a one man campaign
    >>> which has been started after all the key decisions have been made
    >>> and the key implementations have selected 32 bit ints. To statnd a
    >>> chance you need to work on what will be done with 128 bit
    >>> processors, not 64 bit processors where it is done and dusted.
    >>>

    >> It is still a one-man campaign. I am anxious to turn it into a 2-man
    >> campaign.


    Your approach on this group is more likely to make people campaign
    against you.

    >> It is not obvious what to do with 128 bits. The point is that integers
    >> usually count things, but it is unlikely that there will ever be
    >> enough memory in a machine to overflow a 64 bit int.

    >
    > Why do say integers usually count things? Don't you ever calculate
    > things with integers? I used to work on projects (cryptography stuff)
    > where calculating was more common than counting and ints were
    > always too short. Counting is usually done with integers, but you
    > can't turn that round the other way.


    We've been through this before with Malcolm, he seems unable to
    comprehend that a lot of peoples experience does not match his. and that
    it is only his personal opinion which he has been unable to give any
    convincing evidence for, let alone proof.
    --
    Flash Gordon
    Flash Gordon, Jul 14, 2007
    #15
  16. "Ben Bacarisse" <> wrote in message
    > Why do say integers usually count things? Don't you ever calculate
    > things with integers? I used to work on projects (cryptography stuff)
    > where calculating was more common than counting and ints were
    > always too short. Counting is usually done with integers, but you
    > can't turn that round the other way.
    >

    As Flash says, we've been through all this before. I even pulled up some
    Java stats that showed pretty clearly that there were about as many indexed
    array accesses as integer operations in a sample of Java programs. I
    couldn't find a similar study for C, though I didn't try too hard, but there
    is no reason to suppose that C programs are radically different from Java
    ones.

    Computers spend most of their cycles moving data from one place to another,
    and most integers are used to count things in the computer's memory. That's
    not every cycle, of course, nor is every single integer a count of
    something - cryptography is an obvious exception, as are intermediate
    results in frequency transforms, or pixel colours. The last leads us to
    another issue, in a typical image function

    void setpixel(long *img, int width, int height, int x, int y, long val)
    {
    assert(x >= 0 && x < width);
    assert*y >= 0 && y < height);
    img[y*width + x] = height;
    }

    How many integers do we have? You could say width * height, plus a few, or
    you could say six, of which two are pixel values and four intermediates in
    array calculations. I'm counting it as six, which isn't the only answer
    justifiable, but makes sense in the context of how best to define the types
    in a high-level language.

    --
    Free games and programming goodies.
    http://www.personal.leeds.ac.uk/~bgy1mm
    Malcolm McLean, Jul 14, 2007
    #16
  17. "Malcolm McLean" <> writes:
    [...]
    > My point exactly. We fill the language with gibberish types, which
    > don't actually gain anything because eventually some fucntion
    > somewhere will expect an int.
    > Join the campaign for 64 bit ints and this nonsense will fade away.


    Your best approach, I think, would be to take an existing compiler and
    modify it so it supports only the 64-bit int that you want.
    (Presumably you would drop short, long, and long long; I'm guessing
    you'd still want unsigned int, but that's up to you.) You could then
    use your customized compiler for your own programming.

    It's likely that nobody else would be interested in using it. But if
    you're right, everyone else is wrong, and your approach is better than
    what we've been doing for the past several decades, then an existing
    compiler could be the best way to spread your unusual ideas.

    --
    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."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Jul 14, 2007
    #17
  18. Flash Gordon Guest

    Malcolm McLean wrote, On 14/07/07 19:29:
    >
    > "Ben Bacarisse" <> wrote in message
    >> Why do say integers usually count things? Don't you ever calculate
    >> things with integers? I used to work on projects (cryptography stuff)
    >> where calculating was more common than counting and ints were
    >> always too short. Counting is usually done with integers, but you
    >> can't turn that round the other way.
    >>

    > As Flash says, we've been through all this before. I even pulled up some
    > Java stats that showed pretty clearly that there were about as many
    > indexed array accesses as integer operations in a sample of Java
    > programs. I couldn't find a similar study for C, though I didn't try too
    > hard, but there is no reason to suppose that C programs are radically
    > different from Java ones.


    As was pointed out it explicitly excluded major application domains and
    had other major flaws in trying to prove your point, so it failed to
    prove it. For example there was nothing in the study indicating that the
    extremely small sample was representative.

    > Computers spend most of their cycles moving data from one place to
    > another,


    In your opinion. The only code I've come across where that was even
    close to true were dedicated communications cards.

    > and most integers are used to count things in the computer's
    > memory.


    In your opinion. It is untrue for all of the software I've worked on in
    over 20 years.

    The one piece of SW I've come across where I think your claim might be
    true, the original designer admitted when I confronted him that with
    hindsight it was the wrong design, and that my suggestion which would
    have avoided at least three quarters of the moving would have been
    vastly more efficient. However, even then when you add in the other
    processors in the system more processing power (probably by an order of
    magnitude or more, since I'm talking about the other dozen or more
    processors) was spent processing data then moving or counting it.

    > That's not every cycle, of course, nor is every single integer a
    > count of something - cryptography is an obvious exception,


    As is a lot of image processing (done as integer arithmetic for speed),
    a lot of financial processing (done as integer arithmetic on pennies
    because you are not aloud to have rounding errors), as is almost all the
    software in almost every avionics system I've worked on (imaging
    systems, radar systems, built in test software etc).

    > as are
    > intermediate results in frequency transforms, or pixel colours. The last
    > leads us to another issue, in a typical image function


    > void setpixel(long *img, int width, int height, int x, int y, long val)
    > {
    > assert(x >= 0 && x < width);
    > assert*y >= 0 && y < height);
    > img[y*width + x] = height;
    > }
    >
    > How many integers do we have? You could say width * height, plus a few,
    > or you could say six, of which two are pixel values and four
    > intermediates in array calculations. I'm counting it as six, which isn't
    > the only answer justifiable, but makes sense in the context of how best
    > to define the types in a high-level language.


    The integer processing I've done when doing image processing had more
    like several dozen integer operations on pixel values, and only a very
    few on position. Almost all of the algorithms I've worked on or come
    across are designed so that the address calculations are simple
    increments, because there is too much other integer work to do to waist
    cycles on address arithmetic.

    One made up example is proof of nothing. Even one real example proves
    nothing about what the major use for integers is.

    If you want to say it is anything other than personal opinion then find
    some evidence, otherwise stop claiming your personal opinion is reality.
    I.e. either find a study designed to prove your point or get your
    university to fund one and do it properly. I'm sure the stats department
    can tell you how to design a proper study, including telling you that
    you need to find a large enough *representative* sample.

    I'm not the only one to have expressed a dissenting opinion, an I don't
    think I've seen anyone agree with you. Ever considered that if no one
    supports you then the experience of most people here disagrees with you
    and that therefore it might be you that is wrong?
    --
    Flash Gordon
    Flash Gordon, Jul 14, 2007
    #18
  19. "Flash Gordon" <> wrote in message
    news:-gordon.me.uk...
    >
    > If you want to say it is anything other than personal opinion then find
    > some evidence, otherwise stop claiming your personal opinion is reality.
    > I.e. either find a study designed to prove your point or get your
    > university to fund one and do it properly. I'm sure the stats department
    > can tell you how to design a proper study, including telling you that you
    > need to find a large enough *representative* sample.
    >

    That's a very common fallacy. I can find some objection to your evidence,
    therefore you have offered a "no evidence" position.
    Eg Martha saw Fred do the murder. But Martha is Fred's ex-mistress.
    Therefore there is no evidence against Fred. No. It's plausible that an
    ex-mistress would want to frame someone for murder, but not very likely
    given the risks.
    >
    > I'm not the only one to have expressed a dissenting opinion, an I don't
    > think I've seen anyone agree with you. Ever considered that if no one
    > supports you then the experience of most people here disagrees with you
    > and that therefore it might be you that is wrong?
    >

    I haven't seen anyone really demolish my claim that most processor cycles
    are consumed in moving data from place to another. Generally what is offered
    is "I can write a program where that isn't true" or "my subjective opinion
    is otherwise because I do X, which involves a lot of integer calculation".
    That is weak because we naturally say "the spreadheet is calculating an
    average". It is, and that is point of the operation. However really it is
    updating a video display.

    --
    Free games and programming goodies.
    http://www.personal.leeds.ac.uk/~bgy1mm
    Malcolm McLean, Jul 14, 2007
    #19
  20. "Keith Thompson" <> wrote in message
    news:...
    > "Malcolm McLean" <> writes:
    > [...]
    >> My point exactly. We fill the language with gibberish types, which
    >> don't actually gain anything because eventually some fucntion
    >> somewhere will expect an int.
    >> Join the campaign for 64 bit ints and this nonsense will fade away.

    >
    > Your best approach, I think, would be to take an existing compiler and
    > modify it so it supports only the 64-bit int that you want.
    > (Presumably you would drop short, long, and long long; I'm guessing
    > you'd still want unsigned int, but that's up to you.) You could then
    > use your customized compiler for your own programming.
    >
    > It's likely that nobody else would be interested in using it. But if
    > you're right, everyone else is wrong, and your approach is better than
    > what we've been doing for the past several decades, then an existing
    > compiler could be the best way to spread your unusual ideas.
    >

    It is an idea. I could modify the GNU front end, and it would probably be
    quite trivial, though quite hard to understand the code structure.
    However the vast majority of my programming has to work on anything, which
    is partly why having several integer types is such a nuisance.

    ints have been able to address all of memory space, with the unimportant
    exception of strings or char arrays which occupy more than 50% of memory, of
    the vast majority of machines up till now. The advent of 64 bits onto the
    desktop will change that.

    --
    Free games and programming goodies.
    http://www.personal.leeds.ac.uk/~bgy1mm
    Malcolm McLean, Jul 14, 2007
    #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. Dave
    Replies:
    3
    Views:
    362
    Christopher Boomer
    Aug 6, 2003
  2. Harvey Thomas
    Replies:
    0
    Views:
    376
    Harvey Thomas
    Aug 6, 2003
  3. Greenhorn
    Replies:
    15
    Views:
    813
    Keith Thompson
    Mar 6, 2005
  4. Replies:
    3
    Views:
    200
    Sherm Pendley
    Aug 3, 2005
  5. SM
    Replies:
    4
    Views:
    209
Loading...

Share This Page