 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 13-Sep-08 11:47, Gail wrote:
>
> "Orchid XP v8" <voi### [at] dev null> wrote in message
> news:48cb8646$1@news.povray.org...
>>
>> Maybe that's part of the problem - I don't have any C programming
>> resources where I can actually look things up. So if something doesn't
>> work, there's the Borland C++ help file, or there's experimentation.
>> Neither of these things help terribly much.
>>
>
> Such a pity that no free C/C++ language guide exists...
>
> http://www.google.com/search?hl=en&q=C+language+guide
> http://www.google.com/search?q=C%2B%2B+language+guide
>
> Please note the deliberate sarcasm in the above statement.
<slighly worried>
That's the second day in a row. I hope all goes well with you and your
new job.
</slighly worried>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 <voi### [at] devnull> wrote:
> Warp wrote:
> > So let me get this straight: You are comparing C in a 10+ years old MS-DOS
> > system to higher-level programming languages (such as Java and Haskell) in
> > modern systems with modern OSes and modern compilers, and based on this you
> > have decided that C sucks?
> As far as I'm aware, C hasn't changed in 20 years, never mind 10.
Compilers, tools and operating systems have. Besides, C itself has changed
as well (the latest standard is from 1999).
Or are you telling me this isn't happening with haskell either? If I'm
not mistaken, haskell didn't even have a debugger until recently.
> Really? I had assumed that after you read past the end of the file, it's
> behaviour is simply undefined. I wasn't expecting the C standard to
> actually bother to define the result of an operation you're not supposed
> to perform.
How are you supposed to detect the end of file if you are not supposed
to ever reach the end of the file? That's kind of contradictory.
> > Besides, reaching the end of file (and getting that -1) is *not* an error.
> No, reaching EOF is not an error - failing to check for EOF is an error.
Since reaching EOF is completely valid, how is the compiler supposed to
make sure that you write a conditional which takes it into account? It can't
do this at runtime because returning EOF is completely valid and not an
error, and thus it cannot raise any exceptions at runtime because EOF was
returned. 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).
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?
> >> I've never seen a C debugger.
> >
> > Thus you base all your prejudices on non-knowledge.
> Yes - because having a debugger would make function names easier to
> remember and pointer syntax less baffling and printf() would work
> right... oh, wait...
Now you are twisting the argument, and arguing for the sake of arguing.
The above context had nothing to do with printf or function names.
> > Luckily haskell doesn't have any arbitrarily selected features in it
> > which you need to memorize (such as for example some function names).
> Well at least you can easily look up Haskell function names.
Yes, that's something not possible with C.
> Maybe that's part of the problem - I don't have any C programming
> resources where I can actually look things up.
Well, I don't have any haskell programming resources where I can
look things up.
(Before you write an answer to that, think about it for a second.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> As far as I'm aware, C hasn't changed in 20 years, never mind 10.
>
> Compilers, tools and operating systems have. Besides, C itself has changed
> as well (the latest standard is from 1999).
My main problem with C is it's design. It isn't *designed* to be "safe"
or "easy", it's designed to be efficient. The result is a language which
offers really minimal assistance to programmers. Crawling through a
program with a debugger hardly compares to having a problem detected at
compile-time before the program even runs.
I'm sure compilers and debuggers have got better over time. But that
doesn't change the fundamental design of the language. It's unsafe by
design, and that causes me endless difficulties.
> Or are you telling me this isn't happening with haskell either? If I'm
> not mistaken, haskell didn't even have a debugger until recently.
(And FWIW, the debugger really isn't that good.)
>> Really? I had assumed that after you read past the end of the file, it's
>> behaviour is simply undefined. I wasn't expecting the C standard to
>> actually bother to define the result of an operation you're not supposed
>> to perform.
>
> How are you supposed to detect the end of file if you are not supposed
> to ever reach the end of the file? That's kind of contradictory.
It's different in every language of course, but what typically happens
is that you have a function that says "is this EOF yet?", and if it is,
you stop reading. And if you don't stop, that's a program bug, and
should be signalled as one.
Apparently in C it's arranged differently.
>>>> I've never seen a C debugger.
>>> Thus you base all your prejudices on non-knowledge.
>
>> Yes - because having a debugger would make function names easier to
>> remember and pointer syntax less baffling and printf() would work
>> right... oh, wait...
>
> Now you are twisting the argument, and arguing for the sake of arguing.
> The above context had nothing to do with printf or function names.
My point is that having a debugger doesn't magically solve all the problems.
>>> Luckily haskell doesn't have any arbitrarily selected features in it
>>> which you need to memorize (such as for example some function names).
>
>> Well at least you can easily look up Haskell function names.
>
> Yes, that's something not possible with C.
It wasn't when I was trying to learn it, no. Today, we have the Internet.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 <voi### [at] devnull> wrote:
> > How are you supposed to detect the end of file if you are not supposed
> > to ever reach the end of the file? That's kind of contradictory.
> It's different in every language of course, but what typically happens
> is that you have a function that says "is this EOF yet?", and if it is,
> you stop reading. And if you don't stop, that's a program bug, and
> should be signalled as one.
I fail to see how that's different from how C does it. You read a value
and check if it was EOF. What's the fundamental difference?
> > Now you are twisting the argument, and arguing for the sake of arguing.
> > The above context had nothing to do with printf or function names.
> My point is that having a debugger doesn't magically solve all the problems.
But it solves many of the problems you are complaining about.
> >> Well at least you can easily look up Haskell function names.
> >
> > Yes, that's something not possible with C.
> It wasn't when I was trying to learn it, no. Today, we have the Internet.
Exactly how is that different from haskell?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Mueen Nawaz <m.n### [at] ieeeorg> wrote:
>> And besides, in C you have the STL which makes such operations somewhat
>> easier. Not as nice as C++, perhaps, but more manageable.
>
> How can you have a standard template library in C, given that C has
> absolutely no support for templates?
Good point. But don't they have something similar in function as the
C++ standard library?
--
When you die, you lose a very important part of your life.
-- Brooke Shields
/\ /\ /\ /
/ \/ \ u e e n / \/ a w a z
>>>>>>mue### [at] nawazorg<<<<<<
anl
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mueen Nawaz <m.n### [at] ieeeorg> wrote:
> Good point. But don't they have something similar in function as the
> C++ standard library?
In the standard C library? Nope. The standard C library offers *nothing*
to help the programmer with handling dynamic data (except a few unsafe
string manipulation functions). It also offers no algorithms whatsoever
(except that horrid qsort() function).
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp nous illumina en ce 2008-09-13 03:36 -->
> Nicolas Alvarez <nic### [at] gmailcom> wrote:
>> Orchid XP v8 wrote:
>>> I guess it works differently with a real OS. I've only ever compiled C
>>> code under MS-DOS, and there you don't get "segfaults"
>
>> MS-DOS has no memory protection at all. If you write into address 0x0000,
>> you might overwrite the operating system.
>
> What operating system?
>
MS-DOS, from before Windows 95. You know, a black screen with white text, no
graphical user interface. Everything done from the command prompt.
--
Alain
-------------------------------------------------
You know you've been raytracing too long when you see something in the real
world and you think, "Hey! How did they get that effect?"
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> In the standard C library? Nope. The standard C library offers *nothing*
> to help the programmer with handling dynamic data (except a few unsafe
> string manipulation functions). It also offers no algorithms whatsoever
> (except that horrid qsort() function).
Wow. Crappy.
--
"Cashew?" "Gesundheit!"
/\ /\ /\ /
/ \/ \ u e e n / \/ a w a z
>>>>>>mue### [at] nawazorg<<<<<<
anl
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain wrote:
> Warp nous illumina en ce 2008-09-13 03:36 -->
>> Nicolas Alvarez <nic### [at] gmailcom> wrote:
>>> MS-DOS has no memory protection at all. If you write into address
>>> 0x0000, you might overwrite the operating system.
>>
>> What operating system?
>>
> MS-DOS, from before Windows 95. You know, a black screen with white text,
> no graphical user interface. Everything done from the command prompt.
I think he's saying MS-DOS doesn't deserve being called an operating
system :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Yes indeed, and if you look at what he writes about C it is not that he
> has problems with imperative languages in general but with this one for
> particular reasons.
But his reasoning always seems to be based on using some ancient compiler
for 5 minutes 20 years ago. I really don't believe that if he sat down for
an hour with a "learn C" book, he couldn't pick it up. Not given the number
of other more complex languages he's picked up. The mistakes that he always
cites (like printf crashing the machine with beeps etc) are common newbie
mistakes, but nothing that won't be caught by a modern OS/compiler and fixed
with a 1 minute lesson.
> Even after adjusting the grammar (Ik begrijp werkelijk niet waarom u het
> zo hard/moeilijk vindt om C. te leren...) it will still be on the edge of
> comprehensible and not something any Dutchman would write (though I really
> do like the kernverklaringen, we really should introduce that in the
> language).
Hehe, surprising how much of that I could understand given my knowledge of
German ;-) Not that I could write any of it, but reading it was almost ok.
> Language is much more than syntax and grammar. Which was the point I
> wanted to make in the first place.
But with the knowledge of syntax and grammar you can at least make a good
start that will work 99% of the time. It may not be the most efficient or
elegant way, but it will work. Only with experience will you become like a
"native" of the language.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott wrote:
> But his reasoning always seems to be based on using some ancient
> compiler for 5 minutes 20 years ago.
1. It was 10 years ago, not 20.
2. It was 6 months, not 5 minutes.
3. I think this horse is now well and truly dead. ;-)
> I really don't believe that if he
> sat down for an hour with a "learn C" book, he couldn't pick it up.
When I was a lad, I was always hearing about how C was this "ultimate
programming language" and how it was the "most powerful" language and
how BASIC and Pascal were mere toys for amatures. Anyway, when I heard
that next semester we'd be doing C, I took it upon myself to borrow a
book about it from the college library.
Frankly I lost interest when I learned that C doesn't even distinguish
Booleans from integers - but they don't let you pass a module just
because you've lost interest. So when the semester actually started, I
made an effort to learn.
I did eventually get a moderately complex program to work. But basically
every time my program didn't work, I'd replace the implementation with
an equivilent but differently worded one until the program actually
worked. (Presumably my idea of "equivilent" doesn't agree with C's.)
Fortunately, my program involved no string manipulation of any kind. In
fact, about all it did involve was doing calculations and writing pixels
to the screen using Borland's proprietry video API.
> Not given the number of other more complex languages he's picked up.
You are seriously claiming that there are languages which are "more
complex" than C?
> The
> mistakes that he always cites (like printf crashing the machine with
> beeps etc) are common newbie mistakes, but nothing that won't be caught
> by a modern OS/compiler and fixed with a 1 minute lesson.
I gather C++ fixes this anyway.
Given that C++ is supposed to be "like C but better" (or more exactly,
"like C but object-oriented"), this is also a language I took a look at.
My dad has a "learn C++ in 21 days" book. (Given my dad's inumerable
misunderstandings about computer technology, this is quite amusing.) So
one day I sat down and had a look.
The first few chapters look almost exactly like a C tutorial. There's no
printf(), but everything else seems exactly the same. Only much later in
the book does it even start to talk about features I haven't seen
before. It strikes me that this is very probably the wrong way to go
about learning C++.
Anyway, again when I learned that dynamic binding is an extra feature
that you have to manually tern on, I kind of lost interest. (Plus my
head was spinning by the time I'd finished reading about the inner
complexities of pointers vs references, copy constructors, etc.) I'm not
sure if C++ really is this hard or whether the book was just badly
written, but it sure did an efficient job of putting me off.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Anyway, again when I learned that dynamic binding is an extra feature that
> you have to manually tern on, I kind of lost interest. (Plus my head was
> spinning by the time I'd finished reading about the inner complexities of
> pointers vs references, copy constructors, etc.) I'm not sure if C++
> really is this hard or whether the book was just badly written, but it
> sure did an efficient job of putting me off.
Sounds like it tried to cram in too much too soon, something is wrong if you
find yourself wondering about dynamic binding before you understand what
while(*a++=*b++); does! YOu can get a very long way without ever needing to
know about dynamic binding or the detail of how copy constructors work.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott wrote:
>> Anyway, again when I learned that dynamic binding is an extra feature
>> that you have to manually tern on, I kind of lost interest. (Plus my
>> head was spinning by the time I'd finished reading about the inner
>> complexities of pointers vs references, copy constructors, etc.) I'm
>> not sure if C++ really is this hard or whether the book was just badly
>> written, but it sure did an efficient job of putting me off.
>
> Sounds like it tried to cram in too much too soon
Well, it *is* named "learn C++ in 21 days". ;-)
> something is wrong if
> you find yourself wondering about dynamic binding before you understand
> what while(*a++=*b++); does! YOu can get a very long way without ever
> needing to know about dynamic binding or the detail of how copy
> constructors work.
It did seem complex and unecessary. I kept asking myself "why the hell
do I need to care about such things?" At the time, I assumed it was
because C++ is badly designed. From what Warp has said, maybe it was
just that the book was badly designed. It presented the information as
being stuff that every beginner C++ programmer absolutely must know.
From the sound of it, that's not actually the case.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> 3. I think this horse is now well and truly dead. ;-)
That's probably true. You have decided that you have, and will always
have, a strong prejudice against C and C++, and absolutely nothing will
ever convince you otherwise.
> Anyway, again when I learned that dynamic binding is an extra feature
> that you have to manually tern on, I kind of lost interest.
This I simply cannot comprehend.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> My dad has a "learn C++ in 21 days" book. (Given my dad's inumerable
> misunderstandings about computer technology, this is quite amusing.) So
> one day I sat down and had a look.
http://norvig.com/21-days.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I did eventually get a moderately complex program to work. But basically
> every time my program didn't work, I'd replace the implementation with an
> equivilent but differently worded one until the program actually worked.
This is the sort of thing I was referring to when I said you need to know
what you don't know about your code. You can't just guess your way to an
understanding; you must first learn why your original code is broken. This
isn't always possible but it's a good goal. You learn a lot more that way.
> 1. It was 10 years ago, not 20.
Surely the things you've learned about programming in the last 10 years
would be helpful. Personally, I failed to learn C++ the first time I tried
but succeeded the second time after years of working with other languages.
Anyway, if you're not interested in learning C++, that's cool. I had thought
you were interested. I just see a pattern in your posts where there are
things you want (in this case a programming job), and when people encourage
you to get them, you list reasons why you're not able to, or why it's
difficult. You need to learn to ignore or deal with the hurdles and push
yourself until you get where you want to be.
- Slime
[ http://www.slimeland.com/ ]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Invisible <voi### [at] devnull> wrote:
>> 3. I think this horse is now well and truly dead. ;-)
>
> That's probably true. You have decided that you have, and will always
> have, a strong prejudice against C and C++, and absolutely nothing will
> ever convince you otherwise.
What, you mean... a bit like you and every programming language that
isn't C++? :-P
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Slime wrote:
>> I did eventually get a moderately complex program to work. But basically
>> every time my program didn't work, I'd replace the implementation with an
>> equivilent but differently worded one until the program actually worked.
>
> This is the sort of thing I was referring to when I said you need to know
> what you don't know about your code. You can't just guess your way to an
> understanding; you must first learn why your original code is broken. This
> isn't always possible but it's a good goal. You learn a lot more that way.
I guess the problem was not having anybody to ask nor any documentation
to look at. My mental model of what the code should be doing was clearly
broken, or the code would have done what I intended. But without any way
to figure out why... there's not a lot you can do.
>> 1. It was 10 years ago, not 20.
>
> Surely the things you've learned about programming in the last 10 years
> would be helpful.
I somewhat doubt that knowing Smalltalk, Java, Tcl, PostScript and
Haskell is going to be of any help in learning either C or C++.
> Anyway, if you're not interested in learning C++, that's cool. I had thought
> you were interested. I just see a pattern in your posts where there are
> things you want (in this case a programming job), and when people encourage
> you to get them, you list reasons why you're not able to, or why it's
> difficult. You need to learn to ignore or deal with the hurdles and push
> yourself until you get where you want to be.
It's just very difficult to find motivation when
1. all your endevours fail
2. nobody except you actually gives a damn anyway
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I somewhat doubt that knowing Smalltalk, Java, Tcl, PostScript and Haskell
> is going to be of any help in learning either C or C++.
I think they will. Not in specific ways, just in that you've learned to wrap
your mind around a lot of different types of languages. But I guess we've
already discussed this. =)
> It's just very difficult to find motivation when
>
> 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!
- Slime
[ http://www.slimeland.com/ ]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
