Chambers wrote:
> This is similar to Java, although it is 
> not platform independent (there is a platform independent open source 
> version, called Mono, which is able to execute many .Net applications).

Actually, the CIL is indeed platform independent. What isn't is a large 
number of windowing libraries and a few others that are per-OS, primarily 
because you *can* get to some low-level stuff. There's virtually nothing in 
the definition of the libraries or language that would be difficult (as 
opposed to tedious) to implement on other OSes.  Of course, if you do things 
like inspect the Windows message pump, or you query the X server's WM 
properties, you're going to have unportable code. A Windows service is going 
to have different wrappers than a Linux service, because the two have 
fundamentally different operational mechanisms. *That* is where the 
non-portability bits come from.  Well, that and that it hasn't been ported 
too much yet.

> There are other technologies and features, of course, mostly aimed at 
> interoperability of various system components (for instance, LINQ, which 
> allows SQL-type queries from languages such as C# and VB).

There's also a tremendous focus on being able to use different parts of the 
systems from different vendors. The whole bit of managing "components" is 
that. So if you don't want to write it and it doesn't come with, chances are 
good you can buy it already built for you.

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

Invisible wrote:
> Well, certainly you give it a bunch of files and it knows how to compile 
> them. But do you want it to link them all into a single executable? Or 
> maybe two seperate executables?

Yes. That's what the separate "projects" in one "solution" are, in VS.

> Or perhaps you're trying to produce a 
> DLL? Presumably you have to configure this somewhere...

Sure. You set flags on the project properties pages.

> Interesting. I thought it was only object files that contain linker 
> tables...

Depends on the OS and CPU. For example, on CP/M, you're right. The binary 
.COM file is just bytes of machine code that load at 0x100, and the OS jumps 
to 0x100 when it starts. That's responsible for setting up the stack (based 
on an address left in global memory) and parsing the command line (at 0x80).

On even simple UNIXes, you have things in the headers to set up how big the 
stack is, how big the "zero out this memory space" area is, and which 
addresses have to have the start address where you loaded the executable 
added. Any OS taking advantage of memory protection is going to have 
metadata in the executable format.

> Mind you, having just said that... various programs have custom icons 
> and so forth. That's definitely not executable code. Hmm...

Yep, that too.

> [Now the old MS-DOS *.com files really *are* just bare machine code, 
> always loaded at a specific machine address...]

Yes, left over from CP/M.

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

Invisible wrote:
> I know a header file can theoretically contain anything. But I always 
> thought that the idea was to put only public things in a header file, 
> because if it's not in the header file, other files can't know it exists 
> so it can't be accessed.

No, it's so that there's only one place to change it when you change it. The 
same reason you'd use an "include" in any other language or document or 
whatever.

If it's not declared, you can't easily use it from outside where it's 
defined. One declares it in a header file so one doesn't have to type it out 
all the time or risk getting the declaration wrong.

However, sometimes when I'm debugging stuff that's just breaking deep in the 
bowels of someone else's program, I'll do something like
   { extern int write(int,char*,int); write(1,"#1\n",3); }
just to put in a debugging line to tell me whether it crashed before
or after that point, which prevents me from having to #include the
right pile of header files to declare write() properly.

> Java and Pascal I already have quite extensive experience with. 
> (Although I imagine since the last time I touched Java the APIs have 
> been changed *again*. Oh, and I hear they kludged in generics?) Both of 
> these languages know the difference between a pointer and an array, 
> however.

True. C doesn't have arrays, really. At least, none with actual names.

So you have a lot of experience with Java, and you find *C's* syntax unwieldy?

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> True. C doesn't have arrays, really. At least, none with actual names.

  Actually C *does* have arrays. For example, this is an array:

int table[10];

  Here 'table' is *not* a pointer to a memory location containing space
