So, I'm learning C# right now, and I've got a couple of notes I thought 
I'd share...

1) The designers have decided that Garbage Collection is a Good 
Thing(tm), and that pointers are Dangerous.  So, while it's actually 
possible to use pointers, they spend a lot of time telling you not to.

I have to wonder, is the whole debate about GC merely due to the fact 
that current implementations aren't satisfactory?  If there were better 
implementations that were more predictable about object destruction and 
memory cleanup, and especially about when they clean up the fragmented 
memory space, would developers be more willing to live with it?

In fact, 10 years from now, is the debate over GC going to seem like the 
debate between C and C++: sure, C can be faster, but for most developers 
the benefits of C++ outweigh the negligible speed penalty.

Or is GC a flawed concept to begin with, and doomed to mediocre performance?

2) WHY is it considered a Good Thing that class methods must be written 
inline?  The language doesn't allow class prototypes, and claims this is 
a benefit because "header files aren't necessary."  I actually *like* 
header files, a well written one gives you a great overview of the class 
in question, and many times I refer to them rather than the 
documentation for class libraries.

Note: it may be that Interfaces solve this for me, I haven't gotten that 
far in the language yet.  In a few more days, I will have.

3) It's hard to believe how much some people are MS fanboys.  I picked 
up a number of C# books at the library (point of fact: I now have, in my 
possession, more books on C# from the local library, than my library had 
on *all* programming languages combined 15 years ago.  I know, because I 
read all of *those*, too).  Two of them have caught my eye, for being 
complete opposites:

The first has numerous errors in the code, and I mean extremely obvious 
things like:
   System.Console.WriteLine("Now assigning 10 to obj.value: ");
   obj.value = 20;
   System.Console.Writeline("Value of obj.value: {0}", obj.value);

Given that the above snippet is repeatedly (the program mentioned is 
repeated some four or five times), it's staggering to think that this 
error was never caught.  And it's only one example of the extremely 
sloppy editing.

Then, the author has the audacity to claim that MS's biggest mistakes 
with J++ were 1) Signing a contract with Sun, saying that they would 
accept Sun's standards on the Java language, and 2) Allowing the 
contract to be understandable.  These two items combined meant that when 
MS tried to "Embrace, Extend, Terminate" (or whatever that phrase is), 
Sun rightfully sued them and won.  Personally, I think their biggest 
mistake was to try to subvert another company's IP like that.

Now, this other book I'm reading has been edited well (I haven't found 
any errors in the code yet, or even in the grammar), and the author, 
despite writing a book on C# and obviously loving the language, still 
pokes fun at MS.  My favorite quote:
Q: How many OO programmers does it take to change a lightbulb?
A: None, MS changed the standard to darkness.

4) Lastly, sometimes it's the little things that count.  Personally, I 
love the fact that I don't have to right 'get' and 'set' functions for 
member variables, even when accessing the data is not straightforward.

Basically, C# allows you to give any member variable implicit get / set 
functions that are called when you access the variable normally.  In 
other words, you can access a member variable like this:

objA.val = objB.val;

And what will execute is:

objA.val_set( objB.val_get() );

Even though the variable 'val' can be a plain old int, or any other 
type.  I think this is really, really cool :)

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

Post a reply to this message

I'm certainly not an expert on a plethora of languages but I do have 
some views on the points you raise.

1)  On Garbage Collection, I regard this as a huge factor in favour of 
C# and .Net.  The way that the language, type system, IL and GC are 
interwoven is superb.  It very substantially reduces the opportunity to 
create difficult to eradicate memory allocation / deallocation bugs.

Surely a C++ guru will know how to avoid or at least find and fix such 
problems but in .Net the problem to a large degree simply isn't there. 
End result in my experience is that it is actually practical for a 
non-guru to produce large sophisticated and functional programs.

And in regard to speed loss from GC, I really have not observed a 
problem.  You might think it is a huge overhead but it has not yet shown 
to be an issue at all for me.  I imagine that in certain types of 
applications it could be an issue in which case there are coding styles 
and techniques to minimise any impact and still remain within 'managed' 
code.

So it doesn't seem to be an issue at all.  People coming from other 
language backgrounds seem to have an impression that it is massively 
slower or a huge impost.  It seems like the opposite to me.

2)  Similarly this seems like a C vs C# pedigree thing.  Interfaces is 
certainly one answer.  The other i guess is that with the XML comments, 
Intellisense, Object Viewer, Class diagrams and other IDE goodies it is 
pretty easy to see the class jierarchy, properties, methods etc.

Story - My brother-in-law is a 20+ year veteran of C, C++ in embedded 
systems and under Windows using OWL and MFC.  My background is more PC 
and Mainframe assembler, a bit of C, lots of SQL and passing 
acquaintance with C++ (which I detest) and Java.

As I got into C# and .Net I found it to be very well thought out, rich 
and powerful.

Whenever we would discuss programming stuff he would raise two big 
things - GC and lack of header files (and therefore class prototypes). 
Here is a typical conversation that was unresolved for both of us:

