Hi,
I have recently begun using templates in C++ and have found it to be
quite useful. However, hearing stories of code bloat and assorted
problems I decided to write a couple of small programs to check. What I
expected was that there would be minor code bloat and some speed
improvement when using templates. However...
I wrote a basic list container (using templates), and a list container
(using virtual derived classes). I also tried with the std lib vector
class. I ran 1000000 inserts and accesses to all these lists and got
the following results (compiling on windows with microsoft compiler):
Size:
22,528 mytpl.exe
36,864 nonstd.exe
40,960 std.exe
The first is my template list, the second my non-template list, and the
third is using the std vector.
The first surprise was that my template list was actually *smaller*
than the non-template version! Very surprising. However, it's not all
good news. I then ran some timing tests.
Time:
875: running std.exe
1484: running nonstd.exe
1563: running mytpl.exe
As expected, the std vector is the fastest. However my template list
class is the *slowest*!!! This was definitly not expected.
Does anyone have any inputs on what's going on?
cheers,
/Charles
45  2827  ch**********@gmail.com wrote:
[..]
As expected, the std vector is the fastest. However my template list
class is the *slowest*!!! This was definitly not expected.
Does anyone have any inputs on what's going on?
Not really. How can anyone tell anything about the performance of
_your_ program we cannot see, on _your_ computer, without any
ability to measure anything? Are you kidding?
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Victor Bazarov wrote:
ch**********@gmail.com wrote:
[..]
As expected, the std vector is the fastest. However my template list
class is the *slowest*!!! This was definitly not expected.
Does anyone have any inputs on what's going on?
Not really. How can anyone tell anything about the performance of
_your_ program we cannot see, on _your_ computer, without any
ability to measure anything? Are you kidding?
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Hmmm.... well that's a good point. I couldn't find any way of uploading
my code.
However, it's pretty small, so I'll just paste it below
----------------------- Template List ----------------------------
template <class T>
class ListNode
{
public:
ListNode (T * pVal) {uVal = pVal;}
T * uVal;
ListNode<T>* uNext;
ListNode<T>* uPrev;
};
template <class T>
class MyTList
{
public:
MyTList () { vFirst = NULL; }
void Insert (T * e) {
ListNode<T* ln;
ln = new ListNode<T(e);
ln->uNext = vFirst;
ln->uPrev = NULL;
if (vFirst != NULL)
vFirst->uPrev = ln;
vFirst = ln;
}
ListNode<T* GetNodes () { return vFirst;}
private:
ListNode<T* vFirst;
};
--------------------------------- Template List ends
----------------------------
--------------------------------- Non Template List
-----------------------------
class ListElem
{
public:
virtual ~ListElem (void) {}
ListElem * uNext;
ListElem * uPrev;
};
class MyList
{
public:
MyList () { vFirst = NULL;}
void Insert (ListElem * e) {
e->uNext = vFirst;
e->uPrev = NULL;
if (vFirst != NULL)
vFirst->uPrev = e;
vFirst = e;
}
ListElem * GetNodes () { return vFirst; }
private:
ListElem * vFirst;
};
------------------------------ Non template list ends
--------------------------
Note that the code is *very* similar. I had to derive a ListElem for
the non-template class:
class MyClassElem : public ListElem
{
public:
MyClassElem (MyClass * c) { uMyClass = c; }
MyClass * uMyClass;
};
But didn't have to do anything for the template version.
The cpp test code basically just runs two loops (inserting and
get-ting).
cheers,
/Charles ch**********@gmail.com wrote:
Victor Bazarov wrote:
>ch**********@gmail.com wrote:
>>[..]
As expected, the std vector is the fastest. However my template list
class is the *slowest*!!! This was definitly not expected.
Does anyone have any inputs on what's going on?
Not really. How can anyone tell anything about the performance of
_your_ program we cannot see, on _your_ computer, without any
ability to measure anything? Are you kidding?
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Hmmm.... well that's a good point. I couldn't find any way of
uploading my code.
What do you mean?
However, it's pretty small, so I'll just paste it below
It would be best to have all of it, especially to see how you use
your classes and the vector.
----------------------- Template List ----------------------------
template <class T>
class ListNode
{
public:
ListNode (T * pVal) {uVal = pVal;}
T * uVal;
ListNode<T>* uNext;
ListNode<T>* uPrev;
};
template <class T>
class MyTList
That's a misnomer. You might want to call it 'MyTPTRList', since
you're not storing T, but you store pointers to T.
Now, you don't show how you actually fill it up. Are you creating
objects in the free store (using 'new')?
{
public:
MyTList () { vFirst = NULL; }
void Insert (T * e) {
ListNode<T* ln;
ln = new ListNode<T(e);
ln->uNext = vFirst;
ln->uPrev = NULL;
if (vFirst != NULL)
vFirst->uPrev = ln;
vFirst = ln;
}
ListNode<T* GetNodes () { return vFirst;}
private:
ListNode<T* vFirst;
};
--------------------------------- Template List ends
----------------------------
--------------------------------- Non Template List
-----------------------------
class ListElem
{
public:
virtual ~ListElem (void) {}
ListElem * uNext;
ListElem * uPrev;
};
class MyList
{
public:
MyList () { vFirst = NULL;}
void Insert (ListElem * e) {
e->uNext = vFirst;
e->uPrev = NULL;
if (vFirst != NULL)
vFirst->uPrev = e;
vFirst = e;
}
ListElem * GetNodes () { return vFirst; }
private:
ListElem * vFirst;
};
------------------------------ Non template list ends
--------------------------
Note that the code is *very* similar. I had to derive a ListElem for
the non-template class:
class MyClassElem : public ListElem
{
public:
MyClassElem (MyClass * c) { uMyClass = c; }
MyClass * uMyClass;
};
But didn't have to do anything for the template version.
The cpp test code basically just runs two loops (inserting and
get-ting).
I took your code, derived DoubleListElem from ListElem, and here is
the test driver:
int main()
{
clock_t c0 = clock();
MyTList<doublemtld;
for (int i = 0; i < 1000000; ++i)
mtld.Insert(new double(i));
clock_t c1 = clock();
MyList mld;
for (int i = 0; i < 1000000; ++i)
mld.Insert(new DoubleListElem(new double(i)));
clock_t c2 = clock();
std::cout << "Template: " << c1 - c0 << std::endl;
std::cout << "Nontemplate: " << c2 - c1 << std::endl;
}
The template turned out a tiny bit faster. Now, if you want to
really compare it to the behaviour of 'std::vector', you need to
(a) store values, not pointers, (b) figure out better 'Insert'
strategy, possibly without the 'if'.
Since your code for both template and non-template List is the
same, virtually, there should be essentially no difference (and
there wasn't in my test). What is it you're trying to accomplish?
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Victor Bazarov wrote:
ch**********@gmail.com wrote:
Victor Bazarov wrote:
ch**********@gmail.com wrote:
[..]
As expected, the std vector is the fastest. However my template list
class is the *slowest*!!! This was definitly not expected.
Does anyone have any inputs on what's going on?
Not really. How can anyone tell anything about the performance of
_your_ program we cannot see, on _your_ computer, without any
ability to measure anything? Are you kidding?
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Hmmm.... well that's a good point. I couldn't find any way of
uploading my code.
What do you mean?
However, it's pretty small, so I'll just paste it below
It would be best to have all of it, especially to see how you use
your classes and the vector.
----------------------- Template List ----------------------------
template <class T>
class ListNode
{
public:
ListNode (T * pVal) {uVal = pVal;}
T * uVal;
ListNode<T>* uNext;
ListNode<T>* uPrev;
};
template <class T>
class MyTList
That's a misnomer. You might want to call it 'MyTPTRList', since
you're not storing T, but you store pointers to T.
Now, you don't show how you actually fill it up. Are you creating
objects in the free store (using 'new')?
{
public:
MyTList () { vFirst = NULL; }
void Insert (T * e) {
ListNode<T* ln;
ln = new ListNode<T(e);
ln->uNext = vFirst;
ln->uPrev = NULL;
if (vFirst != NULL)
vFirst->uPrev = ln;
vFirst = ln;
}
ListNode<T* GetNodes () { return vFirst;}
private:
ListNode<T* vFirst;
};
--------------------------------- Template List ends
----------------------------
--------------------------------- Non Template List
-----------------------------
class ListElem
{
public:
virtual ~ListElem (void) {}
ListElem * uNext;
ListElem * uPrev;
};
class MyList
{
public:
MyList () { vFirst = NULL;}
void Insert (ListElem * e) {
e->uNext = vFirst;
e->uPrev = NULL;
if (vFirst != NULL)
vFirst->uPrev = e;
vFirst = e;
}
ListElem * GetNodes () { return vFirst; }
private:
ListElem * vFirst;
};
------------------------------ Non template list ends
--------------------------
Note that the code is *very* similar. I had to derive a ListElem for
the non-template class:
class MyClassElem : public ListElem
{
public:
MyClassElem (MyClass * c) { uMyClass = c; }
MyClass * uMyClass;
};
But didn't have to do anything for the template version.
The cpp test code basically just runs two loops (inserting and
get-ting).
I took your code, derived DoubleListElem from ListElem, and here is
the test driver:
int main()
{
clock_t c0 = clock();
MyTList<doublemtld;
for (int i = 0; i < 1000000; ++i)
mtld.Insert(new double(i));
clock_t c1 = clock();
MyList mld;
for (int i = 0; i < 1000000; ++i)
mld.Insert(new DoubleListElem(new double(i)));
clock_t c2 = clock();
std::cout << "Template: " << c1 - c0 << std::endl;
std::cout << "Nontemplate: " << c2 - c1 << std::endl;
}
The template turned out a tiny bit faster. Now, if you want to
really compare it to the behaviour of 'std::vector', you need to
(a) store values, not pointers, (b) figure out better 'Insert'
strategy, possibly without the 'if'.
Since your code for both template and non-template List is the
same, virtually, there should be essentially no difference (and
there wasn't in my test). What is it you're trying to accomplish?
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Hi,
I tried your program and the template version *is* faster - so I'm
really confused. The rest of my code follows:
--------------------- SImple class MyClass (used as values)
---------------------------
class MyClass
{
public:
MyClass (int i) {uI = i; }
int uI;
};
-------------------- Main that runs a test on Template List
-----------------
void main (int argc, char * argv[])
{
MyTList<MyClass one;
ListNode<MyClass* onenode;
long sumone;
for (int i = 0;i < 1000000;i++) {
one.Insert (new MyClass (i));
}
sumone = 0;
onenode = one.GetNodes ();
while (onenode) {
sumone += (onenode->uVal->uI);
onenode = onenode->uNext;
}
}
----------------- Main that runs a test on NonTemplate list
--------------------
void main (int argc, char * argv[])
{
MyList one;
MyClassElem * onenode;
long sumone;
for (int i = 0;i < 1000000;i++) {
one.Insert (new MyClassElem (new MyClass (i)));
}
sumone = 0;
onenode = (MyClassElem*)one.GetNodes ();
while (onenode) {
sumone += onenode->uMyClass->uI;
onenode = (MyClassElem *)onenode->uNext;
}
}
-------------------------- Timer app that runs the above as exes
-----------
void run (char * app)
{
PROCESS_INFORMATION pi;
STARTUPINFO si;
ZeroMemory (&si, sizeof (si));
si.cb = sizeof (si);
si.lpReserved = NULL;
ZeroMemory (&pi, sizeof (pi));
CreateProcess (NULL, app, NULL, NULL, FALSE, 0, NULL, NULL, &si,
&pi);
WaitForSingleObject (pi.hProcess, INFINITE);
}
void main (int argc, char * argv[])
{
DWORD start;
DWORD diff;
if (argc != 2) {
printf("Usage: timer <program to time>\n");
return;
}
start = GetTickCount ();
run (argv[1]);
diff = GetTickCount () - start;
printf("%d: running %s\n", diff, argv [1]);
}
------------------------------- Code Block Ends
--------------------------------------
What I am trying to do is to check if we can use template-based lists
in our company code. We are currently using lists similar to the
non-template version (with derived classes) and the mandate is that the
template list should have a clear advantage if we've to adopt it.
cheers,
/Charles ch**********@gmail.com wrote:
[..]
What I am trying to do is to check if we can use template-based lists
in our company code. We are currently using lists similar to the
non-template version (with derived classes) and the mandate is that
the template list should have a clear advantage if we've to adopt it.
Then stop screwing around and use 'std::list'. And get a book on the
Standard library, preferrably a copy for every programmer on your team
so that nobody is left out trying to figure it out by themselves. I
recommend "Effective" series by Meyers, *all of them*.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Victor Bazarov wrote:
ch**********@gmail.com wrote:
[..]
What I am trying to do is to check if we can use template-based lists
in our company code. We are currently using lists similar to the
non-template version (with derived classes) and the mandate is that
the template list should have a clear advantage if we've to adopt it.
Then stop screwing around and use 'std::list'. And get a book on the
Standard library, preferrably a copy for every programmer on your team
so that nobody is left out trying to figure it out by themselves. I
recommend "Effective" series by Meyers, *all of them*.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Sadly I have no chance of selling the usage of std::list without first
proving that templates are not evil. Plus we do not use exceptions in
our code and the overhead of exception usage is not acceptable to our
company. I did try the std::vector (which was bigger but faster).
In any case I'm still not clear why the timing results are different.
Another intersting point is when I changed your code to use "MyClass"
instead of "double" the template list became slower again!
cheers,
/Charles
Victor Bazarov wrote:
I
recommend "Effective" series by Meyers, *all of them*.
Is there more than the two? ch**********@gmail.com wrote:
Victor Bazarov wrote:
>ch**********@gmail.com wrote:
>>[..]
What I am trying to do is to check if we can use template-based
lists in our company code. We are currently using lists similar to
the non-template version (with derived classes) and the mandate is
that the template list should have a clear advantage if we've to
adopt it.
Then stop screwing around and use 'std::list'. And get a book on the
Standard library, preferrably a copy for every programmer on your
team so that nobody is left out trying to figure it out by
themselves. I recommend "Effective" series by Meyers, *all of them*.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Sadly I have no chance of selling the usage of std::list without first
proving that templates are not evil.
No offence, but you may not be good enough to prove that. That's what
the books written by experts are for.
Besides, no element of the language is "evil" per se. Just like spoons
do not make anybody fat. It's how you use them. One says, "macros are
evil". I say that I cannot do without them in certain situations. What
am I to do? Go hang myself?
Plus we do not use exceptions in
our code and the overhead of exception usage is not acceptable to our
company. I did try the std::vector (which was bigger but faster).
Bigger but faster on what operations? And what relation does 'vector'
have to "no exceptions" policy of your company? It does throw, if you
must know.
In any case I'm still not clear why the timing results are different.
Another intersting point is when I changed your code to use "MyClass"
instead of "double" the template list became slower again!
So what? Performance is a characteristic of an entire application.
It cannot be deduced from the techniques used or from the language in
which the application is written (obvious cases aside). It can only
be *measured*. If your company is concerned with performance, you need
to use tools to figure out what part of your application is slow and
why, and what to do about it. Don't guess [that templates are going to
solve all your problems]. Only use certain elements of the language if
you see that there is no moving forward without them.
You can always improve the performance of some code by either reducing
the amount of [unnecessary] work it's doing or by sacrificing something
else, like memory footprint. Does it have to involve templates? No.
Do templates help? Not really. It's not what they are for.
The bottomline: learn the language, learn what different elements are
for, and use them as appropriate. But FCOL, learn the language!
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
charles.l...@gmail.com skrev:
Victor Bazarov wrote:
ch**********@gmail.com wrote:
[..]
What I am trying to do is to check if we can use template-based lists
in our company code. We are currently using lists similar to the
non-template version (with derived classes) and the mandate is that
the template list should have a clear advantage if we've to adopt it.
Then stop screwing around and use 'std::list'. And get a book on the
Standard library, preferrably a copy for every programmer on your team
so that nobody is left out trying to figure it out by themselves. I
recommend "Effective" series by Meyers, *all of them*.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Sadly I have no chance of selling the usage of std::list without first
proving that templates are not evil. Plus we do not use exceptions in
our code and the overhead of exception usage is not acceptable to our
company.
What overhead? Unless you write quite specialised code, the overhead of
exceptionhandling is certainly acceptable. As I assume that your
company does try to do some errorhandling, the overhead of
exception-handling is not just something you pay for. You do also get
something in return - namely no longer needing to continuously check
return codes.
This is not just a programmer convenience. It is also far less code,
far less clutter and faster programs, but most importantly it's
increased reliability since you are no longer as likely to overlook
missing return code checks. I can tell you, as I right now work for a
company with the same exception policy (no exceptions!) as in your
company, and our codebase does have places where errorcodes are not
checked (and potential resource leaks because the style and the age of
the code means that to many raw allocations are made and not always
freed after use). The problem with my company is not only that there is
a distrust in exceptions (probably for the same silly reasons that your
company has) and that our codebase is very large (20000 sourcefiles on
the project I am working on), so I can see some raison in not changing
policy. Unfortunately the same reasoning might very well result in
throwing C++ out the window. No new projects are - to my knowledge -
started in C++ today, and who can really blame that considering the
mess they have brought them self into.
/Peter
I did try the std::vector (which was bigger but faster).
In any case I'm still not clear why the timing results are different.
Another intersting point is when I changed your code to use "MyClass"
instead of "double" the template list became slower again!
cheers,
/Charles
"Noah Roberts" <ro**********@gmail.comwrote in
news:11*********************@16g2000cwy.googlegrou ps.com:
>
Victor Bazarov wrote:
> I
recommend "Effective" series by Meyers, *all of them*.
Is there more than the two?
Yep, three.
Effective C++
More Effective C++
Effective STL
Victor Bazarov wrote:
ch**********@gmail.com wrote:
Victor Bazarov wrote:
ch**********@gmail.com wrote:
[..]
What I am trying to do is to check if we can use template-based
lists in our company code. We are currently using lists similar to
the non-template version (with derived classes) and the mandate is
that the template list should have a clear advantage if we've to
adopt it.
Then stop screwing around and use 'std::list'. And get a book on the
Standard library, preferrably a copy for every programmer on your
team so that nobody is left out trying to figure it out by
themselves. I recommend "Effective" series by Meyers, *all of them*.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Sadly I have no chance of selling the usage of std::list without first
proving that templates are not evil.
No offence, but you may not be good enough to prove that. That's what
the books written by experts are for.
It's true I'm not an expert but I would still like to understand the
language elements I am using. Performance is a key factor in our
company and it's natural for me to try and understand how a feature
like templates would affect it before recommending it's use.
I have started to read "Effective C++" by Scott. It's *excellent*
(thanks for the reco) but it doesn't give me anything much about
performance of templates. Maybe that's because there isn't enough
benchmarks yet or because templates don't have a consistent affect on
performance (??).
I've also read the latest "Technical Report on C++ Performance ISO/IEC
TR 18015:2006(E)" where I picked up that templates <quote>can lead to
an unexpectedly large amount of code and data.</quote>.
Besides, no element of the language is "evil" per se. Just like spoons
do not make anybody fat. It's how you use them. One says, "macros are
evil". I say that I cannot do without them in certain situations. What
am I to do? Go hang myself?
Plus we do not use exceptions in
our code and the overhead of exception usage is not acceptable to our
company. I did try the std::vector (which was bigger but faster).
Bigger but faster on what operations? And what relation does 'vector'
have to "no exceptions" policy of your company? It does throw, if you
must know.
Yes I do know (I have to enable exception sematics while compiling).
It's bigger and faster on the same test case (inserting 1000000
elements and accessing them). The reason I can't recommend it's usage
is simply because it requires exception support.
In any case I'm still not clear why the timing results are different.
Another intersting point is when I changed your code to use "MyClass"
instead of "double" the template list became slower again!
So what? Performance is a characteristic of an entire application.
It cannot be deduced from the techniques used or from the language in
which the application is written (obvious cases aside). It can only
be *measured*. If your company is concerned with performance, you need
to use tools to figure out what part of your application is slow and
why, and what to do about it. Don't guess [that templates are going to
solve all your problems]. Only use certain elements of the language if
you see that there is no moving forward without them.
We do use several tools to measure performance. However, the philosophy
of the company is that the way to good performance is for each
subsystem to squeeze out the best possible performance. This is
especially true for "basic" elements like the list and we have several
high-quality basic elements (like lists, synchronization primitives,
memory managers, etc). The lists are, however, inheritance based so I
wanted to convert to template based because I read that templates were
recommended for containers.
Of course the idea that if everything is high performance, the product
will be high performance is not entirely true (which is why we use
profilers to find bottlenecks), but it does work very well in practice.
Our products are small and _fast_.
I did try looking at some good open source projects (apache httpd and
bekeley db) to see if they use templates but they don't. So maybe I'm
on a sticky wicket here.
You can always improve the performance of some code by either reducing
the amount of [unnecessary] work it's doing or by sacrificing something
else, like memory footprint. Does it have to involve templates? No.
Do templates help? Not really. It's not what they are for.
The holy grail we look for is to improve both speed *and* resource
usage without sacrificing features. It's one of our key
differentiators. It's not easy to do but it's possible.
What really interested me, though, was that while whatever I read
seemed to say that using templates would make your code bigger but
faster, in this simple example templates are smaller and slower!
The bottomline: learn the language, learn what different elements are
for, and use them as appropriate. But FCOL, learn the language!
I will :-). Thanks for your inputs and help so far.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
peter koch wrote:
charles.l...@gmail.com skrev:
Victor Bazarov wrote:
ch**********@gmail.com wrote:
[..]
What I am trying to do is to check if we can use template-based lists
in our company code. We are currently using lists similar to the
non-template version (with derived classes) and the mandate is that
the template list should have a clear advantage if we've to adopt it.
>
Then stop screwing around and use 'std::list'. And get a book on the
Standard library, preferrably a copy for every programmer on your team
so that nobody is left out trying to figure it out by themselves. I
recommend "Effective" series by Meyers, *all of them*.
>
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Sadly I have no chance of selling the usage of std::list without first
proving that templates are not evil. Plus we do not use exceptions in
our code and the overhead of exception usage is not acceptable to our
company.
What overhead? Unless you write quite specialised code, the overhead of
exceptionhandling is certainly acceptable. As I assume that your
company does try to do some errorhandling, the overhead of
exception-handling is not just something you pay for. You do also get
something in return - namely no longer needing to continuously check
return codes.
This is not just a programmer convenience. It is also far less code,
far less clutter and faster programs, but most importantly it's
increased reliability since you are no longer as likely to overlook
missing return code checks. I can tell you, as I right now work for a
company with the same exception policy (no exceptions!) as in your
company, and our codebase does have places where errorcodes are not
checked (and potential resource leaks because the style and the age of
the code means that to many raw allocations are made and not always
freed after use). The problem with my company is not only that there is
a distrust in exceptions (probably for the same silly reasons that your
company has) and that our codebase is very large (20000 sourcefiles on
the project I am working on), so I can see some raison in not changing
policy. Unfortunately the same reasoning might very well result in
throwing C++ out the window. No new projects are - to my knowledge -
started in C++ today, and who can really blame that considering the
mess they have brought them self into.
/Peter
Exception handling does have *significant* peformance overhead.
<quote>Compared to a normal function return, returning from a function
by throwing an exception may be as much as three orders of magnitude
(!) slower</quote>. Even though you may incur this cost rarely
(depending on how you use exceptions), there is still potential code
bloat and a performance hit.
We use assertions quite generously (which reduces the number of error
returns drastically) and that works very well. We have no
memory/resource leaks (in our codebase of 3500 files - not nearly as
large as yours) and we do check for return codes everywhere.
IMHO exceptions aren't that great anyway (also see http://www.joelonsoftware.com/items/2003/10/13.html) because they don't
mandate who deals with them (i.e. there is no ownership of errors). In
the return code world the caller *must* deal with the error conditions.
In the exception world, he can ignore it to the peril of functions
higher up in the chain.
Having said that, exceptions could be useful for simple, or business
oriented programs where performance isn't a major factor (like much of
Java code). Or maybe we need to think up a different paradigm for error
handling altogether.... ch**********@gmail.com wrote:
peter koch wrote:
charles.l...@gmail.com skrev:
Victor Bazarov wrote:
ch**********@gmail.com wrote:
[..]
What I am trying to do is to check if we can use template-based lists
in our company code. We are currently using lists similar to the
non-template version (with derived classes) and the mandate is that
the template list should have a clear advantage if we've to adopt it.
Then stop screwing around and use 'std::list'. And get a book on the
Standard library, preferrably a copy for every programmer on your team
so that nobody is left out trying to figure it out by themselves. I
recommend "Effective" series by Meyers, *all of them*.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
>
Sadly I have no chance of selling the usage of std::list without first
proving that templates are not evil. Plus we do not use exceptions in
our code and the overhead of exception usage is not acceptable to our
company.
What overhead? Unless you write quite specialised code, the overhead of
exceptionhandling is certainly acceptable. As I assume that your
company does try to do some errorhandling, the overhead of
exception-handling is not just something you pay for. You do also get
something in return - namely no longer needing to continuously check
return codes.
This is not just a programmer convenience. It is also far less code,
far less clutter and faster programs, but most importantly it's
increased reliability since you are no longer as likely to overlook
missing return code checks. I can tell you, as I right now work for a
company with the same exception policy (no exceptions!) as in your
company, and our codebase does have places where errorcodes are not
checked (and potential resource leaks because the style and the age of
the code means that to many raw allocations are made and not always
freed after use). The problem with my company is not only that there is
a distrust in exceptions (probably for the same silly reasons that your
company has) and that our codebase is very large (20000 sourcefiles on
the project I am working on), so I can see some raison in not changing
policy. Unfortunately the same reasoning might very well result in
throwing C++ out the window. No new projects are - to my knowledge -
started in C++ today, and who can really blame that considering the
mess they have brought them self into.
/Peter
Exception handling does have *significant* peformance overhead.
<quote>Compared to a normal function return, returning from a function
by throwing an exception may be as much as three orders of magnitude
(!) slower</quote>. Even though you may incur this cost rarely
(depending on how you use exceptions), there is still potential code
bloat and a performance hit.
We use assertions quite generously (which reduces the number of error
returns drastically) and that works very well. We have no
memory/resource leaks (in our codebase of 3500 files - not nearly as
large as yours) and we do check for return codes everywhere.
IMHO exceptions aren't that great anyway (also see
http://www.joelonsoftware.com/items/2003/10/13.html) because they don't
mandate who deals with them (i.e. there is no ownership of errors). In
the return code world the caller *must* deal with the error conditions.
In the exception world, he can ignore it to the peril of functions
higher up in the chain.
Having said that, exceptions could be useful for simple, or business
oriented programs where performance isn't a major factor (like much of
Java code). Or maybe we need to think up a different paradigm for error
handling altogether....
Joel is right about all sorts of things, but he isn't right about
everything. There are contexts within which exceptions are a pain and
places where their use makes no sense or complicates code. But that
isn't the same as saying that they are never the best way of dealing
with a situations.
His two arguments are easily put in perspective though:
"They are invisible in the source code": For the first take a look at http://www.kirit.com/Handling%20COM%...20in%20C%2B%2B on my site
which explores this issue in the context of COM error handling. The
sample code that Microsoft used is buggy precisely because they nest if
statements to handle error conditions. Yes the error checking
statements are clearly visible and that is exactly the problem - they
obscure the flow to such an extent that they themselves become a source
of problems.
"They create too many possible exit points": Joel's second point is
true if you are manually handling resources (i.e. you have to manually
free the resources). Then the extra exit points are an important
consideration. If you're using RIAA then this is a non-issue. And if
you're not using RIAA then you're not really using C++ IMHO.
K
Kirit Sælensminde wrote:
ch**********@gmail.com wrote:
peter koch wrote:
charles.l...@gmail.com skrev:
Victor Bazarov wrote:
ch**********@gmail.com wrote:
[..]
What I am trying to do is to check if we can use template-basedlists
in our company code. We are currently using lists similar to the
non-template version (with derived classes) and the mandate is that
the template list should have a clear advantage if we've to adopt it.
>
Then stop screwing around and use 'std::list'. And get a book onthe
Standard library, preferrably a copy for every programmer on yourteam
so that nobody is left out trying to figure it out by themselves.I
recommend "Effective" series by Meyers, *all of them*.
>
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Sadly I have no chance of selling the usage of std::list without first
proving that templates are not evil. Plus we do not use exceptions in
our code and the overhead of exception usage is not acceptable to our
company.
>
What overhead? Unless you write quite specialised code, the overhead of
exceptionhandling is certainly acceptable. As I assume that your
company does try to do some errorhandling, the overhead of
exception-handling is not just something you pay for. You do also get
something in return - namely no longer needing to continuously check
return codes.
This is not just a programmer convenience. It is also far less code,
far less clutter and faster programs, but most importantly it's
increased reliability since you are no longer as likely to overlook
missing return code checks. I can tell you, as I right now work for a
company with the same exception policy (no exceptions!) as in your
company, and our codebase does have places where errorcodes are not
checked (and potential resource leaks because the style and the age of
the code means that to many raw allocations are made and not always
freed after use). The problem with my company is not only that there is
a distrust in exceptions (probably for the same silly reasons that your
company has) and that our codebase is very large (20000 sourcefiles on
the project I am working on), so I can see some raison in not changing
policy. Unfortunately the same reasoning might very well result in
throwing C++ out the window. No new projects are - to my knowledge -
started in C++ today, and who can really blame that considering the
mess they have brought them self into.
>
/Peter
>
Exception handling does have *significant* peformance overhead.
<quote>Compared to a normal function return, returning from a function
by throwing an exception may be as much as three orders of magnitude
(!) slower</quote>. Even though you may incur this cost rarely
(depending on how you use exceptions), there is still potential code
bloat and a performance hit.
We use assertions quite generously (which reduces the number of error
returns drastically) and that works very well. We have no
memory/resource leaks (in our codebase of 3500 files - not nearly as
large as yours) and we do check for return codes everywhere.
IMHO exceptions aren't that great anyway (also see
http://www.joelonsoftware.com/items/2003/10/13.html) because they don't
mandate who deals with them (i.e. there is no ownership of errors). In
the return code world the caller *must* deal with the error conditions.
In the exception world, he can ignore it to the peril of functions
higher up in the chain.
Having said that, exceptions could be useful for simple, or business
oriented programs where performance isn't a major factor (like much of
Java code). Or maybe we need to think up a different paradigm for error
handling altogether....
Joel is right about all sorts of things, but he isn't right about
everything. There are contexts within which exceptions are a pain and
places where their use makes no sense or complicates code. But that
isn't the same as saying that they are never the best way of dealing
with a situations.
His two arguments are easily put in perspective though:
"They are invisible in the source code": For the first take a look at
http://www.kirit.com/Handling%20COM%...20in%20C%2B%2B on my site
which explores this issue in the context of COM error handling. The
sample code that Microsoft used is buggy precisely because they nest if
statements to handle error conditions. Yes the error checking
statements are clearly visible and that is exactly the problem - they
obscure the flow to such an extent that they themselves become a source
of problems.
"They create too many possible exit points": Joel's second point is
true if you are manually handling resources (i.e. you have to manually
free the resources). Then the extra exit points are an important
consideration. If you're using RIAA then this is a non-issue. And if
you're not using RIAA then you're not really using C++ IMHO.
K
You're argument is perfectly valid - not using exceptions does make the
code less readable and potentially more buggy. The flip side is that
not using exeption also makes the code more efficient. So if you're
willing to pay the price (which we are) of strict reviews/inspections
and a host of automated unit tests it may still not be worth the
overhead of exceptions.
Microsoft code is not a good example in any case. I've been looking at
good open source projects (apache and berkelydb) and they don't use
exceptions or templates. And their code quality is excellent without
paying the price of any overhead. Microsoft's code is both buggy and
bloated - really not the best of examples. :-) :-)
Kirit Sælensminde wrote:
ch**********@gmail.com wrote:
peter koch wrote:
charles.l...@gmail.com skrev:
Victor Bazarov wrote:
ch**********@gmail.com wrote:
[..]
What I am trying to do is to check if we can use template-basedlists
in our company code. We are currently using lists similar to the
non-template version (with derived classes) and the mandate is that
the template list should have a clear advantage if we've to adopt it.
>
Then stop screwing around and use 'std::list'. And get a book onthe
Standard library, preferrably a copy for every programmer on yourteam
so that nobody is left out trying to figure it out by themselves.I
recommend "Effective" series by Meyers, *all of them*.
>
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Sadly I have no chance of selling the usage of std::list without first
proving that templates are not evil. Plus we do not use exceptions in
our code and the overhead of exception usage is not acceptable to our
company.
>
What overhead? Unless you write quite specialised code, the overhead of
exceptionhandling is certainly acceptable. As I assume that your
company does try to do some errorhandling, the overhead of
exception-handling is not just something you pay for. You do also get
something in return - namely no longer needing to continuously check
return codes.
This is not just a programmer convenience. It is also far less code,
far less clutter and faster programs, but most importantly it's
increased reliability since you are no longer as likely to overlook
missing return code checks. I can tell you, as I right now work for a
company with the same exception policy (no exceptions!) as in your
company, and our codebase does have places where errorcodes are not
checked (and potential resource leaks because the style and the age of
the code means that to many raw allocations are made and not always
freed after use). The problem with my company is not only that there is
a distrust in exceptions (probably for the same silly reasons that your
company has) and that our codebase is very large (20000 sourcefiles on
the project I am working on), so I can see some raison in not changing
policy. Unfortunately the same reasoning might very well result in
throwing C++ out the window. No new projects are - to my knowledge -
started in C++ today, and who can really blame that considering the
mess they have brought them self into.
>
/Peter
>
Exception handling does have *significant* peformance overhead.
<quote>Compared to a normal function return, returning from a function
by throwing an exception may be as much as three orders of magnitude
(!) slower</quote>. Even though you may incur this cost rarely
(depending on how you use exceptions), there is still potential code
bloat and a performance hit.
We use assertions quite generously (which reduces the number of error
returns drastically) and that works very well. We have no
memory/resource leaks (in our codebase of 3500 files - not nearly as
large as yours) and we do check for return codes everywhere.
IMHO exceptions aren't that great anyway (also see
http://www.joelonsoftware.com/items/2003/10/13.html) because they don't
mandate who deals with them (i.e. there is no ownership of errors). In
the return code world the caller *must* deal with the error conditions.
In the exception world, he can ignore it to the peril of functions
higher up in the chain.
Having said that, exceptions could be useful for simple, or business
oriented programs where performance isn't a major factor (like much of
Java code). Or maybe we need to think up a different paradigm for error
handling altogether....
Joel is right about all sorts of things, but he isn't right about
everything. There are contexts within which exceptions are a pain and
places where their use makes no sense or complicates code. But that
isn't the same as saying that they are never the best way of dealing
with a situations.
His two arguments are easily put in perspective though:
"They are invisible in the source code": For the first take a look at
http://www.kirit.com/Handling%20COM%...20in%20C%2B%2B on my site
which explores this issue in the context of COM error handling. The
sample code that Microsoft used is buggy precisely because they nest if
statements to handle error conditions. Yes the error checking
statements are clearly visible and that is exactly the problem - they
obscure the flow to such an extent that they themselves become a source
of problems.
"They create too many possible exit points": Joel's second point is
true if you are manually handling resources (i.e. you have to manually
free the resources). Then the extra exit points are an important
consideration. If you're using RIAA then this is a non-issue. And if
you're not using RIAA then you're not really using C++ IMHO.
K
[OFF TOPIC]
Nice article btw - I liked the fonts and layout. Just curious - do you
hand code your site it or is use some program?
[/OFF TOPIC] ch**********@gmail.com wrote:
Microsoft code is not a good example in any case. I've been looking at
good open source projects (apache and berkelydb) and they don't use
exceptions or templates.
Do you think this might have something to do with both of those
projects being written in C and not C++? It's hard to use
exceptions or templates if the language has no support for them. ch**********@gmail.com wrote:
Kirit Sælensminde wrote:
>>Joel is right about all sorts of things, but he isn't right about
everything. There are contexts within which exceptions are a pain and
places where their use makes no sense or complicates code. But that
isn't the same as saying that they are never the best way of dealing
with a situations.
His two arguments are easily put in perspective though:
"They are invisible in the source code": For the first take a look at
http://www.kirit.com/Handling%20COM%...20in%20C%2B%2B on my site
which explores this issue in the context of COM error handling. The
sample code that Microsoft used is buggy precisely because they nest if
statements to handle error conditions. Yes the error checking
statements are clearly visible and that is exactly the problem - they
obscure the flow to such an extent that they themselves become a source
of problems.
"They create too many possible exit points": Joel's second point is
true if you are manually handling resources (i.e. you have to manually
free the resources). Then the extra exit points are an important
consideration. If you're using RIAA then this is a non-issue. And if
you're not using RIAA then you're not really using C++ IMHO.
You're argument is perfectly valid - not using exceptions does make the
code less readable and potentially more buggy. The flip side is that
not using exeption also makes the code more efficient. So if you're
willing to pay the price (which we are) of strict reviews/inspections
and a host of automated unit tests it may still not be worth the
overhead of exceptions.
Nonsense. If exceptions are used as designed, for exception conditions,
the reverse is often true. All those conditionals add more overhead to
the normal program flow than exceptions.
--
Ian Collins. Ch**********@gmail.com wrote:
>
Exception handling does have *significant* peformance overhead.
<quote>Compared to a normal function return, returning from a function
by throwing an exception may be as much as three orders of magnitude
(!) slower</quote>. Even though you may incur this cost rarely
(depending on how you use exceptions), there is still potential code
bloat and a performance hit.
For that to be true, the exception condition would have to occur once
every 1000 calls or less. In which case, is it truly an exception
condition?
We use assertions quite generously (which reduces the number of error
returns drastically) and that works very well. We have no
memory/resource leaks (in our codebase of 3500 files - not nearly as
large as yours) and we do check for return codes everywhere.
IMHO exceptions aren't that great anyway (also see
http://www.joelonsoftware.com/items/2003/10/13.html) because they don't
mandate who deals with them (i.e. there is no ownership of errors). In
the return code world the caller *must* deal with the error conditions.
And if it can't? It passes another error condition back to its caller.
May as well let the run time take care of this, which is what
exceptions do.
In the exception world, he can ignore it to the peril of functions
higher up in the chain.
Having said that, exceptions could be useful for simple, or business
oriented programs where performance isn't a major factor (like much of
Java code). Or maybe we need to think up a different paradigm for error
handling altogether....
You have to differentiate between errors and exception conditions. If
there is a reasonable probability an operation will fail, return an
error. If not, throw and exception.
--
Ian Collins.
ajalk...@gmail.com wrote:
ch**********@gmail.com wrote:
Microsoft code is not a good example in any case. I've been looking at
good open source projects (apache and berkelydb) and they don't use
exceptions or templates.
Do you think this might have something to do with both of those
projects being written in C and not C++? It's hard to use
exceptions or templates if the language has no support for them.
Berkely DB has a C++ version. I just re-checked and the do provide
support (optional) for exceptions, though they do not use templates.
The exception support also can be "turned off".
Could you point me (genuinely) to a powerful project that does use
modern C++? I have been looking but haven't been too successful yet.
Adobe uses the boost library somewhere, but adobe is *so* slow to load
it's a bad example for me. So I'm still looking.
Ian Collins wrote:
Ch**********@gmail.com wrote:
Exception handling does have *significant* peformance overhead.
<quote>Compared to a normal function return, returning from a function
by throwing an exception may be as much as three orders of magnitude
(!) slower</quote>. Even though you may incur this cost rarely
(depending on how you use exceptions), there is still potential code
bloat and a performance hit.
For that to be true, the exception condition would have to occur once
every 1000 calls or less. In which case, is it truly an exception
condition?
We use assertions quite generously (which reduces the number of error
returns drastically) and that works very well. We have no
memory/resource leaks (in our codebase of 3500 files - not nearly as
large as yours) and we do check for return codes everywhere.
IMHO exceptions aren't that great anyway (also see
http://www.joelonsoftware.com/items/2003/10/13.html) because they don't
mandate who deals with them (i.e. there is no ownership of errors). In
the return code world the caller *must* deal with the error conditions.
And if it can't? It passes another error condition back to its caller.
May as well let the run time take care of this, which is what
exceptions do.
In the exception world, he can ignore it to the peril of functions
higher up in the chain.
Having said that, exceptions could be useful for simple, or business
oriented programs where performance isn't a major factor (like much of
Java code). Or maybe we need to think up a different paradigm for error
handling altogether....
You have to differentiate between errors and exception conditions. If
there is a reasonable probability an operation will fail, return an
error. If not, throw and exception.
--
Ian Collins.
I think I agree with you. Ideally the way to go would be a to use
errors generally and exceptions for truly exceptional conditions.
What would then qualify as an exceptional condition? I can think of
running out of memory as one, but can't really think of any other.
"File not found" and "Null pointer" exceptions which are common in java
are definitly not exceptional conditions - file not found is common and
"null pointer" should be handled as an error. ch**********@gmail.com wrote in news:1166001450.978398.194870@
16g2000cwy.googlegroups.com:
ajalk...@gmail.com wrote:
>ch**********@gmail.com wrote:
Microsoft code is not a good example in any case. I've been looking at
good open source projects (apache and berkelydb) and they don't use
exceptions or templates.
Do you think this might have something to do with both of those
projects being written in C and not C++? It's hard to use
exceptions or templates if the language has no support for them.
Berkely DB has a C++ version. I just re-checked and the do provide
support (optional) for exceptions, though they do not use templates.
The exception support also can be "turned off".
Could you point me (genuinely) to a powerful project that does use
modern C++? I have been looking but haven't been too successful yet.
Adobe uses the boost library somewhere, but adobe is *so* slow to load
it's a bad example for me. So I'm still looking.
The Adaptive Communications Environment (ACE). http://www.cs.wustl.edu/~schmidt/ACE.html
Andre Kostur wrote:
ch**********@gmail.com wrote in news:1166001450.978398.194870@
16g2000cwy.googlegroups.com:
ajalk...@gmail.com wrote:
ch**********@gmail.com wrote:
Microsoft code is not a good example in any case. I've been looking at
good open source projects (apache and berkelydb) and they don't use
exceptions or templates.
Do you think this might have something to do with both of those
projects being written in C and not C++? It's hard to use
exceptions or templates if the language has no support for them.
Berkely DB has a C++ version. I just re-checked and the do provide
support (optional) for exceptions, though they do not use templates.
The exception support also can be "turned off".
Could you point me (genuinely) to a powerful project that does use
modern C++? I have been looking but haven't been too successful yet.
Adobe uses the boost library somewhere, but adobe is *so* slow to load
it's a bad example for me. So I'm still looking.
The Adaptive Communications Environment (ACE).
http://www.cs.wustl.edu/~schmidt/ACE.html
Thanks! I'll go through it. ch**********@gmail.com wrote:
ajalk...@gmail.com wrote:
ch**********@gmail.com wrote:
Microsoft code is not a good example in any case. I've been looking at
good open source projects (apache and berkelydb) and they don't use
exceptions or templates.
Do you think this might have something to do with both of those
projects being written in C and not C++? It's hard to use
exceptions or templates if the language has no support for them.
Berkely DB has a C++ version. I just re-checked and the do provide
support (optional) for exceptions, though they do not use templates.
The exception support also can be "turned off".
Could you point me (genuinely) to a powerful project that does use
modern C++? I have been looking but haven't been too successful yet.
Adobe uses the boost library somewhere, but adobe is *so* slow to load
it's a bad example for me. So I'm still looking.
If I've understood correctly, Berkeley DB is implemented in C and only
wrappers for C++ are provided.
Another poster recommended ACE. It is an excellent library that I've
used quite a bit, but since it is quite an old library and has to
support a large selection of compilers it is a bit conservative in its
use of modern features so that all platforms are supported.
One library I've often seen mentioned regarding modern C++ usage is
Blitz++. I haven't used it myself but you might want to take a look at
it also:
"Blitz++ is a C++ class library for scientific computing which provides
performance on par with Fortran 77/90. It uses template techniques to
achieve high performance. Blitz++ provides dense arrays and vectors,
random number generators, and small vectors" http://sourceforge.net/project/showf...group_id=63961
Maybe also Crypto++ might be interesting for you: http://www.cryptopp.com/
Noah Roberts a écrit :
Victor Bazarov wrote:
> I
recommend "Effective" series by Meyers, *all of them*.
Is there more than the two?
Yes 3 :o)
Effective C++
More Effective C++
Effective STL ch**********@gmail.com a écrit :
Victor Bazarov wrote:
>ch**********@gmail.com wrote:
>>[..]
What I am trying to do is to check if we can use template-based lists
in our company code. We are currently using lists similar to the
non-template version (with derived classes) and the mandate is that
the template list should have a clear advantage if we've to adopt it.
Then stop screwing around and use 'std::list'. And get a book on the
Standard library, preferrably a copy for every programmer on your team
so that nobody is left out trying to figure it out by themselves. I
recommend "Effective" series by Meyers, *all of them*.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Sadly I have no chance of selling the usage of std::list without first
proving that templates are not evil. Plus we do not use exceptions in
our code and the overhead of exception usage is not acceptable to our
company. I did try the std::vector (which was bigger but faster).
In any case I'm still not clear why the timing results are different.
Another intersting point is when I changed your code to use "MyClass"
instead of "double" the template list became slower again!
cheers,
/Charles
Well, you really must use std::vector instead of std::list, "Effective
STL" might help you more:
When you used std::vector, did you reserved the memory beforehand ?
std::vector<MyClassmyVector(100000);
or
myVector.reserve(100000);
Otherwise, there is performances degradation due to reallocation.
This wouldn't happen with std::list.
Michael ch**********@gmail.com skrev:
[snip]
What overhead? Unless you write quite specialised code, the overhead of
exceptionhandling is certainly acceptable. As I assume that your
company does try to do some errorhandling, the overhead of
exception-handling is not just something you pay for. You do also get
something in return - namely no longer needing to continuously check
return codes.
This is not just a programmer convenience. It is also far less code,
far less clutter and faster programs, but most importantly it's
increased reliability since you are no longer as likely to overlook
missing return code checks. I can tell you, as I right now work for a
company with the same exception policy (no exceptions!) as in your
company, and our codebase does have places where errorcodes are not
checked (and potential resource leaks because the style and the age of
the code means that to many raw allocations are made and not always
freed after use). The problem with my company is not only that there is
a distrust in exceptions (probably for the same silly reasons that your
company has) and that our codebase is very large (20000 sourcefiles on
the project I am working on), so I can see some raison in not changing
policy. Unfortunately the same reasoning might very well result in
throwing C++ out the window. No new projects are - to my knowledge -
started in C++ today, and who can really blame that considering the
mess they have brought them self into.
/Peter
Exception handling does have *significant* peformance overhead.
<quote>Compared to a normal function return, returning from a function
by throwing an exception may be as much as three orders of magnitude
(!) slower</quote>. Even though you may incur this cost rarely
(depending on how you use exceptions), there is still potential code
bloat and a performance hit.
Right. I never argued about the time spent when an exception was
thrown. If timing in that case is interesting and crucial to your
program, I do understand that this is one place to avoid exception
handling.
What I had in mind was performance of the normal execution path. Here,
using exception handling will in the optimal case improve performance,
both in terms of size and speed. Some compilers will have a slight
overhead in some cases (doing some simple housekeeping on entry to some
functions), but that overhead is comparable in size and speed to
norrmal "if-then-else" error-handling.
We use assertions quite generously (which reduces the number of error
returns drastically) and that works very well.
I like using assertions myself, but if you claim that assertions are
related to exception handling it demonstrates that you haven't
understood either one or both of these topics.
We have no
memory/resource leaks (in our codebase of 3500 files - not nearly as
large as yours) and we do check for return codes everywhere.
This is very dandy. I must add that our software runs "forever" on the
systems they are installed on so they do not leak like a pig, But to
claim that your software behaves well irrespective of any path through
your code and irrespective of any possible faliure, begs the question
how you can be so sure. It either requires loads of resources or some
intelligent form of resource-management, that simply can't be achieved
without using generic code and thus templates.
IMHO exceptions aren't that great anyway (also see
http://www.joelonsoftware.com/items/2003/10/13.html) because they don't
mandate who deals with them (i.e. there is no ownership of errors).
There is no ownership of errors using return codes, certainly!
In
the return code world the caller *must* deal with the error conditions.
Why? In order to avoid errors, you mean? Well ;-)
In the exception world, he can ignore it to the peril of functions
higher up in the chain.
Surely, the normal handling of an exception should be to ignore it
(making sure you function is exception safe), letting the function that
knows how to deal with the exception handle it.
Having said that, exceptions could be useful for simple, or business
oriented programs where performance isn't a major factor (like much of
Java code). Or maybe we need to think up a different paradigm for error
handling altogether....
Wauh! You have a lot to learn.
/Peter ch**********@gmail.com wrote:
Kirit Sælensminde wrote:
ch**********@gmail.com wrote:
peter koch wrote:
charles.l...@gmail.com skrev:
Victor Bazarov wrote:
ch**********@gmail.com wrote:
[..]
What I am trying to do is to check if we can use template-based lists
in our company code. We are currently using lists similar to the
non-template version (with derived classes) and the mandate is that
the template list should have a clear advantage if we've to adopt it.
Then stop screwing around and use 'std::list'. And get a book on the
Standard library, preferrably a copy for every programmer on your team
so that nobody is left out trying to figure it out by themselves. I
recommend "Effective" series by Meyers, *all of them*.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
>
Sadly I have no chance of selling the usage of std::list without first
proving that templates are not evil. Plus we do not use exceptions in
our code and the overhead of exception usage is not acceptable toour
company.
What overhead? Unless you write quite specialised code, the overhead of
exceptionhandling is certainly acceptable. As I assume that your
company does try to do some errorhandling, the overhead of
exception-handling is not just something you pay for. You do also get
something in return - namely no longer needing to continuously check
return codes.
This is not just a programmer convenience. It is also far less code,
far less clutter and faster programs, but most importantly it's
increased reliability since you are no longer as likely to overlook
missing return code checks. I can tell you, as I right now work fora
company with the same exception policy (no exceptions!) as in your
company, and our codebase does have places where errorcodes are not
checked (and potential resource leaks because the style and the ageof
the code means that to many raw allocations are made and not always
freed after use). The problem with my company is not only that there is
a distrust in exceptions (probably for the same silly reasons that your
company has) and that our codebase is very large (20000 sourcefileson
the project I am working on), so I can see some raison in not changing
policy. Unfortunately the same reasoning might very well result in
throwing C++ out the window. No new projects are - to my knowledge -
started in C++ today, and who can really blame that considering the
mess they have brought them self into.
/Peter
Exception handling does have *significant* peformance overhead.
<quote>Compared to a normal function return, returning from a function
by throwing an exception may be as much as three orders of magnitude
(!) slower</quote>. Even though you may incur this cost rarely
(depending on how you use exceptions), there is still potential code
bloat and a performance hit.
We use assertions quite generously (which reduces the number of error
returns drastically) and that works very well. We have no
memory/resource leaks (in our codebase of 3500 files - not nearly as
large as yours) and we do check for return codes everywhere.
IMHO exceptions aren't that great anyway (also see
http://www.joelonsoftware.com/items/2003/10/13.html) because they don't
mandate who deals with them (i.e. there is no ownership of errors). In
the return code world the caller *must* deal with the error conditions.
In the exception world, he can ignore it to the peril of functions
higher up in the chain.
Having said that, exceptions could be useful for simple, or business
oriented programs where performance isn't a major factor (like much of
Java code). Or maybe we need to think up a different paradigm for error
handling altogether....
Joel is right about all sorts of things, but he isn't right about
everything. There are contexts within which exceptions are a pain and
places where their use makes no sense or complicates code. But that
isn't the same as saying that they are never the best way of dealing
with a situations.
His two arguments are easily put in perspective though:
"They are invisible in the source code": For the first take a look at
http://www.kirit.com/Handling%20COM%...20in%20C%2B%2B on my site
which explores this issue in the context of COM error handling. The
sample code that Microsoft used is buggy precisely because they nest if
statements to handle error conditions. Yes the error checking
statements are clearly visible and that is exactly the problem - they
obscure the flow to such an extent that they themselves become a source
of problems.
"They create too many possible exit points": Joel's second point is
true if you are manually handling resources (i.e. you have to manually
free the resources). Then the extra exit points are an important
consideration. If you're using RIAA then this is a non-issue. And if
you're not using RIAA then you're not really using C++ IMHO.
K
[OFF TOPIC]
Nice article btw - I liked the fonts and layout. Just curious - do you
hand code your site it or is use some program?
[/OFF TOPIC]
It uses our web application and O/RM framework FOST.3. It runs the wiki
and bulletin board modules.
It's about 99% C++ (a few ASP pages, but they're being phased out) and
uses Boost and exceptions. There are around 14 occurances of the delete
keyword most of which seem to be for handling the buffers in the TCP/IP
stream implementations. I consider it a fairly good example of good
modern C++, but then I'm very biased :-)
To bring this on topic, I don't see how the framework could have been
written to be as reliable as it is without the use of templates and
exceptions. The introspection used to generate the SQL and COM access
points makes very heavy use of templates. Without exceptions the design
of the system would be so convulated it'd be impossible to work with.
As it is it's faster to work in C++ to build new features than it is
using scripting languages.
K aj******@gmail.com wrote:
ch**********@gmail.com wrote:
ajalk...@gmail.com wrote:
ch**********@gmail.com wrote:
Microsoft code is not a good example in any case. I've been looking at
good open source projects (apache and berkelydb) and they don't use
exceptions or templates.
>
Do you think this might have something to do with both of those
projects being written in C and not C++? It's hard to use
exceptions or templates if the language has no support for them.
Berkely DB has a C++ version. I just re-checked and the do provide
support (optional) for exceptions, though they do not use templates.
The exception support also can be "turned off".
Could you point me (genuinely) to a powerful project that does use
modern C++? I have been looking but haven't been too successful yet.
Adobe uses the boost library somewhere, but adobe is *so* slow to load
it's a bad example for me. So I'm still looking.
If I've understood correctly, Berkeley DB is implemented in C and only
wrappers for C++ are provided.
Another poster recommended ACE. It is an excellent library that I've
used quite a bit, but since it is quite an old library and has to
support a large selection of compilers it is a bit conservative in its
use of modern features so that all platforms are supported.
One library I've often seen mentioned regarding modern C++ usage is
Blitz++. I haven't used it myself but you might want to take a look at
it also:
"Blitz++ is a C++ class library for scientific computing which provides
performance on par with Fortran 77/90. It uses template techniques to
achieve high performance. Blitz++ provides dense arrays and vectors,
random number generators, and small vectors"
http://sourceforge.net/project/showf...group_id=63961
Maybe also Crypto++ might be interesting for you:
http://www.cryptopp.com/
Neat - thanks!
These are all libraries though, are there any products that use modern
C++? It seems to me (maybe wrongly) that there are very few products
using modern C++ (compared to C and vanilla-C++).
I'm guessing this could be because the latest features don't (didn't?)
have widespread compiler support but I could be wrong.
I just checked firefox and it is using templates (yay) - any other
products out there?
Kirit Sælensminde wrote:
ch**********@gmail.com wrote:
Kirit Sælensminde wrote:
ch**********@gmail.com wrote:
>
peter koch wrote:
charles.l...@gmail.com skrev:
Victor Bazarov wrote:
ch**********@gmail.com wrote:
[..]
What I am trying to do is to check if we can use template-based lists
in our company code. We are currently using lists similar to the
non-template version (with derived classes) and the mandateis that
the template list should have a clear advantage if we've toadopt it.
>
Then stop screwing around and use 'std::list'. And get a book on the
Standard library, preferrably a copy for every programmer on your team
so that nobody is left out trying to figure it out by themselves. I
recommend "Effective" series by Meyers, *all of them*.
>
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Sadly I have no chance of selling the usage of std::list without first
proving that templates are not evil. Plus we do not use exceptions in
our code and the overhead of exception usage is not acceptable to our
company.
>
What overhead? Unless you write quite specialised code, the overhead of
exceptionhandling is certainly acceptable. As I assume that your
company does try to do some errorhandling, the overhead of
exception-handling is not just something you pay for. You do alsoget
something in return - namely no longer needing to continuously check
return codes.
This is not just a programmer convenience. It is also far less code,
far less clutter and faster programs, but most importantly it's
increased reliability since you are no longer as likely to overlook
missing return code checks. I can tell you, as I right now work for a
company with the same exception policy (no exceptions!) as in your
company, and our codebase does have places where errorcodes are not
checked (and potential resource leaks because the style and the age of
the code means that to many raw allocations are made and not always
freed after use). The problem with my company is not only that there is
a distrust in exceptions (probably for the same silly reasons that your
company has) and that our codebase is very large (20000 sourcefiles on
the project I am working on), so I can see some raison in not changing
policy. Unfortunately the same reasoning might very well result in
throwing C++ out the window. No new projects are - to my knowledge -
started in C++ today, and who can really blame that considering the
mess they have brought them self into.
>
/Peter
>
Exception handling does have *significant* peformance overhead.
<quote>Compared to a normal function return, returning from a function
by throwing an exception may be as much as three orders of magnitude
(!) slower</quote>. Even though you may incur this cost rarely
(depending on how you use exceptions), there is still potential code
bloat and a performance hit.
We use assertions quite generously (which reduces the number of error
returns drastically) and that works very well. We have no
memory/resource leaks (in our codebase of 3500 files - not nearly as
large as yours) and we do check for return codes everywhere.
IMHO exceptions aren't that great anyway (also see
http://www.joelonsoftware.com/items/2003/10/13.html) because they don't
mandate who deals with them (i.e. there is no ownership of errors).In
the return code world the caller *must* deal with the error conditions.
In the exception world, he can ignore it to the peril of functions
higher up in the chain.
Having said that, exceptions could be useful for simple, or business
oriented programs where performance isn't a major factor (like muchof
Java code). Or maybe we need to think up a different paradigm for error
handling altogether....
>
Joel is right about all sorts of things, but he isn't right about
everything. There are contexts within which exceptions are a pain and
places where their use makes no sense or complicates code. But that
isn't the same as saying that they are never the best way of dealing
with a situations.
>
His two arguments are easily put in perspective though:
>
"They are invisible in the source code": For the first take a look at
http://www.kirit.com/Handling%20COM%...20in%20C%2B%2B on my site
which explores this issue in the context of COM error handling. The
sample code that Microsoft used is buggy precisely because they nest if
statements to handle error conditions. Yes the error checking
statements are clearly visible and that is exactly the problem - they
obscure the flow to such an extent that they themselves become a source
of problems.
>
"They create too many possible exit points": Joel's second point is
true if you are manually handling resources (i.e. you have to manually
free the resources). Then the extra exit points are an important
consideration. If you're using RIAA then this is a non-issue. And if
you're not using RIAA then you're not really using C++ IMHO.
>
>
K
[OFF TOPIC]
Nice article btw - I liked the fonts and layout. Just curious - do you
hand code your site it or is use some program?
[/OFF TOPIC]
It uses our web application and O/RM framework FOST.3. It runs the wiki
and bulletin board modules.
It's about 99% C++ (a few ASP pages, but they're being phased out) and
uses Boost and exceptions. There are around 14 occurances of the delete
keyword most of which seem to be for handling the buffers in the TCP/IP
stream implementations. I consider it a fairly good example of good
modern C++, but then I'm very biased :-)
To bring this on topic, I don't see how the framework could have been
written to be as reliable as it is without the use of templates and
exceptions. The introspection used to generate the SQL and COM access
points makes very heavy use of templates. Without exceptions the design
of the system would be so convulated it'd be impossible to work with.
As it is it's faster to work in C++ to build new features than it is
using scripting languages.
K
Cool :-)
Michael DOUBEZ wrote:
ch**********@gmail.com a écrit :
Victor Bazarov wrote:
ch**********@gmail.com wrote:
[..]
What I am trying to do is to check if we can use template-based lists
in our company code. We are currently using lists similar to the
non-template version (with derived classes) and the mandate is that
the template list should have a clear advantage if we've to adopt it.
Then stop screwing around and use 'std::list'. And get a book on the
Standard library, preferrably a copy for every programmer on your team
so that nobody is left out trying to figure it out by themselves. I
recommend "Effective" series by Meyers, *all of them*.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Sadly I have no chance of selling the usage of std::list without first
proving that templates are not evil. Plus we do not use exceptions in
our code and the overhead of exception usage is not acceptable to our
company. I did try the std::vector (which was bigger but faster).
In any case I'm still not clear why the timing results are different.
Another intersting point is when I changed your code to use "MyClass"
instead of "double" the template list became slower again!
cheers,
/Charles
Well, you really must use std::vector instead of std::list, "Effective
STL" might help you more:
When you used std::vector, did you reserved the memory beforehand ?
std::vector<MyClassmyVector(100000);
or
myVector.reserve(100000);
Otherwise, there is performances degradation due to reallocation.
This wouldn't happen with std::list.
Michael
I tried initializing the vector as suggested and it made no difference.
I think it's not doing enough re-allocs to make any perceptible
difference.
I also tried using the std::list - and it became 3 times slower! The
vector seems to be the fastest for my current usage.
cheers,
/Charles ch**********@gmail.com skrev:
[snip]
These are all libraries though, are there any products that use modern
C++? It seems to me (maybe wrongly) that there are very few products
using modern C++ (compared to C and vanilla-C++).
I'm guessing this could be because the latest features don't (didn't?)
have widespread compiler support but I could be wrong.
I just checked firefox and it is using templates (yay) - any other
products out there?
You could visit boost: they have a section "who's using boost). Lots of
companies probably do not show up there. All my projects except for
the current one have used "modern" C++ such as templates and boost
libraries and of course the standard library. I believe that using
these modern techniques is the rule rather than the exception, at least
until you go to libraries that are old and/or supposed to support lots
of possibly old and nonconforming compilers (such as gcc 2.95 or VC
6.0).
/Peter
peter koch wrote:
ch**********@gmail.com skrev:
[snip]
These are all libraries though, are there any products that use modern
C++? It seems to me (maybe wrongly) that there are very few products
using modern C++ (compared to C and vanilla-C++).
I'm guessing this could be because the latest features don't (didn't?)
have widespread compiler support but I could be wrong.
I just checked firefox and it is using templates (yay) - any other
products out there?
You could visit boost: they have a section "who's using boost). Lots of
companies probably do not show up there. All my projects except for
the current one have used "modern" C++ such as templates and boost
libraries and of course the standard library. I believe that using
these modern techniques is the rule rather than the exception, at least
until you go to libraries that are old and/or supposed to support lots
of possibly old and nonconforming compilers (such as gcc 2.95 or VC
6.0).
/Peter
Thanks.
This discussion was really good for me. I learnt a lot! ch**********@gmail.com wrote:
Exception handling does have *significant* peformance overhead.
<quote>Compared to a normal function return, returning from a function
by throwing an exception may be as much as three orders of magnitude
(!) slower</quote>.
"may be" is the key sequence there. Implementations have vastly
improved since the early 90's.
Even though you may incur this cost rarely
(depending on how you use exceptions), there is still potential code
bloat and a performance hit.
When examining the costs of exceptions you need to compare it to
alternative methods of error handling, not to simple function
returning. There are two viable alternatives:
1) error code returns.
These must be checked and can be ignored leaving the program in an
unkowingly erroneous state.
2) error code globals
lots of problems there.
Either one must have error checking in the form of ifs all over the
place; often times several levels of them because you catch an error,
need to stop, and return that error up the call stack. Exceptions
handle this kind of thing quite well. The question is, are the ifs
that much less of a performance hit?
We use assertions quite generously (which reduces the number of error
returns drastically) and that works very well. We have no
memory/resource leaks (in our codebase of 3500 files - not nearly as
large as yours) and we do check for return codes everywhere.
memory/resource leaks have nothing to do with exceptions. Have you
compared the cleanliness of exceptions vs return codes and have you
compared the performance of exceptions to error code checking
"everywhere"?
IMHO exceptions aren't that great anyway (also see
http://www.joelonsoftware.com/items/2003/10/13.html) because they don't
mandate who deals with them (i.e. there is no ownership of errors).
That is an illogical mandate. The callee can't know who best can
handle the errors it generates. Obviously it returns an error because
for some reason it can't deal with it on its own...why attempt to
enforce a relationship that is possibly not valid?
In
the return code world the caller *must* deal with the error conditions.
Not true...the caller can just ignore them. Exceptions cannot be
ignored.
In the exception world, he can ignore it to the peril of functions
higher up in the chain.
As can error codes except that once ignored there is no way to know
that an error occured. Exceptions will pull up the stack until handled
and cannot be ignored.
Having said that, exceptions could be useful for simple, or business
oriented programs where performance isn't a major factor (like much of
Java code).
That assumes that exceptions cause a performance penalty such that
error handling using them is too much penalty for high performance
systems. There is no indication that you have measured this penalty
and seem to be simply making miles and miles of assumptions based on no
data whatsoever.
There are two things to consider: Do exceptions really cause a penalty
that so outweighs error code handling that one is better than the other
performance wise; this is highly questionable. Second, is your system
such that it needs to be able to deal with erroneous conditions as
quickly as the mainline, which has to be very fast; this is extreemly
rare.
Another thing to consider...do the mainline and error path have equal
performance requirements? If not, could the mainline be made faster by
not having error handling code in it? If so, even if exceptions are
slower maybe they are the better alternative.
Andre Kostur wrote:
"Noah Roberts" <ro**********@gmail.comwrote in
news:11*********************@16g2000cwy.googlegrou ps.com:
Victor Bazarov wrote:
I
recommend "Effective" series by Meyers, *all of them*.
Is there more than the two?
Yep, three.
Effective C++
More Effective C++
Effective STL
Ok, yeah I forgot about the last one...I don't have it. ch**********@gmail.com wrote:
Sadly I have no chance of selling the usage of std::list without first
proving that templates are not evil. Plus we do not use exceptions in
our code and the overhead of exception usage is not acceptable to our
company. I did try the std::vector (which was bigger but faster).
Interesting. Sounds very familiar. It's funny how many managers
mandate this kind of crap without even looking into real costs. The
last manager we had mandated the same things. Took forever to convince
him that the STL was faster even with *real measured data*. Thick
heads just don't move I guess.
What was really interesting is that we use visual studio 7, and now 8.
Mandate said we would not use exceptions but we had them enabled
because of course nothing compiles without them (not if you use ANY of
the standard lib except the C part). This meant we where paying all
the costs of using them but getting none of the benefits.
The things people do based on assumptions...
And there you go...if you use the STL you will have to enable
exceptions (if you're even turning them off) and thus will have all the
costs associated with them. Any size increase for tables, any call
overhead for functions...etc...will all be paid if you use the STL. ch**********@gmail.com wrote:
Sadly I have no chance of selling the usage of std::list without first
proving that templates are not evil. Plus we do not use exceptions in
our code and the overhead of exception usage is not acceptable to our
company. I did try the std::vector (which was bigger but faster).
BTW, who do you work for? I want to make sure I don't ever apply there
:P ch**********@gmail.com wrote:
Neat - thanks!
These are all libraries though, are there any products that use modern
C++? It seems to me (maybe wrongly) that there are very few products
using modern C++ (compared to C and vanilla-C++).
We used to be in the same position you are in with a manager mandating
all sorts of silly and ill concieved policies such as never use
exceptions and stay away from STL. Eventually we showed him that the
STL was definately not a problem and started using it....never sold
exceptions.
But he is gone now and things have changed. We now use boost and the
STL all over the place. Exceptions will be moving in as soon as some
training takes place (these guys never learned RAII for example). The
more square wheels we replace with STL and boost the cleaner, more
secure, and faster the code gets...and yes, these effects are
measurable.
No, you can't see our code...it's proprietery (I won't even talk about
who we are)...but our product is a complex engineering product that
must have good performance for it to sell. Performance is a big deal
for us and we have no problem using the STL because it is just plain
faster than the alternatives.
I think most of the time these managers are just avoiding STL and
exceptions because they are clueless when it comes to them; this
coincides with my experience. Instead of learning new things that
could make them better they prefer to stay where they are. It is
amazing how strongly they fight change.
That said...you're wasting time. You'll spend hours on this and never
get anywhere with them...or you'll get just far enough to make it
worse. Find a different job where you can work with people who know
more and have more open minds about things...prefering to look at
measurable data rather than base wide sweeping decisions on assumptions. ch**********@gmail.com wrote:
This discussion was really good for me. I learnt a lot!
Oh! you posted here too (apart from comp.lang.c++.moderated). I have
posted upon this a while ago at comp.lang.c++.moderated (don't know
whether it would appear or not), but here is an **approximate** copy of
that (look there for my exact posting)!
/*------------ HISTORY of this topic at 'comp.lang.c++.moderated'
-------------------*/ ch**********@gmail.com wrote:
Hi,
I have recently begun using templates in C++ and have found it to be
quite useful. However, hearing stories of code bloat and assorted
problems I decided to write a couple of small programs to check. What I
expected was that there would be minor code bloat and some speed
improvement when using templates. However...
I wrote a basic list container (using templates), and a list container
(using virtual derived classes). I also tried with the std lib vector
class. I ran 1000000 inserts and accesses to all these lists and got
the following results (compiling on windows with microsoft compiler):
Size:
22,528 mytpl.exe
36,864 nonstd.exe
40,960 std.exe
The first is my template list, the second my non-template list, and the
third is using the std vector.
The first surprise was that my template list was actually *smaller*
than the non-template version! Very surprising. However, it's not all
good news. I then ran some timing tests.
Time:
875: running std.exe
1484: running nonstd.exe
1563: running mytpl.exe
As expected, the std vector is the fastest. However my template list
class is the *slowest*!!! This was definitly not expected.
Does anyone have any inputs on what's going on?
cheers,
/Charles
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
frame wrote:
I wrote a basic list container (using templates), and a list container
(using virtual derived classes). I also tried with the std lib vector
class. I ran 1000000 inserts and accesses to all these lists and got
the following results (compiling on windows with microsoft compiler):
Size:
22,528 mytpl.exe
36,864 nonstd.exe
40,960 std.exe
The first is my template list, the second my non-template list, and the
third is using the std vector.
The first surprise was that my template list was actually *smaller*
than the non-template version!
It's hard to comment without actually taking a look at what/how you
programmed!!
However, the above results are not so surprising (to me) due to the
following reasons/assumptions:
mytpl.exe: (basic list container using templates) you would have used
a single class with few basic operations to attain the functionality
you intended for.
nonstd.exe: (using virtual derived classes) you would have used many
classes to attain the same functionality.
std.exe: (using std::vector) vector comes with a quite a bit of
baggage (allocators, iterators ...). However, it's interesting to know
that you implemented a "list" using "vector" in spite of "std::list"
availability!
Question: Is the 'list' you implemented a "linked list" kind of thing
or an "array" kind?
Very surprising. However, it's not all
good news. I then ran some timing tests.
Time:
875: running std.exe
1484: running nonstd.exe
1563: running mytpl.exe
As expected, the std vector is the fastest. However my template list
class is the *slowest*!!! This was definitly not expected.
Does anyone have any inputs on what's going on?
Again, it's hard to say why, without actually analyzing your programs
(for time and space complexities of the algorithms you applied). A
language (C++ or anything else) wouldn't be able to come to rescue us
from our programming inefficiencies and definitely it would be worth
spending more time on improving our algorithm efficiencies rather than
niggling over the way we use a language.
ch**********@gmail.com wrote:
frame wrote:
I wrote a basic list container (using templates), and a list container
(using virtual derived classes). I also tried with the std lib vector
class. I ran 1000000 inserts and accesses to all these lists and got
the following results (compiling on windows with microsoft compiler):
>
Size:
22,528 mytpl.exe
36,864 nonstd.exe
40,960 std.exe
>
The first is my template list, the second my non-template list, and the
third is using the std vector.
>
The first surprise was that my template list was actually *smaller*
than the non-template version!
It's hard to comment without actually taking a look at what/how you
programmed!!
Yes I see that :-). I've pasted my code below. This is the first time
I've posted to a usenet group. I've also made the mistake of
"cross-posting" to comp.lang.c++ with the same topic <blush/>.
However, the above results are not so surprising (to me) due to the
following reasons/assumptions:
mytpl.exe: (basic list container using templates) you would have used
a single class with few basic operations to attain the functionality
you intended for.
nonstd.exe: (using virtual derived classes) you would have used many
classes to attain the same functionality.
std.exe: (using std::vector) vector comes with a quite a bit of
baggage (allocators, iterators ...). However, it's interesting to know
that you implemented a "list" using "vector" in spite of "std::list"
availability!
You are basically right about the way I've written the classes.
However, my understanding was that the compiler would generate the
classes in the template version which I hand coded in the virtual
derived class version. So the net result would have been a slight
increase in the template version (as the compiler would have copied the
entire class for every new type).
I used std::vector simply because I read somewhere that it was the
fastest container available and I wanted to use it as a benchmark for
the "best possible" performance :-)
Question: Is the 'list' you implemented a "linked list" kind of thing
or an "array" kind?
It's a "linked list" kind. Have pasted the code below.
Very surprising. However, it's not all
good news. I then ran some timing tests.
>
Time:
875: running std.exe
1484: running nonstd.exe
1563: running mytpl.exe
>
As expected, the std vector is the fastest. However my template list
class is the *slowest*!!! This was definitly not expected.
Does anyone have any inputs on what's going on?
Again, it's hard to say why, without actually analyzing your programs
(for time and space complexities of the algorithms you applied). A
language (C++ or anything else) wouldn't be able to come to rescue us
from our programming inefficiencies and definitely it would be worth
spending more time on improving our algorithm efficiencies rather than
niggling over the way we use a language.
Actually what I'm looking at is the *cost* of template usage (if any)
in terms of speed and size. I'm not really looking for the best
implementation of a list. From what I read, templates should have given
me larger code that may have been faster. Instead it gave me smaller
code that's slower which is what I found surprising.
Programs follow:
----------------------- Template List ----------------------------
template <class T>
class ListNode
{
public:
ListNode (T * pVal) {uVal = pVal;}
T * uVal;
ListNode<T>* uNext;
ListNode<T>* uPrev;
};
template <class T>
class MyTList
{
public:
MyTList () { vFirst = NULL; }
void Insert (T * e) {
ListNode<T* ln;
ln = new ListNode<T(e);
ln->uNext = vFirst;
ln->uPrev = NULL;
if (vFirst != NULL)
vFirst->uPrev = ln;
vFirst = ln;
}
ListNode<T* GetNodes () { return vFirst;}
private:
ListNode<T* vFirst;
};
--------------------------------- Template List ends
----------------------------
--------------------------------- Non Template List
-----------------------------
class ListElem
{
public:
virtual ~ListElem (void) {}
ListElem * uNext;
ListElem * uPrev;
};
class MyList
{
public:
MyList () { vFirst = NULL;}
void Insert (ListElem * e) {
e->uNext = vFirst;
e->uPrev = NULL;
if (vFirst != NULL)
vFirst->uPrev = e;
vFirst = e;
}
ListElem * GetNodes () { return vFirst; }
private:
ListElem * vFirst;
};
------------------------------ Non template list ends
--------------------------
Note that the code is *very* similar for the template and non-template
version. I had to derive a ListElem for the non-template class:
class MyClassElem : public ListElem
{
public:
MyClassElem (MyClass * c) { uMyClass = c; }
MyClass * uMyClass;
};
But didn't have to do anything for the template version.
The cpp test code basically just runs two loops (inserting and
get-ting 1000000 elements).
cheers,
/Charles
/*------------ HISTORY Ends -------------------*/ ch**********@gmail.com wrote:
Yes I see that :-). I've pasted my code below. This is the first time
I've posted to a usenet group.
Welcome to the board!
You are basically right about the way I've written the classes.
However, my understanding was that the compiler would generate the
classes in the template version which I hand coded in the virtual
derived class version. So the net result would have been a slight
increase in the template version (as the compiler would have copied the
entire class for every new type).
I used std::vector simply because I read somewhere that it was the
fastest container available and I wanted to use it as a benchmark for
the "best possible" performance :-)
That's unfair!! I guess you aren't completely aware of the cost of
allocating memory dynamically using 'new' operator (see down below for
the results I got, which might be of interest to you).
>
Question: Is the 'list' you implemented a "linked list" kind of thing
or an "array" kind?
It's a "linked list" kind. Have pasted the code below.
Okay, I have gone through and found that you are actually trying to
implement "a LIFO doubly linked list". (LIFO: Last In First Out i.e. on
traversing the list starting with MyTList::GetNodes(), the last element
inserted into the list would be the first element that would be
visited).
Again, it's hard to say why, without actually analyzing your programs
(for time and space complexities of the algorithms you applied). A
language (C++ or anything else) wouldn't be able to come to rescue us
from our programming inefficiencies and definitely it would be worth
spending more time on improving our algorithm efficiencies rather than
niggling over the way we use a language.
Actually what I'm looking at is the *cost* of template usage (if any)
in terms of speed and size.
Usually, the "language implementers" strive their best to enforce a
near "zero-cost" overhead (either in terms of time or space) on usage
of any language feature and that too "C++" would be at the forefront in
matters like this. As a "language user", one should not worry about
things like this.
I'm not really looking for the best
implementation of a list. From what I read, templates should have given
me larger code that may have been faster. Instead it gave me smaller
code that's slower which is what I found surprising.
No, I think you are mistaken. "Algorithm Implementations" (but not
"Language Implementations") matter a lot!!! When you are trying to
compare/compete the performance of your code with some of the best
implementation's (i.e. library writer's), everything matters!
Programs follow:
----------------------- Template List ----------------------------
template <class T>
class ListNode
{
public:
ListNode (T * pVal) {uVal = pVal;}
T * uVal;
ListNode<T>* uNext;
ListNode<T>* uPrev;
};
template <class T>
class MyTList
{
public:
MyTList () { vFirst = NULL; }
void Insert (T * e) {
ListNode<T* ln;
ln = new ListNode<T(e);
ln->uNext = vFirst;
ln->uPrev = NULL;
if (vFirst != NULL)
vFirst->uPrev = ln;
vFirst = ln;
}
ListNode<T* GetNodes () { return vFirst;}
private:
ListNode<T* vFirst;
};
--------------------------------- Template List ends
Question: Why are you trying to insert "a pointer to a ListNode, that
inturn holds a pointer to an object" into the list, rather than
inserting "a pointer to a ListNode, that 'contains' an object"? The
latter would cut down one-half of the calls to "new" operator!
//////////////////////////////////////////////////////////////////////
Vulnerable fragments of the code you presented:
==================================
template <class T>
class ListNode
{
public:
ListNode (T * pVal) {uVal = pVal;}
T * uVal;
....
};
template <class T>
class MyTList
{
public:
...
void Insert (T * e) {
ListNode<T* ln;
ln = new ListNode<T(e);
...
}
...
};
Probable "driver" should have been:
========================
int main(){
....
MyTList<doubleaMyTList;
for (int i = 0;i < 1000000;i++)
aMyTList.Insert (new double(i));
....
}
//////////////////////////////////////////////////////////////////////
Instead, why not the following can be??
//////////////////////////////////////////////////////////////////////
Suggested change:
==============
template <class T>
class ListNode
{
public:
ListNode (T pVal) {uVal = pVal;}
T uVal; //Hold "OBJECT" rather than a pointer to it!
...
};
template <class T>
class MyTList
{
public:
...
void Insert (T e) {
ListNode<T* ln;
ln = new ListNode<T(e);
...
}
...
};
Probable "driver" can be:
=================
int main(){
....
MyTList<doubleaMyTList;
for (int i = 0;i < 1000000;i++)
aMyTList.Insert (i);
....
}
//////////////////////////////////////////////////////////////////////
I tried the above approach and following are the results on my machine
using 'GNU's gcc' compiler:
Run Time with the code you presented to 'insert' 1000000 doubles: 650
seconds
=========
Run Time with my suggested change: 360 seconds
=========
If you are ready to consider a bit more advanced version of mine that
would do the memory allocation in "chunks" rather than one by one on
demand, then the results would be more interesting. Here is my quick
and dirty "bit more advanced version" (this should be compilable and
executable with 'GNU's gcc'):
//////////////////////////////////////////////////////////////////////
#include <stdio.h>
#include <string.h>
#include <time.h>
#include <iostream>
#include <vector>
using namespace std;
template <class T>
class ListNode
{
public:
T uVal;
ListNode<T>* uNext;
ListNode<T>* uPrev;
};
template <class T>
class MyTList
{
public:
MyTList (size_t myPoolSize = 1000000) {
vFirst = NULL;
// Extra baggage initialization
_myPoolSize = myPoolSize;
_myMemoryPool = new ListNode<T>[_myPoolSize];
_myNext = _myPoolSize - 1;
}
void Insert (T e) {
ListNode<T>* ln;
if(_myNext<0){
// memory pool exhausted; so, let's refill it!
_myMemoryPool = new ListNode<T>[_myPoolSize];
_myNext = _myPoolSize - 1;
}
ln = &(_myMemoryPool[_myNext--]);
ln->uVal = e; //Default assignment operator of "ListNode"
suffices in this case.
ln->uNext = vFirst;
ln->uPrev = NULL;
if (vFirst != NULL)
vFirst->uPrev = ln;
vFirst = ln;
}
ListNode<T* GetNodes () { return vFirst;}
private:
ListNode<T* vFirst;
// Extra baggage for memory management and for extra performance!!
ListNode<T>* _myMemoryPool;
size_t _myPoolSize;
int _myNext;
};
int main()
{
clock_t t1 = clock();
MyTList<doubleaMyTList;
for (int i = 0; i < 1000000; ++i)
aMyTList.Insert(i);
clock_t t2 = clock();
std::vector<doubleaVec(1000000);
for (int i = 0; i < 1000000; ++i)
aVec.push_back(i);
clock_t t3 = clock();
cout << "MyTList: " << t2 - t1 << endl;
cout << "std::vector: " << t3 - t2 << endl;
return 0;
}
//////////////////////////////////////////////////////////////////////
And the ouput was this:
MyTList: 30
std::vector: 50
(We can beat them, Charles!!)
Note that the code is *very* similar for the template and non-template version.
Hence, I don't want to comment upon your "non-template" version!! But,
I would like to repeat what I had said in my earlier posting:-
A language (C++ or anything else) wouldn't be able to come to rescue us
from our programming inefficiencies and definitely it would be worth
spending more time on improving our algorithm efficiencies rather than
niggling over the way we use a language.
-srikar vedantam ch**********@gmail.com wrote:
for (int i = 0;i < 1000000;i++) {
one.Insert (new MyClass (i));
}
Here you do 1000000 memory allocations
for (int i = 0;i < 1000000;i++) {
one.Insert (new MyClassElem (new MyClass (i)));
}
And here you do 2000000 memory allocations.
In the std::vector version there will only be a handful of allocations.
This could explain the differences you are seeing. ch**********@gmail.com wrote:
"File not found" and "Null pointer" exceptions which are common in java
are definitly not exceptional conditions - file not found is common and
"null pointer" should be handled as an error.
I think file not found is almost always an exceptional condition, no matter
how frequently it happens. In an interactive program the response to that
condition will be to inform the user, in a non interactive usually to abort
or write to some error log. These actions are not part of the main flow of
the program, nor suffer any harm for the minimal delay the exception
handling can have even with the compilers worse in this aspect.
Surely one can imagine a directory reading utility that tries to open all
possible file names, and returns the names in which the open succeed. Here
a delay caused by exception handling if the "file not found" condition is
handled that way can be significant. But in this case, and other more
realistic of the same type, put the blame in the inadequate algorithm used,
not in the exception handling.
A null pointer is like have a 0 value in an integer: It can be exceptional,
a symptom of a serious flaw or a perfectly normal condition, depending of
what each concrete functions than handle pointers expects.
The same thing with any other general condition. A 'end of file reached' is
a perfectly normal event when reading a text file, but is abnormal when
reading a fixed size field in a binary file with well defined format.
--
Salu2
Noah Roberts wrote:
ch**********@gmail.com wrote:
Exception handling does have *significant* peformance overhead.
<quote>Compared to a normal function return, returning from a function
by throwing an exception may be as much as three orders of magnitude
(!) slower</quote>.
"may be" is the key sequence there. Implementations have vastly
improved since the early 90's.
Even though you may incur this cost rarely
(depending on how you use exceptions), there is still potential code
bloat and a performance hit.
When examining the costs of exceptions you need to compare it to
alternative methods of error handling, not to simple function
returning. There are two viable alternatives:
1) error code returns.
These must be checked and can be ignored leaving the program in an
unkowingly erroneous state.
2) error code globals
lots of problems there.
Either one must have error checking in the form of ifs all over the
place; often times several levels of them because you catch an error,
need to stop, and return that error up the call stack. Exceptions
handle this kind of thing quite well. The question is, are the ifs
that much less of a performance hit?
We use assertions quite generously (which reduces the number of error
returns drastically) and that works very well. We have no
memory/resource leaks (in our codebase of 3500 files - not nearly as
large as yours) and we do check for return codes everywhere.
memory/resource leaks have nothing to do with exceptions. Have you
compared the cleanliness of exceptions vs return codes and have you
compared the performance of exceptions to error code checking
"everywhere"?
IMHO exceptions aren't that great anyway (also see
http://www.joelonsoftware.com/items/2003/10/13.html) because they don't
mandate who deals with them (i.e. there is no ownership of errors).
That is an illogical mandate. The callee can't know who best can
handle the errors it generates. Obviously it returns an error because
for some reason it can't deal with it on its own...why attempt to
enforce a relationship that is possibly not valid?
In
the return code world the caller *must* deal with the error conditions.
Not true...the caller can just ignore them. Exceptions cannot be
ignored.
In the exception world, he can ignore it to the peril of functions
higher up in the chain.
As can error codes except that once ignored there is no way to know
that an error occured. Exceptions will pull up the stack until handled
and cannot be ignored.
Having said that, exceptions could be useful for simple, or business
oriented programs where performance isn't a major factor (like much of
Java code).
That assumes that exceptions cause a performance penalty such that
error handling using them is too much penalty for high performance
systems. There is no indication that you have measured this penalty
and seem to be simply making miles and miles of assumptions based on no
data whatsoever.
There are two things to consider: Do exceptions really cause a penalty
that so outweighs error code handling that one is better than the other
performance wise; this is highly questionable. Second, is your system
such that it needs to be able to deal with erroneous conditions as
quickly as the mainline, which has to be very fast; this is extreemly
rare.
Another thing to consider...do the mainline and error path have equal
performance requirements? If not, could the mainline be made faster by
not having error handling code in it? If so, even if exceptions are
slower maybe they are the better alternative.
You make several good points and I was especially struck by your last
one (the different requirements for mainline and error paths). I will
do some more research on exception costs but right now I'm still
working on the template front. :-)
I don't want to give the impression that my manager is not open to
change. He's a smart guy, has been programming a long time now (20+
years) and is willing to listen if I can convince him. Which is why I'm
spending the time and effort to evaluate templates and their
performance impact.
Old Wolf wrote:
ch**********@gmail.com wrote:
for (int i = 0;i < 1000000;i++) {
one.Insert (new MyClass (i));
}
Here you do 1000000 memory allocations
for (int i = 0;i < 1000000;i++) {
one.Insert (new MyClassElem (new MyClass (i)));
}
And here you do 2000000 memory allocations.
In the std::vector version there will only be a handful of allocations.
This could explain the differences you are seeing.
Yes that could be it - in fact in the previous post (frame) wrote a
memory-managed list class that actually out-performed vector (for this
specific case) :-)
On Wed, 13 Dec 2006 09:13:04 -0800, Noah Roberts wrote: ch**********@gmail.com wrote:
>Sadly I have no chance of selling the usage of std::list without first
proving that templates are not evil. Plus we do not use exceptions in
our code and the overhead of exception usage is not acceptable to our
company. I did try the std::vector (which was bigger but faster).
[...]
And there you go...if you use the STL you will have to enable
exceptions (if you're even turning them off) and thus will have all the
costs associated with them. Any size increase for tables, any call
overhead for functions...etc...will all be paid if you use the STL.
To add to this: with gcc for example you can compile with a
-fno-exceptions flag. Of the obverse -fexceptions flag the manual states:
"Enable exception handling. Generates extra code needed to propagate
exceptions. For some targets, this implies GCC will generate frame
unwind information for all functions, which can produce significant
data size overhead, although it does not affect execution."
This is all a bit vague and of course implementation-dependent. What I
have found in practice on my system is that with -fno-exceptions you can
still compile code (including STL code) that throws exceptions... what you
cannot do is catch them (code will not compile). It seems that on a throw
a default catch kicks in which simply prints out the exception and aborts
the program.
I tried both flags on a sample program of mine that makes very heavy use
of STL containers (including throwing calls such as vector::at()) but
doesn't catch exceptions. There was indiscernible difference in either
program size or execution speed.
--
Lionel B
On Thu, 14 Dec 2006 02:31:45 -0800, VaderX wrote:
Noah Roberts wrote:
>ch**********@gmail.com wrote:
[snip]
I don't want to give the impression that my manager is not open to
change. He's a smart guy, has been programming a long time now (20+
years) and is willing to listen if I can convince him. Which is why I'm
spending the time and effort to evaluate templates and their
performance impact.
Well hey, point him at this thread! At the very least he can't fail to be
impressed by your diligence ;)
--
Lionel B
Lionel B wrote:
On Thu, 14 Dec 2006 02:31:45 -0800, VaderX wrote:
Noah Roberts wrote:
ch**********@gmail.com wrote:
[snip]
I don't want to give the impression that my manager is not open to
change. He's a smart guy, has been programming a long time now (20+
years) and is willing to listen if I can convince him. Which is why I'm
spending the time and effort to evaluate templates and their
performance impact.
Well hey, point him at this thread! At the very least he can't fail to be
impressed by your diligence ;)
--
Lionel B
I'll do that! :-) :-) :-) This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: arch |
last post by:
Hi,
I am trying to implement a class hierarchy where there will be a base class
defining the interface and some common operations (interface+implentation):
Constraints : no STL. This will be...
|
by: Sebastian Faust |
last post by:
Hi,
I have a design problem about which I am thinking now for a while and still
couldnt find any help in deja. What I need is something like a virtual
function template. I know that this is not...
|
by: franklini |
last post by:
i cant seem to figure out what is wrong with this class. it has to do
with the input/output stream override. please can somebody help me.
#include <iostream>
#include <string>
#include <vector>...
|
by: Tony Johansson |
last post by:
Hello experts!
I have two class template below with names Array and CheckedArray.
The class template CheckedArray is derived from the class template Array
which is the base class
This program...
|
by: Tony Johansson |
last post by:
Hello Experts!
What does this mean actually.
If you have a template with a type and non-type template argument, say, like
this
template<typename T, int a>
class Array {. . .};
then A<int,...
|
by: RainBow |
last post by:
Greetings!!
I introduced the so-called "thin-template" pattern for controlling the
code bloat caused due to template usage.
However, one of the functions in the template happens to be virtual...
|
by: Stephan Steiner |
last post by:
Hi
Generally,
FileInfo fi = new FileInfo(path);
long size = fi.Length;
gets you the length of a file in bytes. However, when copying files, even
while the copy operation is still in...
|
by: rep_movsd |
last post by:
Hi folks
I was on topcoder and came across an interesting problem...
It involved dynamic programming ( storing function results in a map to
avoid repeated computation ) and I ended up having...
|
by: WebCM |
last post by:
I'm looking for a good idea or ready library for templates. HTML with
PHP isn't the best solution (it's more difficult for end-users of CMS
to edit them). Perhaps, everything I need is:
-...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
| |
