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

On 4/17/2012 12:26, nemesis wrote:
> IDEs are only really useful for OO languages.

I'm pretty sure LISP machines had exceedlingly kick-ass IDEs long before 
there was CLOS.

Plus, the IDE for Smalltalk doesn't really deal too much with the fact that 
it's OO. It didn't do any of the sorts of completion you're talking about.

-- 
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/19/2012 10:14, nemesis wrote:
> yes. It's easy to rewrite Make from scratch for your every projects.

Maybe your projects. Mine compiles 1934 packages, and it's a pretty trivial 
program by google standards. :-)

> BTW, do your scripts handle automatic compilation of only the parts that
> were last updated?

Even better. Mine doesn't even compile code that *you* compiled previously. 
It also doesn't run unit tests for code that didn't change since last time 
it was tested. It also tells the builders of the libraries I use if they 
change code that breaks my code that depends on them.

It's pretty cool, but still a fair PITA sometimes.

>> (I wonder why nobody has yet thought of making an editor where you can add
>> buttons to the toolbar and kind arbitrary commands to them? You could even
>> give them keyboard shortcuts...)
>
> emacs can do that. And any decent text editor allows you to bind some
> keyboard shortcut to some command.

Yah. We call it an IDE. ;-)

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