Him:  How do you do X in .Net ?
Me:   Ah, that is still just like X
Him:  How do you do Y in .Net ?
Me:   You don't really have to or want to do that
Him:  I like to do that
Me:   But why when you don't need to
Him:  Well its good to because ...
Me:   But that isn't a problem in .Net because ...
Him:  Well I like to do it and it is a good idea
Me:   I can see that in C++ but they've really done away with that 
problem in C# / .Net
Him:  Well that can't be because I've seen problems when you don't do that
Me:   Yeah in C++ but you don't need to in C# and if you really want to 
you could probably do it using ...
Him:  Well I like to do it
Me:   Ok.

Guess what ?  Recently he's started really using VB.Net and now C#.Net 
and he pretty much raves over the improvements.  Suddenly there is no 
more discussion about the resistance points but we have fun talking 
about all of the neat new things and how well it all fits together.

Then there is the framework which to me seems more comprehensive and 
consistent than anything for Java.

And I think that LINQ, anonymous types, extension methods etc in .Net 
3.0 / 3.5 are really extending the framework in powerful ways while 
maintaining and extending the core.

Call me a C# / .Net fanboy but don't call me one for Microsoft.  I 
reckon they should put the C# guys starting with Anders Hejlsberg in 
charge of the next OS they do.

Post a reply to this message

Paul Fuller wrote:

> Call me a C# / .Net fanboy but don't call me one for Microsoft.  I 
> reckon they should put the C# guys starting with Anders Hejlsberg in 
> charge of the next OS they do.

"The next OS they do"?

Heh. You're a funny guy...



I must admit, I did take a brief look at various .Net languages. But 
that's the biggest drawback of Haskell: It makes you hate normal languages!

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v7 wrote:
> Paul Fuller wrote:
> 
>> Call me a C# / .Net fanboy but don't call me one for Microsoft.  I 
>> reckon they should put the C# guys starting with Anders Hejlsberg in 
>> charge of the next OS they do.
> 
> "The next OS they do"?
> 
> Heh. You're a funny guy...

Well there will be a next Microsoft OS.  I just wish it would be lean 
and clean which is the opposite of Vista.

> 
> 
> 
> I must admit, I did take a brief look at various .Net languages. But 
> that's the biggest drawback of Haskell: It makes you hate normal languages!
> 

I haven't looked at Haskell much.  The obscure little fragments that you 
post and expound upon are enough to warn me away :)

Lambda expressions which are new to C# look similarly obtuse.  Maybe 
I'll see the light one day.

Post a reply to this message

Paul Fuller <pgf### [at] optusnetcomau> wrote:
> 1)  On Garbage Collection, I regard this as a huge factor in favour of 
> C# and .Net.

  Garbage collection is not the Holy Grail of programming (nothing is).
And you have to know about its weaknesses. Certainly these weaknesses
may not be relevant in many cases, but in some cases they may be.

  Garbage collection basically means that all your objects are destroyed
with a delay (or, at least in Java, may not be destroyed at all; I don't
know how it works in C#). In many cases this doesn't matter. However, in
the cases where it does matter it can be a real problem.
  Sometimes it may be imperative that the destructor of the object be
called *immediately* when that object goes out of scope. Delaying that
destructor call may even cause a malfunction in the program (sometimes
even in situations which happen rarely and may not be caught in testing).
One good example of this is a destructor which closes an open file handle
the object has: The number of open file handles is often limited, and if
they are not closed after use, the program may run out of them.
  Manually closing the file handle when it's not needed anymore is not
any better then manual memory management: There's always the danger of
a leak. Functions may be exited at unexpected places, etc.

  So, basically, garbage collection takes care of memory management,
often at the cost of reducing the possibility of the user implementing
automatic management of resources other than memory. These resources may
be system resources, or resources in the program itself. GC seems to
completely disregard them.

  In a language like Java the only way you can manage such resources is
by manually freeing resources when they are not needed anymore. This is
a step back to the C memory (and other resources) management: Laborious
and error-prone.
  C# may be slightly better in this regard, though.

  Another problem with GC, which admittedly is often not very relevant,
but in some cases may be, is that GC is very detrimental with regard
to swapping.

  Suppose that you have made a program which just sits in the background
and waits for some task requests (like those background applications in
Windows which often put a small icon in the taskbar). This application
may have reserved a fair amount of memory for itself, but for a given
task it might only need a small part of this memory.

  Since this application is idle, if the system is running out of memory
the system will swap the memory used by this application to disk. If then
this small task is requested, only the memory actually needed for the
task will be swapped out of the disk. The rest will be kept in the swap.

  However, assume that the GC engine happens to be triggered during this
task. What happens? Since the GC engine scans the entire memory used by
the application, *all* of its reserved memory will be swapped from the disk.
If there's nothing to gargabe-collect, all this swapping would then be
completely useless.
  If the system was running low on memory to begin with, this can be
quite detrimental. The system may start swapping like mad, all for
absolutely no benefit.

  So the question is: If you are making such an application, can you
tell C# to *not* to use garbage collection? Is GC optional?

  One of the biggest problems I see with GC is that in most languages
it's not optional.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Paul Fuller <pgf### [at] optusnetcomau> wrote:
>> 1)  On Garbage Collection, I regard this as a huge factor in favour of 
>> C# and .Net.
> 
>   Garbage collection is not the Holy Grail of programming (nothing is).
> And you have to know about its weaknesses. Certainly these weaknesses
> may not be relevant in many cases, but in some cases they may be.

