SGCL is precise, parallel garbage collection library for C++ (at this time
for Windows 32/64 only). SGCL is free software published under University of
Illinois/NCSA Open Source License.
Get it at: http://sourceforge.net/projects/sgcl/
Regards
Sebastian Nibisz
Feb 28 '08
72  3360 
On 2008-03-03 16:36:34 -0500, Ioannis Vranos
<iv*****@nospam.no.spamfreemail.grsaid:
>
Yes, MS did push it forward, but it is an ECMA standard (and if I
recall well, both C++/CLI and CLI must have become ISO standards too).
C++/CLI did not become an ISO standard.
--
Pete
Roundhouse Consulting, Ltd. ( www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
( www.petebecker.com/tr1book)
>
But Microsoft getting ECMA to bless it does.
--
I guess it depends on what you mean by standard. The ISO C++ standard
is in my view an excellent example of an industry standard, with broad
industry support and consent. In particular there are many separate
and competing implementations, and a broad range of industry input to
the standardization process.
AFAICT those qualities don't apply to the ECMA C++/CLI standard. It
would be better described as a formal standard, and as such is little
more than a rigorous specification.
Casually referring to them both as "standards" is rather misleading.
But unfortunately rather common.
-jarl. jl******@hotmail.com writes:
That would be a terrible mistake. Having the garbage collector run
user code of any kind is hugely inappropriate, and exactly what landed
C# and Java in the resource management mess that they're in.
And that is precisely why, at $day$job$, someone's currently busy rewriting
a latency-sensitive realtime application from Java into C++. Having the VM
take a powder, at random times, to clean up its heap, gets old very quickly.
When C++ programmers complain about garbage collection, it's almost
always because they've been exposed to how garbage collection works in
either C# or Java.
Amen.
P.S. And the dude who's currently rewriting all that Java code in C++ is
not, I repeat, is NOT, using some loopy C++-based garbage collection
framework or library.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQBHzJZYx9p3GYHlUOIRAsHhAJ47WtYenHsg1noRM/TheMEE8dNCXQCcCp53
ntZGVxvnAgMOWxe6Yl3oQ3o=
=sT5P
-----END PGP SIGNATURE-----
On 2008-03-03 18:37:39 -0500, jl******@hotmail.com said:
>>
But Microsoft getting ECMA to bless it does.
--
I guess it depends on what you mean by standard.
I mean something that a recognized standards organization calls a standard.
--
Pete
Roundhouse Consulting, Ltd. ( www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
( www.petebecker.com/tr1book)
Actually it looks like I was right, C++/CLI and CLI have become ISO
standards in addition to ECMA standards too.
Here is an interesting link about the rationale of C++/CLI that I think
is a "must" read for all.
I remind you that CLI is the standard for a type of a Virtual Machine
(examples are .NET, Mono), and C++/CLI is a standard that makes it
possible for C++ to take advantage all the facilities of this type of VM.
It keeps the notion of native code and managed code separate, while it
allows them to be intermixed at the same time.
The link: http://www.gotw.ca/publications/C++CLIRationale.pdf
On 2008-03-04 06:00:50 -0500, James Kanze <ja*********@gmail.comsaid:
>
(On another note: I think I'll write up a proposal real quick
for a standard hash function for pointers, since it's something
that a user can't write in an architecture independent manner.)
There's already one in C++0x. The template std::hash has a
specialization for std::hash<T*>, which gives you a callable type.
--
Pete
Roundhouse Consulting, Ltd. ( www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
( www.petebecker.com/tr1book)
On 2008-03-04 05:37:12 -0500, Ioannis Vranos
<iv*****@nospam.no.spamfreemail.grsaid:
Actually it looks like I was right, C++/CLI and CLI have become ISO
standards in addition to ECMA standards too.
CLI is an ISO standard. There is no ISO binding of C++ to CLI.
--
Pete
Roundhouse Consulting, Ltd. ( www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
( www.petebecker.com/tr1book)
On Mar 3, 6:27 am, Kai-Uwe Bux <jkherci...@gmx.netwrote:
Sam wrote:
James Kanze writes:
[snip]
Garbage
[snip]
collection is essential in Java, because all objects must be
allocated dynamically, and user defined types can't have value
semantics. It's optional in C++, because we do have value
semantics. Optional, but it still saves the programmer some
unnecessary work.
No, it's not "optional" in C++. It does not exist, at all,
in C++. Go look up the "optional" part of ISO/IEC 14882:2003
that defines whatever you think "garbage collection" means
in the C++ context. I eagerly await the results of your
search.
I don't think that is entirely correct.
It's not correct at all. However...
The C++ standard is worded very cautiously with regard to new
and delete to leave a tremendous amount of freedom to the
implementation. I think, a compliant implementation could use
garbage collection. In particular, I do not know of any
language in the C++ standard that would require the following
program to ask the execution environment for an unbounded
amount of memory:
int main ( void ) {
while ( true ) {
new int ( 5 );
}
}
There are a few legal constructs in C++ which do cause problems
with garbage collection. (They don't occur in any reasonable
real programs, but they are formally there.) When I said it was
"optional", I was thinking in terms of the way threading is
optional. The standard doesn't really define it, and you do
need to fudge a few things to make it fit, but in practice, it's
available to anyone that wants it, and it's actually widely used
in C++ applications already. Just like threading.
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On Feb 28, 8:26*am, "Sebastian Nibisz" <EB...@poczta.onet.plwrote:
Garbage collection is for lazy rich folks who can't be bothered to
take out their own trash.
struct node
{
* * node* next;
};
node* root = new node;
node* n = root;
for (int x = 0; x < 1000000; ++x)
{
* * n = n->next = new node;
}
How to release memory?
#include <boost/shared_ptr.hpp>
struct CNode
{ boost::shared_ptr<CNodem_sNext;
};
int main(int argc, char **argv)
{ boost::shared_ptr<CNodesRoot(new CNode);
CNode *p = sRoot.get();
for (size_t i = 0; i < 100; i++)
p = (p->m_sNext = boost::shared_ptr<CNode>(new CNode)).get();
return 0;
}
James Kanze wrote:
I'm sorry, but it's frustrating. Somewhat upthread, someone
said "recursion", doubtlessly ironically, since I do presume
that everyone would realize that explicitly recursing 1000000
times was a bad idea.
If you think there's something wrong with recursion then there's something
wrong with your chosen language(s) and implementation(s)...
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?u
In article <63*************@mid.individual.net>, ia******@hotmail.com
says...
[ ... ]
No, something like
struct Parent
{
struct Child
{
Parent* parent;
Child( Parent* parent ) : parent(parent) {}
};
Child* child;
Parent() : child(new Child(this)) {}
};
Shouldn't be a problem for anything worthy of being called a garbage
collector at all.
At its most basic, a garbage collector starts from a root set (basically
auto and static variables) and chases any pointers it finds in those,
recursive, until it can't find any pointers it hasn't already chased.
Each object it encounters is marked as being in use.
With a cycle like the above, when there are no more pointers in the root
set to provide access to the struct, it gets collected -- its internal
structure is basically irrelevant at that point (except, possibly, to do
things like finalization on the objects being collected).
--
Later,
Jerry.
The universe is a figment of its own imagination.
In article <8a128594-ca3f-4933-a9e5-abc99e1ce915
@e10g2000prf.googlegroups.com>, pe***************@gmail.com says...
[ ... ]
It would break some of my code which hashes on a pointer.
I would have been surprised if there wasn't any code in the world it
would break -- but I think it's also a pretty easy break to fix. As I
mentioned elsethread, it seems like the obvious thing to do is store the
original address, and always use it for the hash. A hash function in the
standard library could make this entirely transparent.
--
Later,
Jerry.
The universe is a figment of its own imagination.
On Mar 4, 1:07 pm, Pete Becker <p...@versatilecoding.comwrote:
On 2008-03-04 06:00:50 -0500, James Kanze <james.ka...@gmail.comsaid:
(On another note: I think I'll write up a proposal real quick
for a standard hash function for pointers, since it's something
that a user can't write in an architecture independent manner.)
There's already one in C++0x. The template std::hash has a
specialization for std::hash<T*>, which gives you a callable type.
Excellent. What about std::hash<type_info>?
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On Mar 6, 12:54 am, Jon Harrop <use...@jdh30.plus.comwrote:
James Kanze wrote:
I'm sorry, but it's frustrating. Somewhat upthread, someone
said "recursion", doubtlessly ironically, since I do presume
that everyone would realize that explicitly recursing
1000000 times was a bad idea.
If you think there's something wrong with recursion then
there's something wrong with your chosen language(s) and
implementation(s)...
If you think you can recurse a 1000000 times in C or in C++,
you've got another think coming. It just won't work, at least
with the implementations I've got access to.
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On Mar 5, 11:02 pm, Peter <ExcessPh...@gmail.comwrote:
On Feb 28, 8:26 am, "Sebastian Nibisz" <EB...@poczta.onet.plwrote:
Garbage collection is for lazy rich folks who can't be bothered to
take out their own trash.
struct node
{
node* next;
};
node* root = new node;
node* n = root;
for (int x = 0; x < 1000000; ++x)
{
n = n->next = new node;
}
How to release memory?
#include <boost/shared_ptr.hpp>
struct CNode
{ boost::shared_ptr<CNodem_sNext;
};
int main(int argc, char **argv)
{ boost::shared_ptr<CNodesRoot(new CNode);
CNode *p = sRoot.get();
for (size_t i = 0; i < 100; i++)
p = (p->m_sNext = boost::shared_ptr<CNode>(new CNode))..get();
return 0;
}
Core dumps on Solaris, with g++. I expect that it core dumps
most of the time, with most implementations.
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
I think we must follow the approach of C++/CLI (if not adopting it):
Separation of native types and new "managed" types, both having their
own kinds of pointers, and both being able to be intermixed.
Native types work as usual, managed types have two types of destructors,
the usual one for deterministic destruction and one (called finalizer)
for GC-time destruction which is called if the destructor has not been
called already.
The native pointers (*) behave as usually, the managed pointers (^),
called handlers, have some restrictions imposed by the VM (for example
not considering their value as permanent since the GC can move them
around, unless we explicitly "pin" them, etc).
I think trying to make the existing native types to work under a VM with
all their features is impossible. I think the general approach of
C++/CLI is the perfect one (of course one may disagree with some details
of it).
On 2008-03-06 05:15:45 -0500, James Kanze <ja*********@gmail.comsaid:
On Mar 4, 1:07 pm, Pete Becker <p...@versatilecoding.comwrote:
>On 2008-03-04 06:00:50 -0500, James Kanze <james.ka...@gmail.comsaid:
>>(On another note: I think I'll write up a proposal real quick
for a standard hash function for pointers, since it's something
that a user can't write in an architecture independent manner.)
>There's already one in C++0x. The template std::hash has a
specialization for std::hash<T*>, which gives you a callable type.
Excellent. What about std::hash<type_info>?
Not there yet. <gI think it's a better solution than adding a
hash_code() member function to type_info, which could lead to binary
incompatibilities.
--
Pete
Roundhouse Consulting, Ltd. ( www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
( www.petebecker.com/tr1book)
James Kanze wrote:
On Mar 6, 12:54 am, Jon Harrop <use...@jdh30.plus.comwrote:
>James Kanze wrote:
I'm sorry, but it's frustrating. Somewhat upthread, someone
said "recursion", doubtlessly ironically, since I do presume
that everyone would realize that explicitly recursing
1000000 times was a bad idea.
>If you think there's something wrong with recursion then
there's something wrong with your chosen language(s) and
implementation(s)...
If you think you can recurse a 1000000 times in C or in C++,
you've got another think coming. It just won't work, at least
with the implementations I've got access to.
Exactly. That is a shortcoming of those languages and does not reflect upon
recursion.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?u
Sebastian Nibisz wrote:
SGCL is precise, parallel garbage collection library for C++ (at this time
for Windows 32/64 only). SGCL is free software published under University
of Illinois/NCSA Open Source License.
Get it at:
http://sourceforge.net/projects/sgcl/
Regards
Sebastian Nibisz
I can't find any useful information about this project, e.g. what kind of
GC, what are its properties, could it be used in Mono...
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?u
In article <fq***********@ulysses.noc.ntua.gr>, iv*****@nospam.no.spamfreemail.gr says...
I think we must follow the approach of C++/CLI (if not adopting it):
Separation of native types and new "managed" types, both having their
own kinds of pointers, and both being able to be intermixed.
IMO, it would be better to forego garbage collection completely -- it
doesn't provide (anywhere close to) enough utility to justify this kind
of brain damage.
--
Later,
Jerry.
The universe is a figment of its own imagination.
Jon Harrop wrote:
James Kanze wrote:
>On Mar 6, 12:54 am, Jon Harrop <use...@jdh30.plus.comwrote:
>>James Kanze wrote:
I'm sorry, but it's frustrating. Somewhat upthread, someone
said "recursion", doubtlessly ironically, since I do presume
that everyone would realize that explicitly recursing
1000000 times was a bad idea.
If you think there's something wrong with recursion then
there's something wrong with your chosen language(s) and
implementation(s)...
If you think you can recurse a 1000000 times in C or in C++,
you've got another think coming. It just won't work, at least
with the implementations I've got access to.
Exactly. That is a shortcoming of those languages and does not reflect upon
recursion.
It's not a short-coming of the languages, it's a QoI issue. Functional
languages translate such deep recursion into loops, because they have
to. Procedural languages provide looping constructs directly, so there
is not a compelling reason to perform such an optimization. If
recursion ever becomes a hyper-fashionable alternative to looping,
subsequent procedural language implementations likely will offer
guarantees about what sorts of recursion will be translated to loops.
In today's environment, though, as Peter Koch said, there is rarely (if
ever) a need for such deep recursion, anyway.
On 6 Mar., 14:56, Jon Harrop <use...@jdh30.plus.comwrote:
James Kanze wrote:
On Mar 6, 12:54 am, Jon Harrop <use...@jdh30.plus.comwrote:
James Kanze wrote:
I'm sorry, but it's frustrating. *Somewhat upthread, someone
said "recursion", doubtlessly ironically, since I do presume
that everyone would realize that explicitly recursing
1000000 times was a bad idea.
If you think there's something wrong with recursion then
there's something wrong with your chosen language(s) and
implementation(s)...
If you think you can recurse a 1000000 times in C or in C++,
you've got another think coming. *It just won't work, at least
with the implementations I've got access to.
Exactly. That is a shortcoming of those languages and does not reflect upon
recursion.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.http://www.ffconsultancy.com/products/?u
On 6 Mar., 14:56, Jon Harrop <use...@jdh30.plus.comwrote:
James Kanze wrote:
On Mar 6, 12:54 am, Jon Harrop <use...@jdh30.plus.comwrote:
James Kanze wrote:
I'm sorry, but it's frustrating. *Somewhat upthread, someone
said "recursion", doubtlessly ironically, since I do presume
that everyone would realize that explicitly recursing
1000000 times was a bad idea.
If you think there's something wrong with recursion then
there's something wrong with your chosen language(s) and
implementation(s)...
If you think you can recurse a 1000000 times in C or in C++,
you've got another think coming. *It just won't work, at least
with the implementations I've got access to.
Exactly. That is a shortcoming of those languages and does not reflect upon
recursion.
What do You mean? Do yo mean the inability to change a recursion to a
loop or the inability to have a large stack?
If it is the first case, then you're wrong: the loop in question could
not be reduced to a loop. If it the other case, youre also wrong
because there is nothing that demands that only a small stack should
be used.
/Peter This thread has been closed and replies have been disabled. Please start a new discussion. |
