In article <a6ohei$4v...@cascade.cs.ubc.ca>, gill...@cs.ubc.ca says...

You've hit the nail right on the head with this post! Good analogy too
:).

Whats wrong Bart, have you recognized yourself in the above paragraph?

In article <3C90BC56.878E6...@hobbiton.org>, NotFound

Can't there be more than one advantage to using the standard libraries
over custom user code? I'm not sure what "the" advantage means, anyway.

Libraries allow increased resources to be invested in their production,
due to a larger number of users (as compared to single-use non-library
code). These extra resources can be used to make the library more robust,
easier to use, more efficient, smaller, easily portable, etc.

The standard libraries are some of the most widely used, due to their
inclusion with virtually every compiler. Since the interface is largely
fixed, resources can go mainly to robustness and efficiency. I'd expect
speed-critical portions of the standard libraries to be quite optimized.
These include memory copy, basic string operations, freestore management,
and I/O. Since the standard library is often supplied by the compiler
vendor, architecture-specific optimizations are sometimes present
(especially in the memory/string functions).

As far as writing something as fast as the standard library, the issue is
the amount of efficiency you can get for a moderate cost. Given unlimited
resources, you can compete with any library. Given a practical amount of
resources, it's often a win to use the standard library.

news:e0821c1d.0203161511.1833aab4@posting.google.com...
<news:ymWj8.19056$Yg2.2167677@news20.bellglobal.com>...

I couldn't care less for this debate, nor for your flamebait. Follow-
ups set.

Bart.

I agree with your statement that the main advantage of the standard
library is its speed and its stability. But you cannot always write an
equally fast alternative to its routines in standard C++, because they
might be implemented in assembler. And hand-crafted assembler written
by skilled programmers is still faster than most output of nowadays'
compilers. The main problem is that the standard library is written
specifically for a platform, while portable code isn't.

For an example, you can search this ng for a few hundred posts about
'FastString' by Peter Olcott. Although 99% if not more of those
threads are total crap, one interesting fact which emerges is that
Olcott's own standard C++ (or C for that matter) kind-of
implementation was still quite a lot slower than the standard
library's memcpy. This may be a function where optimization is
especially important, but there are others as well. One example might
be a deque, which is generally implemented as a bunch of blocks; those
blocks might have a certain size due to the platform's memory access
methods, which can not be detected by standard C++.

Aaron

You cannot write it in standard C++, i agree, but out of this newsgroup
(comp.lang.c++) is not the only way of write code ;) If the need for
speed in important one can use platform especific extensions,
assembler... and achieve the portability with conditional compilation
for each platform required. That need time and resources and is not
always an alternative, of course.

Aaaaahhhh!!!! Please, not, i don't want to read Olcott's inevntions
again :D

And there are others cases when not, i am sure. And in Olcott's threads
I remember read apropos of std::string that specific specialization for
basic_string<char> is not used almost in one compiler for the reason
that stability is more important than speed for the customers. Then one
cannot expect that the standard library is optimized in all cases.

Regards.

"Lame C++" can bootstarp because if does not compile it does not show
the message.
Did you mean that Lame C++ was previously built on some other
compiler, because then the fault can be in the other compiler, so why
blame Lame C++.

My main reason for asking was that Ioannis said that working with
something called container or box[Sorry I forget these things] would
@not@ make my code slower if instead I used the variable sized arrays
of C99, I disagree mainly because it depends upon what I need, if I
need only to have variable sized arrays, then they would under most
circumstances provide better performence.
What do you think?
Also what about the virtual functions I hear that they make the
performence slower.

[BIG SNIP]

The equivalent of a code printing something like

#include <stdio.h>

int main()
{
        printf("Choo Mantar");

in C++ would be

#include <cstdio>
using std::cout

int main()
{
        printf("Choo Mantar");

I have quite very much times considered using

std::cout << "This " << "is" << "         ";

To be slower than

printf("This is            ");

Thanks for showing. However how general is this observation?

How do you define "Write-only" language.

P.S. I disagree with the type of arguments that you give like Zog C++
inserting a delay, it would be nice if you could not waste others time
with these arguements. Thanks.

PPS Somewhere you mentioned that the only way to win this arguement is
not to participate. I realised that and did not post[Frankly I had
other reasons also], But what about you, you also seem to be with the
stand that C is always faster than C++.

news:51d20cd0.0203170958.517da407@posting.google.com...
<news:3C91B1C1.7C16EE5C@eton.powernet.co.uk>...

<Snip>

Don't blame the other compiler either, blame those who developed Lame C++.

I don't get it, any fault found in something I produce I can blame on the
development tools. How then do I react to accolades?

/Al

news:51d20cd0.0203170958.517da407@posting.google.com...

That's a good theory. :)

C++ containers aren't slower, the only thing they have is space cost.
They do hot have time cost because their member functions are inlined.
An example, std::string vs char * in my tests:

http://users.forthnet.gr/ath/jvr/c++faq.htm

They have a slightly more cost than conventional member functions but in
the context they are used that is expected anyway (e.g. the example of
Richard Heathfield where he said he likes to store keeping information
himeself).

From my measurements i have found no additional time cost between cout
in printf in both my compilers.

See it from a philosophical view. Almost the whole C89 is a subset of
C++, so how can it be faster than C++? :)

--
Ioannis

* Ioannis Vranos
* Programming pages: http://www.noicys.d2g.com
* Alternative URL: http://run.to/noicys

No, although they have certain characteristics in common.

<snip>

I know, but of course you *do* get one separate specialised version for
each *type*, which was all I intended to claim. My apologies if I didn't
put it clearly enough.

<snip>

--
Richard Heathfield : bin...@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

If it can't compile itself, it can't bootstrap. And it's quite clear
that it can't compile itself.

Your question is based on such a fundamental misunderstanding of my
original point that it's hard to know where to begin answering. Instead,
allow me to re-state the original point.

Ioannis Vranos claimed that MSVC++ was the most broken C++ compiler out
there (or some similar words). I showed him that this is not true, by
providing an example of an even more broken C++ compiler - one that is
so broken it can't even compile a single C++ program. The bootstrapping
joke was just that - a joke.

I think that the question is flawed. The speed of your program depends
far more on your choosing appropriate algorithms and implementing them
well, than it does on your choice of language. Choose the language you
like best, but don't try to pretend that it's faster, or slower, than
the alternative choice.

If you choose the right algorithms, the performance hit of virtual
functions is unlikely to be significant enough to matter.

<snip>

A language in which typical programs are very hard to read.

My point in using that illustration was that implementations, not
languages, determine performance. If you don't want to hear the answer,
don't ask the question.

No, I take the position that implementations, not languages, determine
performance, but that there are some aspects inherent in C++ which will
tend to make it marginally slower than C in some circumstances.
Conversely, there are some situations in which C++ will be faster. It
depends on many factors, of which the overwhelming ones are (1) the
program and (2) the implementation. Your choice of language matters much
less than either of these two factors.

--
Richard Heathfield : bin...@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

A car is a subset of a car+caravan. The car is faster.

This analogy *doesn't* show that C is faster than C++. It only shows
that it is not illogical for the possibility to exist.

--
Richard Heathfield : bin...@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

Intro
-----

A thread has been cross-posted on four groups on the subject of C or
C++.  As I'm only writing as an embedded programmer, I wanted to avoid
adding to that cross-posting fray.  I'm posting this only in CAE.

I should say what my biases are before I speak.  I'm not a C expert,
though I've been using C since 1978 and have written a working, toy C
compiler.  I'm not a C++ expert, though I've been using C++ since 1989
for Windows programming.

What I care about is very different from what many C++ programmers
care about, because my area of designing and coding small embedded
systems does NOT include any Windows or Linux programming.  (That is
not to say I don't program on Windows or Linux, just that I don't
program them for embedded products.)  And keep in mind that I'm
talking about only one facet of my programming experience -- the
embedded facet.  And that my embedded universe is NOT the same as the
embedded universe as a whole -- again, it is only a subset of that,
too.

I'm very interested in using C++ in my projects.  I'm just quite
skeptical, for a variety of reasons, about using one.

My World and Welcome To It
--------------------------

My world includes processors with as little as 500 instructions of
code space, or so.  Some of my applications only require 1/10th of
that, to be honest.  I rarely, very rarely get to use a processor with
more than 32k instructions available.  The RAM is often limited to a
few tens of bytes and rarely gets more than 2-3k byte.  I'm currently
working on several projects:  one with 512 words of code space and 128
bytes of ram; one with 16k word of code space and 1500 bytes of ram;
and one with 1/2Mb of code space and 1/8Mb of ram.  This isn't an
unusual mix or me.

For the most part, my applications are sensitive to cost, power, board
space, radiated EMF, and so on.  In part, that means in some cases
that an additional $20 in the CPU section makes the difference between
having a product which succeeds and having a product no one buys, even
if everything else is just fine.

Now for the smaller CPU environments, I usually use assembly, because
those applications often have extremely tight requirements.  I may
need to count cycles to make certain that either path across a branch
boundary takes the same cycle count, for example.  Further, the
application design is the big part of it and the coding time is rather
small by comparison.  So the issue of "faster coding" doesn't really
come into place as much on these smaller systems.  For the larger
applications, I often use C, mixed with assembly.

I can't afford templates, if instantiating support for a data type
causes functions I don't actually use to be generated and linked, for
example.  I can't afford exception handling, if the compiler still
generates defensive code even when I don't use any syntax in my code
for them.

For the greater part, well-optimized and well-designed libraries buy
me exactly zilch for my applications.  That's not entirely true, of
course.  Floating point libraries, for example, can be quite useful.
But by and large, libraries either aren't re-entrant; they make
assumptions which aren't true in my environment; they provide far too
many features and I have no choice but to include them all or use none
of them; and so on.  So talking about the benefits of C++ libraries,
templated or otherwise, makes little headway with me.  At least,
that's how it has been so far for me.

I don't have a purchased operating system, I write my own.  I don't
have a supplied library, I write my own.  I do care about ram usage,
stack usage, and program space.  I care a great deal about partial
template specialization in C++, but I wouldn't care much about access
to large, standard template libraries.

I care a great deal about having control over the processor I work on.
I care most of all in knowing exactly what kind of code is generated
by the compiler I use for syntax I write.  I need to have an intuitive
understanding of what happens for each and every line of source code I
lay down, when I'm writing it.

How many people using C++ know exactly how the vtable mechanism works?
In the face of multiple inheritance?  With virtual base objects?  How
many people how a C++ compiler supports dynamic casts or know what
causes the C++ compiler to generate (or not generate) support for it?
What mechanism does a C++ compiler use for exception handling?  What
does it cost?  Where?  If one stays away from a mechanism, how much of
it is still present?

I need to know what is generated, time and again.  In short, my focus
is exactly on the compiler itself and my ability to know what it does.
For folks working on large systems, it's enough for them to know that
it "doesn't cost much."  For me, cost isn't just a little bit of code
space, a little bit of ram space, and a little bit of execution time.
Sometimes, it's not a matter of degree, but a matter of YES/NO,
GOOD/BAD, WORKS/DOESN'T WORK.  I can't leave these details as some
abstract matter of implementation I can ignore.  Often, the compiler
makes decisions about "what's works for non-critical situations"
because that is where many of the applications are at.

But that's not where MY applications are at.  All the details must be
well understood.  The compiler itself and the linker support is my
main focus.  Not the libraries.

Hopefully, that gives an idea of where I'm coming from to those who
use C++ as part of their application development on systems where the
equivalent transistor count is measured in the 100's of millions or
billions.  I just don't live in their world.

So I'm speaking as one who uses assembly and C for their current
embedded applications and who would enjoy using a subset of C++.  But
I also have some concerns, too.

C++ as a Superset of C
----------------------

Strictly speaking, C++ is not a superset of C.  If unsure of that
fact, pages 816 to 818 in Stroustrup's 3rd edition of "The C++
Programming Language" indicates that some ANSI C programs are not
valid C++ and includes examples, as well.  But for many practical
purposes, developing new source code for C++ looks about like working
with a superset of C.

But it is the object code generation that is more the question mark
for an embedded programmer.  Not so much the source code input to the
compiler.

C++ Exception Semantics
-----------------------

For embedded use, this is an area which worries me where separate
compilation is supported (which it is, in every case I am aware of.)

I know.  Most folks just say, "Well, don't use exceptions then."  But
a properly functioning C++ compiler, it seems to me, must generate
correct code for source code unit A when it has absolutely no idea
what kind of exception handling may be required in source code unit B,
compiled separately and perhaps at a very different time.  And I have
absolutely no confidence at all that the linkers available to an
embedded programmer will cover over the problem I'm about to
illustrate here.

Take this sequence of code, found as part of some function in some
source code file:
       .
       .
       foo ();
       String s;
       foo ();
       .
       .

For purposes of discussion, assume this fragment occurs as part of a
routine that doesn't use try..catch at all in a source code module
that doesn't use try...catch or declare any throws, either.  In fact,
assume the module was written almost like C code by someone who wasn't
thinking about or worrying over exceptions at all.  It might even be a
C source code file modified slightly to take advantage of a few C++
features, such as the String class.

Also, for purposes here, assume that foo() is an external procedure
and that the compiler has a declaration for it, but does not know its
definition.

The C++ compiler, being a smart and proper C++ compiler, sees the
first call to foo() and can just allow a normal stack unwind to occur
if foo() throws an exception.  In other words, no extra code is needed
at this point to support the unwind process.  But once String s has
been created, the C++ compiler knows that it must be properly
destroyed before an unwind can be allowed if an exception occurs later
on.  So the second call to foo() is semantically different from the
first.  If the 2nd call to foo() throws an exception (which it may or
may not) in foo(), the compiler must have placed code designed to
handle the destruction of String s before letting the usual unwind
occur.

Now, the above is a case where a common, garden variety embedded
programmer would imagine that the two calls to foo() would take the
same time, require the same resources, and otherwise be the same.
Most programmers I know would believe and defend that position, even
when told that instead of a C compiler it is a C++ compiler looking at
the source code.  Even the more sensitive thinking programmers who are
aware of exception handling, stack unwinding, and so on, would tend to
pause for a while when faced with a source file which quite simply
contains NO try..catch blocks, no throws, and otherwise completely
avoids any use of C++ syntax related to exceptions.

Yet the C++ compiler *must* be aware of the difficulties and *must*
generate different code in these cases, where foo() is permitted to
generate exceptions.  And without an empty throw clause in it's
declaration, the C++ compiler must assume that it may.

All this, in a snip of code in a function in a module none of which
has any syntax dealing with exceptions at all.

Now, I know it is possible to declare foo() with a throw in the
declaration so that the compiler knows it cannot throw an exception.
The compiler may be able to do better, in code generation in such a
case where careful, explicit attention has been given to the function
declarations.  But in reality, in embedded systems trying to make th
transition to using C++ with programmers learning to use C++ features
and perhaps modifying existing code to be compiled with a C++
compiler, this is ...

read more »

news:doenges.1016437690@lpr.e-technik.tu-muenchen.de...

You are right. The code:

#include <iostream>
#include <cstdio>
#include <ctime>
#include <climits>

int main()
{
 using namespace std;

 clock_t t1, t2, t3, t4;
 unsigned long i;
 const unsigned long LIMIT=16384;

 for(t2=clock(); !((t1=clock())-t2); )
   ;
 for(i=0; i<LIMIT; i++)
    printf("This is useless test, \"Pinky we will take over the
world...\"\n\"Naarf!\"\n");

 t2=clock();

 for(t4=clock(); !((t3=clock())-t4); )
   ;
 for(i=0; i<LIMIT; i++)
    cout<<"This is useless test, \"Pinky we will take over the
world...\"\n\"Naarf!\"\n";

 t4=clock();

 printf("\nprintf() operations took %lu clock_t\n",
static_cast<clock_t>(t2-t1));
 cout<<"cout operations took " << t4-t3<<" clock_t"<<endl;

produces in my machine (MINGW32 compiler). I have run them minimized
because printing these on screen on the fly would take considerable
time.

1st run:

printf() operations took 4686 clock_t
cout operations took 982 clock_t

2nd run:

printf() operations took 4957 clock_t
cout operations took 971 clock_t

Does this mean "C is slower"? Of course not. But it can't be faster than
C++.

Also check http://users.forthnet.gr/ath/jvr/c++faq.htm for another
timining experiment i have done.

--
Ioannis

* Ioannis Vranos
* Programming pages: http://www.noicys.d2g.com
* Alternative URL: http://run.to/noicys

news:3C95AFBD.FBC7D218@eton.powernet.co.uk...

Well, next time don't chalenge if VC++ is not the most broken compiler.
You are going against common sense. :P Seriously speaking i said that as
an exaggeration, just don't comment on ANSI C++ code that it doesn't
compile under VC++. :)

--
Ioannis

* Ioannis Vranos
* Programming pages: http://www.noicys.d2g.com
* Alternative URL: http://run.to/noicys