Actually, I just got through reading a section about how to set up your 
objects to be destroyed as soon as possible, rather than waiting for the 
  normal run of the GC.  You implement a certain function ("Dispose", I 
think it was), and make a single call to the GC telling it that this 
class needs immediate destruction.

Then, any instances of that class are destroyed as soon as possible (re: 
when they go out of scope, usually), similar to how objects in C++ are 
destroyed.

I just remembered another point I was thinking, though.

The whole point of GC is to make memory management easy.  In fact, 
that's why languages like Java and C# don't like pointers.  However, 
they're really sidestepping the issue, because memory management is 
*hard*.  You don't get rid of the problem by masking it with prettiness; 
instead, you need to train better programmers.

If someone can't logically think through the memory usage of their 
program, maybe they shouldn't be programming.

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

Post a reply to this message

"Chambers" <ben### [at] pacificwebguycom> wrote in message
news:47eb3257$1@news.povray.org...
>
> 3) It's hard to believe how much some people are MS fanboys.

All too common in the IT area, unfortunatly. I hate them, no matter what
flavour they come in. Try reading one of gamespot's console forums (or on
second thoughts, don't)

Personally, I can't stand anyone who's so in favour of one
language/consol/game/... that they can't look objectivly at alternatives.

Post a reply to this message

Chambers <ben### [at] pacificwebguycom> wrote:
> 1) The designers have decided that Garbage Collection is a Good 
> Thing(tm), and that pointers are Dangerous.  So, while it's actually 
> possible to use pointers, they spend a lot of time telling you not to.

  That depends on your definition of "pointer".

  In my books Java references *are* pointers. They may have some restrictions
compared to, for example, C pointers, but they are pointers nevertheless.

  What is it that makes it a pointer? Easy: If you do an "a = b;", does
the object get copied, or do now 'a' and 'b' refer to the same object?

> I have to wonder, is the whole debate about GC merely due to the fact 
> that current implementations aren't satisfactory?  If there were better 
> implementations that were more predictable about object destruction and 
> memory cleanup, and especially about when they clean up the fragmented 
> memory space, would developers be more willing to live with it?

  GC is ok most of the time. However, there are situations where it may
have negative effects, as I commented in the other post.

> In fact, 10 years from now, is the debate over GC going to seem like the 
> debate between C and C++: sure, C can be faster, but for most developers 
> the benefits of C++ outweigh the negligible speed penalty.

  "C is faster than C++" is a persistent myth. This has never been so.

> 2) WHY is it considered a Good Thing that class methods must be written 
> inline?

  Beats me.

>  The language doesn't allow class prototypes, and claims this is 
> a benefit because "header files aren't necessary."

  This sounds like a hindrance to modularity. I assume that you can't
have types, functions and variables which are local to a compilation unit
and are completely invisible to the outside?

  In C++ I use this a lot. Not only do I try to make the public interface
of a class (or module) as minimal as possible, I also try to make the
private part as small as possible too. If something is only used by this
class, but it can be moved out of the class, I do so: I move it inside
the compilation unit where that class is implemented. Even if something
is inside this class, for example an inner class, if I can I only
pre-declare that inner class and declare/implement it in the compilation
unit. That is, for example like this:

// AClass.hh
// ---------
class AClass
{
 public:
    ...

 private:
    class InnerClass;
    ...
};

// AClass.cc
// ---------
class AClass::InnerClass
{
    // Implementation of InnerClass here.
};

  This removes clutter from the AClass definition.

> 4) Lastly, sometimes it's the little things that count.  Personally, I 
> love the fact that I don't have to right 'get' and 'set' functions for 
> member variables, even when accessing the data is not straightforward.

> Basically, C# allows you to give any member variable implicit get / set 
> functions that are called when you access the variable normally.

  Some would argue that's exposing the class' internal structure (even if the
variable is not *really* public), and thus it's against good OO principles.

  Usually one should completely avoid get and set methods for member
variables. (Granted, this is not always possible, but in a well-designed
program it can usually be mostly avoided.)

-- 
                                                          - Warp

Post a reply to this message

Chambers wrote:
> I have to wonder, is the whole debate about GC merely due to the fact 
> that current implementations aren't satisfactory?  If there were better 
> implementations that were more predictable about object destruction and 
> memory cleanup, and especially about when they clean up the fragmented 
> memory space, would developers be more willing to live with it?

No. There are very predictable GC engines used in hard-real-time 
systems. And GC tends to be as fast or faster than manual memory 
allocation in most situations as well.

> Or is GC a flawed concept to begin with, and doomed to mediocre 
> performance?

Actual measurements repeatedly show GC outperforming manual memory 
management in almost all cases.

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.

> 2) WHY is it considered a Good Thing that class methods must be written 
> inline? 

Because it prevents you from duplicating the same information (the 
function declarations) in two different places. (Not that I necessarily 
disagree with you, but that's why.)

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.

 > The language doesn't allow class prototypes, and claims this is
> a benefit because "header files aren't necessary."  I actually *like* 
> header files, a well written one gives you a great overview of the class 
> in question, and many times I refer to them rather than the 
> documentation for class libraries.

You generate that from the class body. You don't write it twice. That's 
for an IDE or document processor, not a human.

I like having a table of contents in a book, too. I don't want to 
maintain it manually as I write the book.

> Note: it may be that Interfaces solve this for me, I haven't gotten that 
> far in the language yet.  In a few more days, I will have.

Not really.

> error was never caught.  And it's only one example of the extremely 
> sloppy editing.

Yah, in the Erlang book he's got a bunch of places where the code call 
the function "add_one" and the prose calls it "addOne". Like he was used 
to one convention and found out that most people use the other 
convention or something. Which is confusing when you're passing 
parameters from three or four places (the code, the config file, the 
caller) and those parameters include the names of the functions to call 
and such.

> 4) Lastly, sometimes it's the little things that count.  Personally, I 
> love the fact that I don't have to right 'get' and 'set' functions for 
> member variables, even when accessing the data is not straightforward.