for 10 ints. 'table' is an array of 10 ints. While it behaves a lot like
a pointer (and is implicitly cast to an int* when necessary), there are
significant differences compared to a pointer. For instance, sizeof(table)
is not the same as sizeof(int*). Also, you can't make 'table' "point" to
somewhere else (because it's not a pointer).

  These are stack-allocated arrays. It is also possible to create
heap-allocated arrays, although not directly. You have to enclose it
inside a struct, like this:

struct ArrayContainer
{
    int table[10];
};

  Here 'table' is also *not* a pointer, it's an array. Now you can allocate
instances of that struct with malloc() and you will effectively have a
heap-allocated array.

  (Granted, C arrays are a bit rigid and non-dynamic, but they are still
arrays by any definition.)

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> For instance, sizeof(table) is not the same as sizeof(int*). 

Yes, OK.

> Also, you can't make 'table' "point" to
> somewhere else (because it's not a pointer).

I thought "table" was essentially a constant pointer to the first element. I 
forgot about the sizeof() bit.  I.e., that "int table[10]" made table be a 
constant pointer to the first element of an anonymous block ten integers in 
size.

>   Here 'table' is also *not* a pointer, it's an array. Now you can allocate
> instances of that struct with malloc() and you will effectively have a
> heap-allocated array.

int* table = malloc(10*sizeof(int));
creates an anonymous array, then sets "table" as a pointer to the start of 
it. So you can have heap-allocated arrays, you just can't give them names. :-)

Now we're picking nits, tho.  You're right, C does have arrays.

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> int* table = malloc(10*sizeof(int));
> creates an anonymous array, then sets "table" as a pointer to the start of 
> it. So you can have heap-allocated arrays, you just can't give them names. :-)

  The other difference is that there's no way of retrieving the size of that
"array".

-- 
                                                          - Warp

Post a reply to this message

On 22-7-2009 10:39, Invisible wrote:
> clipka wrote:
> 
>> Once you've embraced the OO paradigms, you'll no longer wonder whether 
>> it's a
>> step back or sideways - you'll know that it's a step forward.
> 
> This is where I mutter something about functional programming being the 
> future, and everybody agrees with me...

Nah, it was a long tome ago when these were the future (roughly between 
'54 and '58).

Post a reply to this message

On 22-7-2009 1:26, David H. Burns wrote:
> andrel wrote:
> 
>> That you see your smiley does not mean everybody else will.
> 
> Thanks. Did you see it? I did when I read my own post. I don't think it 
> shows up in the text in
> my "sent" file. These matters get complicated.
> :) (smiley ?)
> 

I do. In your post, not when replying :) , neither yours nor mine.
The point I tried to make earlier is that it depends on the mail reader 
of the person *reading*. You don't have an influence on it. You type a 
colon followed by a bracket, that is what you sent and what is supported 
by NNTP. After that somebody is trying to cleverly replace them by 
rotated smileys, which is OK as long as they get it right :/
IIRC they have problems with exotic ones like \o/ perhaps because they 
can conceivably be in a real post or in /ASCII art/.

In short, there is a big chance that what you will see is not what I 
wrote. Perhaps it is what I intended.

Post a reply to this message

On 22-7-2009 11:13, David H. Burns wrote:
> Eero Ahonen wrote:
>> David H. Burns wrote:
>>> (Laugh) I love it! What can be off-topic to off-topic?  What you mean, I
>>> think, is that
>>> this topic is forbidden! Or maybe simply unwanted.
>>>
>>
>> On-topic. Your conversation is clearly about Pov-RAY, so it would
>> naturally fit onto the on-topic groups better than to shit-chatting
>> off-topic group :-).
>>
>> -Aero
> I was told I was off topic in the programming group -- or maybe it's 
> just what
> I say, or how I say it, not the subject that's off-topic. But my critics 
> are right;
> I don't know enough detail to really discuss OOP. 

That did not stop other people here to start a lot of threads. ;) So, 
welcome. Take a seat, relax and try to find a role in this bunch of 
looneys. AFAIK we don't have an on-topic poster here yet, so if that is 
what you like...

> I just voice my objections which apparently aren't shared.

They are to a certain extendthey are. The main problem though, apart 
from this being the wrong group is that you restarted a useless 
discussion for the 42nd time.

>:)

Post a reply to this message

"David H. Burns" <dhb### [at] cherokeetelnet> wrote:
> > Yes, I personally do advocate going for strong OOP-support with POV-Ray 4 SDL. I
> > do so as a POV-Ray user, and I do so as a contributing developer.
> >
> > Yes, I did present a serious proposal for a new, OOP-enabled SDL in the povray 4
> > newsgroup some months ago.
> >
> > Yes, being active in the development of POV-Ray 3.7 I *may* happen to personally
> > get my hands dirty on the code of POV-Ray 4's SDL engine.
>
> So it is so after all
> :(

So it is *what* after all? Me single-handedly going to take over the world or
what??

Mwahahaha - Yeeees - I've always wanted to do that...

Ah, BTW & FYI: Me being a contributing developer to POV-Ray doesn't mean that
I'm member of the official dev team. I do contribute code now and then, but as
for making decisions about which direction to go, the buck does *not* stop
here.

Post a reply to this message