Warp wrote:
>     IntegerOrFloat* ptr = whatever;

That's a pointer to a struct. :-)

I know you're joking, but that's the sort of quibble people make when 
distinguishing references from pointers from addresses.

>   The point was not whether it has public and private sections, but
> whether you can implement something the class uses somewhere else than
> in the class declaration, completely invisible to the rest of the program.

Um, yes. I'm not sure what you mean, tho.

How can it be "completely invisible to the rest of the program" and 
still be useful?

You can implement private methods that only the class can call and which 
are invisible to any code not in the class defining the method, if 
that's what you mean.  You can even put it in a separate file all by itself.

>   That was not my point. My point was that it's nice that I can put some
> implementations in a separate file, which reduces the clutter of the
> class declaration.

C# has "partial classes". That's what it's for.  In practice, code 
generators put generated code in one file and leave the other for you to 
futz with.

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Basically, there are any number of people who say "fast is better than 
>> correct" because they've never built programs where incorrectness costs 
>> money or lives.
> 
>   Oh, garbage collection is the Holy Grail of programming which, magically,
> makes programs "correct". Yeah. ;)

No, but it solves all kinds of nasty problems, just like the speed 
penalty of array bounds checking does.

>> You can't accidentally declare the function taking a float in the 
>> headers and an integer in the body and have mysterious type crashes at 
>> runtime in spite of your static typing.
> 
>   C# doesn't check at compile time that all your types match?

It does. I was speaking of C or C++.  If you only have one declaration 
matching a given type to a given variable, then they can't get out of sync.

Ada gives you separate headers from bodies, but you have to actually 
compile the headers, and you have to compile every header before its 
body, and you can't refer to a header that was compiled after yours 
were, so basically the language is required to enforce that the two 
don't get out of sync.

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

Darren New wrote:
> You can't accidentally declare the function taking a float in the 
> headers and an integer in the body and have mysterious type crashes at 
> runtime in spite of your static typing.

C++ won't let you do that, either.

It won't give a compiler error as overriding the function is allowed; 
but it WILL give you a linker error, as the correct implementation is 
not found anywhere.

-- 
...Ben Chambers
www.pacificwebguy.com

Post a reply to this message

Chambers wrote:
> Darren New wrote:
>> You can't accidentally declare the function taking a float in the 
>> headers and an integer in the body and have mysterious type crashes at 
>> runtime in spite of your static typing.
> 
> C++ won't let you do that, either.

Really?

So if I have a class declared as

A.h:
  class A { int X; float Y; }

A.c:

void makeAlpha(A* alpha) {
   alpha.X = 27;
   alpha.Y = 82.3;
}

B.c:
void useAlpha() {
   A alpha;
   makeAlpha(&alpha);
   printf("%d\n", alpha.X);
}

And I compile A.c, then change A.h to put the member variables in the 
opposite order, then compile B.c, and link the results together, you're 
telling me the C++ standard tells me that shouldn't link?

I'm impressed.

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

Darren New wrote:
> And I compile A.c, then change A.h to put the member variables in the 
> opposite order, then compile B.c, and link the results together, you're 
> telling me the C++ standard tells me that shouldn't link?
> 
> I'm impressed.

Actually, I think I misunderstood what you said before.  Anyway, with 
the example you cite, any modern IDE would notice that A.h had changed 
and recompile A.c.  I have no idea what would happen if you forced it to 
link against the old version, but probably the crashes you mentioned.

However, I really have to question the validity of your grief... after 
all, explicitly linking against an out of date binary is bound to cause 
trouble for you no matter what.

-- 
...Ben Chambers
www.pacificwebguy.com

Post a reply to this message

Chambers wrote:
> However, I really have to question the validity of your grief... after 
> all, explicitly linking against an out of date binary is bound to cause 
> trouble for you no matter what.

Well, yes. That's why Ada, for example, mandates that the compiler check 
for that sort of thing.