Even nicer, that you can decide later to change from a normal member 
variable to a getter/setter property, and all you have to do is 
recompile the callers without changing the source. (Do you even have to 
recompile the callers? I'd assume so, given how it's implemented.)

There's a lot of cool stuff in C#, especially in libraries they don't 
cover in tutorial-level books. I found the O'Reilly book very helpful too.

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

Paul Fuller wrote:
> And in regard to speed loss from GC, I really have not observed a 
> problem.  You might think it is a huge overhead but it has not yet shown 
> to be an issue at all for me. 

Now that I think about it, I remember reading that MS's goal was to come 
up with a GC that ran faster than a page fault.

> So it doesn't seem to be an issue at all.  People coming from other 
> language backgrounds seem to have an impression that it is massively 
> slower or a huge impost.  It seems like the opposite to me.

It *used* to be slow, 20 or 30 years ago. But that's like complaining 
that C++ is hard to debug because after you run it through cfront and 
compile the C code, you've lost all the source file line numbering.

> passing acquaintance with C++ (which I detest)

I saw a LOL line on another conversation.
    > > Having used Ada and C++ extensively,
    > > I'll take Ada over C++ any day.
    > Never having used Ada at all, I'll take Ada over C++.

> As I got into C# and .Net I found it to be very well thought out, rich 
> and powerful.

It's still statically typed and compiled, so you still have the troubles 
interfacing with Other Stuff sometimes. Like SQL - you still wind up 
changing things in several places when you change the type of 
arrangement of a SQL table.  I found that annoying for doing prototyping.

> about all of the neat new things and how well it all fits together.

It really is amazingly well thought out as a language. Plus they've 
added generics, partial classes, inline SQL, etc.

> Then there is the framework which to me seems more comprehensive and 
> consistent than anything for Java.

Yep. Again, of course, they had the hindsight of what Java had to 
explore and then maintain.  Java was kind of "the first one you throw 
out once you learn what you actually want," IMO.

> Call me a C# / .Net fanboy but don't call me one for Microsoft.  I 
> reckon they should put the C# guys starting with Anders Hejlsberg in 
> charge of the next OS they do.

I thought that was the idea behind Vista? Most of it rewritten to .NET?

-- 
   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:
>   Manually closing the file handle when it's not needed anymore is not
> any better then manual memory management: There's always the danger of
> a leak. Functions may be exited at unexpected places, etc.

Of course, all these objections are fairly irrelevant when the OS is 
actually designed to help the GC system.

For example, nobody complains "UNIX signals are bad, because if you 
don't catch them, your process might have files open when it exits." No, 
the OS closes the files for you. It doesn't delete temp files, and it 
doesn't roll back half-completed transactional changes to the file 
system (e.g., it won't let you rename files such that all three change 
or none change, even if you dump core in the middle), but people don't 
seem to complain about this aspect for some reason.

In a system that actually actively supports GC, a program trying to 
access a file handle that someone else has open (and locked) will cause 
a GC in that program to finalize those resources, freeing up the lock, 
in exactly the same way that a modern desktop OS will page out inactive 
portions of one process to free up memory for other processes.

And again, there are pretty trivial techniques to prevent this from 
being a problem. At the top of your main loop, you do a quick GC to 
scavenge anything you accidentally freed.

And of course anything that allocated stuff on the heap has this sort of 
problem anyway, unless you wind up essentially writing your own GC anyway.

>   So, basically, garbage collection takes care of memory management,
> often at the cost of reducing the possibility of the user implementing
> automatic management of resources other than memory. These resources may
> be system resources, or resources in the program itself. GC seems to
> completely disregard them.

Only naive GC.  Of course, sophisticated GC needs support throughout the 
system. Some systems have this.

Other systems don't have this sort of problem at all, in that files are 
memory resources just like "in-memory" structures, so going out of scope 
deletes the file just like you'd expect.

>   C# may be slightly better in this regard, though.

Syntactically, it's a bit easier, but it's essentially the same 
mechanism under the covers. It's just easier to invoke it.

>   Another problem with GC, which admittedly is often not very relevant,
> but in some cases may be, is that GC is very detrimental with regard
> to swapping.

I don't think I've demand-paged in ages. Certainly not any process I've 
let run to completion.

I've noticed that every program I use that actually uses too much data 
to conveniently fit in memory (e.g., photoshop, mysql, various other 
database-like engines) all manage their own memory-to-disk paging.

I bet you could get a speed boost by leaving out the demand-paging bits 
on modern chips and just go back to swapping and overlays in the rare 
cases where people care, and let them implement it themselves. You'd 
still probably want virtual addressing, so I don't know how much you'd 
actually save if you did this.

