>>>> while (x[i] = y[i--]) ;
>>>
>>>> is perfectly valid. You sick, sick people.
>>>
>>> I think that's Undefined Behavior because the same variable is being
>>> modified and referenced more than once in the same expression.
>>>
>>
>> Nothing undefined here.
>
> Does it compare x[i] to y[i] or to y[i-1]? Why do you answer that way?

Last time I checked, the /comparison/ operator is ==.

The = operator performs *assignment*. :-P

(Assuming that neither x[] nor y[] contains any zero bytes, presumably 
this is also an infinite loop...)

Post a reply to this message

>> When will we see the Haskell# language?
>
> I'm pretty sure the whole .NET bit is too OO to make that useful.There's
> way too much stateful stuff (like I/O) that you'd want to use from .NET
> to make it reasonable to have a purely function .net language.

Haskell already supports a wide range of I/O operations. That's pretty 
stateful, and it's not a problem.

Yeah, if you wanted to talk to the .NET libraries, it would all end up 
being monadic. (Even the .NET stuff that's actually pure - since it 
isn't /marked/ as pure.) But it would still work fine.

I think it's probably vacuous to try to estimate how "useful" it would 
be without actually trying it...

Post a reply to this message

> The time of monolithic pieces of software is long buried in the past.
> Today it's all composable by hundreds of small libs, perhaps even loaded
> at runtime. Ever even heard of web mashups? Application servers?

Well, unfortunately Haskell does not yet support dynamic linking very 
well. (At least it now has /some/ support for it...)

>> How hard would it be to allow each directory to contain a file saying
>> what commands each key should be bound to?
>
> with a Makefile file in each directory each time you press make on the
> command-line it makes that part. ;)

Yeah, that could work.

>> The whole point of a text editor is for looking at text.
>
> no, the whole point of a text *editor* is for *editing* text.

Well, if that's your attitude, then surely ed is good enough for you?

>> Why make it look awful when you can make it look good? Why make your
>> job harder when you can make it easier?
>
> Nobody is making it look awful. But between spending time making it look
> good and do nothing and looking awful and doing a shitton of stuff, you
> know what open-source developers will do...
>
> plus, looking awful does not your job harder. On the contrary: in my
> experience the most beautiful-looking text editors out there are usually
> the most featureless and useless there are. Why implement features that
> will make it complex and awful-looking? Better just have a simple
> interface and when the user wants to copy the next 5 long paragraphs and
> paste them 5 times they should do it manually by constant repetition of
> the basic, beautiful and simple mechanisms, rather than just typing
> y5}5p... clearly the latter is making your job far harder!

I can't even tell what the hell you're saying now. :-P

Post a reply to this message

>> (And besides, any kind of detection of this cannot be 100% accurate,
>> as the problem "will this line of code ever be reached?" is unsolvable
>> in the general case.)
>
> But detecting type errors isn't 100% accurate either.
>
> int x = 1 ? 5 : "hello";
>
> That's not legal, but it's not a type violation either.

The general problem of determining whether every possible code path is 
well-typed is undecidable. Type systems insert artificial restrictions 
to /make/ the problem decidable. Hence, there are expressions and 
statements which are well-typed, but do not type-check.

Post a reply to this message

>> It even complains if you have a void function that uses return just to
>> exit early, and there's nothing afterwards...)
>
> I didn't run into that.

By "complains" I mean it gives you a warning. It still compiles OK.

Post a reply to this message

On 20/04/2012 01:57 AM, Darren New wrote:
> On 4/17/2012 1:52, Invisible wrote:
>> Except that assembly generally follows a simple and consistent syntax,
>
> ... says the man who never programmed in an assembly language for
> machines designed to be programmed in assembly language.

So what /was/ the Motorola 68000 designed to be programmed in then?

>> an "obscure feature" which you don't need to know about. :-P
>
> It *is* outside the C standard, tho, in terms of what it "means".

Sure. But in terms of writing practical code that runs on common 
hardware under common operating systems - which is the target of this 
book - it's not exactly "obscure". It's not like this is a book about 
how to program microcontrollers. (That would be something else entirely...)

>> I dislike code that's so littered with comments that you can't see the
>> code
>
> Except in assembler.

?

>> I guess this is why autoconf exists. :-P
>
> That and amongst many, many, *many* other reasons.

I found another one:

http://tinyurl.com/32vda9

>>> Second warning: the signedness of char is local to the compiler.
>>
>> Really? The book seems to say that all integer types default to signed,
>> unless you request unsigned. (AFAIK, there isn't a way to request
>> signed.)
>
> Except characters. Because PDP-11.

It worries me that we're still using a language who's fundamental design 
decisions are based on hardware first produced in the 1970s.

But it worries me more that they only stopped manufacturing the PDP-11 
in the 1990s. o_O

>> So much for C and C++ being for system-level programming. :-P
>
> It was never very *good* for it. It was just better than its competitors
> of the time.

Jesus, did it even *have* any competitors?!

>>> Usually, float is a 32 bits, double is 64 bits. But it is known that
>>> some compiler would perform the computation on 80 bits registers...
>>
>> Is there a way to explicitly request 80 bits?
>
> No, of course not. C doesn't provide any way to ask for a type based on
> what you need. You can only ask for types based on what the CPU
> provides

