Windows Vista = quality. Read all about it here. - Linux

This is a discussion on Windows Vista = quality. Read all about it here. - Linux ; On Oct 26, 11:33 am, The Ghost In The Machine wrote: [some interesting stuff that was not inconsistent with my prior post deleted] > > > virtual memory > > More complicated than that, actually. Every element in a > ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 34 of 34

Thread: Windows Vista = quality. Read all about it here.

  1. Re: Windows Vista = quality. Read all about it here.

    On Oct 26, 11:33 am, The Ghost In The Machine
    wrote:

    [some interesting stuff that was not inconsistent with my prior post
    deleted]

    >
    > > virtual memory


    >
    > More complicated than that, actually. Every element in a
    > classical linked list is a potential page fault. A walk
    > through a linked list, no matter where the elements are
    > in virtual memory, will [POTENTIALLY???] result in page faulting if the
    > amount of information (virtual memory used thereby) is
    > greater than the amount of RAM.


    I'm not sure I follow, unless you insert "POTENTIALLY" in the above,
    as I have. I thought the reason they use virtual memory is precisely
    because some people do not have enough RAM, so they have to use their
    HD as 'virtual' RAM.

    >
    > Depending on the application, one can work with certain
    > clustering notions to attempt to limit page faulting.
    >
    >


    Clustering implies statistics to me. I'm not sure where you're going
    with this, perhaps a page fault occurs when you cannot access data
    within XYZ milliseconds, so you need to employ statistics to get a
    reasonably quick access time. News to me if so.


    >
    > I'm old enough to have implemented a JSR instruction in
    > an 1802, thank you very much.


    Seems that both you and Peter Köhlmann have the same problem--you're
    old timers, perhaps over-the-hill and laid off hardware engineers--
    and you resist progress and change because you remember "the good old
    days" (they were terrible in fact).

    Why don't you give in to progress Ghost and use a modern OS like
    Windows Vista(TM)? You could do worse.

    RL


  2. Re: Windows Vista = quality. Read all about it here.

    Linonut wrote:

    > *plonk*
    > *plonk*
    > *plonk*
    > *plonk*
    > *plonk*


    chrisv wannabe




  3. Re: Windows Vista = quality. Read all about it here.

    After takin' a swig o' grog, DFS belched out this bit o' wisdom:

    > Linonut wrote:
    >
    >> *plonk*
    >> *plonk*
    >> *plonk*
    >> *plonk*
    >> *plonk*

    >
    > chrisv wannabe


    Nah, just decided to dispense with the most persistent, unadulterated
    idiots, for a change.

    --
    Tux rox!

  4. Re: Windows Vista = quality. Read all about it here.

    In comp.os.linux.advocacy, raylopez99

    wrote
    on Sat, 27 Oct 2007 02:35:37 -0700
    <1193477737.122308.48320@o80g2000hse.googlegroups.c om>:
    > On Oct 26, 11:33 am, The Ghost In The Machine
    > wrote:
    >
    > [some interesting stuff that was not inconsistent with my prior post
    > deleted]
    >
    >>
    >> > virtual memory

    >
    >>
    >> More complicated than that, actually. Every element in a
    >> classical linked list is a potential page fault. A walk
    >> through a linked list, no matter where the elements are
    >> in virtual memory, will [POTENTIALLY???] result in page faulting if the
    >> amount of information (virtual memory used thereby) is
    >> greater than the amount of RAM.

    >
    > I'm not sure I follow, unless you insert "POTENTIALLY"
    > in the above, as I have.


    A point, perhaps. If one walks the entire list, and the
    list consumes more virtual than available RAM, one will
    by necessity require a page fault. Granted, one can make
    some assumptions to reduce the number of page faults --
    the simplest one is node-sharing, but that introduces
    another pointer and another potential page fault per
    listnode visit. There's also the issue that each list
    consumes a maximum of 16 bytes (assuming 64-bit pointers)
    for the actual list part; the rest is payload. It would
    take a very long list to exhaust 512 MB in that case,
    and one runs into other problems, such as O(N) search time.
    If a payload does not fit in a page, one has additional
    computational complexities regarding number of page faults.

    Other data structures would be more useful, if less
    storage-efficient, in that case. The best one I know of
    is a balanced variable-size multiary tree structure, with
    retrieval time O(log N), insertion/update time O(log N), storage
    O(N log N). A lot of internals refer to a "red-black"
    tree which should have similar characteristics; I'd have
    to research precisely what that is admittedly but C++'s
    STL uses it.

    The names here are ad-hoc. The build assumption is that
    the elements come in unsorted. I assume everyone here is
    familiar with "big-O" notation.

    Structure Storage Build Add Update Delete Search
    Space Time Time Time Time Time

    Array O(N) O(N) O(1) 0 O(1) O(N)
    C string O(N) O(N) O(N) 0 O(N) O(N)
    Sorted Array O(N) O(N^2) O(N) O(N) O(N) O(log N)
    1-List/Ring O(N) O(N) O(1) 0 O(1) O(N)
    2-List/Ring O(N) O(N) O(1) 0 O(1) O(N)
    Skip List O(N log N) O(N log N) O(log N) O(log N) O(log N) O(log N)
    Linked Htable O(N) O(N) O(1) O(1) O(1) O(N)
    Skipping HTab O(N) O(N log N) O(log N) O(log N) O(1) O(log N)
    Dyn. Htable O(N log N) O(N log N) O(log N) O(log N) O(log N) O(log N)
    BTree O(N log N) O(N log N) O(log N) O(log N) O(log N) O(log N)

    1-List = singly-linked; 2-List = doubly-linked. Arrays
    and lists have update times of 0 as the element does not
    have to be moved if the key changes. (In the case of
    a C string, the "key" is a single char.)

    The linked hashtable deserves some explanation. The
    fixed-sized variant can reduce access time by a factor
    of K, where K is the number of slots (each containing
    a linked list). The trouble is that K never changes,
    and O(N/K) = O(N). The dynamic hashtable is a fair bit
    better but the insertion time is longer as there is the
    potential that it has to restructure itself. It also uses
    more storage space.

    It's not clear to me whether a skipping hashtable should be
    O(log N) or O(N) insertion-wise. The general idea is that
    the key hashes, then the table finds the next slot that's not
    full; a skipping hashtable is therefore of limited size.

    The C string is an array of byte (or ASCII char), and has
    terrible characteristics, mostly because one has to go
    hunt for the end. However, it does have the merit of
    extreme simplicity of implementation; strings in VMS, for
    example, had to spend 8 extra bytes for a descriptor.

    The sorted array's initial build can be O(N^2) if the build
    is done naively, or O(N log N) if the array is initially built
    unsorted, and then sorted using an efficient in-place sort
    such as shellsort. The temporary memory used by such a sort
    is not shown in the above table, but would be O(log N) in
    the sorted array's case.

    Since log(1,000,000) = 13.82, the difference between
    O(N^2) and O(N log N) is considerable for large datasets.
    However, one does have to consider that the expensive
    page faults (where a disk seek and read have to occur)
    might wipe out any advantages of a larger data structure in
    some applications, as a memory read might take a fraction
    of a microsecond, whereas a head seek and read will take
    10,000 times as long.

    > I thought the reason they use virtual memory is precisely
    > because some people do not have enough RAM, so they have to use their
    > HD as 'virtual' RAM.


    And the flip side of that is that if one needs more
    virtual memory than real memory, one has to page fault if
    one traverses all of that virtual memory. (Clearly if one
    doesn't need to traverse the entire list, the non-traversed
    parts can sit in disk storage.)

    >
    >>
    >> Depending on the application, one can work with certain
    >> clustering notions to attempt to limit page faulting.
    >>
    >>

    >
    > Clustering implies statistics to me.


    No, in this case one puts related information into the
    same page. The only stat might be the amount of used
    memory on that particular page. The term "clustering"
    is suggestive of a bunch of bees clustering around their
    queen (OK, so "swarming" is the more usual choice there)
    or a bunch of tents clustering around a central maypole
    or houses clustering around a well, or some such.

    > I'm not sure where you're going
    > with this, perhaps a page fault occurs when you cannot access data
    > within XYZ milliseconds, so you need to employ statistics to get a
    > reasonably quick access time. News to me if so.


    No, a page fault occurs if the page is not in RAM.
    The idea is that if one needs this information, one might
    also need certain nearby information, so one can spend
    one page fault and bring all this related information into
    RAM as well, speeding up things (theoretically).

    >
    >
    >>
    >> I'm old enough to have implemented a JSR instruction in
    >> an 1802, thank you very much.

    >
    > Seems that both you and Peter Köhlmann have the same problem--you're
    > old timers, perhaps over-the-hill and laid off hardware engineers--
    > and you resist progress and change because you remember "the good old
    > days" (they were terrible in fact).
    >
    > Why don't you give in to progress Ghost and use a modern OS like
    > Windows Vista(TM)? You could do worse.


    I'll be lucky to get Vista installed on my 512 MB 1.4 GHz
    Athlon, which runs fine under Gentoo Linux -- and I can
    probably forget about Aero, even though I have a BT5500
    nVidia card.

    As for "modern"...what makes Vista modern? The best
    answer you've given me thus far is that Vista is modern
    because it is monopolistic ("everyone uses it"). This is
    not modern any more than horses were modern at the start
    of the "horseless carriage" era.

    >
    > RL
    >


    --
    #191, ewill3@earthlink.net
    Windows Vista. Because it's time to refresh your hardware. Trust us.

    --
    Posted via a free Usenet account from http://www.teranews.com


  5. Re: Windows Vista = quality. Read all about it here.

    On Oct 29, 10:04 am, The Ghost In The Machine
    wrote:
    > In comp.os.linux.advocacy, raylopez99


    > >> More complicated than that, actually. Every element in a
    > >> classical linked list is a potential page fault. A walk
    > >> through a linked list, no matter where the elements are
    > >> in virtual memory, will [POTENTIALLY???] result in page faulting if the
    > >> amount of information (virtual memory used thereby) is
    > >> greater than the amount of RAM.

    >
    > > I'm not sure I follow, unless you insert "POTENTIALLY"
    > > in the above, as I have.

    >
    > A point, perhaps. If one walks the entire list, and the
    > list consumes more virtual than available RAM, one will
    > by necessity require a page fault.


    Ok, I figured it out. My mistake. I thought a "page fault" is in
    fact an exception thrown (maybe it is actually) that results in a
    crash--my mistake. Apparently a page fault is simply an excpetion
    thrown (?) or other flag that simply requires the OS to seek the hard
    drive for the information requested, which of course is slow but
    doesn't mean (as I erroneously thought) that your program will crash.


    > The linked hashtable deserves some explanation. The
    > fixed-sized variant can reduce access time by a factor
    > of K, where K is the number of slots (each containing
    > a linked list).


    Very interesting, but a bit off topic, no? I have Jusenius (sic) book
    on STL C++ and my CSci 101 textbook gets into this, and yes a linked
    hashtable is good for preventing collisions, but this stuff is
    language and OS agnostic. I bet the best software engineers work for
    MSFT, not the Penguin.


    >
    > The C string is an array of byte (or ASCII char), and has
    > terrible characteristics, mostly because one has to go
    > hunt for the end.


    In Managed C++/C# (aka .NET) the string is a immutable class called a
    reference type. It sucks because it can't be changed once
    instantiated, but the clever software engineers at Microsoft (there's
    that word again "clever", seems to go hand-in-hand with the word
    "Microsoft") have come up with another class callled StringBuilder
    that's mutable and can be changed on-the-fly, hence StringBuilder
    mystring = "XYZ"; mystring = "ABC" is OK and reassignment does not
    cause a null pointer or orphaned pointer or crash, etc.


    > However, it does have the merit of
    > extreme simplicity of implementation; strings in VMS, for
    > example, had to spend 8 extra bytes for a descriptor.
    >


    VMS. So you were born in the 1930s, physically peaked in the 1950s (to
    the extent a lifelong couch potato can physically peak),
    intellectually peaked in the 1970s, and now all you can talk about is
    your glory days, like the Springstein song. Sorry to hear about that--
    get with the times Ghost -Machine (your handle no doubt from the best
    seller by Tracy Kitter* on the VAX from the 1970s)--buy Vista and rock
    on!

    > > I thought the reason they use virtual memory is precisely
    > > because some people do not have enough RAM, so they have to use their
    > > HD as 'virtual' RAM.

    >
    > And the flip side of that is that if one needs more
    > virtual memory than real memory, one has to page fault if
    > one traverses all of that virtual memory. (Clearly if one
    > doesn't need to traverse the entire list, the non-traversed
    > parts can sit in disk storage.)


    OK, got it. Thanks.

    >
    > >> Depending on the application, one can work with certain
    > >> clustering notions to attempt to limit page faulting.

    >
    > > Clustering implies statistics to me.

    >
    > No, in this case one puts related information into the
    > same page. The only stat might be the amount of used
    > memory on that particular page. The term "clustering"
    > is suggestive of a bunch of bees clustering around their
    > queen (OK, so "swarming" is the more usual choice there)
    > or a bunch of tents clustering around a central maypole
    > or houses clustering around a well, or some such.


    OK, non-standard usuage. Usually clustering implies statistics.

    >
    > > I'm not sure where you're going
    > > with this, perhaps a page fault occurs when you cannot access data
    > > within XYZ milliseconds, so you need to employ statistics to get a
    > > reasonably quick access time. News to me if so.

    >
    > No, a page fault occurs if the page is not in RAM.
    > The idea is that if one needs this information, one might
    > also need certain nearby information, so one can spend
    > one page fault and bring all this related information into
    > RAM as well, speeding up things (theoretically).
    >


    Yes, I figured this out even before I got to this paragraph.

    >
    >
    > >> I'm old enough to have implemented a JSR instruction in
    > >> an 1802, thank you very much.

    >
    > > Seems that both you and Peter Köhlmann have the same problem--you're
    > > old timers, perhaps over-the-hill and laid off hardware engineers--
    > > and you resist progress and change because you remember "the good old
    > > days" (they were terrible in fact).

    >
    > > Why don't you give in to progress Ghost and use a modern OS like
    > > Windows Vista(TM)? You could do worse.

    >
    > I'll be lucky to get Vista installed on my 512 MB 1.4 GHz
    > Athlon, which runs fine under Gentoo Linux -- and I can
    > probably forget about Aero, even though I have a BT5500
    > nVidia card.


    Sorry to hear about your pecuniary financial position Ghost. You old
    timers need some sort of charity fund it seems.

    >
    > As for "modern"...what makes Vista modern? The best
    > answer you've given me thus far is that Vista is modern
    > because it is monopolistic ("everyone uses it"). This is
    > not modern any more than horses were modern at the start
    > of the "horseless carriage" era.


    Well, Robert Bork, a famous economist/ Supreme Court justice candidate
    from the 1980s (when you were in your 50s), disagrees. He said MSFT
    is powerful (he was a government witness against MSFT) because the
    economies of scale in using MSFT OS are large, and the marginal cost
    of an extra copy of WIndows is near zero, meaning in theory MSFT can
    (and should) capture the entire OS market. I agree. I'm surprised
    Linux even has 0.6% market share, and am even more amazed Apple's
    market share is rising.

    RL


  6. Re: Windows Vista = quality. Read all about it here.

    In comp.os.linux.advocacy, raylopez99

    wrote
    on Mon, 29 Oct 2007 13:09:10 -0700
    <1193688550.260284.153940@v3g2000hsg.googlegroups.c om>:
    > On Oct 29, 10:04 am, The Ghost In The Machine
    > wrote:
    >> In comp.os.linux.advocacy, raylopez99

    >
    >> >> More complicated than that, actually. Every element in a
    >> >> classical linked list is a potential page fault. A walk
    >> >> through a linked list, no matter where the elements are
    >> >> in virtual memory, will [POTENTIALLY???] result in page faulting if the
    >> >> amount of information (virtual memory used thereby) is
    >> >> greater than the amount of RAM.

    >>
    >> > I'm not sure I follow, unless you insert "POTENTIALLY"
    >> > in the above, as I have.

    >>
    >> A point, perhaps. If one walks the entire list, and the
    >> list consumes more virtual than available RAM, one will
    >> by necessity require a page fault.

    >
    > Ok, I figured it out. My mistake. I thought a "page fault" is in
    > fact an exception thrown (maybe it is actually) that results in a
    > crash--my mistake.


    Processor faults can come from a variety of conditions,
    some of which are expected. A page fault is one of
    the expected conditions; another one might be a floating
    point exception, which in some systems is transparently
    (if slowly) handled by the kernel.

    These are distinguished from processor *interrupts*, which
    are from devices such as the keyboard or network card.

    > Apparently a page fault is simply an excpetion
    > thrown (?) or other flag that simply requires the OS to seek the hard
    > drive for the information requested, which of course is slow but
    > doesn't mean (as I erroneously thought) that your program will crash.


    The program *will* crash if the kernel can't find the
    requisite address in swap, in which case in Linux it sets
    up a signal (I don't know the Windows equivalent offhand)
    and returns back to userspace. The signal -- SIGSEGV --
    cannot be caught or ignored; the process dies. A parent
    process can catch the death (SIGCHLD) and try to respawn
    it.

    >
    >
    >> The linked hashtable deserves some explanation. The
    >> fixed-sized variant can reduce access time by a factor
    >> of K, where K is the number of slots (each containing
    >> a linked list).

    >
    > Very interesting, but a bit off topic, no? I have Jusenius (sic) book
    > on STL C++ and my CSci 101 textbook gets into this, and yes a linked
    > hashtable is good for preventing collisions, but this stuff is
    > language and OS agnostic. I bet the best software engineers work for
    > MSFT, not the Penguin.


    Correct to some extent -- though one wonders about that registry.

    >
    >
    >>
    >> The C string is an array of byte (or ASCII char), and has
    >> terrible characteristics, mostly because one has to go
    >> hunt for the end.

    >
    > In Managed C++/C# (aka .NET) the string is a immutable class called a
    > reference type. It sucks because it can't be changed once
    > instantiated, but the clever software engineers at Microsoft (there's
    > that word again "clever", seems to go hand-in-hand with the word
    > "Microsoft") have come up with another class callled StringBuilder
    > that's mutable and can be changed on-the-fly, hence StringBuilder
    > mystring = "XYZ"; mystring = "ABC" is OK and reassignment does not
    > cause a null pointer or orphaned pointer or crash, etc.


    Be very careful here. There's a difference in C++ STL between

    std::string p = "abc";
    p = "def";

    and

    std::string p = "abc";
    p[0] = 'd';
    p[1] = 'e';
    p[2] = 'f';

    The former is changing a string's pointer; the latter the
    contents itself.

    In raw C one can declare:

    char * p = "abc";
    p = "def";

    or
    char * p = "abc";
    p[0] = 'd';
    p[1] = 'e';
    p[2] = 'f';

    Depending on compiler settings (specifically -fwritable-strings
    in GCC), this may or may not work.

    In Java, strings cannot be easily changed but one can do the former:

    java.lang.String v = "abc";

    v = "def";

    Java has no analog for the latter, though an ugly
    introspection hack is available -- most purists consider
    this a bug.

    >
    >
    >> However, it does have the merit of
    >> extreme simplicity of implementation; strings in VMS, for
    >> example, had to spend 8 extra bytes for a descriptor.
    >>

    >
    > VMS. So you were born in the 1930s, physically peaked in the 1950s (to
    > the extent a lifelong couch potato can physically peak),
    > intellectually peaked in the 1970s, and now all you can talk about is
    > your glory days, like the Springstein song. Sorry to hear about that--
    > get with the times Ghost -Machine (your handle no doubt from the best
    > seller by Tracy Kitter* on the VAX from the 1970s)--buy Vista and rock
    > on!


    Very bad guess. I was born in the early 1960's.

    >
    >> > I thought the reason they use virtual memory is precisely
    >> > because some people do not have enough RAM, so they have to use their
    >> > HD as 'virtual' RAM.

    >>
    >> And the flip side of that is that if one needs more
    >> virtual memory than real memory, one has to page fault if
    >> one traverses all of that virtual memory. (Clearly if one
    >> doesn't need to traverse the entire list, the non-traversed
    >> parts can sit in disk storage.)

    >
    > OK, got it. Thanks.
    >
    >>
    >> >> Depending on the application, one can work with certain
    >> >> clustering notions to attempt to limit page faulting.

    >>
    >> > Clustering implies statistics to me.

    >>
    >> No, in this case one puts related information into the
    >> same page. The only stat might be the amount of used
    >> memory on that particular page. The term "clustering"
    >> is suggestive of a bunch of bees clustering around their
    >> queen (OK, so "swarming" is the more usual choice there)
    >> or a bunch of tents clustering around a central maypole
    >> or houses clustering around a well, or some such.

    >
    > OK, non-standard usuage. Usually clustering implies statistics.
    >
    >>
    >> > I'm not sure where you're going
    >> > with this, perhaps a page fault occurs when you cannot access data
    >> > within XYZ milliseconds, so you need to employ statistics to get a
    >> > reasonably quick access time. News to me if so.

    >>
    >> No, a page fault occurs if the page is not in RAM.
    >> The idea is that if one needs this information, one might
    >> also need certain nearby information, so one can spend
    >> one page fault and bring all this related information into
    >> RAM as well, speeding up things (theoretically).
    >>

    >
    > Yes, I figured this out even before I got to this paragraph.
    >
    >>
    >>
    >> >> I'm old enough to have implemented a JSR instruction in
    >> >> an 1802, thank you very much.

    >>
    >> > Seems that both you and Peter Köhlmann have the same problem--you're
    >> > old timers, perhaps over-the-hill and laid off hardware engineers--
    >> > and you resist progress and change because you remember "the good old
    >> > days" (they were terrible in fact).

    >>
    >> > Why don't you give in to progress Ghost and use a modern OS like
    >> > Windows Vista(TM)? You could do worse.

    >>
    >> I'll be lucky to get Vista installed on my 512 MB 1.4 GHz
    >> Athlon, which runs fine under Gentoo Linux -- and I can
    >> probably forget about Aero, even though I have a BT5500
    >> nVidia card.

    >
    > Sorry to hear about your pecuniary financial position Ghost. You old
    > timers need some sort of charity fund it seems.


    Yes, we do. Care to donate $1500 (per user) for new
    hardware and a software license to run this modern OS? :-P

    >
    >>
    >> As for "modern"...what makes Vista modern? The best
    >> answer you've given me thus far is that Vista is modern
    >> because it is monopolistic ("everyone uses it"). This is
    >> not modern any more than horses were modern at the start
    >> of the "horseless carriage" era.

    >
    > Well, Robert Bork, a famous economist/ Supreme Court justice candidate
    > from the 1980s (when you were in your 50s), disagrees. He said MSFT
    > is powerful (he was a government witness against MSFT) because the
    > economies of scale in using MSFT OS are large, and the marginal cost
    > of an extra copy of WIndows is near zero, meaning in theory MSFT can
    > (and should) capture the entire OS market. I agree. I'm surprised
    > Linux even has 0.6% market share, and am even more amazed Apple's
    > market share is rising.


    I was asking why Vista was modern, not why Microsoft is
    or is not a monopoly.

    Now, let's try again. Why is Vista modern?

    >
    > RL
    >



    --
    #191, ewill3@earthlink.net
    Windows. Multi-platform(1), multi-tasking(1), multi-user(1).
    (1) if one defines "multi" as "exactly one".

    --
    Posted via a free Usenet account from http://www.teranews.com


  7. Re: Windows Vista = quality. Read all about it here.

    [snips]

    On Mon, 29 Oct 2007 16:53:04 -0700, The Ghost In The Machine wrote:

    > Be very careful here. There's a difference in C++ STL between
    >
    > std::string p = "abc";
    > p = "def";
    >
    > and
    >
    > std::string p = "abc";
    > p[0] = 'd';
    > p[1] = 'e';
    > p[2] = 'f';
    >
    > The former is changing a string's pointer; the latter the
    > contents itself.


    Is it mandated that the former modifies a pointer?

    > In raw C one can declare:
    >
    > char * p = "abc";
    > p = "def";


    Correct...

    > or
    > char * p = "abc";
    > p[0] = 'd';
    > p[1] = 'e';
    > p[2] = 'f';


    Err... no. In C, one can do no such thing, as p points to a string
    literal, meaning any attempt to write to it invokes undefined behaviour
    and all bets are off.

    > Depending on compiler settings (specifically -fwritable-strings in GCC),
    > this may or may not work.


    If it does, it's by "luck"; the code is broken.

    > I was asking why Vista was modern, not why Microsoft is or is not a
    > monopoly.
    >
    > Now, let's try again. Why is Vista modern?


    Er... cuz it only got released this year?

  8. Re: Windows Vista = quality. Read all about it here.

    In article <0c8iv4-im2.ln1@sirius.tg00suus7038.net>, The Ghost In The Machine wrote:
    >In comp.os.linux.advocacy, raylopez99
    >
    > wrote
    >on Mon, 29 Oct 2007 13:09:10 -0700
    ><1193688550.260284.153940@v3g2000hsg.googlegroups.c om>:
    >> On Oct 29, 10:04 am, The Ghost In The Machine
    >> wrote:
    >>> In comp.os.linux.advocacy, raylopez99

    >>
    >>> >> More complicated than that, actually. Every element in a
    >>> >> classical linked list is a potential page fault. A walk
    >>> >> through a linked list, no matter where the elements are
    >>> >> in virtual memory, will [POTENTIALLY???] result in page faulting if the
    >>> >> amount of information (virtual memory used thereby) is
    >>> >> greater than the amount of RAM.
    >>>
    >>> > I'm not sure I follow, unless you insert "POTENTIALLY"
    >>> > in the above, as I have.
    >>>
    >>> A point, perhaps. If one walks the entire list, and the
    >>> list consumes more virtual than available RAM, one will
    >>> by necessity require a page fault.

    >>
    >> Ok, I figured it out. My mistake. I thought a "page fault" is in
    >> fact an exception thrown (maybe it is actually) that results in a
    >> crash--my mistake.


    Page fault is when you dont have an object in core memory.
    At that point, it is swapped in.

    --
    The most powerful Usenet tool you have ever heard of.
    NewsMaestro v. 4.0.5 - Way Too Cool has been released.

    Automatic enablement of all buttons, checkboxes and fields
    depending on operation.
    Templates generator improvements.

    Job list improvements for new installations having no jobs
    to begin with.

    In some previous releases some class files were missing.
    As a result, the program would not run.
    Sorry for the inconvenience.

    Multi-job support and other important feature additions
    and various improvements and optimizations.

    Web page:
    http://newsmaestro.sourceforge.net/

    Download page:
    http://newsmaestro.sourceforge.net/D...nformation.htm

    Send any feedback to newsmaestroinfo \at/ mail.ru.
    Your personal info will not be released and your privacy
    will be honored.



  9. Re: Windows Vista = quality. Read all about it here.

    In comp.os.linux.advocacy, Kelsey Bjarnason

    wrote
    on Mon, 29 Oct 2007 17:34:07 -0700
    :
    > [snips]
    >
    > On Mon, 29 Oct 2007 16:53:04 -0700, The Ghost In The Machine wrote:
    >
    >> Be very careful here. There's a difference in C++ STL between
    >>
    >> std::string p = "abc";
    >> p = "def";
    >>
    >> and
    >>
    >> std::string p = "abc";
    >> p[0] = 'd';
    >> p[1] = 'e';
    >> p[2] = 'f';
    >>
    >> The former is changing a string's pointer; the latter the
    >> contents itself.

    >
    > Is it mandated that the former modifies a pointer?


    Good question; I'd have to look. Most likely it is.

    >
    >> In raw C one can declare:
    >>
    >> char * p = "abc";
    >> p = "def";

    >
    > Correct...
    >
    >> or
    >> char * p = "abc";
    >> p[0] = 'd';
    >> p[1] = 'e';
    >> p[2] = 'f';

    >
    > Err... no. In C, one can do no such thing, as p points to a string
    > literal, meaning any attempt to write to it invokes undefined behaviour
    > and all bets are off.


    That is a change then from the original C compilers (prior
    to about 1989 or so). I'd frankly have to look. Clearly,
    however, the best one can hope for is a SIGSEGV then.

    Modern C compilers should generate a warning or error
    on the char * p = "abc" (the proper decl includes a 'const').

    >
    >> Depending on compiler settings (specifically -fwritable-strings in GCC),
    >> this may or may not work.

    >
    > If it does, it's by "luck"; the code is broken.


    True.

    >
    >> I was asking why Vista was modern, not why Microsoft is or is not a
    >> monopoly.
    >>
    >> Now, let's try again. Why is Vista modern?

    >
    > Er... cuz it only got released this year?


    Well, yes, that's why it's so modern. Even though Linux
    has better GUI. :-)

    --
    #191, ewill3@earthlink.net
    Useless C/C++ Programming Idea #2239120:
    void f(char *p) {char *q = p; strcpy(p,q); }

    --
    Posted via a free Usenet account from http://www.teranews.com


  10. Re: Windows Vista = quality. Read all about it here.

    [snips]

    On Mon, 29 Oct 2007 19:22:24 -0700, The Ghost In The Machine wrote:

    >>> char * p = "abc";
    >>> p[0] = 'd';
    >>> p[1] = 'e';
    >>> p[2] = 'f';

    >>
    >> Err... no. In C, one can do no such thing, as p points to a string
    >> literal, meaning any attempt to write to it invokes undefined behaviour
    >> and all bets are off.

    >
    > That is a change then from the original C compilers (prior
    > to about 1989 or so).


    K&R may have allowed this; C90 doesn't.

    > I'd frankly have to look. Clearly,
    > however, the best one can hope for is a SIGSEGV then.


    Yeah, except an implementation is under no requirement to reject it; a
    DOS-based app with such code in it may "work", insofar as DOS has little
    concept of memory protection.

    > Modern C compilers should generate a warning or error on the char * p =
    > "abc" (the proper decl includes a 'const').


    Nope. The type of a string literal is char *, not const char *.
    Presumably this is for hysterical raisins, but the damage, if any, is
    done. The types are compatible, the operations being performed aren't.

    >>> Now, let's try again. Why is Vista modern?

    >>
    >> Er... cuz it only got released this year?

    >
    > Well, yes, that's why it's so modern. Even though Linux has better GUI.
    > :-)


    Well, now, no, actually it doesn't. X11 has a better GUI underpinning and
    KDE, Gnome, et al make better use of it to provide a better user
    experience. Linux doesn't even have a GUI.


    That said, when's Aero going to catch up to beryl - other than in hardware
    requirements, which apparently it has long since pasted beryl in? We'll
    leave any other UI issues aside for the moment; watching the lumbering
    behemoth consume enough power to drive a truck, yet deliver features on
    the scale of a mouse-drawn cart is quite sufficiently amusing for the
    moment.

  11. Re: Windows Vista = quality. Read all about it here.

    In comp.os.linux.advocacy, Kelsey Bjarnason

    wrote
    on Tue, 30 Oct 2007 12:45:24 -0700
    :
    > [snips]
    >
    > On Mon, 29 Oct 2007 19:22:24 -0700, The Ghost In The Machine wrote:
    >
    >>>> char * p = "abc";
    >>>> p[0] = 'd';
    >>>> p[1] = 'e';
    >>>> p[2] = 'f';
    >>>
    >>> Err... no. In C, one can do no such thing, as p points to a string
    >>> literal, meaning any attempt to write to it invokes undefined behaviour
    >>> and all bets are off.

    >>
    >> That is a change then from the original C compilers (prior
    >> to about 1989 or so).

    >
    > K&R may have allowed this; C90 doesn't.


    Noted.

    >
    >> I'd frankly have to look. Clearly,
    >> however, the best one can hope for is a SIGSEGV then.

    >
    > Yeah, except an implementation is under no requirement to reject it; a
    > DOS-based app with such code in it may "work", insofar as DOS has little
    > concept of memory protection.


    I was thinking something a little more modern, but point taken.

    >
    >> Modern C compilers should generate a warning or error on the char * p =
    >> "abc" (the proper decl includes a 'const').

    >
    > Nope. The type of a string literal is char *, not const char *.
    > Presumably this is for hysterical raisins, but the damage, if any, is
    > done. The types are compatible, the operations being performed aren't.


    Oops. Mea culpa. A pity admittedly.

    >
    >>>> Now, let's try again. Why is Vista modern?
    >>>
    >>> Er... cuz it only got released this year?

    >>
    >> Well, yes, that's why it's so modern. Even though Linux has better GUI.
    >> :-)

    >
    > Well, now, no, actually it doesn't. X11 has a better GUI underpinning and
    > KDE, Gnome, et al make better use of it to provide a better user
    > experience. Linux doesn't even have a GUI.
    >


    Eeek. Can someone get me down from here? I seem to have
    been hoist by my own petard and am now dangling from a
    lamp in the ceiling. :-)

    >
    > That said, when's Aero going to catch up to beryl - other than
    > in hardware requirements, which apparently it has long since
    > pasted beryl in? We'll leave any other UI issues aside for
    > the moment; watching the lumbering behemoth consume enough power
    > to drive a truck, yet deliver features on the scale of a
    > mouse-drawn cart is quite sufficiently amusing for the
    > moment.


    Yeah, except that the power consumption is going to be an
    issue for Al Gore's troops at some point, since the vast
    majority of GUI users will probably end up with Aero, and
    a large amount of electrical power is generated from coal.

    Blecch.

    --
    #191, ewill3@earthlink.net
    Useless C/C++ Programming Idea #2239120:
    void f(char *p) {char *q = p; strcpy(p,q); }

    --
    Posted via a free Usenet account from http://www.teranews.com


  12. Re: Windows Vista = quality. Read all about it here.

    [snips]

    On Tue, 30 Oct 2007 14:31:46 -0700, The Ghost In The Machine wrote:

    >>> I'd frankly have to look. Clearly,
    >>> however, the best one can hope for is a SIGSEGV then.

    >>
    >> Yeah, except an implementation is under no requirement to reject it; a
    >> DOS-based app with such code in it may "work", insofar as DOS has little
    >> concept of memory protection.

    >
    > I was thinking something a little more modern, but point taken.


    Well, kinda the point - because it's undefined behaviour, any result is
    allowed - including appearing to work. Until it decides to scramble your
    drive. Or whatever.

    > Eeek. Can someone get me down from here? I seem to have
    > been hoist by my own petard and am now dangling from a
    > lamp in the ceiling. :-)


    Heh. We all does it, I was just having some fun with it.

    > Yeah, except that the power consumption is going to be an
    > issue for Al Gore's troops at some point, since the vast
    > majority of GUI users will probably end up with Aero, and
    > a large amount of electrical power is generated from coal.


    Meaning more coal burned, meaning more coal mined, meaning more coal dust
    in the air. Hmm. Black lung, brought to you by Vista(tm).

  13. Re: Windows Vista = quality. Read all about it here.

    Kelsey Bjarnason wrote:
    > [snips]
    >
    > On Mon, 29 Oct 2007 16:53:04 -0700, The Ghost In The Machine wrote:
    >
    >
    >>Be very careful here. There's a difference in C++ STL between
    >>
    >>std::string p = "abc";
    >>p = "def";
    >>
    >>and
    >>
    >>std::string p = "abc";
    >>p[0] = 'd';
    >>p[1] = 'e';
    >>p[2] = 'f';
    >>
    >>The former is changing a string's pointer; the latter the
    >>contents itself.

    >
    >
    > Is it mandated that the former modifies a pointer?


    The OP is wrong. p="def" calls a string assignment operator to store a
    copy of "def" in the string p. How it does that is none of our business
    because the standard is defined in terms of operational effect, not in
    terms of algorithm to be used (although sometimes the algorithm pretty
    much has to be what it has to be). But I think the OP was trying to say
    that this statement makes p point to the original string literal "def".
    Wrong there too.

    --
    Ron House house@usq.edu.au
    http://www.sci.usq.edu.au/staff/house

  14. Re: Windows Vista = quality. Read all about it here.

    [snips]

    On Wed, 31 Oct 2007 14:01:52 +1000, Ron House wrote:
    >>>std::string p = "abc";
    >>>p = "def";


    >>>The former is changing a string's pointer; the latter the
    >>>contents itself.

    >>
    >> Is it mandated that the former modifies a pointer?


    > The OP is wrong. p="def" calls a string assignment operator to store a
    > copy of "def" in the string p.


    Right.

    > How it does that is none of our business
    > because the standard is defined in terms of operational effect, not in
    > terms of algorithm to be used


    Which was kinda the point. I'm sure there are some implementations which
    work this way, but if it's not mandated that they work this way, one
    cannot assert it is done this way "in C++", only in a given set of C++
    implementations.

    > much has to be what it has to be). But I think the OP was trying to say
    > that this statement makes p point to the original string literal "def".
    > Wrong there too.


    Well certainly p wouldn't, as p isn't even a pointer, it's an instance of
    a class, so you can't really point it at anything. You can assign the
    "value" of "def" to p, but that's a different animal entirely.

    Not to be confused with C's char *p = "def" which actually does point p at
    (the first element of the non-modifiable character array) "def".

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2