>   If the system was running low on memory to begin with, this can be
> quite detrimental. The system may start swapping like mad, all for
> absolutely no benefit.

I wouldn't say "no benefit". If the system is smart, it'll do a GC 
*before* it swaps out the task. That's the sort of thing I'm talking 
about: it'll save swapping time and swap space.

Erlang has a primitive called "hibernate", which does a GC on the 
process then swaps it out until it gets the next message. Normally you'd 
only do this if you expect to be idle for a while (say, the backup 
process waiting for the next scheduled backup to roll around).

>   So the question is: If you are making such an application, can you
> tell C# to *not* to use garbage collection? Is GC optional?

Not really.

-- 
   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:
>   In my books Java references *are* pointers. They may have some restrictions
> compared to, for example, C pointers, but they are pointers nevertheless.

The restrictions are why people call them "references" instead of 
"pointers", just like you call them "pointers" instead of "addresses" 
because they can only point to one type of object. I.e., you can have an 
integer and a float at the same address, but you can't have one pointer 
that points to either of those. (And no, "void*" doesn't count void* 
points to neither, not either.)

It's really just a precision-in-terminology thing for people who make 
such distinctions in their everyday work of designing languages. :-)

>>  The language doesn't allow class prototypes, and claims this is 
>> a benefit because "header files aren't necessary."
> 
>   This sounds like a hindrance to modularity. I assume that you can't
> have types, functions and variables which are local to a compilation unit
> and are completely invisible to the outside?

Sure you can. C# has the same public/private/protected/<mumble> that C++ 
has. With the added advantage that private variables really are private.

(There's one more access class that I forget what it is, but it means 
basically visible across compilation units but not across "assemblies", 
where an "assembly" is a unit of distribution of object code, like a 
library or component. So you can have a type that's private to your 
entire graphics library, usable from everywhere inside the graphics lib 
without being visible outside it.)

>   This removes clutter from the AClass definition.

In C#, you don't have to do anything like that. You declare AClass as 
public, AClass::Inner as private, and you're done. You don't have to 
pick different files to put them in to enforce who gets to see them.

Nor, for that matter, do you need to do anything funky with private 
member variables in a class. If you don't give someone the source code, 
they don't see the private variables.

>   Usually one should completely avoid get and set methods for member
> variables. (Granted, this is not always possible, but in a well-designed
> program it can usually be mostly avoided.)

Well, in the cases where this is used, they're "properties" of the 
object. If you're setting whether the printer will print in color or 
not, you use a "property" and C# writes the setter and getter routines 
for you. It's not exposing a member variable - that's the point of 
making it a property.

-- 
   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:
> In a system that actually actively supports GC, 

Oh, and there are actually versions of GC that reference-count objects 
that have external resources in them, and clean them up promptly if you 
don't let the reference escape the scope they're in.  (Actually, isn't 
Java doing this sort of thing now somewhere?)

Looking at Java's GC and concluding that GC sucks is like looking at 
notepad and concluding that text processors suck.

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

> Looking at Java's GC and concluding that GC sucks is like looking at 
> notepad and concluding that text processors suck.

OK, *surely* this ought to be quoted somewhere prominent? ;-)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> >   Manually closing the file handle when it's not needed anymore is not
> > any better then manual memory management: There's always the danger of
> > a leak. Functions may be exited at unexpected places, etc.

> Of course, all these objections are fairly irrelevant when the OS is 
> actually designed to help the GC system.

  The OS may help the GC system when we are talking about OS resources.