The original question was "what's the benefit of not having separate 
headers". That's one of the benefits - you don't even have to check if 
the binary is out of date. Unless you have object code for headers, 
there's no good way of checking whether the header has been changed 
since the body has been changed, or whether the version of the header 
you're using matches the version of the body.

Does C++ still choke if one source file has "extern int X;" and the 
other has "float X;" as globals? Certainly C has no concept of "this is 
a header" at compile time. Some compilers might try to make up for that 
fact, but it's not part of the language.

If your compiler takes type declarations out of the object files instead 
of the source code for types that you aren't actively compiling, I can't 
see any good reason to manually maintain two versions of the declarations.

Eiffel's IDE even has functions to make "short" and "flat" and 
"short/flat" declarations from the code.  ("Short" being just the 
signatures, and "flat" being code as if no inheritance was involved.)

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> >     IntegerOrFloat* ptr = whatever;

> That's a pointer to a struct. :-)

  A union is not a struct. The 'ptr' truely points directly to either an
integer or a float, at the exact same memory location. There's no need
to calculate memory offsets.

> You can implement private methods that only the class can call and which 
> are invisible to any code not in the class defining the method, if 
> that's what you mean.  You can even put it in a separate file all by itself.

  If that's so, what's this talk about C# forcing you to implement everything
inline? I thought that meant you *can't* implement any part of a class in
a separate file.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Warp wrote:
>>>     IntegerOrFloat* ptr = whatever;
> 
>> That's a pointer to a struct. :-)
> 
>   A union is not a struct. 

My bad. I understood, I just mispoke.

> The 'ptr' truely points directly to either an
> integer or a float, 

No, it points to the union. The integer and the float are both at the 
same *address*, but the pointer points to a *union*. :-)

Consider the difference between "pointer arithmetic" and "address 
arithmetic". If ptr points to an integer, then ptr++ should change its 
address by sizeof(int), right?

Again, it's nitpicking, but it's the kind of language-lawyering that 
language designers babble about.

> at the exact same memory location. There's no need
> to calculate memory offsets.

Right. That's *address* arithmetic, tho. You can have different types of 
pointers all pointing to the same address, *because* the difference 
between "pointer" and "address" is whether it has a type. (At least in 
most language design discussions.)

>> You can implement private methods that only the class can call and which 
>> are invisible to any code not in the class defining the method, if 
>> that's what you mean.  You can even put it in a separate file all by itself.
> 
>   If that's so, what's this talk about C# forcing you to implement everything
> inline? I thought that meant you *can't* implement any part of a class in
> a separate file.

Err, no. It's called a "partial class". I believe perhaps the first 
version of C# didn't have that?

// File A1.cs
partial class A {
   void alpha(...) { ... }
}

// File A2.cs
partial class A {
   void beta(...) { ... }
}

As I said, mostly used for code generators to stay out of your way.



-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

Btw, it seems that I am not the only one who realizes the problem of
delayed object destruction. In fact, a name has been coined for when
an object is destroyed immediately when it goes out of scope in a GC
environment: Deterministic finalization.

  One example of someone else discussing this same subject, from the point
of view of .NET:
 
http://www.deez.info/sengelha/2005/02/11/deterministic-finalization-in-garbage-collected-languages/

  Probably more examples can be found by googling "deterministic finalization".

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   Btw, it seems that I am not the only one who realizes the problem of
> delayed object destruction. 

Heh. I think most everyone realizes it.  :-)  People just aren't sure of 
any good(*) way of solving it.

Indeed, I've seen research in Java where they look at the generated 
code, determine that a pointer to an object *must* be the last pointer 
(e.g., it hasn't been assigned to an instance variable, it hasn't been 
passed to something separately compiled that might have stored it, etc) 
and GC that object as soon as it goes out of scope. Apparently this 
provides even *better* performance than GC alone.  Basically moving (via 
optimization rather than via asking the programmer) the object to the 
stack instead of the heap.

(*) Where "good" encompasses "runs on popular OSes" and "works with 
"normal" languages.

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message