Orchid Win7 v1 escreveu:
>>>> so, all your programs are some monolithic piece of software with all
>>>> parts compiled in one go?
>>>
>>> Yes. Why?
>>
>> because it's both wrong and dumb.
> 
> That's right up there with saying that Haskell is better than C because 
> C is both wrong and dumb. Yeah, it's true, but it won't convince anybody...

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, ok, for sufficiently small toy applications and scripts, 
monolithic is good enough.

> 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. ;)

>>>> you're nuts. Any decent editor has support for several file buffers.
>>>
>>> Any decent GUI-mode text editor, yes. On the a text terminal, you
>>> can't do that.
>>>
>>> (Correction: Emacs can do it. And it looks awful.)
>>
>> emacs, vi, pico etc...
>>
>> it may look awful, but it behaves great. Ever heard "don't judge a book
>> by its cover"?
> 
> The whole point of a text editor is for looking at text.

no, the whole point of a text *editor* is for *editing* text.

> 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!

Post a reply to this message

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.

> 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".

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

Except in assembler.

> That's pretty messed up.

Why is it messed up? Ada even has a type for "one byte of memory" and a 
different type for "one byte of I/O".  You might read 8-bit strings from an 
I/O channel into 9-bit memory.

>> One warning: sizeof() will return the size in char, not bytes.
> Oh, that's fun. Let us hope that char *is* one byte, otherwise... damn!

Nah. There's a header file that tells you how many bits per byte. I'm pretty 
sure C assumes binary computers, tho. :-)

> I guess this is why autoconf exists. :-P

That and amongst many, many, *many* other reasons. Note that C isn't a 
portable language. It just lets you stick many versions of the source code 
into one file.

>> 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.

> 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.

> microcontroller, I might be worried. On a desktop PC, I'm not too concerned.

Now, yeah. Note that IEEE standardized floating point *long* after C was 
around. Heck, even after x86 was around IIRC.

>> 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, and 
header files to tell you what the CPU provides so you can write code to try 
to compile the right version. In Ada, in contrast, you'd say "give me the 
float with X range and Y precision."

> 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.

> So, it always rounds downwards?

It might depend on the sign. Two positive integers always rounds down.

> 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?

> 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".

>>> Next, we learn that function arguments can have default values. But get
>>> this:
>>>
>>> "Any or all of the function's parameters can be assigned default
>>> values. The one restriction is this: If any of the parameters does not
>>> have a default value, no previous parameter may have a default value."
>>>
>>> ...um, what?
>>
>> 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.

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

On 4/17/2012 3:47, Invisible wrote:
> Now, I'm used to programming languages where the decision to inline
> something or not is down to the compiler. It's not something an application
> programmer would ever have to worry about. And it seems that the inline
> directive is only a "hint" in C++ anyway, so I have to wonder, whether this
> particular directive is now obsolete.

This explains it better.

http://yosefk.com/c++fqa/inline.html

> 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.

> I'm not sure what's so "unmanageable" about it all. Provided you don't try
> to reach behind the abstraction, there's no particular need to understand
> how it works.

As long as you never make a mistake, yes. If you pass the wrong type, the 
wrong number, or do something with a bad pointer that makes you clobber the 
stack, it's helpful to know how it works. ;-)

> "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.

> "They take care of internal housekeeping."
> ...actually...

Program Status Word.

> 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.

> 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.

-
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

On 4/17/2012 7:17, Invisible wrote:
> would inlining it "bring its own performance costs"? I don't get that.

If you have several copies inlined different places, it may not be in CPU 
cache (or might even be paged out). I.e., by inlining, if you make it 
bigger, that's possibly a performance hit. Or not. Depends.

> OK, /that/ sounds rather more significant.

Not really.

> 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. The reason it's inline if it's in a class definition is the 
class definition gets compiled every time you #include it. Hence you're 
going to have lots of copies of the same function compiled, which therefore 
won't link, *unless* they're inline, because inline functions get merged by 
the compiler, see.

*That* is why it's "significant".

> Even so, there might be 15^2 function calls, but only at most 15 of them
> will be /active/ simultaneously - which means only 15 stack frames at once. No?

Also, again, depends on your computer. I think we have 6 stack levels on the 
credit card terminal available.

> Well, yes. As I understand it, by default C++ doesn't reserve a whole lot of
> stack space,

That's really nothing to do with C++ per se.

> I'm a curious soul. I think to have some idea how things work, even if I
> don't know all of the details... ;-)

