![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New <dne### [at] san rr com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New <dne### [at] san rr com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New <dne### [at] san rr com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |