how to design a replacement for C++
Lynn McGuire
will never go away: http://apenwarr.ca/log/?m=201007#22
Lynn
Balog Pal
> will never go away: http://apenwarr.ca/log/?m=201007#22
Very good stuff.
Francesco S. Carta
> Interesting article on why C++ development may be fading but it
> will never go away: http://apenwarr.ca/log/?m=201007#22
Uhm, some good stuff, some bad.
I've gone through and I've read the precedent post too, a rant about C++
(not that the one you linked isn't a rant, it also is, somewhat).
Although his rants contain a fair bit of good speech (as for the
contents), it's a shame he shapes it interleaving gratuitous vulgarities
and insults: that's the drop that moved the needle from "towards" to
"away", for me.
[ aside:
I wonder why, in the 17 years he used C++ (and I suppose he used C for
longer) he didn't discover that one doesn't need to dereference and
enclose in parentheses a pointer to function in order to make the call.
- notice that I'm speaking about the syntax to make calls via pointers
to function; pointers to member function need the parentheses and that
is somewhat ugly, but I could easily work around it (and I'm not Jack
TopCoder) -
I suppose he still has some gaps to fill, maybe other basic ones too,
regardless of his long experience.
end aside ]
--
FSC - http://userscripts.org/scripts/show/59948
http://fscode.altervista.org - http://sardinias.com
Ian Collins
> Lynn McGuire <l...@winsim.com>, on 23/07/2010 10:45:22, wrote:
>
>> Interesting article on why C++ development may be fading but it
>> will never go away: http://apenwarr.ca/log/?m=201007#22
>
> Uhm, some good stuff, some bad.
>
> I've gone through and I've read the precedent post too, a rant about C++
> (not that the one you linked isn't a rant, it also is, somewhat).
>
> Although his rants contain a fair bit of good speech (as for the
> contents), it's a shame he shapes it interleaving gratuitous vulgarities
> and insults: that's the drop that moved the needle from "towards" to
> "away", for me.
I gave up at "C and C++ both get the job done in their respective
niches. And those niches are shrinking dramatically". I assume he
hasn't heard of embedded devices.
--
Ian Collins
Francesco S. Carta
Well, if you resisted to that, you would have filled the measure and
would have left in a further couple of paragraphs if not earlier - but
maybe I would be better shutting up right now, I would not feel fine
dissecting his articles here if he doesn't happen to read this ng. I
could drop him a message though...
uhm... no. I'll just shut up.
Il gioco non varrebbe la candela.
Jonathan Lee
> I gave up at "C and C++ both get the job done in their respective
> niches. And those niches are shrinking dramatically". I assume he
> hasn't heard of embedded devices.
Not just that. Look at http://www.langpop.com/
C, C++, and Java are consistently in the top 3 by all kinds of
metrics. I've seen similar stats elsewhere.
More than that, but I think Java's numbers are a bit inflated.
Not sure about universities elsewhere, but in Canada Java is
the "intro" programming language. So statistics like "most
discussions on site _____" will include a lot of 1st and 2nd
years asking generic questions about how to make a stack and
such (in Java).
--Jonathan
Öö Tiib
>
> I gave up at "C and C++ both get the job done in their respective
> niches. And those niches are shrinking dramatically". I assume he
> hasn't heard of embedded devices.
>
His further opinion seems to be that these niches are shrinking since
C (or C++) + script (his favorite is Python) are taking over. Odd. I
do not remember any market share that we had as pure without scripts.
All successful C++ projects some sort of scripts have been always
used. It all started with C + Perl and has always stayed like that.
Even for developing embedded systems the scripts are used massively
(but they remain less in end product). For tools, configuring,
testing, build system, prototyping, deploying, emulating/fakeing parts
(or whole external entities) under development, customizing ... etc.
Even when one views scripts as temporary solution, these stay often
there forever for practical reasons, because there is always better
way to use budget than to replace scripts in less critical/often
changing part with compiled code.
Balog Pal
> Although his rants contain a fair bit of good speech (as for the
> contents), it's a shame he shapes it interleaving gratuitous vulgarities
> and insults: that's the drop that moved the needle from "towards" to
> "away", for me.
Well, is the other guy is right, and there's nothing to do about it, one can
still use call up some stilistic issue do dismiss the content... :-o
Francesco S. Carta
Too bad you snipped the parts where I said that some of that content is
_bad_.
I've not dismissed it just because of its style: had it been more right
than wrong, I would have kept a reference to that website, but since
it's 50/50 (at best) and since it's pretty bad style, I feel I can
safely dismiss it.
There are tons of more knowledgeable people that write in a far more
pleasant way, my spare time is limited by definition and I _have_ to
make a choice about what to read: wrong information, vulgarities and
insults tell me I can safely drop that source, whatever "right" things
that source could give me.
Öö Tiib
> Interesting article on why C++ development may be fading but it
> will never go away: http://apenwarr.ca/log/?m=201007#22
Sort of whiny.
Does not like
* std::string (template gibberish).
* boost::format (template gibberish).
* boost::bind (template gibberish).
* std::map (operator [] and template gibberish).
Especially long he goes on about std::map's operator []. His long
speech about its "Ha-ha" downsides felt longer than to read the <map>
header (350 lines or so).
So seems ordinary whiner. If that Avery Pennarun could code he could
write some pennarun::map behaving like he wants quicker than all the
obsenities he wrote about standard one.
Francesco S. Carta
Further than the complaints you pointed out, that are all about the STL
and as such can completely be worked around (as you correctly said), he
pushed himself that far as to say that a pointer to member function
should hold a "this" pointer - that is, a complaint about the language
itself: he would prefer those pointers to be tied to one specific
instance instead of pointers that can be applied to whichever object.
This would completely defeat the purpose of that feature.
Well, if someone can't see how "less is more" in cases like this (and
even more in a flexible and extensible language as C++ is) one can't
really appreciate the full power of a programming language - and in
fact, seems like he's not aware that one can easily create a class that
ties an object with a pointer to one of its member functions.
Ian Collins
>
> Further than the complaints you pointed out, that are all about the STL
> and as such can completely be worked around (as you correctly said), he
> pushed himself that far as to say that a pointer to member function
> should hold a "this" pointer - that is, a complaint about the language
> itself: he would prefer those pointers to be tied to one specific
> instance instead of pointers that can be applied to whichever object.
In practice, how often are pointers to member functions used? I don't
think I've ever had cause to use one except for exotic RPC applications.
--
Ian Collins
Francesco S. Carta
I can think of different ways to use those pointers, though, I have no
idea of how (in)frequent those usages could be, compared to the average
real-life programmer workday.
Given, I can think of them but I didn't try to implement them to see how
easily I could re-implement them without using pointers to member
functions (in order to see if they would be a real advantage or just a
"I want to use /that/ feature" mind-trip).
I think I'll give it a shot, I'm really curious because it seems to be
an undervalued feature.
Bo Persson
Yes, what does "popular" really mean?
I do some of my work in Cobol, where most of the guys are 50+ years
old and hardly ever have any beginner's questions. And if they did,
wouldn't ask them on an internet forum anyway. .-)
Bo Persson
Balog Pal
> Too bad you snipped the parts where I said that some of that content is
> _bad_.
IMO more like too good -- we both know that your away speach is mere
notpicking on a randomly selected sendence, that is quite irrelevant wrt.
the content.
> I've not dismissed it just because of its style: had it been more right
> than wrong, I would have kept a reference to that website, but since it's
> 50/50 (at best) and since it's pretty bad style, I feel I can safely
> dismiss it.
I'd be really interested how you calculated that 50% bad figure. Do you
think std::string is not a monster? That std::map is not broken in the
interface? That C++ lacks lots of undamental support for trivial things that
we struggle to cover with template magic with all its painful consequences
(what btw after stripping concepts is bound to stay for another decade?)
> There are tons of more knowledgeable people that write in a far more
> pleasant way, my spare time is limited by definition and I _have_ to make
> a choice about what to read: wrong information, vulgarities and insults
> tell me I can safely drop that source, whatever "right" things that source
> could give me.
When I'm concerned about tinme spent on nonintertesting stuff, I start by
NOT writing about in in a forum. ;-)
Balog Pal
>Especially long he goes on about std::map's operator []. His long
>speech about its "Ha-ha" downsides felt longer than to read the <map>
>header (350 lines or so).
Length of <map> is quite irrelevant. Do you defend its interface design?
In my experience it is pretty broken. Sure why stop at std::map, MOST of the
standard lib is poor quality, and it is very sad. I try to think a list of
what is good, and nothing emerges except for vector. And guess how many of
us had vector-like classes before the standard.
The point f the standard lib would have been to give good support out of the
box -- and it more like creates pain only. At least if used "alone".
Sure you can patch it up with your own exrtensions or popular existing
libs -- but that we could do without standard lib, could we?
I recall back in 96-97 most voces pushed "give us a standard NOW", whatever
it takes. Possibly me too. Did not turned up as a good idea in retrospect.
:-((((
>So seems ordinary whiner. If that Avery Pennarun could code he could
>write some pennarun::map behaving like he wants quicker than all the
>obsenities he wrote about standard one.
Sure, I have bunch of my classes that are good, and used many libraries,
just if you work on a project where using the standard lib was decided, it
is pretty hard to go ahead. Either having different classes side-by-side,
or replacing the existing ones. (certainly the story of map is a dwarf
compared to std::string)
Balog Pal
I use them time to time. But most frequently they are goning into
std::mem_fun or sigc::mem_fun or boost::bind, that well indicates that
having a bound pointer is something of need.
But the guy's other point is more right. We had a ton of discussion on
unified function calls' usability ( i.e. the language make
obj.foo(param) callable as foo(obj, param) ). For both functions and
operators. Clearing up a big mess. there is normally an agreement that it
would be fine. But it will never go into the standard as that would make
name lookup different, and have possibility to change existing code.
Checkmate.
Balog Pal
> I think I'll give it a shot, I'm really curious because it seems to be an
> undervalued feature.
The landscape is pretty simple.
STL introduced iterators, algorithms, and stuff tso you can supposedly write
in that style.
But those ideas are hanging in the air, and turn not usable at all. For the
very issues mentioned, there is no working way to call your functions.
The minimum would have needed:
- something that is usable like boost::bind, with native support
- built-in support that is now covered by boost::ref and boost::cref
- perfect forwarding
- iterator that in modeled like GOF iterator rather than on simple ponter
- resolving the error: 'reference to reference' issue. At least for the
natural const& to const&. :-((
- allowing definiton of local functions, or at least local classes usable
with templates
just what pops up in a few minutes
Francesco S. Carta
> "Francesco S. Carta" <entu...@gmail.com>
>
>> Too bad you snipped the parts where I said that some of that content
>> is _bad_.
>
> IMO more like too good -- we both know that your away speach is mere
> notpicking on a randomly selected sendence, that is quite irrelevant
> wrt. the content.
Interesting, since when were you capable of telepathy?
Mine was not just a pure nitpick: he directly sent to hell the reader -
to use an euphemism - implying the reader wanted to remove the
preprocessor from that "new language" and he called names on the
standardization committee just because he doesn't like the way they
designed the STL.
And that's not "one randomly selected sentence": those are two well
selected - and heavy - ones.
>> I've not dismissed it just because of its style: had it been more
>> right than wrong, I would have kept a reference to that website, but
>> since it's 50/50 (at best) and since it's pretty bad style, I feel I
>> can safely dismiss it.
>
> I'd be really interested how you calculated that 50% bad figure. Do you
> think std::string is not a monster? That std::map is not broken in the
> interface? That C++ lacks lots of undamental support for trivial things
> that we struggle to cover with template magic with all its painful
> consequences (what btw after stripping concepts is bound to stay for
> another decade?)
That 50% was a fair figure - fair towards the article author. I don't
know your method: I happen to give more importance to quality than to
quantity, and a few really bad arguments can outweigh a bigger number of
good points, as for what regards the overall evaluations of some writing.
As for what concerns what is good and what is bad, it's clear that we
have different points of view and different tastes.
As for what concerns the "template magic" that you seem to be missing,
why don't you simply post your issues here and see if somebody can give
you some nice solution for your problem(s)?
>> There are tons of more knowledgeable people that write in a far more
>> pleasant way, my spare time is limited by definition and I _have_ to
>> make a choice about what to read: wrong information, vulgarities and
>> insults tell me I can safely drop that source, whatever "right" things
>> that source could give me.
>
> When I'm concerned about tinme spent on nonintertesting stuff, I start
> by NOT writing about in in a forum. ;-)
Well, I couldn't really say anything about that, because you have been
smart enough to put the sentence in the first singular person.
_I_ spoke about an offensive person with limited views that writes
articles containing wrong and biased information (the fact that he says
something correct is a secondary point).
Writing a follow-up on such a subject has a well defined purpose for me:
steer people away from such kind of crap.
I must take note that your comment on that article was a plain "Very
good stuff."
...note taken.
Francesco S. Carta
> "Francesco S. Carta" <entu...@gmail.com>
>> I think I'll give it a shot, I'm really curious because it seems to be
>> an undervalued feature.
>
> The landscape is pretty simple.
>
> STL introduced iterators, algorithms, and stuff tso you can supposedly
> write in that style.
>
> But those ideas are hanging in the air, and turn not usable at all. For
> the very issues mentioned, there is no working way to call your functions.
Please elaborate here. I have no problems calling my functions, of
either type.
> The minimum would have needed:
> - something that is usable like boost::bind, with native support
> - built-in support that is now covered by boost::ref and boost::cref
> - perfect forwarding
> - iterator that in modeled like GOF iterator rather than on simple ponter
> - resolving the error: 'reference to reference' issue. At least for the
> natural const& to const&. :-((
> - allowing definiton of local functions, or at least local classes
> usable with templates
>
> just what pops up in a few minutes
>
I will not enter into this kind of discussion, I still have a long way
to go before fully understanding the power of what C++ already gives me.
If you feel strong enough on your feet as to suggest improvements and
additions to the language and its library, I'm sure you'll find a lot of
knowledgeable people ready to discuss them, refine them and eventually
consider them for inclusion: comp.std.c++
Bo Persson
Most of these features already have papers written, and will be
included in C++0x.
Not all of us see it as a advantage to have compiler magic for all
specific features, but find it more useful to be able to express it as
a library. That enables more use of the building blocks provided by
the compiler .
Bo Persson
James Kanze
Or large scale servers. Or numeric applications.
My impression (based on working in a lot of different
environments) is that C++ is anything but a niche
language---rather, it's the language you use when the niche
you're working in doesn't have an appropriate niche language.
--
James Kanze
James Kanze
I've used them on occasion. And they're not that rare as
template arguments (or as a first argument to boost::bind).
--
James Kanze
Öö Tiib
> >"Öö Tiib" <oot...@hot.ee>
> >Especially long he goes on about std::map's operator []. His long
> >speech about its "Ha-ha" downsides felt longer than to read the <map>
> >header (350 lines or so).
>
> Length of <map> is quite irrelevant. Do you defend its interface design?
> In my experience it is pretty broken. Sure why stop at std::map, MOST of the
> standard lib is poor quality, and it is very sad. I try to think a list of
> what is good, and nothing emerges except for vector. And guess how many of
> us had vector-like classes before the standard.
Yes it is true, std::map's operator [] is crap, but map itself is
useful. std::string i entirely avoid since it silently constructs from
char const* or char* (that are almost equal to void*). I prefer to use
std::wstring for holding text and std::vector<char> for holding binary
blocks of data.
I disagree that all standard lib is terrible. Too small it is
perhaps ... yes. underdocumented and underannounced. Standards text is
hard to read. All implementations push their non-standard crap more
than standard library.
I like the attitude that boost community carries. When something is
inconvenient or missing then why not to make it convenient and
present. One can not wait for a round table of intel, at&t, microsoft,
sun, apple and so on sit and to solve all the problems, especially
when the solutions contradict with their business interests.
> The point f the standard lib would have been to give good support out of the
> box -- and it more like creates pain only. At least if used "alone".
> Sure you can patch it up with your own exrtensions or popular existing
> libs -- but that we could do without standard lib, could we?
Mostly because standard library is very small toolset with weak
documentation so one can live without.
> I recall back in 96-97 most voces pushed "give us a standard NOW", whatever
> it takes. Possibly me too. Did not turned up as a good idea in retrospect.
> :-((((
>
> >So seems ordinary whiner. If that Avery Pennarun could code he could
> >write some pennarun::map behaving like he wants quicker than all the
> >obsenities he wrote about standard one.
>
> Sure, I have bunch of my classes that are good, and used many libraries,
> just if you work on a project where using the standard lib was decided, it
> is pretty hard to go ahead. Either having different classes side-by-side,
> or replacing the existing ones. (certainly the story of map is a dwarf
> compared to std::string)
Everybody has their own tools. It is because when you write for some
specific niche then too over-bloated standard library may be also
nuisance. Single toolset can not be good for all jobs. i avoid
std::string (and char in other contexts but "a byte") it does help
more than hurt.
Miles Bader
> Yes it is true, std::map's operator [] is crap, but map itself is
> useful.
Wait, why is [] crap...? (I don't use std::map very much, but when I
have, I've used [], and it worked fine, just as one would expect)
> I disagree that all standard lib is terrible.
In fact, in my experience, the STL is quite good -- very usable for many
common tasks, fast, and unbloated.
I dunno why Balog said that.
-Miles
--
Is it true that nothing can be known? If so how do we know this? -Woody Allen
James Kanze
> Öö Tiib <oot...@hot.ee> writes:
> > Yes it is true, std::map's operator [] is crap, but map
> > itself is useful.
> Wait, why is [] crap...?
The usual complaint is that it can't be used on a const
std::map, because it can modify the map.
Whether this is a good thing or not depends on the application.
There is no one correct solution.
[...]
> In fact, in my experience, the STL is quite good -- very usable for many
> common tasks, fast, and unbloated.
It's not that well designed, but let's not exagerate. It's
still quite usable. And the libraries in other languages aren't
without problems either.
--
James Kanze
Juha Nieminen
> Interesting article on why C++ development may be fading but it
> will never go away: http://apenwarr.ca/log/?m=201007#22
"C++ has made templates a dirty word"
I have never quite understood the general aversion towards C++ templates
out there. Maybe I'm biased.
I find that C++ templates make writing programs simpler, not more
complicated. Many things can be done with simple one-liners which would
otherwise require dozens of lines of complicated code.
A common complaint about C++ templates is the error messages they
produce. I *am* definitely biased on this aspect because I have actually
learned to read those error messages and I can usually find quite quickly
what the real problem is. (Of course it helps that compilers have got a
lot better at synthesizing the most relevant parts of the error even in
complicated templated code.) I can see, however, how a beginner programmer
can get confused with them.
However, dissing C++ templates only because they produce complicated
error messages is throwing the baby out with the bath water.
When Java was designed as a "better C++" (which is the case, no matter
how much Java people deny this irrefutable fact), they naturally left any
kind of support for templates completely out because, you know, templates
are "evil" and produce bad code.
Many years later they came to regret this, as a lack for any kind of
generic code (besides what OOP offers) was a kind of limiting factor and
produced ugly code. So rather than to succumb to the lure of C++ templates
they introduced a "better template mechanism" (and because "template" is
a curseword they couldn't use that name, and hence they invented a new
name for it, namely "generics", to avoid any negative comparisons). Of
course these "better templates" are much less useful because they cannot
be used to eg. create generic containers which can support basic types
(such as ints).
I don't know how the "generics" in C# work, so maybe they are honestly
"better" there.
James Kanze
> Lynn McGuire <l...@winsim.com> wrote:
> > Interesting article on why C++ development may be fading but it
> > will never go away: http://apenwarr.ca/log/?m=201007#22
> "C++ has made templates a dirty word"
> I have never quite understood the general aversion towards C++ templates
> out there. Maybe I'm biased.
People don't like power:-).
> I find that C++ templates make writing programs simpler, not more
> complicated. Many things can be done with simple one-liners which would
> otherwise require dozens of lines of complicated code.
There are many uses of C++ templates. For things like typesafe
containers, they are exceptionally good---it's not an accident
that Java duplicated the syntax exactly (including the mistake
of using <..>, rather than some other parenthesing). For things
like metaprogramming, the obvious objection is that they weren't
really designed for it, and the syntax required quickly makes
the code unreadable. But of course, this complaint generally
comes from supporters of languages which don't have any
metaprogramming possibilities at all. In the end, nothing is
free, and in every individual case, you have to weigh the cost
(in terms of readability, etc.) of using metaprogramming vs. the
advantages (less code, often simpler to use, etc.) Sometimes,
the balance will weigh one way, other times the other. When the
balance is against metaprogramming, don't use it.
[...]
> When Java was designed as a "better C++" (which is the case, no matter
> how much Java people deny this irrefutable fact), they naturally left any
> kind of support for templates completely out because, you know, templates
> are "evil" and produce bad code.
Or perhaps because when Java was being designed, they were still
largely unknown territory. Java was designed as a "better C++"
based on the experience we had with C++ around 1990. Some of
the things it incorporates from C++ are things we later learned
were errors, to be avoided (i.e. putting the function
definitions inside the class, or having an iterator in which
access and stepping were bound up in a single function).
> Many years later they came to regret this, as a lack for any kind of
> generic code (besides what OOP offers) was a kind of limiting factor and
> produced ugly code. So rather than to succumb to the lure of C++ templates
> they introduced a "better template mechanism" (and because "template" is
> a curseword they couldn't use that name, and hence they invented a new
> name for it, namely "generics", to avoid any negative comparisons).
The name "generics" precedes that of "templates". (I don't know
why C++ chose "template", rather than "generic".)
> Of course these "better templates" are much less useful
> because they cannot be used to eg. create generic containers
> which can support basic types (such as ints).
That's part of a larger problem in Java. Java's authors clearly
recognized the need for types with value semantics, but decided
that they knew which ones you needed, for all time. A cleaner
design would have not had the built in types at all, but only
Integer and Double classes, pre-defined along the lines of
String. And operator overloading, so that you could add and
subtract them with a reasonable syntax.
> I don't know how the "generics" in C# work, so maybe they are honestly
> "better" there.
I don't know if there's a "better". Different might be a more
appropriate word. (In general---I don't know C# either.) Java
templates are very good for the problem they were designed to
solve. Almost as good as C++ templates for that problem. They
intentionally don't solve other problems. C++ templates can't
be said to have a congenial syntax for many of the
metaprogramming problems, but in the end, they're better than
nothing (which is what Java offers in this regard).
--
James Kanze
Daniel
> Some of the things [Java] incorporates from C++ are things we later learned
> were errors, to be avoided (i.e. putting the function definitions inside the
>
Not sure who are the "we", but I know a lot of people won't follow you
on that one. Do you know any more recent languages that have copied
the C++ idea of splitting the implementation of a class, putting some
of it in a "header" file and the rest in a "source" file? Do you see
an advantage in separating the class data members in one file and the
implementation in another, except for the inlined implementation which
goes in the header? This doesn't seem to me to be a particularly
useful way to organize code. More useful is to separate interface
from implementation, which is not the point of .h and .cpp.
-- Daniel
Joshua Maurice
I feel the exact same way about the word "pointer". Oh how much I
loathe talking about Java "references". They should rightfully be
called pointers. I've had several fun conversations about how all Java
functions pass by value, and people will say "nu uh!" because it's "a
reference". The object is not copied, but the reference is copied.
Modifying a parameter reference will not modify the callers reference,
but modifying the pointed-to object in the function will modify the
caller's object. This sounds a whole lot like pointers to me.
ralph
<joshua...@gmail.com> wrote:
>
>I feel the exact same way about the word "pointer". Oh how much I
>loathe talking about Java "references". They should rightfully be
>called pointers. I've had several fun conversations about how all Java
>functions pass by value, and people will say "nu uh!" because it's "a
>reference". The object is not copied, but the reference is copied.
>Modifying a parameter reference will not modify the callers reference,
>but modifying the pointed-to object in the function will modify the
>caller's object. This sounds a whole lot like pointers to me.
Java doesn't have 'pointers'. Period. Sorry that makes you ill, but it
is a simple fact. Java was deliberately designed to not have them.
The reason you think they exist in Java is because your definition is
too narrow. In general all elements of interest in computing exist
with two attributes - the block of memory that holds a value, and the
address for where that block of memory exists. In creating apps and
even languages the concept of de-referencing a value from its address
is universal. In common parlance that might be called a "pointer". But
that is only part of the story.
The other part is that a language that truly supports pointers must
also support pointer arithmetic. C and C++ support it, Java does not.
-ralph
Michael Doubez
> On Wed, 28 Jul 2010 18:48:08 -0700 (PDT), Joshua Maurice
>
>
> >I feel the exact same way about the word "pointer". Oh how much I
> >loathe talking about Java "references". They should rightfully be
> >called pointers. I've had several fun conversations about how all Java
> >functions pass by value, and people will say "nu uh!" because it's "a
> >reference". The object is not copied, but the reference is copied.
> >Modifying a parameter reference will not modify the callers reference,
> >but modifying the pointed-to object in the function will modify the
> >caller's object. This sounds a whole lot like pointers to me.
>
> Java doesn't have 'pointers'. Period.
I have not programmed in java for a long time but I clearly remember
getting a "null pointer exception".
> Sorry that makes you ill, but it
> is a simple fact. Java was deliberately designed to not have them.
What it doesn't have is pointer data types.
> The reason you think they exist in Java is because your definition is
> too narrow. In general all elements of interest in computing exist
> with two attributes - the block of memory that holds a value, and the
> address for where that block of memory exists. In creating apps and
> even languages the concept of de-referencing a value from its address
> is universal. In common parlance that might be called a "pointer". But
> that is only part of the story.
It is not in common parlance, it is the definition of the concept of
'pointer': a physical entity that refer to another.
> The other part is that a language that truly supports pointers must
> also support pointer arithmetic.
Why ? We could redesign C and C++ without pointer arithmetic (making
arrays first class object by example).
> C and C++ support it, Java does not.
Because Java cannot manipulate a type it doesn't have.
--
Michael
Michael Doubez
> On Jul 27, 9:49 am, James Kanze <james.ka...@gmail.com> wrote:> Some of the things [Java] incorporates from C++ are things we later learned
> > were errors, to be avoided (i.e. putting the function definitions inside the
> > class...).
>
> Not sure who are the "we", but I know a lot of people won't follow you
> on that one. Do you know any more recent languages that have copied
> the C++ idea of splitting the implementation of a class, putting some
> of it in a "header" file and the rest in a "source" file?
Do you know of any recent language that doesn't offer dynamic typing
and garbage collection ?
Most of them (all perhaps) are not general programming language but
tend to RAD or scripting. The paradigm are also geeraly not the same
(pure OOP and/or FP).
> Do you see
> an advantage in separating the class data members in one file and the
> implementation in another, except for the inlined implementation which
> goes in the header?
Having access to the data layout for composition, allowing cross
dependencies.
IMHO what would be an improvement would rather to be able to add non-
virtual member function outside the class defintion such that you
would not expose internal functions.
> This doesn't seem to me to be a particularly
> useful way to organize code. More useful is to separate interface
> from implementation, which is not the point of .h and .cpp.
The data layout is part of the interface. This is anathema to pure OOP
but C++ is not an OOP.
--
Michael
ralph
<michael...@free.fr> wrote:
>
>What it doesn't have is pointer data types.
>
I would have thought the light would have come on when you typed that.
>> ... In common parlance that might be called a "pointer". But
>> that is only part of the story.
>
>It is not in common parlance, it is the definition of the concept of
>'pointer': a physical entity that refer to another.
>
As such a limited definition would also include hunting dogs, I
suggest it would be obvious that something else needs to be included.
>> The other part is that a language that truly supports pointers must
>> also support pointer arithmetic.
>
>Why ? We could redesign C and C++ without pointer arithmetic (making
>arrays first class object by example).
>
You certainly could come up with a redesigned programming language
that deliberately doesn't use or allow pointers - and Java is one of
them.
>> C and C++ support it, Java does not.
>
>Because Java cannot manipulate a type it doesn't have.
Hello?
-ralph
Balog Pal
>>I feel the exact same way about the word "pointer". Oh how much I
>>loathe talking about Java "references". They should rightfully be
>>called pointers. I've had several fun conversations about how all Java
>>functions pass by value, and people will say "nu uh!" because it's "a
>>reference". The object is not copied, but the reference is copied.
>>Modifying a parameter reference will not modify the callers reference,
>>but modifying the pointed-to object in the function will modify the
>>caller's object. This sounds a whole lot like pointers to me.
>
> Java doesn't have 'pointers'. Period. Sorry that makes you ill, but it
> is a simple fact. Java was deliberately designed to not have them.
You mean the java propaganda was constructed that way. What changes reality
very little: all what java has is equivalent to the pointers in C/C++,
bringing it all the problems, and lacking even the essential tools like
const. :-((
The one thing that is actually eliminated in java is pointer math.
The point java promised was they solved the *practical problems* related to
pointers by eliminating them, that certainly did not happen. Well having
full GC eliminates *technically* dongling pointers, and a couple cases that
are UB in C/C++ lead to defined misbehavior instead. What can be viewed as
better in sense you at least don't launch nukes. Or viewed as the same as in
you get the same crap instead of the quality you desired.
Alf P. Steinbach /Usenet
> On 29 juil, 03:38, Daniel<danielapar...@gmail.com> wrote:
>> On Jul 27, 9:49 am, James Kanze<james.ka...@gmail.com> wrote:> Some of the things [Java] incorporates from C++ are things we later learned
>>> were errors, to be avoided (i.e. putting the function definitions inside the
>>> class...).
>>
>> Not sure who are the "we", but I know a lot of people won't follow you
>> on that one. Do you know any more recent languages that have copied
>> the C++ idea of splitting the implementation of a class, putting some
>> of it in a "header" file and the rest in a "source" file?
>
> Do you know of any recent language that doesn't offer dynamic typing
> and garbage collection ?
I'm inferring that you think C++ doesn't offer dynamic typing, and that you
think C++ doesn't offer garbage collection.
On the contrary, objects of polymorphic classes are dynamically typed, the
effect of many built-in operations depend on dynamic type, and even C++98
enables garbage collection (some people do use the Boehm garbage collector).
The problems with C++ lacking proper support for creating and using libraries
are well known at least by most experts. Unfortunately Daveed's module proposal,
which could at least have eased some of the problems, didn't make into the first
version of C++0x. It would also be nice with a standard for binary compatibility
of compiled code; alas, AFAIK there's no proposal.
Cheers & hth.,
- Alf
--
blog at <url: http://alfps.wordpress.com>
Alf P. Steinbach /Usenet
> On 29 juil, 06:28, ralph<nt_consultin...@yahoo.net> wrote:
>> On Wed, 28 Jul 2010 18:48:08 -0700 (PDT), Joshua Maurice
>>
>> <joshuamaur...@gmail.com> wrote:
>>
>>> I feel the exact same way about the word "pointer". Oh how much I
>>> loathe talking about Java "references". They should rightfully be
>>> called pointers. I've had several fun conversations about how all Java
>>> functions pass by value, and people will say "nu uh!" because it's "a
>>> reference". The object is not copied, but the reference is copied.
>>> Modifying a parameter reference will not modify the callers reference,
>>> but modifying the pointed-to object in the function will modify the
>>> caller's object. This sounds a whole lot like pointers to me.
>>
>> Java doesn't have 'pointers'. Period.
>
> I have not programmed in java for a long time but I clearly remember
> getting a "null pointer exception".
That is correct. In addition, the Java language specification employs the term
"pointer". Ralph is simply uninformed.
Ian Collins
> * Michael Doubez, on 29.07.2010 09:41:
>> On 29 juil, 03:38, Daniel<danielapar...@gmail.com> wrote:
>>> On Jul 27, 9:49 am, James Kanze<james.ka...@gmail.com> wrote:> Some
>>> of the things [Java] incorporates from C++ are things we later learned
>>>> were errors, to be avoided (i.e. putting the function definitions
>>>> inside the
>>>> class...).
>>>
>>> Not sure who are the "we", but I know a lot of people won't follow you
>>> on that one. Do you know any more recent languages that have copied
>>> the C++ idea of splitting the implementation of a class, putting some
>>> of it in a "header" file and the rest in a "source" file?
>>
>> Do you know of any recent language that doesn't offer dynamic typing
>> and garbage collection ?
>
> I'm inferring that you think C++ doesn't offer dynamic typing, and that
> you think C++ doesn't offer garbage collection.
>
> On the contrary, objects of polymorphic classes are dynamically typed,
> the effect of many built-in operations depend on dynamic type, and even
> C++98 enables garbage collection (some people do use the Boehm garbage
> collector).
It's also not too hard to hard to implement scripting language style
dynamic typing. I'd just written this
Object object;
object["name"] = "fred";
object["size"] = 10L;
object["hasChildren"] = false;
object["attributes"]["sub"]["name"] = "child";
(which could be PHP or even JavaScript) when I read your post!
--
Ian Collins
James Kanze
> On Jul 27, 9:49 am, James Kanze <james.ka...@gmail.com>
> wrote:> Some of the things [Java] incorporates from C++ are
> things we later learned
> > were errors, to be avoided (i.e. putting the function definitions inside the
> > class...).
> Not sure who are the "we",
Software engineers, concerned with reliably developing code on
large projects.
> but I know a lot of people won't follow you
> on that one. Do you know any more recent languages that have copied
> the C++ idea of splitting the implementation of a class, putting some
> of it in a "header" file and the rest in a "source" file?
Do you know of any recent language that is designed for large
scale software development, as opposed to animating web pages or
the like?
This is a serious question. I'm not familiar with all recent
languages, but the ones I do know are mostly scripting
languages, or only slightly above, and are not suited for large
scale development. The most recent languages I've seen designed
for large scale development are C++ and Ada 95, and Ada 95 has
an even stricter separation than C++.
> Do you see an advantage in separating the class data members
> in one file and the implementation in another, except for the
> inlined implementation which goes in the header?
Different people work on them. Also, most build systems have
file level granularity; you don't want a change in the
implementation to trigger a recompilation of all of the client
code.
> This doesn't seem to me to be a particularly
> useful way to organize code. More useful is to separate interface
> from implementation, which is not the point of .h and .cpp.
The separation could be better. Much better. (There's
a proposal to add modules to C++.) For example, it would be
better (although perhaps hard to implement) if the private part
of a class wasn't in the header file. The use of textual
inclusion for the separation of interface from implementation is
a hack. It works, sort of, but there are clearly better
solutions (e.g. Modula-2 or Ada). But it's also better than
nothing at all.
--
James Kanze
Michael Doubez
+use...@gmail.com> wrote:
> * Michael Doubez, on 29.07.2010 09:41:
>
> > On 29 juil, 03:38, Daniel<danielapar...@gmail.com> wrote:
> >> On Jul 27, 9:49 am, James Kanze<james.ka...@gmail.com> wrote:> Some of the things [Java] incorporates from C++ are things we later learned
> >>> were errors, to be avoided (i.e. putting the function definitions inside the
> >>> class...).
>
> >> Not sure who are the "we", but I know a lot of people won't follow you
> >> on that one. Do you know any more recent languages that have copied
> >> the C++ idea of splitting the implementation of a class, putting some
> >> of it in a "header" file and the rest in a "source" file?
>
> > Do you know of any recent language that doesn't offer dynamic typing
> > and garbage collection ?
>
> I'm inferring that you think C++ doesn't offer dynamic typing, and that you
> think C++ doesn't offer garbage collection.
The language doesn't offer it (not yet for garbage collection). I
didn't say it couldn't be implemented. AFAIK C++ is still a strong
typed language.
>
> On the contrary, objects of polymorphic classes are dynamically typed, the
> effect of many built-in operations depend on dynamic type, and even C++98
> enables garbage collection (some people do use the Boehm garbage collector).
>
> The problems with C++ lacking proper support for creating and using libraries
> are well known at least by most experts. Unfortunately Daveed's module proposal,
> which could at least have eased some of the problems, didn't make into the first
> version of C++0x.
Yes, it would have been nice. I also would like to see support for
plugin .
> It would also be nice with a standard for binary compatibility
> of compiled code; alas, AFAIK there's no proposal.
Well, we already have better memory layout guarantees in c++0x with
standard-layout and layout-compatible.
--
Michael
James Kanze
> On Wed, 28 Jul 2010 18:48:08 -0700 (PDT), Joshua Maurice
> <joshuamaur...@gmail.com> wrote:
> >I feel the exact same way about the word "pointer". Oh how much I
> >loathe talking about Java "references". They should rightfully be
> >called pointers. I've had several fun conversations about how all Java
> >functions pass by value, and people will say "nu uh!" because it's "a
> >reference". The object is not copied, but the reference is copied.
> >Modifying a parameter reference will not modify the callers reference,
> >but modifying the pointed-to object in the function will modify the
> >caller's object. This sounds a whole lot like pointers to me.
> Java doesn't have 'pointers'.
But it does have a NullPointerException. The authors of Java
obviously felt that it had pointers.
> Period. Sorry that makes you ill, but it is a simple fact.
> Java was deliberately designed to not have them.
Java was deliberately specified not to use the word pointer.
A reference in Java, however, is more like a pointer in C++ than
it is like a reference. And it corresponds to the usual use of
the word pointer in computer science.
[...]
> The other part is that a language that truly supports pointers
> must also support pointer arithmetic.
Why? Pascal and company had "pointers", but no pointer
arithmetic. PL/1 had pointers (long before there was C), but
I don't think it had pointer arithmetic. Ada has pointers
(declared using the keyword "access"), but no pointer
arithmetic. In fact, C and C++ are about the only languages
I know which support pointer arithmetic.
--
James Kanze
Michael Doubez
> On Thu, 29 Jul 2010 00:32:36 -0700 (PDT), Michael Doubez
>
>
> >What it doesn't have is pointer data types.
>
> I would have thought the light would have come on when you typed that.
And the reverse is true: it doesn't have pointer *data type* but it
does have pointer that the marketing relabeled /reference/.
Formally, a reference is a little broader than a pointer: it is a name
that alias something (and I don't speak only of the C++ definition):
it doesn't necessarily have a physical representation.
As an example, a reference to an object is its address while a pointer
to an object is the memory location where you store the address.
That's why you can have NULL pointer but not NULL reference (and Java
has null).
> >> ... In common parlance that might be called a "pointer". But
> >> that is only part of the story.
>
> >It is not in common parlance, it is the definition of the concept of
> >'pointer': a physical entity that refer to another.
>
> As such a limited definition would also include hunting dogs, I
> suggest it would be obvious that something else needs to be included.
Limited ? It is already pretty broad; and my definition already
include Java's mecanism.
> >> The other part is that a language that truly supports pointers must
> >> also support pointer arithmetic.
>
> >Why ? We could redesign C and C++ without pointer arithmetic (making
> >arrays first class object by example).
>
> You certainly could come up with a redesigned programming language
> that deliberately doesn't use or allow pointers - and Java is one of
> them.
I didn't say I could redesign C or C++ without pointer data type, just
that I could remove pointer arithmetic allowing only affectation of
pointer ... like in Java.
--
Michael
Alf P. Steinbach /Usenet
> On 29 juil, 11:23, "Alf P. Steinbach /Usenet"<alf.p.steinbach
> +use...@gmail.com> wrote:
>> * Michael Doubez, on 29.07.2010 09:41:
>>
>>> On 29 juil, 03:38, Daniel<danielapar...@gmail.com> wrote:
>>>> On Jul 27, 9:49 am, James Kanze<james.ka...@gmail.com> wrote:> Some of the things [Java] incorporates from C++ are things we later learned
>>>>> were errors, to be avoided (i.e. putting the function definitions inside the
>>>>> class...).
>>
>>>> Not sure who are the "we", but I know a lot of people won't follow you
>>>> on that one. Do you know any more recent languages that have copied
>>>> the C++ idea of splitting the implementation of a class, putting some
>>>> of it in a "header" file and the rest in a "source" file?
>>
>>> Do you know of any recent language that doesn't offer dynamic typing
>>> and garbage collection ?
>>
>> I'm inferring that you think C++ doesn't offer dynamic typing, and that you
>> think C++ doesn't offer garbage collection.
>
> The language doesn't offer it (not yet for garbage collection). I
> didn't say it couldn't be implemented. AFAIK C++ is still a strong
> typed language.
You're conflating strong/weak typing with static/dynamic typing.
Those concepts are orthogonal.
You can have strong dynamic typing, strong static typing, weak dynamic typing or
weak static typing as the main typing scheme of a language. Also, most languages
that are statically typed include some dynamic typing, which is so for C++, Java
and C# (which means that the classification is to some degree subjective for
static/dynamic, hence "main typing scheme"; for weak versus strong the
classification is in the main subjective, depending on priorities, and it can be
a bit mixed-up depending on what aspects of a language that one considers, which
is so for C++: it's both strongly and weakly typed). Some languages that are
dynamically typed also include some static typing.
>> On the contrary, objects of polymorphic classes are dynamically typed, the
>> effect of many built-in operations depend on dynamic type, and even C++98
>> enables garbage collection (some people do use the Boehm garbage collector).
>>
>> The problems with C++ lacking proper support for creating and using libraries
>> are well known at least by most experts. Unfortunately Daveed's module proposal,
>> which could at least have eased some of the problems, didn't make into the first
>> version of C++0x.
>
> Yes, it would have been nice. I also would like to see support for
> plugin .
>
>> It would also be nice with a standard for binary compatibility
>> of compiled code; alas, AFAIK there's no proposal.
>
> Well, we already have better memory layout guarantees in c++0x with
> standard-layout and layout-compatible.
Yes, but it doesn't define an ABI.
There is a 32-bit ABI definition from Intel, I believe.
But it doesn't even make it to de-facto standard.
Alf P. Steinbach /Usenet
> On Jul 29, 5:28 am, ralph<nt_consultin...@yahoo.net> wrote:
>> On Wed, 28 Jul 2010 18:48:08 -0700 (PDT), Joshua Maurice
>
>> <joshuamaur...@gmail.com> wrote:
>
>>> I feel the exact same way about the word "pointer". Oh how much I
>>> loathe talking about Java "references". They should rightfully be
>>> called pointers. I've had several fun conversations about how all Java
>>> functions pass by value, and people will say "nu uh!" because it's "a
>>> reference". The object is not copied, but the reference is copied.
>>> Modifying a parameter reference will not modify the callers reference,
>>> but modifying the pointed-to object in the function will modify the
>>> caller's object. This sounds a whole lot like pointers to me.
>
>> Java doesn't have 'pointers'.
>
> But it does have a NullPointerException. The authors of Java
> obviously felt that it had pointers.
>
>> Period. Sorry that makes you ill, but it is a simple fact.
>> Java was deliberately designed to not have them.
>
> Java was deliberately specified not to use the word pointer.
No, Java was deliberately specified to use the word pointer. :-)
Pete Becker
>
> Java doesn't have 'pointers'. Period. Sorry that makes you ill, but it
> is a simple fact. Java was deliberately designed to not have them.
>
Why, then, does it have a NullPointerException type?
--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)
Juha Nieminen
> I feel the exact same way about the word "pointer". Oh how much I
> loathe talking about Java "references". They should rightfully be
> called pointers. I've had several fun conversations about how all Java
> functions pass by value, and people will say "nu uh!" because it's "a
> reference". The object is not copied, but the reference is copied.
> Modifying a parameter reference will not modify the callers reference,
> but modifying the pointed-to object in the function will modify the
> caller's object. This sounds a whole lot like pointers to me.
AFAIK (I'm not a Java programmer) there are significant differences
between C/C++ pointers and Java references.
C++ pointers are more tied to low-level memory addresses. You can
perform pointer arithmetic to them (eg. "pointer+1" to get a pointer
to the next element in an array pointed by 'pointer') and you can
unambiguously and consistently compare pointers (in standard C++ at
least with std::less and the other comparison templates). ("Consistently"
in this case means that if you compare two pointers now and the same
pointers one minute from now, you will get the same result.) Because C++
pointers are basically memory addresses, this allows casting a pointer
of one type to a different type (if you are doing a reinterpret-cast,
then the memory address doesn't change).
There are both advantages and disadvantages to equating pointers with
memory addresses in C/C++. It allows more low-level flexibility when
dealing with raw memory and performing other tricks (such as xor-lists),
but on the other hand it makes it more rigid with respect to the memory
allocator (making it more difficult to implement things like garbage
collectors and memory compactors in a fool-proof way).
Java references are much more abstract. They are not tied to a specific
memory address, you can't compare them (other than for equality, I think),
you cannot cast them to incompatible types and obviously you cannot perform
pointer arithmetic.
AFAIK it's possible for a reference to be "pointing" to one memory
location at one moment, and a minute later the memory management system
having changed it to "point" to a completely different location (completely
transparently from the program's point of view). This allows things like
memory compaction (which is good for cache optimization and other things).
This is not possible in C++ because of the raw wild memory pointers.
Juha Nieminen
> Why, then, does it have a NullPointerException type?
Just because a null reference is the same as a null pointer doesn't
mean that *all* references are the same as pointers.
Pete Becker
Umm, I must be mssing something. The claim that I replied to (which you
snipped) was that Java does not have pointers. Having a
NullPointerException certainly suggests that there is such a thing as a
null pointer and, hence, a pointer. Which, in turn, conflicts with the
claim that I replied to (which you snipped).
Daniel
>
> Do you know of any recent language that is designed for large
> scale software development, as opposed to animating web pages or
> the like?
>
development, including massively parrallel applications, and yes,
having followed your excellent posts for years (mostly ten years back,
and by the way, how come you're not in that other newsgroup anymore?)
I know you won't agree with "designed for." But it's a fact that
they're widely used.
But consider. There are lots of areas where there were competing
vendor server products, one written in Java and the other in C++,
where the Java one thrashed the C++ one, e.g. WebLogic versus the
Sybase web server. There are lots of spaces where a suite of Java or
C# server apps have displaced an older suite of C++ apps, for example,
in finance, SunGard Adaptive Analytics (C#) and Calypso (Java) versus
the older C++ products like Mysis Carma or SunGard Infinity. In
telecommunications in the 90s, Java server products were displacing C+
+ products.
Simplicity of development and maintenance is an important part of
suitability for large scale software development, and other languages
have that in spades over C++.
What brought me back to C++ recently is the opposite, writing small
scale numerical calulators for use within other environments.
-- Daniel
Alf P. Steinbach /Usenet
You're wrong. The Java language specification says they are.
Keith H Duggar
> On Jul 29, 2:38 am, Daniel <danielapar...@gmail.com> wrote:
> > Do you see an advantage in separating the class data members
> > in one file and the implementation in another, except for the
> > inlined implementation which goes in the header?
>
> Different people work on them. Also, most build systems have
> file level granularity; you don't want a change in the
> implementation to trigger a recompilation of all of the client
> code.
Exactly. Joshua Maurice and I were just discussing this in
another thread. Apparently the forced conflation of interface
and implementation into the same file really bones Java build
systems. Score another point for the C++ separate compilation
model. It may not be perfect but it's much better than Java's
design for large projects. Worse is Better for the win.
KHD
Michael Doubez
> On 2010-07-29 08:44:13 -0400, Juha Nieminen said:
>
> >> Why, then, does it have a NullPointerException type?
>
> > Just because a null reference is the same as a null pointer doesn't
> > mean that *all* references are the same as pointers.
>
> Umm, I must be mssing something. The claim that I replied to (which you
> snipped) was that Java does not have pointers. Having a
> NullPointerException certainly suggests that there is such a thing as a
> null pointer and, hence, a pointer. Which, in turn, conflicts with the
> claim that I replied to (which you snipped).
>
From Java Sun website:
http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#106237
4.3.1 Objects
An object is a class instance or an array.
The reference values (often just references) *are pointers* to these
objects, and a special null reference, which refers to no object.
[...]
Well, IMO, it makes it pretty clear that Java's reference are pointer.
--
Michael
Öö Tiib
> On Jul 29, 6:28 am, James Kanze <james.ka...@gmail.com> wrote:
>
> > Do you know of any recent language that is designed for large
> > scale software development, as opposed to animating web pages or
> > the like?
>
> Sure. Both Java and C# are widely used for large scale software
> development, including massively parrallel applications, and yes,
> having followed your excellent posts for years (mostly ten years back,
> and by the way, how come you're not in that other newsgroup anymore?)
> I know you won't agree with "designed for." But it's a fact that
> they're widely used.
C# is not "designed". "Plagiarized from java" is fair word there in
every spoken language i know. Java is designed.
> But consider. There are lots of areas where there were competing
> vendor server products, one written in Java and the other in C++,
> where the Java one thrashed the C++ one, e.g. WebLogic versus the
> Sybase web server. There are lots of spaces where a suite of Java or
> C# server apps have displaced an older suite of C++ apps, for example,
> in finance, SunGard Adaptive Analytics (C#) and Calypso (Java) versus
> the older C++ products like Mysis Carma or SunGard Infinity.
Hmm ... but these are exactly "animating web pages or the like" and
"pretend smart but throw dice secretly at background" areas that James
did not include as large scale development. I always suspected it as
reason why world finances did collapse. They did push usage of such
terrible tools in finances, nothing good could come out. Then
outsourced to India and at that spot sane clients took their money
out. What was left did collapse.
> Simplicity of development and maintenance is an important part of
> suitability for large scale software development, and other languages
> have that in spades over C++.
Seriously? Most unmaintainable piece of code i have seen during last
25 years was written in C#. Simple was it maybe for authors to write,
but maintainability was between "no chance" and "impossible". You are
perhaps under illusion that programming languages write software not
people?
Daniel
> On Jul 29, 6:28 am, James Kanze <james.ka...@gmail.com> wrote:
>
> > Different people work on them. Also, most build systems have
> > file level granularity; you don't want a change in the
> > implementation to trigger a recompilation of all of the client
> > code.
>
> and implementation into the same file really bones Java build
> systems. Score another point for the C++ separate compilation
> model. It may not be perfect but it's much better than Java's
> design for large projects.
>
C++ code base, but my recollection is that it took hours, even after
reducing it considerably with precompiled headers and other tweaks.
This compared with minutes for a Java code base of similar size. I
don't think this is a unique observation, and issues with build times
may be of special significance to C++ developers, as compared to other
languages.
Issues with maintenance and rebuilding have more to do with how
dependencies are structured than the .h/.cpp division. And to note,
it is not correct that C++ header files represent interface, they are
as much implementation as interface - including all the private bits.
These are not infrequently affected by maintenance.
With both C++ and Java, genuine separation of interface and
implementation requires careful attention to design, but I would
suggest that the .h/.cpp separation doesn't particularly help, that's
just distributing implementation.
-- Daniel
Daniel
>
> Seriously? Most unmaintainable piece of code i have seen during last
> 25 years was written in C#. Simple was it maybe for authors to write,
> but maintainability was between "no chance" and "impossible". You are
> perhaps under illusion that programming languages write software not
> people?
Nope :-) On the contrary, I am under the impression that it is
possible to write unmaintainable code in any language. Some of the
worst code I have ever seen was written in Old Fortran - goto here,
goto there, goto everywhere - and some of the most elegent code I have
ever seen was also written in Old Fortran, inspired to make the most
of the six character limit to variable and function names.
But ... I think it's fair to state that C++ as it has evolved is
probably not a good model for a more modern language, it's too
complicated, too ad hoc, too mixed up, and I don't think these
characteristics help with maintenance or productivity.
-- Daniel
Balog Pal
>> Different people work on them. Also, most build systems have
>> file level granularity; you don't want a change in the
>> implementation to trigger a recompilation of all of the client
>> code.
>Exactly. Joshua Maurice and I were just discussing this in
>another thread. Apparently the forced conflation of interface
>and implementation into the same file really bones Java build
>systems.
Do they now? The last time I saw a large system, it made full compilation
of several thousand java files faster than just a few C++ ones.
>Score another point for the C++ separate compilation
>model.
I actually like "separation" in theory, but not the imitation we have in
C++, that requires copy/pasting, redundancy -- and for practical reason you
still need plenty of code in the headers (templates, inline funcitions).
And if you shoot for real separation you must pImpl, that again is a sad
story.
While with all the theoretic separation my mundane modules pick up over
million lines from headers. :-( to be redundantly parsed and
code-generated. (Try doing anything with gtkmm... :-( )
The real speed of compilation for C++ became intolerably slow compared to
anything else. Precompiled headers help somewhat, but using them creates
even more cross-dependencies.
>It may not be perfect but it's much better than Java's
>design for large projects. Worse is Better for the win.
IMO the unfit-ness of java for large (or whatever serious) development comes
from a different set of reasons.
Keith H Duggar
> On Jul 29, 10:37 am, Keith H Duggar <dug...@alum.mit.edu> wrote:> On Jul 29, 6:28 am, James Kanze <james.ka...@gmail.com> wrote:
>
> > > Different people work on them. Also, most build systems have
> > > file level granularity; you don't want a change in the
> > > implementation to trigger a recompilation of all of the client
> > > code.
>
> > Exactly ... Apparently the forced conflation of interface
> > and implementation into the same file really bones Java build
> > systems. Score another point for the C++ separate compilation
> > model. It may not be perfect but it's much better than Java's
> > design for large projects.
>
> It's been some time since I've had the opportunity of building a large
> C++ code base, but my recollection is that it took hours, even after
> reducing it considerably with precompiled headers and other tweaks.
> This compared with minutes for a Java code base of similar size. I
> don't think this is a unique observation, and issues with build times
> may be of special significance to C++ developers, as compared to other
> languages.
It's also an irrelevant observation because it compares compilation
of different languages. An accurate comparison is instead between
compiling a header-only implementation of some C++ versus one that
separates .hpp/.cpp. And for Java comparing the time of compiling
only the files that must be compiled due to interface changes vs
compiling all files that import the changed file even if interface
was not changed.
> Issues with maintenance and rebuilding have more to do with how
> dependencies are structured than the .h/.cpp division. And to note,
> it is not correct that C++ header files represent interface, they are
> as much implementation as interface - including all the private bits.
> These are not infrequently affected by maintenance.
Sure. The point is that it is /possible/ to separate some and even
all (for example pure abstract functions, pimpl, etc) implementation
away from the interface. This is simply not possible in Java since
you are /forced/ to conflate implementation and interface in the
same file.
> With both C++ and Java, genuine separation of interface and
> implementation requires careful attention to design, but I would
> suggest that the .h/.cpp separation doesn't particularly help, that's
> just distributing implementation.
Nearly anyone who has worked on large projects knows all too well
that judicious removal of code from headers (function code, pimpl,
explicit template instantiation, etc) can reduce C++ compile times
IMMENSELY. So I'm really not sure what planet you are working on.
KHD
Balog Pal
"Keith H Duggar" <dug...@alum.mit.edu>
>> It's been some time since I've had the opportunity of building a large
>> C++ code base, but my recollection is that it took hours, even after
>> reducing it considerably with precompiled headers and other tweaks.
>> This compared with minutes for a Java code base of similar size. I
>> don't think this is a unique observation, and issues with build times
>> may be of special significance to C++ developers, as compared to other
>> languages.
>It's also an irrelevant observation because it compares compilation
>of different languages.
How could it be irrelevant? Compilation time is a practical matter, nothing
else. It a full rebuild would take just milliseconds, who would bother at
all?
As long as a full rebuild of java still takes a magnitude more than a
fine-tuned C++ system, arguments about superiority of the latter will hardly
win. ;-)
>An accurate comparison is instead between
>compiling a header-only implementation of some C++ versus one that
>separates .hpp/.cpp. And for Java comparing the time of compiling
>only the files that must be compiled due to interface changes vs
>compiling all files that import the changed file even if interface
>was not changed.
Possibly could make a PhD thesis and impress a some folks who only know
build from books... Not anyone from practice.
>Sure. The point is that it is /possible/ to separate some and even
>all (for example pure abstract functions, pimpl, etc) implementation
>away from the interface. This is simply not possible in Java since
>you are /forced/ to conflate implementation and interface in the
>same file.
I'm light on java, but I saw people using 'interface' alot. That is
certainly pure. And does a plenty of separation too. And compiles separately
too using your terms. Is anything preventing to do all the job through
interfaces? Stating that any implementation of the interface is considered
private stuff?
>Nearly anyone who has worked on large projects knows all too well
>that judicious removal of code from headers (function code, pimpl,
>explicit template instantiation, etc) can reduce C++ compile times
>IMMENSELY. So I'm really not sure what planet you are working on.
At a really steep cost -- and leaving that immensly reduced time still
pretty high.
Öö Tiib
>
> But ... I think it's fair to state that C++ as it has evolved is
> probably not a good model for a more modern language, it's too
> complicated, too ad hoc, too mixed up, and I don't think these
> characteristics help with maintenance or productivity.
>
Current trend is that no one writes C++ fully, it is too anarchistic
language. Instead developers write C++ as certain agreed upon subset
of it. Even tools are made/embedded into process that warn against
deviation from such policies.
That makes C++ lot less complicated and mixed up language really.
Other factor that helps with productivity of C++ is presence of
powerful non-standard/niche libraries. In Java and C# it is also
possible to use native libraries written in C or C++ but the
performance gain is lower since the context switch is slow also there
are difficulties to debug library code.
Writing yet another clone of something that is already there on well
tested platform is perhaps simpler with java, writing new things to
new grounds is always simpler with C++.
Daniel
>
>
> > But consider. There are lots of areas where there were competing
> > vendor server products, one written in Java and the other in C++,
> > where the Java one thrashed the C++ one, e.g. WebLogic versus the
> > Sybase web server. There are lots of spaces where a suite of Java or
> > C# server apps have displaced an older suite of C++ apps, for example,
> > in finance, SunGard Adaptive Analytics (C#) and Calypso (Java) versus
> > the older C++ products like Mysis Carma or SunGard Infinity.
>
> Hmm ... but these are exactly "animating web pages or the like" and
> "pretend smart but throw dice secretly at background" areas that James
> did not include as large scale development.
Well, if you include massively scalable applications that run 24/7 or
24/6, that support massive simulations of millions of scenarios over a
grid, that support hundreds of users OLTP or DP dispersed
geographically over a number of continents, if you count all that as
"animating web pages or the like", I really don't know what to
say :-) I choose finance examples because I know them, but you could
pick examples in any industry including telco, energy, transportation,
etc, not too mention tooling coming out of Oracle and IBM. Java has
moved into the server space in a big way over the last decade, and C#
is making inroads too. It's factually incorrect to suggest otherwise.
Do some of the Java and C# server apps and tooling have issues? Yes.
Did some of the C++ sever apps that they displaced also have issues?
Yes. In most cases these are broad architectural design issues that
vendors screwed up, though, rather than language issues.
-- Daniel
Daniel
> Nearly anyone who has worked on large projects knows all too well
> that judicious removal of code from headers (function code, pimpl,
> explicit template instantiation, etc) can reduce C++ compile times
> IMMENSELY.
Of course, but that's a practical detail about C++ and its include
model. The context for this sub-thread was whether more modern
languages would benefit from the C++ style .h/.cpp separation, but
more modern languages don't follow the C++ include model.
-- Daniel
Alf P. Steinbach /Usenet
>
> Nearly anyone who has worked on large projects knows all too well
> that judicious removal of code from headers (function code, pimpl,
> explicit template instantiation, etc) can reduce C++ compile times
> IMMENSELY.
This is true. But it's like being at a football stadium and everybody in the
first row rise up, leaving those in second row with no choice but to stand up,
leaving those in third row with no choice but to stand up, and so on. I'm
talking about a lack of proper separation of concerns and lack of proper
knowledge distribution(design), which means that the typical source code file
has to include tons of unnecessary code in order to get the little that it
really needs -- even with the judicious removal of code...
Cheers,
- Alf (not sure of practicality of proper design in large project)
Joshua Maurice
Well, not to muck up this thread, but I was merely arguing that a file
level dependency graph, where an out of date node forces a rebuild of
everything downstream, aka the Make model, does not work well if you
want incremental Java compilation. This is because Java has
"interface" and "implementation" in the same file. (It's also because
the common operating procedure for Java programmers is to possibly
have circular references in the same compilation dir, to use other
Java names from the same compilation dir and not specify these
dependencies anywhere apart from the actual Java source, and so on.) I
did, however, note that there are approaches to do quite good
incremental Java builds, but I had to write my own tool to do so, and
I had to use some Sun-javac standard, not Java standard, APIs to get
the equivalent of gcc -M.
I'm not actually sure which approach is better. When headers can
include headers, it's a lot of maintenance using pImpl and keeping the
transitive header dependencies low compared to what you have to do in
Java. In Java, I think no actual change is needed to standard
operating procedure; no maintenance is required to make sure you have
the proper separation of "interface" and "implementation" nor manual
work to keep down on transitive header dependencies. I might \guess\
that Java's compilation model is a better one for developers (barring
implementation concerns for the compiler and build system). However,
for Java, someone needs to write the incremental build system (or use
mine if I ever get it finished and open sourced from my company) as no
one has done this yet for a command line general purpose build system
like Make or Ant (and one really can't do it on top of Make).
More information is available in the other thread. Please feel free to
take any other build comments there:
Build systems (was Re: No unanswered question)
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/c830c7c07951f4a6#
Finally, I don't quite see how you can hack a Java style compilation
model onto C++. It seems like quite a big change. Can anyone point me
to a / the C++ module proposal, or walk me through the rough idea?
James Kanze
> On Jul 29, 6:28 am, James Kanze <james.ka...@gmail.com> wrote:
> > Do you know of any recent language that is designed for
> > large scale software development, as opposed to animating
> > web pages or the like?
> Sure. Both Java and C# are widely used for large scale
> software development, including massively parrallel
> applications,
Hmmm. I know of more than one company that have tried using
Java for large scale applications, and have given up. (In this
case, large scale is measured in terms of quantity of code.)
> But consider. There are lots of areas where there were competing
> vendor server products, one written in Java and the other in C++,
> where the Java one thrashed the C++ one, e.g. WebLogic versus the
> Sybase web server.
Most successful Web servers use a mixture of languages. Java is
very successful for the front end interface: a small, frequently
changing program.
> There are lots of spaces where a suite of Java or C# server
> apps have displaced an older suite of C++ apps, for example,
> in finance, SunGard Adaptive Analytics (C#) and Calypso (Java)
> versus the older C++ products like Mysis Carma or SunGard
> Infinity. In telecommunications in the 90s, Java server
> products were displacing C+ + products.
In the telecommunications projects I worked on, Java was used
for the user interfaces, but not much else.
> Simplicity of development and maintenance is an important part of
> suitability for large scale software development, and other languages
> have that in spades over C++.
Do they? I'm sure some do (Ada 95, perhaps), but Java doesn't.
Once you get beyond two or three programmers, managing a project
in Java becomes a nightmare.
> What brought me back to C++ recently is the opposite, writing
> small scale numerical calulators for use within other
> environments.
What's kept me in C++ is large scale projects, where reliability
was important.
--
James Kanze
Öö Tiib
> On Jul 29, 11:27 am, Öö Tiib <oot...@hot.ee> wrote:
>
> > On 29 juuli, 16:20, Daniel <danielapar...@gmail.com> wrote:
>
> > > But consider. There are lots of areas where there were competing
> > > vendor server products, one written in Java and the other in C++,
> > > where the Java one thrashed the C++ one, e.g. WebLogic versus the
> > > Sybase web server. There are lots of spaces where a suite of Java or
> > > C# server apps have displaced an older suite of C++ apps, for example,
> > > in finance, SunGard Adaptive Analytics (C#) and Calypso (Java) versus
> > > the older C++ products like Mysis Carma or SunGard Infinity.
>
> > Hmm ... but these are exactly "animating web pages or the like" and
> > "pretend smart but throw dice secretly at background" areas that James
> > did not include as large scale development.
>
> Well, if you include massively scalable applications that run 24/7 or
> 24/6, that support massive simulations of millions of scenarios over a
> grid, that support hundreds of users OLTP or DP dispersed
> geographically over a number of continents, if you count all that as
> "animating web pages or the like", I really don't know what to
> say :-)
:-D Think. It just can not be the applications really run all these
scenarios and all that crap you say and outcome is simply something as
detrimental as collapse of the institutions themselves and worldwide
economy in tail of those. So something is fake there and the thing
only animates pre-made web pages to the poor users for to look
smart. :-)
> I choose finance examples because I know them, but you could
> pick examples in any industry including telco, energy, transportation,
> etc, not too mention tooling coming out of Oracle and IBM. Java has
> moved into the server space in a big way over the last decade, and C#
> is making inroads too. It's factually incorrect to suggest otherwise.
No, java and C# are fine languages. I was somewhat jokingly dodging
back, because you miss the mark of real problems with C++.
Imagine ... say you are that usual good-for-nothing fatso teaching in
universities ... do you teach something that is told to be noob
friendly or do you teach something that is told to be complex? Now
imagine that you are the other fatso who wants papers from university
that he did study something ... do you learn something that is told to
be newbie-hand-holding-friendly or do you learn something that is told
to be difficult? We can not lie to fatsos, C++ is indeed more feature-
rich and complex to learn (and to teach) than most other languages.
There it goes, fatsos wish it dead.
C++ lives so well *only* because it is almost unavoidable necessity in
so lot of situations. Everything tries to slag it off, tear down or
discriminate, but in vain. If you need power ... then you need it,
nothing to do. It takes more than year of very hard beating to get
livable C++ out of former Javascript or Vis-basic guy but again ...
sometimes there's nothing to do but cream the fatsos. ;-)
> Do some of the Java and C# server apps and tooling have issues? Yes.
> Did some of the C++ sever apps that they displaced also have issues?
> Yes. In most cases these are broad architectural design issues that
> vendors screwed up, though, rather than language issues.
In most modern programming languages you can write *almost* anything.
All issues are always since people in charge did not timely realize
where true bottlenecks and problems are and once they realized it then
they did not manage to repair the screw-up.
Ian Collins
> On Jul 29, 2:20 pm, Daniel<danielapar...@gmail.com> wrote:
>> On Jul 29, 6:28 am, James Kanze<james.ka...@gmail.com> wrote:
>
>>> Do you know of any recent language that is designed for
>>> large scale software development, as opposed to animating
>>> web pages or the like?
>
>> Sure. Both Java and C# are widely used for large scale
>> software development, including massively parrallel
>> applications,
>
> Hmmm. I know of more than one company that have tried using
> Java for large scale applications, and have given up. (In this
> case, large scale is measured in terms of quantity of code.)
>
>> But consider. There are lots of areas where there were competing
>> vendor server products, one written in Java and the other in C++,
>> where the Java one thrashed the C++ one, e.g. WebLogic versus the
>> Sybase web server.
>
> Most successful Web servers use a mixture of languages. Java is
> very successful for the front end interface: a small, frequently
> changing program.
At this point, those of us who have had to configure and maintain Tomcat
run screaming from the room!
I used to write all of the sever side code in my web applications in
PHP, but now all of the required library components, I've gone back to
using C++.
--
Ian Collins
Ian Collins
> On Jul 29, 10:37 am, Keith H Duggar<dug...@alum.mit.edu> wrote:
>> On Jul 29, 6:28 am, James Kanze<james.ka...@gmail.com> wrote:
>>
>>> Different people work on them. Also, most build systems have
>>> file level granularity; you don't want a change in the
>>> implementation to trigger a recompilation of all of the client
>>> code.
>>
>> Exactly ... Apparently the forced conflation of interface
>> and implementation into the same file really bones Java build
>> systems. Score another point for the C++ separate compilation
>> model. It may not be perfect but it's much better than Java's
>> design for large projects.
>>
> It's been some time since I've had the opportunity of building a large
> C++ code base, but my recollection is that it took hours, even after
> reducing it considerably with precompiled headers and other tweaks.
> This compared with minutes for a Java code base of similar size. I
> don't think this is a unique observation, and issues with build times
> may be of special significance to C++ developers, as compared to other
> languages.
One reason is the output of a C++ build is the fully cooked application
where the output form Java compilation is like those part baked breads
supermarkets sell. The consumer has to take them home and finish the job!
> Issues with maintenance and rebuilding have more to do with how
> dependencies are structured than the .h/.cpp division. And to note,
> it is not correct that C++ header files represent interface, they are
> as much implementation as interface - including all the private bits.
> These are not infrequently affected by maintenance.
True, but they also act as documentation of the interface. I often end
up creating an interface for a PHP class just so I can see all the
member function declarations in one place.
> With both C++ and Java, genuine separation of interface and
> implementation requires careful attention to design, but I would
> suggest that the .h/.cpp separation doesn't particularly help, that's
> just distributing implementation.
Fair enough.
--
Ian Collins
Öö Tiib
>
> Finally, I don't quite see how you can hack a Java style compilation
> model onto C++. It seems like quite a big change. Can anyone point me
> to a / the C++ module proposal, or walk me through the rough idea?
Roughly:
Every module or library has (should have) a unique namespace. Add two
operations:
1) You can mark stuff as exported from namespace. That stuff is
interface of module.
2) When someone imports that modules namespace then he gets stuff
declared that the namespace did export without preprocessor involved.
More details-shmetails and so on. I did really hate the proposed bit-
shift-like semantics but otherwise it felt good idea.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1778.pdf
Daniel
> At this point, those of us who have had to configure and maintain Tomcat
> run screaming from the room!
>
No argument from me on that :-)
Myself, I have painful memories of getting combinations of jar files
from various projects to work. When Sun moved to SAX2, they didn't
freeze and deprecate the old SAX1 interfaces, rather, they just added
new methods to existing interfaces (Sun did that a lot.) In any
runtime environment, you could easily pull in several implementations
of these interfaces, some SAX1, some SAX2, as they were typically
found in more that one jar file in the classpath. Renaming a jar file
to start with the letter 'z', to ensure it was picked up last in an
automatically generated classpath, was not unheard of. And relying on
SAX readers was painful, they supported different compliance levels,
worked differently, and produced different output. It was hard to
know exactly whose implementation was being instantiated, because it
was based on abstract factories and reflection, and whichever
component managed to get their class name to the front. With every
new release of a third party component, something seemed to break.
This isn't so much about the language, as about management of change.
Although it would be nice to have language support for versioning,
which Java doesn't have.
-- Daniel
joe
"Juha Nieminen" <nos...@thanks.invalid> wrote in message
news:4c51774d$0$14489$7b1e...@news.nbl.fi...
Where I come from, we call that a HANDLE (caps for emphasis, and NOT to
refer to the Windowsism).
Branimir Maksimovic
Juha Nieminen <nos...@thanks.invalid> wrote:
>
> AFAIK it's possible for a reference to be "pointing" to one memory
> location at one moment, and a minute later the memory management
> system having changed it to "point" to a completely different
> location (completely transparently from the program's point of view).
> This allows things like memory compaction (which is good for cache
> optimization and other things). This is not possible in C++ because
> of the raw wild memory pointers.
That means: stop program, move memory allocated blocks, then update
all references in memory. Imagine n threads running on n cpus and your
program become completely halted while operation works.
This will also cause page trashing thus heavy swapping in
larger programs.
That's why GC per thread instead of GC per n threads is always
better solution, therefore processes that don;t share memory are
always faster then threads that share address space.
Greets
--
drwxr-xr-x 2 bmaxa bmaxa 4096 2010-07-27 16:37 .
Juha Nieminen
> Where I come from, we call that a HANDLE (caps for emphasis, and NOT to
> refer to the Windowsism).
The world would certainly be a better place if everybody used the same
unified terminology, but that's unfortunately not the case, and I'm assuming
that this reference/handle thing might be an example.
James Kanze
> On 07/30/10 03:29 AM, Daniel wrote:
> > On Jul 29, 10:37 am, Keith H Duggar<dug...@alum.mit.edu> wrote:
> >> On Jul 29, 6:28 am, James Kanze<james.ka...@gmail.com> wrote:
> >>> Different people work on them. Also, most build systems have
> >>> file level granularity; you don't want a change in the
> >>> implementation to trigger a recompilation of all of the client
> >>> code.
> >> Exactly ... Apparently the forced conflation of interface
> >> and implementation into the same file really bones Java build
> >> systems. Score another point for the C++ separate compilation
> >> model. It may not be perfect but it's much better than Java's
> >> design for large projects.
> > It's been some time since I've had the opportunity of building a large
> > C++ code base, but my recollection is that it took hours, even after
> > reducing it considerably with precompiled headers and other tweaks.
> > This compared with minutes for a Java code base of similar size. I
> > don't think this is a unique observation, and issues with build times
> > may be of special significance to C++ developers, as compared to other
> > languages.
> One reason is the output of a C++ build is the fully cooked application
> where the output form Java compilation is like those part baked breads
> supermarkets sell. The consumer has to take them home and finish the job!
And you have to hope that he does it correctly (using the right
versions of the libraries, etc.). As they say: write once,
debug everywhere.
But the argument concerned more the developer, who modifies one
small implementation detail (in a source file in C++), then does
make. With Java, every class which uses the modified class will
be recompiled. With C++, only the one source file will be
recompiled.
--
James Kanze
Juha Nieminen
> That means: stop program, move memory allocated blocks, then update
> all references in memory. Imagine n threads running on n cpus and your
> program become completely halted while operation works.
You are both having a very simplistic view of how garbage collection and
memory compaction work (after all, the algorithms have significantly
improved since the early 90's), and underestimating the significance of
cache optimizations. You would be surprised how much significance cache
misses have to the efficiency of a program. (For example, the speed
difference between multiple cache-frienly memory allocations vs. the
same allocations done at random memory locations can easily make a speed
difference of almost an order of magnitude. At least 90% of the speed of
any given program is thanks to the CPU cache.)
Garbage collection *used* to work in the 90's like you describe (ie.
stop the program during a sweep, which could take a noticeable amount
of time), but modern efficient garbage collectors do it a lot more
smartly and efficiently. Likewise memory compaction can be done smartly
and efficiently. Algorithms have improved since those times.
Branimir Maksimovic
Juha Nieminen <nos...@thanks.invalid> wrote:
> Branimir Maksimovic <bm...@hotmail.com> wrote:
> > That means: stop program, move memory allocated blocks, then update
> > all references in memory. Imagine n threads running on n cpus and
> > your program become completely halted while operation works.
>
> You are both having a very simplistic view of how garbage
> collection and memory compaction work (after all, the algorithms have
> significantly improved since the early 90's), and underestimating the
> significance of cache optimizations. You would be surprised how much
> significance cache misses have to the efficiency of a program. (For
> example, the speed difference between multiple cache-frienly memory
> allocations vs. the same allocations done at random memory locations
> can easily make a speed difference of almost an order of magnitude.
> At least 90% of the speed of any given program is thanks to the CPU
> cache.)
>
I don;t think that any of this goes in favor of gc.
http://confluence.atlassian.com/display/DOC/Garbage+Collector+Performance+Issues
http://stackoverflow.com/questions/2297920/jvm-outofmemory-error-death-spiral-not-memory-leak
http://stackoverflow.com/questions/771920/help-with-really-odd-java-gc-behavior
http://www.devproconnections.com/article/net-framework2/Get-to-Know-NET-4-0-s-CLR/2.aspx
"
But there's another feature in CLR 4.0 that a developer very concerned
about ASP.NET garbage collection performance can take advantage of:
garbage collection notifications. There's a "death spiral" that an
ASP.NET server can go into when it's running short of memory and under
extreme load. As memory gets low, the Gen 2 garbage collection runs to
try and free up memory. Often threads are blocked because they depend
on objects in Gen 2, like in-process session objects (you're not still
using in-process session objects are you?). While the Gen 2 garbage
collection runs, the server ends up with all threads blocked, resulting
in request queues growing. When the garbage collection finishes, the
server is hammered by all the requests that are backed up in the queue.
That backlog runs the server out of memory again, causing another Gen 2
garbage collection. With each iteration the queues get larger, until
the worker process recycles or the server crashes.
"
> Garbage collection *used* to work in the 90's like you describe (ie.
> stop the program during a sweep, which could take a noticeable amount
> of time), but modern efficient garbage collectors do it a lot more
> smartly and efficiently. Likewise memory compaction can be done
> smartly and efficiently. Algorithms have improved since those times.
Problem is that when you move memory allocated blocks around,
you have to update all references in program, also with scanning
references you force cache invalidation and page trashing, and I don;t
see how that can be much improved and without stopping whole program.
Joshua Maurice
The system could be improved so that if it detects that the "external
visible class file exported 'interface' " has not changed since last
compile, that is it has the same list of functions and fields with the
same types and names, then it doesn't need to recompile "clients" aka
class files which use that type name. If you just modify the internals
of a Java function, then the class "exported interface" will not
change, so there is no need to recompile "clients", but if you add,
remove, or modify the name or type of a field or function, then you do
have to recompile clients. This is exactly analogous to headers and
cpp files for C++. You just need some not-make-based logic to deal
with it.
PS: Yes I'm glossing over details. See the other thread in comp.lang.c+
+ for the details:
Build systems (was Re: No unanswered question)
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/c830c7c07951f4a6#
Specific post:
http://groups.google.com/group/comp.lang.c++/msg/1775877bafa20eda
This specific paragraph, where I described how I applied my build-
system-in-progress to roughly 100 of those jars:
> A slightly longer explanation of my build system for java: The java code is broken up into different directories which will end up in different jars. There's about 100 jars for those java files. The dependency cascade goes without termination to the boundary of this javac task, taking the conservative approach, then executes javac. It begins the analysis anew for the next javac task, in effect allowing a termination to the dependency cascade. This is required because of the possible circular references in the java code, because developers frequently do not specify java to java file dependency information, and because javac is quite expensive to invoke so the cost is amortized over lots of java files. This seems to result in a good degree of parallelization and a good degree of incremental while still having a fast build.
Keith H Duggar
The problem is that such systems require parsing of the file
and language specific analysis of the file. And that analysis
must examine not only the current contents but some previously
known contents as well. All that is significantly more complex
and costly than simply checking a timestamp, checksum, etc.
KHD
Keith H Duggar
> "Keith H Duggar" <dug...@alum.mit.edu>
>
> >> It's been some time since I've had the opportunity of building a large
> >> C++ code base, but my recollection is that it took hours, even after
> >> reducing it considerably with precompiled headers and other tweaks.
> >> This compared with minutes for a Java code base of similar size. I
> >> don't think this is a unique observation, and issues with build times
> >> may be of special significance to C++ developers, as compared to other
> >> languages.
> >It's also an irrelevant observation because it compares compilation
> >of different languages.
>
> How could it be irrelevant?
Because the point is not comparing C++ and Java build times.
It is comparing what Java build times /would be/ if it allowed
separation of implementation and interface files. Ie it is not
about Java vs C++ build times it's about Java vs Java and C++
vs C++ build times under two different code separation models:
a) all code in one file (Java and header only C++)
b) capability of separating some code into different files
(not supported by Java, supported by .hpp/.cpp C++).
This can be actually be evaluated by simply making a change to
the /implementation/ of a Java function, measuring the compile
time of that one file and then measuring the compile time of
the incremental build which will required compling many more
files specifically the transitive closure of .java files that
import that functions class. (At least from what I understand
from some recent discussions.)
> Compilation time is a practical matter, nothing else. It a
> full rebuild would take just milliseconds, who would bother
> at all?
Apparently it is much more than that or I doubt Joshua would
have been discussing the Java build dependency problems in the
another thread.
http://groups.google.com/group/comp.lang.c++/msg/116fa28be7ebde6f
> As long as a full rebuild of java still takes a magnitude
> more than a fine-tuned C++ system, arguments about superiority
> of the latter will hardly win. ;-)
It's not about Java vs C++ build times it's about Java vs Java
and C++ vs C++ build times under different code separation models.
> >An accurate comparison is instead between
> >compiling a header-only implementation of some C++ versus one that
> >separates .hpp/.cpp. And for Java comparing the time of compiling
> >only the files that must be compiled due to interface changes vs
> >compiling all files that import the changed file even if interface
> >was not changed.
>
> Possibly could make a PhD thesis and impress a some folks who only know
> build from books... Not anyone from practice.
Judging from Joshua's concerns it apparently has very real
practical implications. But, yeah, a Java fanboy compiling
online toy Fahrenheit-to-Celsius calculators won't grok the
concept.
> >Sure. The point is that it is /possible/ to separate some and even
> >all (for example pure abstract functions, pimpl, etc) implementation
> >away from the interface. This is simply not possible in Java since
> >you are /forced/ to conflate implementation and interface in the
> >same file.
>
> I'm light on java, but I saw people using 'interface' alot. That
> is certainly pure. And does a plenty of separation too. And compiles
> separately too using your terms. Is anything preventing to do all
> the job through interfaces? Stating that any implementation of the
> interface is considered private stuff?
Yes you are prevented from doing "all the job through interfaces"
by the fact than at some point you must import a concrete class
to instantiate if you are actually going to do any actual work.
Thus that file now depends on the /implementation/ of the concrete
class and any modification to the /implementation/ will trigger
unnecessary compilation of all files in the transitive closure of
the imports (noting that the Java import command is directed not
symmetric). At least that is my understanding from limited Java
experience and Joshua's comments. Am I wrong about that?
> >Nearly anyone who has worked on large projects knows all too well
> >that judicious removal of code from headers (function code, pimpl,
> >explicit template instantiation, etc) can reduce C++ compile times
> >IMMENSELY. So I'm really not sure what planet you are working on.
>
> At a really steep cost -- and leaving that immensly reduced time
> still pretty high.
Which is irrelevant to the point as I hope you now understand.
KHD
Joshua Maurice
Not really. (Yep, time to muck up this thread.)
To be clear, let's examine what happens in a Make system on C++. At
the first go, no object files exist, so the object files are built.
During this build, you use a language specific tool, something like
gcc -M, to extract the file dependencies. For for the next build, you
do not rerun gcc -M when checking dependencies and such. You use only
the precomputed dependencies of gcc -M from the previous run, and file
timestamps, to determine which files are out of date. You then
recompile these out of date files, and rerun the language specific
tools, ex: gcc -M, to get the new file dependencies.
> The problem is that such systems require parsing of the file
> and language specific analysis of the file.
This is true of the standard C++ and Make solution, and I assume it's
true for your solution. Presumably, you use gcc -M or equivalent to
extract header file dependencies.
>And that analysis must examine not only the current contents but some previously known contents as well
In the standard C++ and Make solution, and I assume also for your
solution, the gcc -M results are saved, traditionally to a .d file. On
the next make execution, these .d files are read in by make.
> All that is significantly more complex
> and costly than simply checking a timestamp, checksum, etc.
Once Make reads in the .d files of the saved state from the previous
run, it then uses simple rules, and file timestamps, to figure out
what's out of date. Specifically, it does not need to call gcc -M on
every call to correctly determine dependencies. It only needs to call
gcc -M when a file is recompiled, and generally such analysis is quite
cheap relative to the cost of a full compile, and it only happens on a
recompile, so it's quite worth it.
So, at face value, your complaints of my Java system apply to the
standard C++ and Make solution. Presumably, you also mean that the
language specific source file parsing must happen on every file on
every build system execution to determine dependencies, and that's
where you're wrong, at least for C++ and Java.
I am suggesting something exactly analogous for Java can exist. At the
first go, there are no output files, so the Java files are all out of
date, so they all get built. As part of the Java compilation process,
you can use language specific tools to extract the needed dependency
information. During the next build, you can use only the precomputed
dependency information and file timestamps to determine if there are
out of date Java files. If you find some out of date Java files, then
recompile those Java files and recompute the dependencies using the
language specific tools. You can then use the available dependency
information (without parsing any additional Java files) to see if any
further Java files are affected by the just-recompiled Java files. If
so, continue the cascading rebuild. Stop the cascading rebuild when
you find yourself in a position where all of the just-built Java files
do not affect Java files not yet built during this build.
You do not need to reparse all of the Java files on every build. You
just need to employ some logic which isn't make-style "file level
dependency graph cascading rebuild without termination".
Daniel Pitts
compilation dependencies.
The only thing that might cause a compile-time dependency is interface
change, or constant (static final primitive/String variable) value
change. You can safely modify/add methods in one Java file without
recompiling other Java files which depend on it. Removing members *may*
result in a link-time error, but also do not require rebuild. Modifying
constants may result in inconsistencies between references to that
constant until a rebuild.
The Java keyword "import" is not analogous to the #include directive. It
tells the compiler that "References to the imported class needn't be
fully qualified." For example, import java.util.List lets you refer to
"List" rather than "java.util.List" in the rest of the file. Importing
or not doesn't really affect compile time (there are a few exceptions,
but they are trivial, and unrelated to the classes imported.)
>
>>> Nearly anyone who has worked on large projects knows all too well
>>> that judicious removal of code from headers (function code, pimpl,
>>> explicit template instantiation, etc) can reduce C++ compile times
>>> IMMENSELY. So I'm really not sure what planet you are working on.
>>
>> At a really steep cost -- and leaving that immensly reduced time
>> still pretty high.
>
> Which is irrelevant to the point as I hope you now understand.
Sorry, late-comer to this thread, so I can't comment on your point ;-)
--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
Joshua Maurice
<newsgroup.spamfil...@virtualinfinity.net> wrote:
> On 7/30/2010 11:00 AM, Keith H Duggar wrote:
> > Thus that file now depends on the /implementation/ of the concrete
> > class and any modification to the /implementation/ will trigger
> > unnecessary compilation of all files in the transitive closure of
> > the imports (noting that the Java import command is directed not
> > symmetric). At least that is my understanding from limited Java
> > experience and Joshua's comments. Am I wrong about that?
>
> Actually, you have an incorrect/oversimplified understanding of Java
> compilation dependencies.
>
> The only thing that might cause a compile-time dependency is interface
> change, or constant (static final primitive/String variable) value
> change. You can safely modify/add methods in one Java file without
> recompiling other Java files which depend on it. Removing members *may*
> result in a link-time error, but also do not require rebuild. Modifying
> constants may result in inconsistencies between references to that
> constant until a rebuild.
>
> The Java keyword "import" is not analogous to the #include directive. It
> tells the compiler that "References to the imported class needn't be
> fully qualified." For example, import java.util.List lets you refer to
> "List" rather than "java.util.List" in the rest of the file. Importing
> or not doesn't really affect compile time (there are a few exceptions,
> but they are trivial, and unrelated to the classes imported.)
Actually, no. Let me continue mucking up this thread. First, let's get
some definitions out of the way:
A build is the act of compiled (and linking, etc.) source files into
"executable" files. A build system is a process or system for doing a
build. It may be the English "call gcc", or it could be an automated
script, or a makefile, etc.
An incremental build is a special kind of build. Developers have their
own local view of the source. Suppose he does a full clean build, then
makes a change to some of the source files. He can then build only
some of the source files, and by selectively building only certain
source files, he can end up in a situation equivalent to what would be
if he did another full clean build. This is an incremental build. An
incremental build is a build which works on top of an already existing
build, and which skips some (preferably most) of the build steps which
would produce equivalent output to the previous build.
Finally, I define a correct incremental build as an incremental build
which produces output equivalent to a full clean build, includes any
build errors. A correct incremental build system is a build system
which does incremental builds, and which only does correct incremental
builds. This is what every developer wants. It doesn't matter if the
build is fast if the build also produces output not equivalent to a
full clean build.
So, in order to guarantee correct incremental, if a Java file has its
"exported interface" change (ex: the type of a function is changed),
then this could affect the compilation of another java file which
"imports" it (either with an import statement, or through a fully
qualified name, or a name when it's in the same package, etc.). If you
did a change to the Java A which would cause the next compilation of
Java file B to fail, but you skip compiling Java file B, then you do
not have a correct incremental build. A full clean build would fail
(and execution may also fail).
So yes, a change inside a Java function body does not require
recompiling any other Java file, but for a correct incremental build
system, a change to a Java classes "exported interface" does require
recompiling all direct dependents.
Daniel Pitts
with "used" exported interface. If the portion of the exported
interface which changed has not been used, then there need not be any
cascading builds.
It seems to me that it wouldn't be too difficult at build-time to create
a dependency relationship among classes as part of the build. It may
reduce the speed of full builds, but that seems unlikely to matter as it
would be the less-common case.
FWIW, I work on some relatively large projects, and the unit tests are
what take the most time of the build. Completely rebuilding the
projects (sans unit tests) take under a minute each, for most projects.
Yes, I would be happier if they ran in under 10 seconds, but the time
isn't a major loss of productivity.
joe
Well that's obviously not ever going to happen, but is it so darned hard
to provide a glossary that gives the meaning of the terms so as to
resolve any potential ambiguity? (rhetorical). A lot of newsgroup
discussions go round-n-round because of the same failing: definitions are
not established at the onset so they must painstakingly bubble up to the
surface after a thousand posts and sometimes NEVER reach fruition because
of the lack-of.
joe
So, how big is one of these new-fangled collectors? How many source files
and lines of code? How many developer-years are required to implement a
robust one? Examples if ya got em please.
Balog Pal
>So yes, a change inside a Java function body does not require
>recompiling any other Java file, but for a correct incremental build
>system, a change to a Java classes "exported interface" does require
>recompiling all direct dependents.
I didn't use it, but my friend used to show me Visual Age for Java, like a
decade back. It had a 'code repository' instead of the classic source
files -- you saw all your packages, classes, functions in a tree view, could
edit anything, got a full version control system on that function level,
etc.
I bet it had no problem doing your perfect incremental build having handy
the nature of any change...
I wish i had like a system for my C/C++ work -- unfortunately the language
is such you can not get rid of source files/translation units entirely. And
using external libraries would spoil a self-limiting approach too.
Balog Pal
>Because the point is not comparing C++ and Java build times.
Kinde tweaking discussion to some made-up point. Sure, it is possible to
use a FU build system with java -- I saw ours out of order time to time,
causing it go make-like, invoking compile on individual files or folders.
then someone fixed it back to get the full fileset and it processed
everything in "no-time" again. Looing for potential speed-up of something
that is fast enough already is IMO fishy, especially when comparing to a
different model where it does not hold.
Yet,
>It is comparing what Java build times /would be/ if it allowed
>separation of implementation and interface files.
What exactly is that disallows the said separation? As mentioned in another
post, VisualAge for Java IIRC did that very separation on its own. Before
Y2K. While the parallel froduct for C++ could not do it, as there having
source files seem unavoidable both in theory and practice.
> Ie it is not
>about Java vs C++ build times it's about Java vs Java and C++
>vs C++ build times under two different code separation models:
> a) all code in one file (Java and header only C++)
> b) capability of separating some code into different files
> (not supported by Java, supported by .hpp/.cpp C++).
And consider also
c) code repository, no files at all...
Juha Nieminen
> I don;t think that any of this goes in favor of gc.
> http://confluence.atlassian.com/display/DOC/Garbage+Collector+Performance+Issues
> http://stackoverflow.com/questions/2297920/jvm-outofmemory-error-death-spiral-not-memory-leak
> http://stackoverflow.com/questions/771920/help-with-really-odd-java-gc-behavior
> http://www.devproconnections.com/article/net-framework2/Get-to-Know-NET-4-0-s-CLR/2.aspx
I didn't claim that garbage collection is completely problem-free and
extremely efficient in all possible situations. I was simply pointing out
that GC algorithms have improved since the early 90's and are much better
now than they were back then (which isn't the same thing as claiming that
they are perfect).
(And for the record, I'm not a GC nor Java fanboy. In fact, I hate the
guts of Java, but that's a different story. It's just that I don't like
to exaggerate problems which aren't there.)
>> Garbage collection *used* to work in the 90's like you describe (ie.
>> stop the program during a sweep, which could take a noticeable amount
>> of time), but modern efficient garbage collectors do it a lot more
>> smartly and efficiently. Likewise memory compaction can be done
>> smartly and efficiently. Algorithms have improved since those times.
>
> Problem is that when you move memory allocated blocks around,
> you have to update all references in program, also with scanning
> references you force cache invalidation and page trashing, and I don;t
> see how that can be much improved and without stopping whole program.
You seem to have the mentality that reference == pointer == memory
address.
As I already wrote, Java references are (AFAIK) more abstract than that
(or can internally made more abstract because the language doesn't assume
they are memory addresses). Moving a block of memory from one place to
another doesn't necessarily mean that all references which work as handles
to that memory block need to be modified. It's possible to have an extra
indirection step, which allows changing the low-level memory address of
the memory block in only one place and have all the references work
without any change. (Think about it like a vtable.)
Juha Nieminen
> So, how big is one of these new-fangled collectors? How many source files
> and lines of code? How many developer-years are required to implement a
> robust one? Examples if ya got em please.
You want me to do the googling for you? I'm sure you can do it yourself.
If you want an intro to modern garbage collection, try the wikipedia
page as a starting point.
James Kanze
> Actually, you have an incorrect/oversimplified understanding of Java
> compilation dependencies.
And you have an incorrect/oversimplified understanding of C++
compilation dependencies.:-)
> The only thing that might cause a compile-time dependency is interface
> change, or constant (static final primitive/String variable) value
> change. You can safely modify/add methods in one Java file without
> recompiling other Java files which depend on it. Removing members *may*
> result in a link-time error, but also do not require rebuild. Modifying
> constants may result in inconsistencies between references to that
> constant until a rebuild.
That's all in theory. In practice, the build systems I've seen
(Java or C++, with one exception: Visual Age) use the file as
the lowest level of granularity. Which means that a change will
trigger a recompilation, even if the change won't change the
generated code.
> The Java keyword "import" is not analogous to the #include directive. It
> tells the compiler that "References to the imported class needn't be
> fully qualified." For example, import java.util.List lets you refer to
> "List" rather than "java.util.List" in the rest of the file. Importing
> or not doesn't really affect compile time (there are a few exceptions,
> but they are trivial, and unrelated to the classes imported.)
Yes, but that's not the question. Java's import is more or less
like C++'s using. And Java "implicitly" includes anything that
is needed, where as in C++, you have to explicitly include it.
But the inclusion mechanism is different---in C++, it's pure
texual inclusion, where as in Java, the included data come from
the compiled .class file. But the fact remains, if you modify a
.java file, the timestamp on the files will tell the build
system that the .class file is out of date, and it will
recompile the .java file, producing a new .class file. Which
will then trigger a recompile of all of the .java files which
use this .class file. Where as if you modify the implementation
code in a C++ source file (.cpp or .cc), the corresponding
object file will be recompiled, but the time stamp on the header
file (.hpp or .hh) will not be modified, and objects built from
sources dependent on the header will not be recompiled.
There are a lot of criticisms to be made for both solutions.
There's no reason why modifying the implementation of a member
function should trigger recompilation of all client sources (as
it does in Java), and there's no reason why correcting an error
in the Doxygen documentation should retrigger recompilation of
all client sources (as it does in both Java and C++---except, I
believe, Visual Age C++). It's also not a good thing that you
can get mixed versions of a class in a single program (most, but
not all, C++ systems; Java only detects this at runtime, because
it doesn't link until runtime, but it's much more tolerant with
regards to differences in the versions).
--
James Kanze
James Kanze
<newsgroup.spamfil...@virtualinfinity.net> wrote:
[...]
> > So yes, a change inside a Java function body does not require
> > recompiling any other Java file, but for a correct incremental build
> > system, a change to a Java classes "exported interface" does require
> > recompiling all direct dependents.
> That is mostly correct. I would qualify it with "exported interface"
> with "used" exported interface. If the portion of the exported
> interface which changed has not been used, then there need not be any
> cascading builds.
> It seems to me that it wouldn't be too difficult at build-time to create
> a dependency relationship among classes as part of the build. It may
> reduce the speed of full builds, but that seems unlikely to matter as it
> would be the less-common case.
There are many things that could be done to improve incremental
builds, but aren't. On all of the systems I've used, and all
but one I've heard about, the granularity of the build system is
the file. If you modify anything in a Java file, or at least
anything that changes the generated .class file (or causes it's
timestamp to be updated), then the build system will cause any
classes which depend on that .class file to be rebuilt; in
practice, the only information the build system has about the
.class file is its time stamp. The same problem occurs with
"benigne" changes (like adding comments, or a non-virtual
private member function) in a C++ header file.
At least one system I've heard about (but never used) tried to
do better. In C++, Visual Age C++ managed things at a much
lower level, maintaining meta-information concerning who really
used what, and how, and knew which changes affected what types
of use. (There was or is also a Visual Age Java, which I
suppose behaves similarly.)
> FWIW, I work on some relatively large projects, and the unit
> tests are what take the most time of the build.
A large project is (or should be) cut up into smaller
components. Normally, you're working on a single component, and
when you incrementally build during development, you'll only run
the unit tests for that component. (Before you commit your
changes, you'll run the unit tests for the entire project, but
if the unit tests for the component were complete, changes in
the component which pass those unit tests shouldn't cause
anything to fail elsewhere in the project.)
--
James Kanze
James Kanze
[...]
> >It is comparing what Java build times /would be/ if it allowed
> >separation of implementation and interface files.
> What exactly is that disallows the said separation?
It's extra work:-). And it has runtime implications.
> As mentioned in another post, VisualAge for Java IIRC did that
> very separation on its own. Before Y2K. While the parallel
> froduct for C++ could not do it, as there having source files
> seem unavoidable both in theory and practice.
Except that in practice, Visual Age C++ did keep different
things separate. And knew what sort of changes affected what
sort of use, so that it wouldn't compile client sources just
because you added a private, non-virtual function to the class
definition.
> > Ie it is not
> >about Java vs C++ build times it's about Java vs Java and C++
> >vs C++ build times under two different code separation models:
> > a) all code in one file (Java and header only C++)
> > b) capability of separating some code into different files
> > (not supported by Java, supported by .hpp/.cpp C++).
> And consider also
> c) code repository, no files at all...
Yes, but only Visual Age uses this model. And it does so for
both C++ and Java. (And as you said, it's been around for some
time now. I believe it's based on work done by Taligent, before
they folded. And I recall one of the developpers from Taligent
explaining it to me sometime around 1992.)
--
James Kanze
James Kanze
> On Jul 30, 1:31 pm, Joshua Maurice <joshuamaur...@gmail.com> wrote:
[...]
> > > But the argument concerned more the developer, who modifies one
> > > small implementation detail (in a source file in C++), then does
> > > make. With Java, every class which uses the modified class will
> > > be recompiled. With C++, only the one source file will be
> > > recompiled.
> > The system could be improved so that if it detects that the "external
> > visible class file exported 'interface' " has not changed since last
> > compile, that is it has the same list of functions and fields with the
> > same types and names, then it doesn't need to recompile "clients" aka
> > class files which use that type name. If you just modify the internals
> > of a Java function, then the class "exported interface" will not
> > change, so there is no need to recompile "clients", but if you add,
> > remove, or modify the name or type of a field or function, then you do
> > have to recompile clients. This is exactly analogous to headers and
> > cpp files for C++. You just need some not-make-based logic to deal
> > with it.
> The problem is that such systems require parsing of the file
> and language specific analysis of the file. And that analysis
> must examine not only the current contents but some previously
> known contents as well. All that is significantly more complex
> and costly than simply checking a timestamp, checksum, etc.
They require meta-information of some sort. If the compiler
collaborates, it could easily generate that meta-information
when compiling. And evaluating that meta-information should
actually cost less than checking a checksum (but not a time
stamp).
--
James Kanze
joe
I don't need the other info. I was just curious for the stats. I have a
feeling it's going to be one of those monstrous things though which I
tend to avoid. If anyone actually KNOWS what I am curious about, please
speak up, thanks. Surely someone here has actually worked on a
sophisticated (not personal project) one (?).
Öö Tiib
What manyears it takes to use? Downloading from sourceforge, some
tinkering ... lets say 0.003 to 0.006 developer years.
joe
No, I meant what it takes "to implement from scratch" and the other stats
which someone, no doubt, can rattle off in one second. I want to mentally
catalog the technology is all. I have no need for said technology though
at this time.
Öö Tiib
I think there are not so lot of people who have implemented GC
libraries. The theory itself is not that complex. Even most clever
algorithms are describable with page of pseudo-code. What makes it
complex is all that platform-specific and implementation-specific
knowledge that is needed for implementing thread safe real-time
garbage collected memory management.
C++ does not yet have such essential things like virtual memory or
threads or atomic operations in it by current standard. Also binary
representation of polymorphic pointer to object may differ from the
one that new did return ... and so on.
Therefore implementing it certainly takes good specialists with deep
knowledge ... and that is situation when you may throw man years in
endlessly and get odd crashes (read "nothing") unless you have such
specialists available.
Jerry Coffin
nos...@thanks.invalid says...
[ ... ]
> I didn't claim that garbage collection is completely problem-free
> and extremely efficient in all possible situations. I was simply
> pointing out that GC algorithms have improved since the early 90's
> and are much better now than they were back then (which isn't the
> same thing as claiming that they are perfect).
I think it's worth pointing out that this isn't really a matter of GC
algorithms having improved since the early 90's. Rather, it's a
matter of older JVMs mostly using algorithms that have been known
since the late 1950's and early 1960's, where current JVMs use
algorithms from the mid- to late-1980's.
I believe current production JVMs mostly use the basic algorithm from
"Generation Scavenging: A Non-disruptive High Performance Storage
Reclamation Algorithm", (Ungar, 1984) in combination with some (but
I don't think all) of the techniques from: "Tenuring Policies for
Generation-Based Storage Reclamation" (Ungar and Jackson, 1988).
--
Later,
Jerry.
Jerry Coffin
5g2000yqz.googlegroups.com>, james...@gmail.com says...
[ ... ]
> At least one system I've heard about (but never used) tried to
> do better. In C++, Visual Age C++ managed things at a much
> lower level, maintaining meta-information concerning who really
> used what, and how, and knew which changes affected what types
> of use. (There was or is also a Visual Age Java, which I
> suppose behaves similarly.)
Note, however, that Visual Age for C++ has been discontinued for
quite a while now -- replaced by XL C++, which has better
conformance, but uses a more conventional build process (normal make
based on file time stamps).
--
Later,
Jerry.
joe
I was looking for quantification associated with a successful modern
implemenation rather than simple qualification. The example need not be
C++ probably.
Jerry Coffin
says...
[ ... ]
> So, how big is one of these new-fangled collectors? How many source files
> and lines of code? How many developer-years are required to implement a
> robust one? Examples if ya got em please.
While the exact size and effort obviously varies, a few data points
are available. For example, a few years ago Ravenbrook Ltd. released
their Memory Pool System as open source. At the time, they claimed
that it represented 30 person years of effort. A quick check of the
files shows around 2.4 megabytes.
Most others of which I'm aware are probably in the same general
ballpark. Of course, some can depend on things like how many systems
it may have been ported to. More ports usually means more work and
more code that don't mean much unless you need those particular
targets.
--
Later,
Jerry.