However, it can't help when we are talking about resources within the
program itself. (For the sake of example, let's assume that the program
uses its own "file handles" instead of the ones provided by the system.
It doesn't need to be something related to physical files per se.)

> For example, nobody complains "UNIX signals are bad, because if you 
> don't catch them, your process might have files open when it exits."

  The problem is not leaving file handles open when the program exits.
The problem is opening more and more file handles without closing the
old ones: In most systems at some point the OS will put a limit to this
and refuse to give any more file handles. At this point the program will
malfunction, and finding and solving the cause can be quite difficult.

  Usually this is a sign of a bug: Some code somewhere is "leaking".
Not all unused file handles are being closed.
  However, with GC, where there's delayed object destruction, it might
not be a bug per se, but a consequence of GC.

> No, the OS closes the files for you.

  It can't close them if it sees that they are in use: Some live objects
are holding the file handles (because these objects have not been
properly destroyed).

> In a system that actually actively supports GC, a program trying to 
> access a file handle that someone else has open (and locked) will cause 
> a GC in that program to finalize those resources, freeing up the lock, 
> in exactly the same way that a modern desktop OS will page out inactive 
> portions of one process to free up memory for other processes.

  It was not a question of accessing locked files. It was a question of
leaking open file handles: At some point the OS may not given any more
of them.

  Of course one thing the OS might try is to tell the GC to make a sweep
to see if that frees any file handles (does any OS actually do this?).
However, as I said, this will work only with system resources.

> And again, there are pretty trivial techniques to prevent this from 
> being a problem. At the top of your main loop, you do a quick GC to 
> scavenge anything you accidentally freed.

  This assumes that the main loop is advanced before the amount of leaked
resources grows too large. It can alleviate the problem, but it's not a
guarantee.

  (And if the main loop is executed very often, eg. thousands of times
per second, wouldn't it cause overhead to call the GC each time?)

> And of course anything that allocated stuff on the heap has this sort of 
> problem anyway, unless you wind up essentially writing your own GC anyway.

  There are alternatives to GC which call destructors immediately when
the objects go out of scope. For example, if I'm not completely mistaken,
objective C uses reference counting.

  Someone mentioned that in C# it's possible to tell for an object that
it should be destroyed immediately when it goes out of scope (but otherwise
regular GC is performed). That sounds like a good solution to me. You get
the best of both worlds.

> >   So, basically, garbage collection takes care of memory management,
> > often at the cost of reducing the possibility of the user implementing
> > automatic management of resources other than memory. These resources may
> > be system resources, or resources in the program itself. GC seems to
> > completely disregard them.

> Only naive GC.  Of course, sophisticated GC needs support throughout the 
> system. Some systems have this.

  There's no way the OS can know about the program's internal resources
even if it cooperates with the GC engine to handle system resources.

> Other systems don't have this sort of problem at all, in that files are 
> memory resources just like "in-memory" structures, so going out of scope 
> deletes the file just like you'd expect.

  Don't stick to the file handles in particular. It was just an easy to
understand example.

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Looking at Java's GC and concluding that GC sucks is like looking at 
> notepad and concluding that text processors suck.

  I can't help it. I love to hate Java.

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> I saw a LOL line on another conversation.
>     > > Having used Ada and C++ extensively,
>     > > I'll take Ada over C++ any day.
>     > Never having used Ada at all, I'll take Ada over C++.

  Ada may be a wonderful language, but its lack of recent popularity
means that the amount of available libraries is probably quite small.
No matter how wonderful a language is, having to reinvent wheels with
it is a major letdown.

  If I had to choose a language other than C++, I'll probably choose Java
because of the amount of libraries and portability, or C# because it
sounds a bit better than Java. (Or if efficiency is not an issue, maybe
I would just go with PHP.)

> It really is amazingly well thought out as a language. Plus they've 
> added generics

  I thought templates are evil? ;)

  It still makes be laugh out loud to remember how Java advocates
fiercely attacked C++ templates. Then, some years later, they added
some crippled template mechanism to Java (which still doesn't solve
all the issues).

> I thought that was the idea behind Vista? Most of it rewritten to .NET?

  Ah, now I understand why it's so large, heavy and slow.

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> The restrictions are why people call them "references" instead of 
> "pointers", just like you call them "pointers" instead of "addresses" 
> because they can only point to one type of object. I.e., you can have an 
> integer and a float at the same address, but you can't have one pointer 
> that points to either of those.

  Actually you can:

    union IntegerOrFloat
    {
        int i;
        float f;
    };

    IntegerOrFloat* ptr = whatever;

;)

> >>  The language doesn't allow class prototypes, and claims this is 
> >> a benefit because "header files aren't necessary."
> > 
> >   This sounds like a hindrance to modularity. I assume that you can't
> > have types, functions and variables which are local to a compilation unit
> > and are completely invisible to the outside?

> Sure you can. C# has the same public/private/protected/<mumble> that C++ 
> has. With the added advantage that private variables really are private.

  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.

> >   This removes clutter from the AClass definition.

> In C#, you don't have to do anything like that. You declare AClass as 
> public, AClass::Inner as private, and you're done. You don't have to 
> pick different files to put them in to enforce who gets to see them.

  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.

  In some cases I have even implemented one class in two files because
the implementation was so massive (even though the public interface of
the class was rather small). This helps keeping source code files smaller
and more manageable.

-- 
                                                          - Warp

Post a reply to this message

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

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

-- 
                                                          - Warp

Post a reply to this message

Orchid XP v7 escribió:
> Darren New wrote:
> 
>> Looking at Java's GC and concluding that GC sucks is like looking at 
>> notepad and concluding that text processors suck.
> 
> OK, *surely* this ought to be quoted somewhere prominent? ;-)

Like on Alain's signature? (He has one hell of a collection of quotes 
rotating there).

Post a reply to this message

Warp escribió:
>   In some cases I have even implemented one class in two files because
> the implementation was so massive (even though the public interface of
> the class was rather small). This helps keeping source code files smaller
> and more manageable.
> 

And back when disks were small, many libraries used to have only one 
function per compilation unit. The reason is that if you use a function 
from some object file, the linker usually adds the *whole* object file.

Post a reply to this message

Warp wrote:

>   I can't help it. I love to hate Java.

Join the freakin' club!

About the only thing Java has going for it is that it's widely 
supported. (Why does that only seem to happen for half-lame languages?)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v7 <voi### [at] devnull> wrote:
> About the only thing Java has going for it is that it's widely 
> supported.

  I like many Java applications (cgoban being a good example), but I don't
like the language itself. :)

-- 
                                                          - Warp

Post a reply to this message

Darren New wrote:
>> As I got into C# and .Net I found it to be very well thought out, rich 
>> and powerful.
> 
> It's still statically typed and compiled, so you still have the troubles 
> interfacing with Other Stuff sometimes. Like SQL - you still wind up 
> changing things in several places when you change the type of 
> arrangement of a SQL table.  I found that annoying for doing prototyping.
> 
The Program <=> SQL divide is what LINQ targets and seems to 
dramatically advance.  Suddenly the result of SQL like processes within 
the program are typed objects.  The IDE provides Intellisense on the 
objects.  They are compile time type checked.