OK, well IA-32 provides 80-bit floats. So... is there a standard way to 
get them?

>> Right. So if I request a 2GB array, it won't actually sit there trying to
>> zero all 2GB of RAM, right before my for-loop rolls over it to
>> initialise it
>> /again/.
>
> The OS probably will, tho, if you have a multi-user OS.

Not much I can do about that. ;-) But yeah, it does make the whole 
design decision seems a be out-dated. (Then again, calling the default 
constructor for each array element might do a lot more work than just 
zeroing some bytes. Presumably the way the OS zeros memory is quite 
efficient.)

>> Oh that's sick. So comma really /is/ an operator? Wow, that's evil.
>
> Why? It's just an operator. Is it really worse than Haskell's "." or
> ">==" operators, or whatever they're called?

You'd expect part of the language's basic syntax to be, you know... part 
of the language's basic syntax. But it isn't. It's just a regular 
operator, which means you can use it in places where you shouldn't be 
putting random commas, and that makes it do strange stuff. (And, being 
C, this isn't checked in any way.)

>> I was referring more to the fact that it's legal to not specify the
>> return
>> type, and if you don't, it defaults to something absurd.
>
> It defaults to integer. Not sure what makes that "absurd".

The /logical/ thing is for a function that doesn't mention a return type 
to default to returning nothing. And yet, it doesn't. It arbitrarily 
defaults to int. Not bool, not void*, not w_char, but int. No reason, it 
just does.

>>> At one point in the argument list, you must start providing default
>>> values, for all argument at the right of that point.
>>
>> ...which makes infinitely more sense than what the book said. :-P
>
> Really!? What the book said was clearly and simply a mathematical-type
> statement. No parameter without defaults can be preceeded by one with
> defaults. Hence all defaults must come after all non-defaults.
>
> The previous statement is inaccurate in that it does not take into
> account no-defaults and all-defaults.

I forget who said it: comprehension = 2 ^ -precision.

Post a reply to this message

>> In other words, yet again, "now you know how this works, you don't
>> need to actually use it".
>
> Right. Except in very limited circumstances when you know how deeply
> you'll recurse, because there's no guarantee it'll work and no way to
> check.

...what?

>> "Registers are a special area of memory built right into the CPU."
>> Erm...
>
> What's questionable about that? Heck, on the Sigma 9, the registers 0
> thru 15 were actually addressed as memory locations 0 thru 15, to the
> point where you could store program code in the registers and branch to it.

Nobody designs hardware like that any more. Haven't done for decades. :-P

>> "They take care of internal housekeeping."
>> ...actually...
>
> Program Status Word.

The /registers/ do not take care of anything. The /processor/ does.

>> So I'm guessing an architecture exists where the instruction pointer
>> /isn't/ a single register then? :-P
>
> Yep. Anything with memory mapping hardware, segment registers, etc.

None of which are relevant in the current day and age, unless you're 
writing an OS. Certainly this technicality has no place in an 
introductory programming text.

>> Still, it does answer something I've always wondered about: What *is*
>> the C calling convention?
>
> Undefined, generally speaking. Or rather, implementation-specific. And
> depends on pragmas, sometimes.

So you're telling me that the de facto calling convention that all 
software always uses is "undefined"?

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Technically, I think a new copy of the function is generated/compiled for 
> each compilation unit that uses it for each type, but the different versions 
> for the same type are merged, right?

  Yes. (Except if the function is inlined by the compiler, in which case
there's no need.)

-- 
                                                          - Warp

Post a reply to this message

Le_Forgeron <lef### [at] freefr> wrote:
> If they are in separate compilation units (different top level *.cpp
> files), each units will get its own version.

  No, they will be merged by the linker (although I'm not completely sure
now if the standard requires it; at the very least it requires for all
static variables inside the function to be merged, IIRC).

  If the context of the template instantiation affects its behavior, then
instantiating it under differing contexts is actually undefined behavior.
(In practice what will usually happen is that only one of them will end up
in the final binary and all the code will call that one; the other contexts
will have no effect on it.)

> (that's the issue with template: generated code can grow very fast if
> you use the template in many *.cpp files)

  Object files might grow, but not the final binary.

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> > The book claims that if you write a function body inside a class definition,
> > that makes the method inline. Is this true? I thought there was no
> > difference either way...

> It *has* to be.

  It doesn't *have* to be (any more than any other function defined in a
header file, or anywhere else), but the standard says it is, and so it is.

  The difference can be seen eg. like this:

//-------- Example 1 ----------
class A
{
 public:
    // This function is implicitly 'inline',
    // no need to specify the keyword:
    void foo() { std::cout << "Hello\n"; }
};
//-----------------------------

//-------- Example 2 ----------
class A
{
 public:
    void foo();
};

// This function is *not* implicitly 'inline' and will cause linker
// errors unless the keyword is used:
void A::foo() { std::cout << "Hello\n"; }
//-----------------------------

-- 
                                                          - Warp

Post a reply to this message