It still depends on the compiler, the declaration, etc. "printf" isn't going 
to pass any arguments in registers, most likely. abs() probably will. You 
can declare (with pragmas, for example) different calling conventions for 
different routines. (There is, for example, the Pascal calling convention, 
which means the caller removes the arguments from the stack, because each 
function in Pascal takes only a fixed number of arguments, so "remove them 
from the stack" code logically can be in only one place.

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

On 4/17/2012 8:06, Warp wrote:
> Invisible<voi### [at] devnull>  wrote:
>>>     Likewise template functions are implicitly 'inline' without having to
>>> explicitly say so.
>
>> Well, by definition a template generates a new copy of the function each
>> time you use it, no?
>
>    No. A new version is created for each used *type*.

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?

I.e., if x.c uses myfunc<int>() and y.c uses myfunc<int>() you'd need to 
compile that function twice and toss one at link time, right?

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

On 4/17/2012 6:40, Warp wrote:
> and that sizeof(char) = 1 (which does not mean "1 byte", but "1 indexable
> memory unit".)

There are lots of RISC CPUs that only allow word-size transfers. But the C 
compiler generates code to do a load, mask, manipulate, merge, and write.

>> The book casually mentions something which /seems/ to be claiming that
>> variables are not initialised to anything in particular unless you
>> specifically request this. That's interesting; I didn't know that.
>
>    C hackers don't want the extra clock cycle to initialize a variable
> which will be immediately assigned a new value anyways.

Because, of course, the compiler can't reliably figure out if you're using 
it before you assign to it. ;-)

>    The former casts *anything* into a double, while the latter casts only
> compatible types. (Which means that the latter will give you a compiler
> error if you try to cast from an incompatible type by mistake.)

Because, as already explained, C++ is designed to make the compiler complain 
about questionable things you might have done accidentally. Like using a 
variable that you might not have assigned to. ;-)

>    If you define a variable (or function) in the global namespace, it will
> be visible in the entire program. (Yes, you can access it from a different
> compilation unit. You just need to declare it with "extern" in that other
> compilation unit to do that.)

I think you're mixing up scope and lifetime here. The variable is "visible" 
in the scope sense only below where you declared it. You can declare it 
anywhere and get to the same variable, sure. I'd call that "accessible" more 
than "visible" maybe?

>    (Also, from a design point of view, global variables decrease abstraction,
> which is bad.)

Meh. My rule is that a global is OK (especially in languages with actual 
namespaces) if you can define the meaning for the entire lifetime of the 
variable. The problem with most globals is that they usually only have 
meaningful values for a portion of the program's execution. But stdin being 
global? Yeah, no problem with that.

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

On 4/17/2012 7:04, Invisible wrote:
>> The integral part of the value is assigned to the int.
> So... it always rounds towards zero?

As long as they're both positive.

> Aren't expressions guaranteed to execute left-to-right?

No. That's what the comma operator is for that you dislike so much. ;-)

> always struggle to remember whether zero means true or false. The solution,

You're aware that boolean math matches up with + and * right? So remember it 
that way.

>  From what I'm seeing, just having multiple compilation units is a
> nightmare.

Multiple compilation units is only a nightmare when each can't refer to any 
other compilation units. The problem isn't that there's multiple compilation 
units, which pretty much every modern language above assembler supports. The 
problem is that xyz.c can't refer to abc.c, so it needs to recompile abc.h 
in order to know what's in abc.c, which of course can get out of sync 
because they're separate compilation units.

If you could #include <abc.o> you'd get rid of all the silliness of 
declaring inline functions multiple times, function prototypes, and all that 
kind of BS.

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

On 4/17/2012 3:16, Invisible wrote:
> It gives you warnings if code is unreachable.

It gives you warnings if it thinks the code is unreachable. It gives you an 
error and won't let it compile if it can prove you have unreachable code.

{ int x = 0; return; x = 1; } // Gives an error.
{ int x = 0; if (true) return; x = 2; } // gives a warning.

> 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.

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

>> is a perfectly valid statement in C++. On the other hand, it also means that
>
>>     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.

It's a simple loop that compare the array x[] and y[] untill it find a 
value that is different.
You get the value of x[i] and see if it's the same as the value of y[i] 
then you decrement i by one.
On exit, i will point to the value preceding the first different value.

You must initiate i to the last valid index of your array.
If all elements of both arrays are the same, you can realy screw things, 
so you beter make sure that the elements zero are different.

Post a reply to this message

On 4/17/2012 9:07, Warp wrote:
> Invisible<voi### [at] devnull>  wrote:
>> For a start, F# is functional in the same way that C++ is
>> object-oriented. I.e., not very. F# is a normal OO language with a few
>> slightly functional ideas bolted on the side as an afterthought.
>
>    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.

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message