>> about all of the neat new things and how well it all fits together.
> 
> It really is amazingly well thought out as a language. Plus they've 
> added generics, partial classes, inline SQL, etc.
> 
>> Then there is the framework which to me seems more comprehensive and 
>> consistent than anything for Java.
> 
> Yep. Again, of course, they had the hindsight of what Java had to 
> explore and then maintain.  Java was kind of "the first one you throw 
> out once you learn what you actually want," IMO.

I agree.  It is a luxury that they have certainly enjoyed and taken full 
advantage of.

> 
>> Call me a C# / .Net fanboy but don't call me one for Microsoft.  I 
>> reckon they should put the C# guys starting with Anders Hejlsberg in 
>> charge of the next OS they do.
> 
> I thought that was the idea behind Vista? Most of it rewritten to .NET?
> 

I'm not sure how much if any of Vista is actually written in .Net. 
Possibly some of the UI but I suspect not much of the core.  In any case 
it is the elegant design that I would like to see applied.  The fact 
that some of technology X may have been used in a bloated disaster isn't 
the same as saying that the design behind technology X shouldn't be used 
to avoid bloat in what comes afterwards.


The false logic is:
- Vista is a disaster
- Vista has some of .Net
- Therefore .Net is a disaster

Used by people who know little or nothing about .Net.

Post a reply to this message

Warp wrote:
> Orchid XP v7 <voi### [at] devnull> wrote:
>> About the only thing Java has going for it is that it's widely 
>> supported.
> 
>   I like many Java applications (cgoban being a good example), but I don't
> like the language itself. :)

I feel the same way about C... ;-)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Darren New wrote:
> There's a lot of cool stuff in C#, especially in libraries they don't 
> cover in tutorial-level books. I found the O'Reilly book very helpful too.

Incidentally, the O'Reilly book is the one that I'm liking :)

(Although it's an older version of the book, but still informative).

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

Post a reply to this message

Orchid XP v7 wrote:
> Darren New wrote:
> 
>> Looking at Java's GC and concluding that GC sucks is like looking at 
>> notepad and concluding that text processors suck.
> 
> OK, *surely* this ought to be quoted somewhere prominent? ;-)
> 

Now quoted at the top of my web site :)

(If you don't see it there, either refresh or click on the "View all 
quotes" link - it's at the bottom of the list, as it's the newest)

Warp wrote:
 > Darren New <dne### [at] sanrrcom> wrote:
 >> Looking at Java's GC and concluding that GC sucks is like looking at
 >> notepad and concluding that text processors suck.
 >
 >   I can't help it. I love to hate Java.
 >

This, also, is now quoted :)

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

Post a reply to this message

Orchid XP v7 a écrit :
> Warp wrote:
>> Orchid XP v7 <voi### [at] devnull> wrote:
>>> About the only thing Java has going for it is that it's widely 
>>> supported.
>>
>>   I like many Java applications (cgoban being a good example), but I 
>> don't
>> like the language itself. :)
> 
> I feel the same way about C... ;-)
> 
And what is your favorite Haskell application?

-- 
Vincent

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Looking at Java's GC and concluding that GC sucks is like looking at 
>> notepad and concluding that text processors suck.
> 
>   I can't help it. I love to hate Java.

It definitely provides many reasons to hate it, indeed!

-- 
   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:
