On Thu, 01 Nov 2007 01:19:42 +0100, Warp <war### [at] tagpovrayorg> wrote:
>   The next C++ standard will commit a big sin and will define the concept
> of garbage collection in C++.


Could you provide a reference? I have seen it being discussed at times,  
but I was not aware that consensus had been reached.



-- 
FE

Post a reply to this message

Warp escribió:
>   However, these ranters go ahead and generalize that this is the case
> with *all* possible programs. You should *always* use C# instead of C++,
> no matter what kind of program you are writing. Current computers have
> multi-gigabyte RAMs, so who cares?

I once saw a website of a guy creating one program a day in C#, to rant 
about how easy it was to code in C# and how everything else sucked ("HA! 
Can you do this with YOUR programming language?"). The simplest of the 
programs ate 40MB of memory. Of course I didn't bother to try the more 
complex ones.

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Except it's not my code, so I couldn't fix it if I wanted to. :-)
> 
>   It's not like programs written in other languages were bug-free...

Not at all. Let me give you an example:

C++ program crashes. How do I know? The socket it's listening on closes 
or, alternately, stops responding to requests because the program hung.

Tcl program crashes. How do I know? It catches the top-level bgerror, 
logs a record to the database (and failing that, writes it to the 
filesystem, and failing that, emails it to me, and failing that, well, 
yeah, OK.)  If the error was something that is probably recoverable 
(such as a lost socket, restarting database, etc) it cleans up all 
globals, reloads the code, closes all open sockets, and launches itself 
again.

You *could* do it in C++, sure, as long as you don't make any mistakes 
that trigger undefined behavior.

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

Darren New wrote:
> You *could* do it in C++, sure, as long as you don't make any mistakes 
> that trigger undefined behavior.

That's really more my gripe. Not that C++ is more buggy. It's that it's 
less easy to notice, track down the source of, or repair a bug. I make 
lots of buggy code as I'm developing. Making non-buggy code in a 
language with no support for knowing you made a bug takes me much much 
longer than finding the bug the first time I run the code I've written.

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

Fredrik Eriksson <noo### [at] nowherecom> wrote:
> On Thu, 01 Nov 2007 01:19:42 +0100, Warp <war### [at] tagpovrayorg> wrote:
> >   The next C++ standard will commit a big sin and will define the concept
> > of garbage collection in C++.

> Could you provide a reference?

http://en.wikipedia.org/wiki/C%2B%2B0x#Transparent_Garbage_Collection

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Fredrik Eriksson <noo### [at] nowherecom> wrote:
>> On Thu, 01 Nov 2007 01:19:42 +0100, Warp <war### [at] tagpovrayorg> wrote:
>>>   The next C++ standard will commit a big sin and will define the concept
>>> of garbage collection in C++.
> 
>> Could you provide a reference?
> 
> http://en.wikipedia.org/wiki/C%2B%2B0x#Transparent_Garbage_Collection

Sounds like "conservative GC" to me, where the runtime deallocates an 
entire page from the address space if, after scanning all memory, can't 
find a pointer-aligned integer whose value is in the range of addresses 
of that page.

I'd be fascinated to see how this works with pointer arithmetic et all.

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

Le 01.11.2007 19:43, Warp nous fit lire :
> Fredrik Eriksson <noo### [at] nowherecom> wrote:
>> On Thu, 01 Nov 2007 01:19:42 +0100, Warp <war### [at] tagpovrayorg> wrote:
>>>   The next C++ standard will commit a big sin and will define the concept
>>> of garbage collection in C++.

> http://en.wikipedia.org/wiki/C%2B%2B0x#Transparent_Garbage_Collection
> 
This is what you get when you mix java-hord with C++ specification...
Looks like the C++ comittee wanted to seduce the careless java-people.

Multiple inheritance is the strong interest of C++ vs Java
(interface just do not always do it).


-- 
The superior man understands what is right;
the inferior man understands what will sell.
-- Confucius

Post a reply to this message

On Thu, 01 Nov 2007 19:43:11 +0100, Warp <war### [at] tagpovrayorg> wrote:
> Fredrik Eriksson <noo### [at] nowherecom> wrote:
>> On Thu, 01 Nov 2007 01:19:42 +0100, Warp <war### [at] tagpovrayorg> wrote:
>> >   The next C++ standard will commit a big sin and will define the  
>> concept
>> > of garbage collection in C++.
>
>> Could you provide a reference?
>
> http://en.wikipedia.org/wiki/C%2B%2B0x#Transparent_Garbage_Collection


"Note: In the post-Kona mailing (2007/10), Transparent Garbage Collection  
has been dropped to a status of Not quite ready for C++0x timetable, but  
actively pursued. This likely will postpone GC from C++0x to the version  
after it."

So, maybe sometime around 2020 then.


-- 
FE

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> > bits were wasted. I re-implemented the this class so that it would only
> > store as many bits as necessary for each element. This meant that if,
> > for example, the integers stored in this vector had value ranges between
> > 0 and 100000, only 17 bits were allocated for each element, producing a
> > saving of 46% in memory usage.

> That's a keyword in Ada, see. :-) You declare the array "packed" and you 
> get that behavior without writing any extra code.

  The question is not whether the language has direct support for
something specific but if offers you the tools to transparently change
the implementation of such a data container in such way if needed
(including things not directly supported by the compiler).

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   The question is not whether the language has direct support for
> something specific but if offers you the tools to transparently change
> the implementation of such a data container in such way if needed
> (including things not directly supported by the compiler).

Yeah, Ada does that too, of course.   I'm just pointing out it has a 
bunch of *other* stuff *also* built in.  Like, most of the kinds of 
things you'd want to do to drive hardware, handle realtime needs, catch 
interrupts, pack bits, use funky size memory bandwidths, replace running 
code without stopping what you're doing, multithreading, mapping 
variables to specific memory locations, handling multi-processor issues 
like atomicity and volitility, and all that sort of stuff, in a 
standardized way you can rely on.

Of course Ada has encapsulation. Better than C++'s, even.

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message