Orchid XP v7 <voi### [at] devnull> wrote:
> I mean, if you're the guy who designed the inside of the C compiler and 
> knows the exact instruction scheduling algorithm that it uses *and* you 
> somehow have access to the source code version of the program *and* you 
> understand the exact execution path that lead to this point *and* you're 
> a super-expert in extremely low-level programming *and* you have insane 
> amounts of time available...

  Or, alternatively, you have a simple C debugger.

-- 
                                                          - Warp

Post a reply to this message

Eero Ahonen wrote:
> Brian Elliott wrote:
>> "Alain" <ele### [at] netscapenet> wrote in message
>> news:4731f3f7$1@news.povray.org...
>>> Once when playing with a small speaker, I pluged it in a transformer
>>> and was prety unimpressed by the feeble low hum I got, so, I plugged
>>> it directly into the wall socket, hoping for a loud hum. Use a regular
>>> electrical plug, hook the speaker whires in to it, plug it in. Instant
>>> POF, flash of light, small cloud of smoke, smell of ozone and burnt
>>> metal, bursted speaker's dome. The coil's whires got vaporised.
>>> At the time, I was about 10 or 11.
>> I did the same to one of those tiny 3-volt DC motors, like the cog-ended
>> ones that are in battery-powered toys.  A friend bragged at school he'd
>> plugged one into the mains, and it went really incredibly fast and was
>> really hot afterwards.
>>
> 
> Every time I read these I feel more and more sorry for myself for NOT
> doing something that stupid (and cool :p) as a kid.
> 

Yeah, me too.

Guess I have still some time left to do something cool with elec ;)

-- Arttu Voutilainen

Post a reply to this message

Warp wrote:
>   Or, alternatively, you have a simple C debugger.

Heck, I used to go through printed hex core dumps to figure out what 
went wrong. It's not that hard, if you know what you're doing.

Of course, with programs bigger than a few dozen K, it helps to have 
automation. :-)

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

Invisible wrote:
> We have a buggy program that keeps throwing exceptions due to a "pure 
> virtual function call".

Usually that means you're invoking a dynamically-bound method for which 
there is no definition. I didn't know you could get that in C++ as the 
first mistake the program makes.

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

Nicolas Alvarez wrote:
> I was once playing around with the flash of an old instant camera.

I made my own Xenon flasher once around that age. Etched my own PCB and 
everything.  It worked.  Once.  Then I had to clean up the parts all 
over the basement.

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Invisible wrote:
> > We have a buggy program that keeps throwing exceptions due to a "pure 
> > virtual function call".

> Usually that means you're invoking a dynamically-bound method for which 
> there is no definition. I didn't know you could get that in C++ as the 
> first mistake the program makes.

  I think that error happens if you try to call a pure virtual function
in the initialization list of the base class constructor. (What I really
don't understand is why it isn't a compile-time error...)

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   I think that error happens if you try to call a pure virtual function
> in the initialization list of the base class constructor. (What I really
> don't understand is why it isn't a compile-time error...)

Just to check, by "pure virtual function", you mean the kind of thing 
that leads to the class being abstract? A function like
   virtual int func() = 0;
or whatever the syntax is?

Oh, right, OK. So it's called in the constructor of the class that 
actually implements the virtual function, except it's called before the 
child's constructor actually gets entered, so the vtable pointer is 
still pointing to the parent's vtable or whatever so the parent has the 
right offsets for its stuff, ....

I can see where catching that would be difficult. If the constructor 
calls x(), and x() calls y(), and y() is abstract in the parent class, 
C++ is going to invoke a function whose definition isn't there.

Most other languages don't futz with the class of the object while it's 
being constructed, so it doesn't really come up, I guess. One of the 
costs of multiple inheritance as implemented by C++?

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

Orchid XP v7 <voi### [at] devnull> wrote:
> Stephen wrote:
>

>
> You're not the only one. In fact, I'm going to go out on a limb here and
> say you're not the only one by a large measure...

I bet that you could build a tree house on that limb :0

Stephen

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Nicolas Alvarez wrote:
> > I was once playing around with the flash of an old instant camera.
>
> I made my own Xenon flasher once around that age. Etched my own PCB and
> everything.  It worked.  Once.  Then I had to clean up the parts all
> over the basement.
>


Well if we are going for a P***ing contest:)

uniselector and a rotary phone dial. It could add and subtract with the output
in binary. Almost as much fun as the wine making.


Stephen

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Invisible wrote:
>>> We have a buggy program that keeps throwing exceptions due to a "pure 
>>> virtual function call".
> 
>> Usually that means you're invoking a dynamically-bound method for which 
>> there is no definition. I didn't know you could get that in C++ as the 
>> first mistake the program makes.
> 
>   I think that error happens if you try to call a pure virtual function
> in the initialization list of the base class constructor. (What I really
> don't understand is why it isn't a compile-time error...)

According to the Microsoft VisualC++ documentation, "usually" it *is* a 
compile-time error, "but cannot be detected in all cases".

Presumably that means that if you do sufficiently freaky things with 
pointers to pointers to data through multiple levels of type casts, the 
compiler can't figure out what you're actually doing or something.

Now, fun thing: Why does it only do this on Windows XP, not Windows NT?

Post a reply to this message