>   The OS may help the GC system when we are talking about OS resources.
> However, it can't help when we are talking about resources within the
> program itself. (For the sake of example, let's assume that the program
> uses its own "file handles" instead of the ones provided by the system.
> It doesn't need to be something related to physical files per se.)

Most systems I've seen deal with this pretty easily, too.

>   The problem is not leaving file handles open when the program exits.
> The problem is opening more and more file handles without closing the
> old ones: In most systems at some point the OS will put a limit to this
> and refuse to give any more file handles. At this point the program will
> malfunction, and finding and solving the cause can be quite difficult.

And this is where I say that the OS support helps a bunch. If the OS 
garbage-collects the file handles like it GCs memory, it's fine.

That is, saying "at some point you run out of file handles and crash" is 
no more a problem with "proper" GC than saying "at some point you run 
out of memory and crash".  Either you're actively using too many file 
handles, or they get cleaned up and collected.

Not in most desktop OSes today, mind.

>   Usually this is a sign of a bug: Some code somewhere is "leaking".
> Not all unused file handles are being closed.
>   However, with GC, where there's delayed object destruction, it might
> not be a bug per se, but a consequence of GC.

At which point the GC runs, the files get closed, and you're golden. No 
more problematic than the fact that memory cleanup is delayed until you 
run out of memory.

>> No, the OS closes the files for you.
> 
>   It can't close them if it sees that they are in use: Some live objects
> are holding the file handles (because these objects have not been
> properly destroyed).

Then it's not safe to close the files. Either they're accessible, in 
which case it's no different than using up memory, or they're not 
accessible, in which case the OS could (in theory) GC the handles for 
you just as easily.

>   Of course one thing the OS might try is to tell the GC to make a sweep
> to see if that frees any file handles (does any OS actually do this?).

That's what I was describing. And yes, there are any number of 
environments that will do this sort of thing. It is, for example, how 
Smalltalk originally worked back when it was its own OS.

> However, as I said, this will work only with system resources.

If you have a resource that's limited in your code, you write a simple 
bit of code that says "if I try to allocate an X, and there are no X's 
left, trigger a garbage collection, then try it again, once."

Just like if you run out of memory.

>   This assumes that the main loop is advanced before the amount of leaked
> resources grows too large. It can alleviate the problem, but it's not a
> guarantee.

True.

>   (And if the main loop is executed very often, eg. thousands of times
> per second, wouldn't it cause overhead to call the GC each time?)

Or call it once a second, or once every N times thru the main loop, or 
whatever.

>> And of course anything that allocated stuff on the heap has this sort of 
>> problem anyway, unless you wind up essentially writing your own GC anyway.
> 
>   There are alternatives to GC which call destructors immediately when
> the objects go out of scope. For example, if I'm not completely mistaken,
> objective C uses reference counting.

The problem with reference counting is twofold: it doesn't work reliably 
if the bits your counting can point to themselves (directly or 
indirectly), and the reference count has to be at least as big as the 
number of possible pointers.

The former is a problem if you want it to be general. Reference-counting 
strings or file handles isn't much of a problem. Reference-counting 
arbitrary user data structures (like doubly-linked lists) doesn't work. 
The firefox people are starting to realize this.

The latter is a problem if you want to deal with (as you are fond of 
using as an example) pixels. Do you really want a 32-bit reference count 
on every 32-bit pixel?

>   Someone mentioned that in C# it's possible to tell for an object that
> it should be destroyed immediately when it goes out of scope (but otherwise
> regular GC is performed). That sounds like a good solution to me. You get
> the best of both worlds.

In C#, you have a "using" statement, which creates a new scope within 
which the object is allocated, and which calls the "Dispose" method when 
you leave the scope. Basically, prettiness for try/catch/finally.

I've seen Java research that does this for *all* objects the compiler 
can prove doesn't escape the scope.  Of course, if you pass a reference 
to the object to some other method, you lose that ability.

>> Only naive GC.  Of course, sophisticated GC needs support throughout the 
>> system. Some systems have this.
> 
>   There's no way the OS can know about the program's internal resources
> even if it cooperates with the GC engine to handle system resources.

What sort of "internal resource" are you talking about? Can you give an 
example?

>> Other systems don't have this sort of problem at all, in that files are 
>> memory resources just like "in-memory" structures, so going out of scope 
>> deletes the file just like you'd expect.
> 
>   Don't stick to the file handles in particular. It was just an easy to
> understand example.

Certainly. It's just an example, but one easy to generalize. What are 
some other examples you've encountered?

AFAICT, there are three bits:
1) Internal pre-allocated things, like a threadpool or buffers in a 
certain kind of memory or something, that the OS can't help with.
2) External things that can get cleaned up reliably, like open file handles.
3) External things that can't get cleaned up reliably, like file data.

#1 is easy to take care of - invoke the GC if it runs out and have the 
"Dispose" free the resource.

#2 can be dealt with like #1 if you have an OS or other virtual layer in 
between (like a VM) cooperating.

#3 is difficult to deal with without extensively labeling what you create.

-- 
   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:
>> I saw a LOL line on another conversation.
>>     > > Having used Ada and C++ extensively,
>>     > > I'll take Ada over C++ any day.
>>     > Never having used Ada at all, I'll take Ada over C++.
> 
>   Ada may be a wonderful language, but its lack of recent popularity
> means that the amount of available libraries is probably quite small.

This is true. Even simple things like base64 are not really easily 
available. I was just amused at the quote.

> No matter how wonderful a language is, having to reinvent wheels with
> it is a major letdown.

That's why I'm looking at Erlang. Nice industrial libraries to go along 
with the "bizarre" language.

>   If I had to choose a language other than C++, I'll probably choose Java
> because of the amount of libraries and portability, or C# because it
> sounds a bit better than Java. (Or if efficiency is not an issue, maybe
> I would just go with PHP.)

PHP is really sucky for anything other than what all the libraries are 
already written for. :-)  It's a good tool to have in the toolbox, but 
I'd not write a (say) desktop app in it, or for that matter anything 
intended to run longer than a web page hit.

>> It really is amazingly well thought out as a language. Plus they've 
>> added generics
> 
>   I thought templates are evil? ;)

I don't think C# generics are like templates. It's been a while, but I 
don't remember even that syntax.

>   It still makes be laugh out loud to remember how Java advocates
> fiercely attacked C++ templates. Then, some years later, they added
> some crippled template mechanism to Java (which still doesn't solve
> all the issues).

They didn't change the VM to support it. How good could it be? I think 
it was more pre-processor tricks than anything, IIRC.

>> I thought that was the idea behind Vista? Most of it rewritten to .NET?
>   Ah, now I understand why it's so large, heavy and slow.

Yep. And not even actually ported. :-)

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

Paul Fuller wrote:
> The Program <=> SQL divide is what LINQ targets and seems to 
> dramatically advance.

Yeah. That, or OO databases, or whatever the flavor-of-the-week is. 
Erlang has its own database stuff, so you can store any value in the 
database, indexed by any value.  Not SQL, but a decent database.

> I'm not sure how much if any of Vista is actually written in .Net. 

Right. Sorry. I hadn't mean to imply it actually *happened*. Just that 
that was the idea of it.

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