Re: memory leak in <vector> STL

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

From: Igor Tandetnik (itandetnik_at_mvps.org)
Date: 07/20/04

  • Next message: Bo Persson: "Re: memory leak in <vector> STL" 
    Date: Tue, 20 Jul 2004 13:42:37 -0400

    "tom_usenet" <tom_usenet@hotmail.com> wrote in message
    news:6okqf0d378ifu91jpo912rcg3kv36qosc0@4ax.com
    > On Tue, 20 Jul 2004 12:55:27 -0400, "Igor Tandetnik"
    > <itandetnik@mvps.org> wrote:
    >
    >> Some of the messages you referred me to seem to claim that x86 is
    >> one of the "abnormal" platforms - that on x86 in protected mode,
    >> loading an invalid address into registers can actually cause CPU to
    >> trip a hardware fault. I don't really know what I'm talking about
    >> here, just parroting back what I read in the post. Please correct me
    >> if I'm wrong or (likely) simply misunderstand the claim.
    >
    > I believe that you only have a problem on x86 if you dereference the
    > pointer - the compiler won't generate the problematic code unless it
    > sees a * or ->. I don't know much about registers and assembler either
    > though!

    Specifically, I'm referring to

    http://www.google.co.uk/groups?selm=j4d7483ask.fsf%40informatik.hu-berlin.de

    saying "People bring up x86 as an example, where a segment register load
    causes a failure if the segment descriptor has been invalidated." Then
    again, as far as I know, Win32 uses flat memory model where all segment
    registers are 0 at all times, so maybe this is irrelevant to our
    architecture of choice after all.

    > You need a version of remove_if that deletes each removed element
    > after copying over it. This may do it in O(n):

    Right, one can do this. It would require a hand-rolled remove()
    implementation though - the stock std::remove_if() is not guaranteed to
    behave this way. 

    -- 
With best wishes,
    Igor Tandetnik
"For every complex problem, there is a solution that is simple, neat,
and wrong." H.L. Mencken
  • Next message: Bo Persson: "Re: memory leak in <vector> STL"

    Relevant Pages

    • Re: non load/store architecture?
      ... Programmers can write great code on a RISC ... Especially in a PC marketplace dominated by the x86. ... Lots of registers and an orthogonal instruction set are important - both have these. ... The lack of registers means much more memory IO, which causes stalls and requires complex scheduling. ...
      (comp.arch.embedded)
    • Re: Intel publishes Larrabee paper
      ... Using x86 as the base it is understandable that the third vector operand ... 32 registers times 4 sets, plus some rename registers and you are ... visible registers your actual register set becomes large, ... The die size tradeoffs of 4 way multi threading is mostly about reducing ...
      (comp.arch)
    • Re: Switch from SBCL to Erlang backend due to scalability issues(GC).
      ... to the SBCL developers saying that they don't use a precise GC on x86 ... should be more likely that their stack locations have to be touched ... than on architectires with more registers. ... and initializing all those stack locations would ...
      (comp.lang.lisp)
    • Re: Relocatable/PIC asm (was intra-segment CALL and JMP)
      ... I'm only writing in x86 assembly right now, ... data back and forth between registers and memory. ... instructions, especially if the instruction is "pairable", i.e., ... Keeping the top two stack items in registers ...
      (alt.lang.asm)
    • Re: More blather about atom
      ... execute on whatever OOO core keeps your x86 workload happy. ... Itanium is so big and complicated, and has so many registers, that it ...
      (comp.arch)