Slime wrote:

>> 1. all your endevours fail
> 
> Learn to recognize the things you *are* good at and build some confidence in 
> yourself. Don't spend all your time focusing on the things you can't do yet; 
> look at what you've done that other people wouldn't even bother to try. When 
> you fail, make a conscious effort to learn from your mistakes.
> 
>> 2. nobody except you actually gives a damn anyway
> 
> Sometimes you only need to please yourself!

It just feels like my life is like Groundhog Day, you know? If I do 
something well, nobody comes up to me and says "Hey Andrew, you did that 
really well." If I have a bad day, nobody comes up to me and says "Don't 
worry Andrew, it'll be better next time." Basically no matter what I do, 
the outcome is always the same: nobody comes up to me and says anything.

You say I should have more confidence in my abilities, but when nobody 
ever tells you you've done something well, you start to wonder whether 
you really have, or whether you're just overestimating your achievements.

It's just really hard to find motivation when no matter what, whether 
you did really well or really badly, the outcome is always exactly the 
same. You start to wonder why you're bothering...

Post a reply to this message

Invisible wrote:
> Apparently there are people who know 
> the Secret Techniques for debugging C programs, and even writing C 
> programs that are correct in the first place 

Sadly, those are the same two things. :-) The kinds of bugs that are 
hard to track down are the ones you need to aboid in the first place.

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Warp wrote:
>   It's impossible to use a hash table and get the elements in increasing
> order with a linear traversal. 

Will the hashmap guarantee equal traversals for hashmaps with equal 
contents, or will it depend on the order of insertion and deletion?


-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Mueen Nawaz wrote:
> It's not how programmers do stuff typically.

One thing I haven't worked out.  Warp keeps saying "don't use new", by 
which he means "let the experts who understand C++ deeply write the 
libraries that use new, and you just use the libraries."  OK, I can 
handle that.

But ... how realistic is that in a large program with complex data? 
Consider something like POV-Ray - isn't that going to have to be using 
"new" as it builds the scene, as it calculates bounding boxes, and stuff 
like that?

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Warp wrote:
>   Since reaching EOF is completely valid, how is the compiler supposed to
> make sure that you write a conditional which takes it into account? 

Some languages can do this, actually, just like some can look at an enum 
and tell you when your switch statement doesn't cover all possibilities. 
:-) It's pretty cool, but certainly not something you could do in a 
language based on the machine level, like C is.

> In fact, returning EOF multiple times is not an error either
> (it can be perfectly possible for different parts of the program to read
> the same file, and all of them get an EOF when there's nothing more to
> read, and all of them still work properly).

Actually, from the keyboard, you can read data, get an eof, read more 
data, and get another eof, just by typing ctrl-D twice.

>   So how is the compiler supposed to make sure that you do the "correct"
> thing when EOF is returned? What *is* the "correct" thing to do?

Not compile a program that tries to read past EOF?

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Will the hashmap guarantee equal traversals for hashmaps with equal 
> contents, or will it depend on the order of insertion and deletion?

  I have no idea. Knowing how hash tables are usually implemented,
I wouldn't be surprised if it didn't guarantee anything. After all,
it *is* called "unordered map". That might literally mean "no order
guaranteed" (not even for two hash maps with the same elements).

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> >   So how is the compiler supposed to make sure that you do the "correct"
> > thing when EOF is returned? What *is* the "correct" thing to do?

> Not compile a program that tries to read past EOF?

  The compiler has to guess how much data there is in a possible input file?

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>> Not compile a program that tries to read past EOF?
>   The compiler has to guess how much data there is in a possible input file?

No. The compiler does something called typestate analysis (not too 
unlike data flow analysis) to ensure that once the function returns EOF 
you don't invoke the read function any more.

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> No. The compiler does something called typestate analysis (not too 
> unlike data flow analysis) to ensure that once the function returns EOF 
> you don't invoke the read function any more.

  Given that in a Turing-complete language it's impossible to prove
in the generic case whether a certain piece of code is ever executed
or not, that would mean that the language would have to be less
expressive than a Turing machine.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   Given that in a Turing-complete language it's impossible to prove
> in the generic case whether a certain piece of code is ever executed
> or not, that would mean that the language would have to be less
> expressive than a Turing machine.

I think you're overgeneralizing. Is it not possible to prove that you 
never use a variable before you assign to it, or that every path to exit 
a value-returning-function actually returns a value? Of course it is. 
Why is it harder to prove you never read from a file handle after it has 
hit EOF?

You might not be able to tell whether a program *will* get to any 
particular point in the code, but you can certainly make it illegal for 
it to get to particular places in the code and hence guarantee it does 
*not* get to that point.

Every implementation of typestate I've seen where people rely on it 
(i.e., require the semantics for the language to work, rather than just 
issuing warnings) includes annotations on module-spanning APIs. In other 
words, when you open a file, the returned file handle is marked at 
"open", and when you read the EOF, it's actually an exception (meaning 
the execution returns to a different place in the code rather than 
returning a flag), so it's easy to tell at each particular line in the 
code whether a file is open or not. I.e., if you have a function that 
returns a file handle, you have to say whether that file handle is 
already at EOF or not, for example.

It also rules out constructs like
   int z;
   if (x == y)
      z = 0;
   my_func(z);

That doesn't make it less turing complete.
-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message