On 8/1/2011 12:19, Warp wrote:
> so there's nothing stopping the compiler itself just embedding some kind
> of "valgrind" into the program itself.

Back when Pascal was popular, I did an enhancement to the Pascal compiler 
used at my university for teaching. Each allocation bumped a global counter 
and put the result in both the pointer and the block of allocated data. It 
also chained together all the data blocks.

Then, every time you used a pointer, it would walk the blocks of allocated 
memory to make sure the pointer was still on the list, then check that the 
counter values were the same. The former kept you from using dangling 
pointers, and the latter kept you from using a pointer that was dangling but 
happened to get reallocated later.

Obviously, performance sucked, but it was only turned on for teaching 
purposes, so that's OK.  And of course you can't do this (as easily) in a 
language that supports pointer arithmetic; you'd have to treat allocations 
as base+index.

>    Visual C++ has a decent debug mode, but I wish it did more. It would be
> nice if gcc had a significantly expanded debug mode. It's not like it
> would be impossible.

I would think anything where you say "we can rely on undefined behavior not 
happening in order to improve this", you could simply define the behavior as 
"we check for this, and drop into the debugger (or whatever) if we find it."

But to be fair, gcc and other compilers have come a long way. They warn you 
if you use variables that may be uninitialized, they warn you if you pass 
the wrong types to printf with a literal formatting argument (which is why 
the iostream argument that it's better because it's strongly typed never 
made much sense to me), and so on.

It would probably be really complicated to check even more stuff.

> I wonder if other programming languages have similar tools.

Stuff that's interpreted (or bytecoded) generally has tools like this, but 
they tell you more what's happening (i.e., "lots of iterations of this 
line") rather than the actual microseconds taken precisely, in part because 
the precision isn't as repeatable in such environments. You can usually see 
what lines were run, how much memory was allocated to particular types, and 
how long individual lines took, but I don't think they tend to go to 
exceptional effort to do better than what you'd get from the straightforward 
"read the CPU performance counter" type of thing.

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message