Le 21/04/2012 05:43, Darren New a écrit :
> 
> I don't think mis-matched declarations were ever something that C
> worried about. Does C++ actually check that sort of thing now?

The mangling pattern/scheme of C++ for function's name uses a lot of the
signature: the namespace, the name itself and the description of the
arguments' types. A bit more than C with its double underscores.

As we are talking of template, I would think the code would be
duplicated anyway in the many files: templates are most probably inline
(if you use 1 of 13 templates, your code only get the one you used).

-- 
Software is like dirt - it costs time and money to change it and move it
around.

Just because you can't see it, it doesn't weigh anything,
and you can't drill a hole in it and stick a rivet into it doesn't mean
it's free.

Post a reply to this message

>> Damn. And to think that I have to lift 14 stone of my dance partner...
>>
>> That said, my shoulder *does* hurt now! >_<
>
> Not for 40 hrs straight...;)

Christ, 40 *seconds* straight is enough to wipe me out. o_O

I'm such a weed...

Post a reply to this message

On 20/04/2012 02:03 PM, Invisible wrote:
> On 20/04/2012 01:36 PM, Warp wrote:
>> Orchid Win7 v1<voi### [at] devnull> wrote:
>>> On the other hand, it appears to be aimed at people who already know the
>>> C++ language. That isn't really me, yet. I know some of the syntax, but
>>> certainly not all of it, or what all of it actually does.
>>
>> I think you'll learn on the fly (at least if you have the right
>> attitude).
>
> Given that I already some some clue about C++, that might actually work...

You know what? I'm just going to /buy/ the book. In the unlikely event 
that it actually helps me to get a better job, it will have easily paid 
for itself multiple times over.

Post a reply to this message

On 4/23/2012 1:08, Invisible wrote:
> a valid operator that you can put anywhere you want...

It has to be between two other arguments, and you can't write a naked comma 
operator in the middle of a function's arguments, because commas separate 
function arguments. So you'd still get a compiler error.

-- 
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/24/2012 0:07, Le_Forgeron wrote:
> The mangling pattern/scheme of C++ for function's name

Ah yes.  I had forgotten about 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/23/2012 1:31, Invisible wrote:
> Damn... I'm trying to think of something you can code without actually using
> recursion. Hmm. Well, I guess there must be /something/...

Almost all business logic. I don't remember seeing any recursion in any 
operating system kernels I've read. I can't think of any recursive SQL code 
I've written at all.

> So if you want to count how many nodes there are in a binary tree, how do
> you do that non-recursively?

You use a queue. Each node you visit, you tack on to the end of the queue to 
be counted, and you go until the queue is empty.

Alternately, manually maintain the stack. Which is not "recursion" in the C 
sense, because you can actually tell without just blasting memory in unknown 
ways when you run out of room for the stack.

> If a programming language supports calling /any/ foreign language, that
> language will always be C. It will know about standard C types, it will
> usually know about C structs, and it will let you call arbitrary C functions.

OK. Yes, as long as you link to the proper C calling convention.

> And yet, the way that you call a C function is, apparently, undefined.

It's implementation-defined. You have to read the compiler manual (or source 
code) to know what the sequence is. And different functions in the same code 
can have different calling conventions.

Unless you have a CPU that actually enforces calling conventions.

> It also makes me wonder how the heck it's possible to take object code from
> multiple C compilers and link it all together, if each of them is
> potentially using a completely different calling convention. It sounds like
> it shouldn't work.

And indeed it doesn't. Try compiling one library with gcc and another with 
visual C and see if they link cleanly. Take a library off the mac and link 
it to a Windows-compiled main().

For that matter, try compiling one program for x86 and the other for x64.

-- 
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/23/2012 0:59, Invisible wrote:
>>> I think it's probably vacuous to try to estimate how "useful" it would be
>>> without actually trying it...
>>
>> Well, they tried making STM work on .NET and gave up because of all the
>> state, if you remember.
>
> They gave up because they tried to make all the existing state mutation
> stuff still work in the presence of transactions, which is /obviously/
> impossible.

That's my point.  How useful would it be if you couldn't actually use any of 
the other .NET libraries, including even I/O, reflection, etc.?

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

>>> Well, they tried making STM work on .NET and gave up because of all the
>>> state, if you remember.
>>
>> They gave up because they tried to make all the existing state mutation
>> stuff still work in the presence of transactions, which is /obviously/
>> impossible.
>
> That's my point. How useful would it be if you couldn't actually use any
> of the other .NET libraries, including even I/O, reflection, etc.?

You do all of that stuff from /outside/ your transactions, that's all. 
Remember, transactions are only for thread communication. You start a 
transaction, fetch the next work item from the shared work queue, and 
the transaction. Then you process the work item, calling whatever 
libraries you need. Simples.

Post a reply to this message

On 25/04/2012 06:22 AM, Darren New wrote:
> On 4/23/2012 1:31, Invisible wrote:
>> Damn... I'm trying to think of something you can code without actually
>> using recursion. Hmm. Well, I guess there must be /something/...
>
> Almost all business logic.

I suppose I should consider myself lucky that I'm never going to be 
writing anything like that.

> I don't remember seeing any recursion in any
> operating system kernels I've read.

Really? That's surprising. No recursive sorting algorithms for balancing 
the B*-trees that the directory nodes use, or for sorting the ready 
thread list by priority?

> I can't think of any recursive SQL code I've written at all.

SQL is a rather special-purpose language. I'm not sure it even 
/supports/ recursion...

>> So if you want to count how many nodes there are in a binary tree, how do
>> you do that non-recursively?
>
> You use a queue. Each node you visit, you tack on to the end of the
> queue to be counted, and you go until the queue is empty.

In other words, you manually implement the stack.

Tell me, in what way does this prevent you running out of stack?

>> And yet, the way that you call a C function is, apparently, undefined.
>
> It's implementation-defined. You have to read the compiler manual (or
> source code) to know what the sequence is. And different functions in
> the same code can have different calling conventions.
>
> Unless you have a CPU that actually enforces calling conventions.

So... how is it ever possible to statically link software?

>> It sounds like it shouldn't work.
>
> And indeed it doesn't. Try compiling one library with gcc and another
> with visual C and see if they link cleanly.

It's news to me that this /doesn't/ work.

I mean, if every compiler uses its own random calling convention, then 
how /the hell/ is it possible to write some C, link it against GMP, 
wxWidgets and the OS header files, and get a usable binary? You know, 
given that you have no idea which compiler these libraries are compiled 
with...

> Take a library off the mac and link it to a Windows-compiled main().

Yeah, well, one is going to be an ELF object, and the other will be a PE 
module. You won't even be able to find a linker program that understands 
both file formats. :-P That has nothing to do with whether the machine 
code within those files would work if you linked it together.

> For that matter, try compiling one program for x86 and the other for x64.

There's absolutely no reason to expect binaries for different 
architectures to work together.

I would, however, expect that on any given architecture, the C calling 
convention is always the same.

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> You know what? I'm just going to /buy/ the book.

  I'd recommend getting both of them. (Of course you could buy the
"Effective C++" first, and if you like it, buy "More Effective C++"
later.)

-- 
                                                          - Warp

Post a reply to this message