Linux-Development-Sys Digest #900, Volume #6 Mon, 28 Jun 99 00:14:18 EDT
Contents:
Re: Why not C++ (Tristan Wibberley)
Re: Why not C++ (Don Waugaman)
Re: Why not C++ (Johan Kullstam)
Re: Why not C++ (Johan Kullstam)
Re: Why not C++ (Greg Comeau)
need some help with some required programs ("Ape Man")
----------------------------------------------------------------------------
From: Tristan Wibberley <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: Sat, 26 Jun 1999 23:39:21 +0100
Reply-To: [EMAIL PROTECTED]
Johan Kullstam wrote:
>
> [EMAIL PROTECTED] (Nathan Myers) writes:
>
> > Johan Kullstam <[EMAIL PROTECTED]> wrote:
> > >the memory fragmentation problem pretty much precludes seriously using
> > >C++ for kernel work. look to microsoft for examples of C++ in action.
>
> > Nazis eat peanut butter. Therefore peanut butter is bad.
>
> thanks for trying godwin's law.
>
> > This supposed "memory fragmentation problem" is just more FUD.
> > Shame on you, Johan.
>
> no, this one really *is* *true*. if you malloc and free a lot of
> things of different sizes, then heap memory does get chopped up. there
> are little bits of free memory here and there. you cannot consolidate
> them. and when allocating you search around for these free holes.
> the typical C++ program does a lot of malloc and free. memory
> fragmentation does occur and it does cause performance loss.
Not if you get a garbage collector and de-fragmenter, in which case C++
can keep the place clean with similar overhead to others - although C++
garbage collectors and de-fragmenters are still quite immature.
--
Tristan Wibberley
------------------------------
From: [EMAIL PROTECTED] (Don Waugaman)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 27 Jun 1999 17:55:29 -0700
In article <[EMAIL PROTECTED]>,
Johan Kullstam <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] (Don Waugaman) writes:
>
>> In article <[EMAIL PROTECTED]>,
>> Johan Kullstam <[EMAIL PROTECTED]> wrote:
>>
>> Which is as much a problem for the C code as for the C++ code, if not
>> more so since schemes such as reference-counted objects is more
>> difficult to implement in C.
[ snip ]
>and in C, mallocs tend to be rare. most C programs will malloc
>everything they need right off the bat and keep hold of the memory
>until they exit.
I disagree with this generalization. I've seen numerous examples of
C programs which will use malloc() / free() frequently during their
execution.
I would welcome correction if I am wrong. Has anyone seen any studies
to either effect?
> however, C++ encourages more dynamic memory
>exercising because its syntax hides the malloc/free somewhat.
This *may* be true, but - again - this is a case of programmer choice.
Nothing stops programmers from using the style that you describe for
the C language. For many types of programs, less-powerful classes may
be better than general classes which allocate consistently on the heap -
thus a FixedSizeArray<> template may be preferable to using vector<> in
some situations. However, when you need the additional power of the
built-in classes, it's good to have them easily available.
>> >the memory fragmentation problem pretty much precludes seriously using
>> >C++ for kernel work.
>>
>> I don't think that memory fragmentation is worse in C than in C++.
>> It's true that some features of C++ can cause programmers to use
>> dynamic memory more than in C. but that's an attribute of the use of
>> the language, not of the language itself.
>>
>> What it means is that in areas where memory fragmentation is an issue,
>> you'll have to be very careful about how you manage memory. This is
>> an issue in C programs as well, of course. The difference is that you
>> can use C++'s features to more easily move between different methods
>> of memory and fragmentation management.
>
>in eg lisp you let your vendor take care of this for you.
And your vendor may sometimes get it wrong. Will he guess correctly for
every instance of a quick-and-dirty filter, an OS kernel, a daemon and
a number-crunching application?
I might add that the C++ programmer doesn't need to write the appropriate
classes for all of those instances - rather, she/he can get a library from
a vendor to do the right thing for him/her in a given situation.
>> For example: collection templates in the C++ Standard Library take an
>> "allocator" template parameter, which means that you can substitute in
>> your own memory allocator if the built-in one isn't acceptable for your
>> needs. This is part of what makes the C++ SL a rather robust design -
>> and something that can't be done without C++'s substantial template
>> support.
>
>is `alloca' a valid `allocator'?
Allocator objects are classes, not functions. alloca() could be used
by a valid allocator object, but your use of that allocator would be
pretty severely proscribed - for instance, it could only be used by
auto objects, and memory allocated by such an allocator could not be
swapped to be the representation of an object at a different scope.
Again, if you decide you need this functionality, you can write it or
get it from a library. C++ is a lot about having choices in how to
implement things - it's a larger toolbox, with better tools, which can
create an object of surpassing beauty and flexibility or mangle the
object being worked on.
>> Could you describe what you don't like about C++ templates, and how a
>> statically-checked language that intends to minimize runtime cost could
>> do better?
>static type checking has nothing to do with anything. imho it's a
>negative. static types are more a disadvantage the larger and more
>complex a program gets.
One of the design decisions behind C++ (and, to a lesser but growing
extent, behind ANSI C) is the use of static type checking. It may have
nothing to do with languages in general, but it has a great deal to do
with the design of this particular language. IMHO static type checking
is a positive, and it makes larger designs easier to maintain correctly.
We may have to agree to disagree.
>C++ doesn't have insignificant runtime costs.
Please name some of C++'s significant runtime costs (that we haven't
already addressed above - namely, memory management issues).
> when you buy into the
>complexity that C++ offers you, i think a more heavyweight language is
>in order.
That may be true in many contexts, but I would point out that no one is
forcing the programmer to write complex C++. Furthermore, while
implementing some reusable functionality in C++ may be complex, it is
often the case that use and reuse of that functionality is rather simple.
Exhibit A is the string class (actually a typedef of a template) which
has a great deal of (rather complex) extensibility for dealing with
different types of character sets and the like, but is rather trivial
for a programmer to use effectively.
>for example, here's a little macro i made in lisp
[ example of defining a new function _=, which applies its rhs function
to its lhs variable, and assigns the result back to that variable,
snipped - a good example of Lisp's flexibility, by the way ]
>this is not terribly important when x is just a variable, but if the
>left hand side is complex and involves much pointer chasing like
>x->y->z->w[5] then having a way to reference it would be a win.
>
> x->y->z->w[5] _= fabs(_);
>
>could perform
>
> x->y->z->w[5] = fabs(x->y->z->w[5]);
>
>the first is more clear imho just like += and friends.
Clearer still would be to eliminate the pointer chasing altogether,
and have each object in the "chain" of pointers return a reference
to the contained thing that ends up being w[5]. Inline functions can
make that kind access to contained members more efficient.
>with the lisp macros i made
>
> (asetf foo (abs it))
>
>is equivalent to
>
> (setf foo (abs foo)).
>
>whether asetf or _= are worthwhile ideas is not my point. my point is
>that in lisp you *can* make an asetf. in C++, no matter what
>templates you have, you cannot create a new operation like _=.
True - you lose some flexibility - but I'd tend to consider such
things a potentially much larger maintenance nightmare than the C++
overloaded operators, where the adherence to the rule of thumb "do
as the ints do" when deciding on operator behavior works pretty well
as a style guideline. C++ parsers are hard enough to write without
having to make them dynamic by the addition of new operators.
>also note that in the definition of asetf i used a lisp function
>group. how do you invoke C++ functions to help you expand a C++
>template?
Can't be done - templates are only expanded at compile time (there's
that design preference for compile-time decisions again) but there is
support for a lot of what you're looking for...
> what about functions which are 99% the same but differ in
>one spot. how can you make an template-if which could invoke the
>right part based on the type or some aspect of the type being passed?
If I interpret your question correctly, template specializations can do
much of what you want to do here. A template specialization basically
means that you fill-in parts of the template for a given instantiation
on a given type. You can also do partial template specialization, which
allows you to fill in the template parts which need to be specialized
for one of the template types, but let the rest be instantiated by the
regular mechanism.
It's not as general a functionality as what you are describing above,
but it does have zero runtime cost - which I belive is not the case in
Lisp.
>consider a min function in C++ that you wish to templatize
>
>template <class X>
>X min(
> X a,
> Y b)
>{
> return a < b ? a : b;
>}
>
>how do you use this for classes for which < is not defined? how would
>you substitute another definition of < if two less-than concepts would
>make sense for a certain class? perhaps you could pass a function.
>but now < and the alt_less_than function would take different syntaxes
>and hence not work like
>
> min(a,b,<) and min(a,b,alt_less_than)
You would use a functor (an object that encapsulates a function).
This is the exact example of how min is defined in the SGI STL:
template <class T>
inline const T& min(const T& a, const T& b) {
return b < a ? b : a;
}
template <class T, class Compare>
inline const T& min(const T& a, const T& b, Compare comp) {
return comp(b, a) ? b : a;
}
The first example uses the built-in < operator, so you can use that for
classes for which defining '<' makes sense. If you need to compare two
classes but not use the built-in operator, either because you prefer not
to use operator overloading or because you have a different ordering
scheme in a different context, you can use the second function.
You would, of course, have to write your own comparator, but that should
be pretty easy:
class StrangeClass {
public:
struct CompareStrangeKeys {
operator()(StrangeClass const&lhs, StrangeClass const& rhs)
{ return (lhs.strangeKey() < rhs.strangeKey()); };
};
operator<(StrangeClass const& rhs)
{ return this -> normalkey < rhs.normalkey; };
}
Now you could say
StrangeClass a(arguments1);
StrangeClass b(arguments2);
StrangeClass::CompareStrangeKeys key_comp;
a = min(a, b);
a = min(a, b, key_comp);
You can write a CompareStrangeKeys struct for every different sort
criteria over your class you can think of - each one just overloads
its own operator() function and you're off to the races.
Now that I think of it, you could do this a little differently:
template <class T>
class less {
public:
bool operator()(T const& a, T const& b) { return a < b; };
};
template <class T, class Compare = less<T> >
inline const T& min(T const& a, T const& b) {
Compare comp;
return comp(a, b);
}
So you would have
StrangeClass a(arguments1);
StrangeClass b(arguments2);
a = min(a, b);
a = min<StrangeClass, StrangeClass::CompareStrangeKeys>(a, b);
if you prefer a slightly different syntax.
Anyway...
I think this thread has gone on long enough for my taste, and is now
sufficiently off-topic to have likely lost the attention of the great
majority of the group. I'll try to sum up my thoughts and then let you
get the last word in. :-)
1) C++ is not perfect - but then, no language is.
2) A lot of what people think are fatal flaws in C++ have never been or
no long are true - again, this is also true of most languages.
3) C++ could be mighty useful for writing device drivers in the kernel
(aha! back on topic...) and with *proper* use of the language would
enhance the flexibility and maintainability of parts of the kernel.
4) I don't think that it's extraordinarily important to compile the whole
kernel in C++, but (by 3) it would be nice to be able to build a device
driver with it.
5) (4) ain't gonna happen soon.
6) Some of the reasons it won't happen are valid; most (see 2) are not.
--
- Don Waugaman ([EMAIL PROTECTED]) O- _|_ Will pun
Web Page: http://www.cs.arizona.edu/people/dpw/ | for food
In the Sonoran Desert, where we say: "It's a dry heat..." | <><
"Very funny, Scotty. Now beam down my clothes."
------------------------------
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
From: Johan Kullstam <[EMAIL PROTECTED]>
Date: 27 Jun 1999 22:52:16 -0400
[EMAIL PROTECTED] (Nathan Myers) writes:
> Johan Kullstam <[EMAIL PROTECTED]> wrote:
> > if you malloc and free a lot of
> >things of different sizes, then heap memory does get chopped up. there
> >are little bits of free memory here and there. you cannot consolidate
> >them. and when allocating you search around for these free holes.
> >the typical C++ program does a lot of malloc and free. memory
> >fragmentation does occur and it does cause performance loss.
>
> Yes, fragmentation happens in some C++ programs. It also happens in C
> programs that do the same work. In C++ you have more opportunities
> to do something about it.
in practice, C++ gives you more opportunities for it to happen to
you. C has explicit mallocing which makes it rare. C++ has malloc
hidden new. yes, you can remake the new
> Fragmentation doesn't happen in some implementations of
> garbage-collected languages. OTOH, garbage-collection is possible
> with C++ as well.
what do you mean by garbage collection? reference counting? how
would you do generational garbage collection of heap memory in C++?
how do you consolidate a fragmented heap? you could have pointers to
anything within in. in ugly code these pointers can be stored in
non-traditional places such ints.
> All variety of problems can arise coding in any language, for
> any application. Problems that cannot be dealt with become language
> problems. In that sense, fragmentation is not a C++ problem.
it is a language problem since C++ cannot do generational garbage
collection.
--
J o h a n K u l l s t a m
[[EMAIL PROTECTED]]
Don't Fear the Penguin!
------------------------------
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
From: Johan Kullstam <[EMAIL PROTECTED]>
Date: 27 Jun 1999 22:46:54 -0400
[EMAIL PROTECTED] (Bruce Hoult) writes:
> In article <[EMAIL PROTECTED]>, Johan Kullstam
> <[EMAIL PROTECTED]> wrote:
>
> > > > on the other hand, common-lisps like CMUCL can acheive near C or
> > > > fortran execution speed. speed is not exclusively the domain of the
> > > > C-like languages.
> > >
> > > I agree. The biggest problem with this is that Common Lisp is limited by
> > > things such as the lack of type (and other) declarations which would
> > > otherwise allow the compiler to generate even better code in many
> > > situations.
> >
> > this is simply not true. lisp *has* types. lisp *has* type
> > declarations. just because the langauage doesn't require explicitly
> > declaring them everywhere doesn't mean it will not let you specify
> > type and optimize accordingly.
>
> Yes I *know* Lisp has type declarations. See the "(and other)" above.
>
> Does CMUCL have a way of declaring that a certain class will never have
> subclasses added? Does CMUCL have a way of declaring that a certain
> generic function will never have methods added or removed?
generic functions as part of CLOS cannot guarentee that new methods
will not be added. however, if at calling you are passing variables
with declared types, then the specific method can be deduced at
compile-time. i am not very familiar with CLOS and how well this is
optimized is dependent upon your lisp implementation.
> If it doens't then how can it optomise this call? Some other bit of code
> may change what "+" means at runtime.
in this instance, + isn't a generic and cannot be overloaded.
overloading isn't such a big deal since many times a function like +
is passed as an arg. for example if you have a mat:+ to add matrices,
you can do
(apply #'+ list-of-numbers)
or
(apply #'mat:+ matrix-list)
depending on the type. if it's tedious to write and sort out the
variants, you can always write a macro.
--
J o h a n K u l l s t a m
[[EMAIL PROTECTED]]
Don't Fear the Penguin!
------------------------------
From: [EMAIL PROTECTED] (Greg Comeau)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking,comp.lang.c++
Subject: Re: Why not C++
Date: 27 Jun 1999 23:17:45 -0400
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:
>On Sat, 26 Jun 1999 00:53:24 +1200, Bruce Hoult <[EMAIL PROTECTED]>
>wrote:
>>Not true, IMHO. Even such simple things as // comments, declaring
>>variables at first use, inline functions and const instead of #define,
>>structs as type names, references, cleaned-up casting, and default
>>arguments make C++ better than C.
>
>None of these things compel me to use C++. The C compiler, e.g., gcc,
>will automatically inline small functions functions. In addition, gcc
>supports an `inline' keyword. As far as structs as type names go, why
>not use a typedef? That is,
>
> typedef struct
> {
> int whatever;
> }
> Whatever;
>
> Whatever X;
This doesn't follow and so seems flawed. Ok, for whatever reason, you
don't like or understand or need (whichever applies) C++. However,
with your reasoning, doing the typedef would not be compelling either.
So why wouldn't you just use struct and not typedef? For that matter,
why not just code in binary?
>Now consider references:
>
> int x;
> x = 1;
> some_function (x);
>
>what will be x's value after the call to some_function? Will it be
>altered? In C, I know immediately know the answer to the question and
>do not have to look further. This kind of syntactic sugar disturbs me
>as one who reads a lot of software that I did not write.
You're setting up straw men. Quick, what will x's value be after the
call to some_other_function?
some_other_function(&x);
So you're wrong. Yep, clearly the C-style use the &, but you do not know
the answer and you do have to look further.
>Regarding //, in two keystrokes, my editor puts /* */ at the end of
>the current line and places the cursor in the middle. If the comment
>requires more than one line, I either hit return to continue onto the
>next line, or reformat the comment as text. I claim that very little
>is achieved by using // comments.
Very little is achieved by your putting blank lines between the paragraphs
in your posts, but I find you still do it. Like above, your staements
are conflicting themselves.
>Please note, I am not arguing that C++ is not a better language than
>C. I am just saying that the reasons that you listed do not make it a
>better language.
Many people feel differently. And even some who don't agree that some
of your counter-arguments above are not sound.
> In my opinion, the only thing that C++ has over C is
>better support for data encapsulation via classes and, possibly,
>exception handling. Other features such as operator overloading I can
Mentioning possibility of abuse is yet another straw man.
I can only conclude from your post that you really don't know much
about C++. At the least, you certainly have not chosen your technical
facts wisely, over and over again.
- Greg
--
Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
Producers of Comeau C/C++ 4.2.38 -- New Release! We now do Windows too.
Email: [EMAIL PROTECTED] / Voice:718-945-0009 / Fax:718-441-2310
*** WEB: http://www.comeaucomputing.com ***
------------------------------
From: "Ape Man" <[EMAIL PROTECTED]>
Subject: need some help with some required programs
Date: Sun, 27 Jun 1999 23:10:33 -0400
Hello,
I am currently devloping a portable mp3 car player. Yes, there are many
out there and I could probably buy one and save alot of time and effort, but
I have spent the past two weeks developing a paper model for onee that no
one currently has built. I want to develope it and maybe market it, but
first I just want to build working model for my enjoyment. Im not going to
get into it too much, but what I need (because I can not program very well)
is three programs that an work together at various points. One program must
create and organize mp3 easily, one program must play and find mp3s and the
third (which is still in developement) must do most of what the otheres do
plus a few other options that will be decided upon later. Also, the second
and third programs most be able to communicate over ethernet with each
other. the third program ma have to be able to run on Win95 or win98 but
that still remains to be decided.
If you are interested in helping me out, or want to talkk about my project,
or if there is even ssuch programs that are already out there, please email
Thanks
shawn
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
