http://groups.google.com/group/comp.lang.c++?hl=en
comp.lang.c++@googlegroups.com
Today's topics:
* cout vs std::cout - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/4f48acdaa9e16cee?hl=en
* The need of Unicode types in C++0x - 5 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/56ed90f231762d03?hl=en
* STL container question - 12 messages, 4 authors
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/d2af39d060636197?hl=en
* Map losing elements!? - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/609ccdff4903d004?hl=en
* extern const variable in case label - 3 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/d0ae89b0e42f5a54?hl=en
* throwing dtors... - 3 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/ec97ab562016d016?hl=en
* OT: 9/11 Anniversary: Watch 9/11 Mysteries - How the World Trade Centre was
demo - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/8d0943d05c7a0f86?hl=en
==============================================================================
TOPIC: cout vs std::cout
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/4f48acdaa9e16cee?hl=en
==============================================================================
== 1 of 1 ==
Date: Thurs, Oct 2 2008 3:32 am
From: Hendrik Schober
Yannick Tremblay wrote:
> In article <gc0i06$qc8$1@cb.generation-online.de>,
> Hendrik Schober <spamtrap@gmx.de> wrote:
>> Yannick Tremblay wrote:
>>> In article <gbqvc0$2um$2@cb.generation-online.de>,
>>> Hendrik Schober <spamtrap@gmx.de> wrote:
>>>> Yannick Tremblay wrote:
> [...]
>>> IMO, this amount to a virtual ban. [...]
>> <shrug>
>> It's what usually all developers agreed on in those projects.
>> It only encourages bad naming when you're afraid of typing
>> (or whatever it is that makes people obsessed with writing the
>> fewest possible characters.)
>
> But you said it yourself:
> "What I've learned, though, is to avoid creating namespaces which are
> long and hard to type right even after weeks ('StringUtility') of
> usage. :)"
>
> So it did encourage you to use shorter and less informative
> identifiers [...]
No. It encouraged to use names that are easier to type.
That doesn't mean they had to be shorter or even less
informative. (But that was when we used an editor that
had no useful typing support. Nowadays probably nobody
would care.)
(Oh, and it was "Strings", not "String". :^> )
> In this case, "String" might be acceptable but this a only the first
> step on a slippery road. Be careful or the namespaces created by
> worse programmers than yoursel will start ressembling hungarian
> warts.
Don't you think that a bunch of programmers who decide
that they generally want to explicitly spell out every
namespace name for every identifier have a typing pain
threshold high enough to not to shorten names beyond
usability?
> Yannick
Schobi
==============================================================================
TOPIC: The need of Unicode types in C++0x
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/56ed90f231762d03?hl=en
==============================================================================
== 1 of 5 ==
Date: Thurs, Oct 2 2008 3:34 am
From: Ioannis Vranos
Pete Becker wrote:
> On 2008-10-01 12:57:27 -0400, Ioannis Vranos
> <ivranos@no.spam.nospamfreemail.gr> said:
>
>>
>> If that system supports Unicode as a system-specific type, why can't
>> wchar_t be made wide enough as that system-specific Unicode type, in
>> that system?
>
> It can be. But the language definition doesn't require it to be, and
> with many implementations it's not
C++03 mentions:
"Type wchar_t is a distinct type whose values can represent distinct
codes for all members of the *largest* extended character set specified
among the supported *locales* (22.1.1). Type wchar_t shall have the same
size, signedness, and alignment requirements (3.9) as one of the other
integral types, called its underlying type".
== 2 of 5 ==
Date: Thurs, Oct 2 2008 3:39 am
From: Ioannis Vranos
James Kanze wrote:
> On Oct 1, 11:59 am, Ioannis Vranos <ivra...@no.spam.nospamfreemail.gr>
> wrote:
>
>> So, since wstring supports the largest character set, why do
>> we need explicit Unicode types in C++?
>
> Because wstring doesn't guarantee Unicode, and implementers
> can't change what it does guarantee in their particular
> implementation.
Again, if the implementers want Unicode, they can add a Unicode local
and make wchar_t size large enough to match it.
In other words, C++0x could require all implementations to provide
specific Unicode locales that will work with existing facilities
(wchar_t, wstring, etc).
== 3 of 5 ==
Date: Thurs, Oct 2 2008 5:34 am
From: REH
On Oct 2, 3:41 am, James Kanze <james.ka...@gmail.com> wrote:
> No. Most systems that claim Unicode support on 16 bits use
> UTF-16. Granted, it's a multi-element encoding, but if you're
> doing anything serious, effectively, so is UTF-32. (In
> practice, I find that UTF-8 works fine for a lot of things.)
>
The ones I am familiar with only support UCS-2, not UTF-16. Windows,
for example, has WCHAR_T which is not UTF-16 (although Windows does
support MBCS, but I am not sure if that is truly UTF-8).
REH
== 4 of 5 ==
Date: Thurs, Oct 2 2008 6:25 am
From: Hendrik Schober
REH wrote:
> On Oct 2, 3:41 am, James Kanze <james.ka...@gmail.com> wrote:
>> No. Most systems that claim Unicode support on 16 bits use
>> UTF-16. Granted, it's a multi-element encoding, but if you're
>> doing anything serious, effectively, so is UTF-32. (In
>> practice, I find that UTF-8 works fine for a lot of things.)
>>
> The ones I am familiar with only support UCS-2, not UTF-16. Windows,
> for example, has WCHAR_T which is not UTF-16 [...].
TTBOMK, this isn't true anymore. It's UTF-16 now, not UCS-2.
> REH
Schobi
== 5 of 5 ==
Date: Thurs, Oct 2 2008 6:43 am
From: REH
On Oct 2, 9:25 am, Hendrik Schober <spamt...@gmx.de> wrote:
> REH wrote:
> > On Oct 2, 3:41 am, James Kanze <james.ka...@gmail.com> wrote:
> >> No. Most systems that claim Unicode support on 16 bits use
> >> UTF-16. Granted, it's a multi-element encoding, but if you're
> >> doing anything serious, effectively, so is UTF-32. (In
> >> practice, I find that UTF-8 works fine for a lot of things.)
>
> > The ones I am familiar with only support UCS-2, not UTF-16. Windows,
> > for example, has WCHAR_T which is not UTF-16 [...].
>
> TTBOMK, this isn't true anymore. It's UTF-16 now, not UCS-2.
>
Thanks. I guess I need to update my reference material. I haven't done
Windows programming since the NT days.
REH
==============================================================================
TOPIC: STL container question
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/d2af39d060636197?hl=en
==============================================================================
== 1 of 12 ==
Date: Thurs, Oct 2 2008 3:56 am
From: Hendrik Schober
Ioannis Vranos wrote:
> [...]
> We must think generally. In general, sorting a list is faster than
> sorting a vector, because the list sorting does not involve the
> construction or destruction of any object.
>
> Regarding ints, I think sorting a vector of ints and as list of ints,
> both have about the same efficiency.
Why don't you just measure before you doubt the statements
of those who already went and did this?
On my platform, this
#include <iostream>
#include <vector>
#include <list>
#include <algorithm>
const unsigned int kLimit = 1000000;
template< class Cont >
void fill(Cont& cont)
{
for( unsigned int u = 0; u < kLimit; ++u ) {
cont.push_back(u);
}
}
template< class Cont >
void test(Cont& cont);
int main()
{
std::vector<unsigned int> v; v.reserve(kLimit);
std::list<unsigned int> l;
std::cout << "filling a vector..." << std::endl;
fill(v);
std::cout << "filling a list..." << std::endl;
fill(l);
std::cout << "...done.\n";
std::cout << "sorting a vector..." << std::endl;
test(v);
std::cout << "sorting a list..." << std::endl;
test(l);
return 0;
}
template< typename T, class Al >
inline void sort(std::vector<T,Al>& v) {std::sort(v.begin(),v.end());}
template< typename T, class Al >
inline void sort(std::list<T,Al>& l) {l.sort();}
#include <windows.h> //for GetTickCount()
template< class Cont >
void test(Cont& cont) {
const DWORD start = GetTickCount();
sort(cont);
std::cout << "...took " << GetTickCount()-start << "msecs." << std::endl;
}
outputs
filling a vector...
filling a list...
...done.
sorting a vector...
...took 47msecs.
sorting a list...
...took 1562msecs.
and thus agrees with everyone who disagreed with you.
> If the programmer decides to replace ints with other objects, he will
> not have to change much in the code, if he uses a list.
Right. It wouldn't do any good anyway as this
#include <iostream>
#include <vector>
#include <list>
#include <algorithm>
#include <string>
const unsigned int kLimit = 1000000;
template< class Cont >
void fill(Cont& cont)
{
for( unsigned int u = 0; u < kLimit; ++u ) {
cont.push_back(Test());
}
}
template< class Cont >
void test(Cont& cont);
class Test {
public:
Test() : instance_(++id_), str_("test it!") {}
bool operator<(const Test& rhs) {return instance_>rhs.instance_;}
private:
unsigned int instance_;
static unsigned int id_;
std::string str_;
};
unsigned int Test::id_ = 0;
int main()
{
std::vector<Test> v; v.reserve(kLimit);
std::list<Test> l;
std::cout << "filling a vector..." << std::endl;
fill(v);
std::cout << "filling a list..." << std::endl;
fill(l);
std::cout << "...done.\n";
std::cout << "sorting a vector..." << std::endl;
test(v);
std::cout << "sorting a list..." << std::endl;
test(l);
return 0;
}
template< typename T, class Al >
inline void sort(std::vector<T,Al>& v) {std::sort(v.begin(),v.end());}
template< typename T, class Al >
inline void sort(std::list<T,Al>& l) {l.sort();}
#include <windows.h> //for GetTickCount()
template< class Cont >
void test(Cont& cont) {
const DWORD start = GetTickCount();
sort(cont);
std::cout << "...took " << GetTickCount()-start << "msecs." << std::endl;
}
outputs
filling a vector...
filling a list...
...done.
sorting a vector...
...took 829msecs.
sorting a list...
...took 2437msecs.
and thus again disagrees with you.
Eagerly awaiting your counter example,
Scho-you-can-take-your-foot-out-of-your-mouth-now-bi
== 2 of 12 ==
Date: Thurs, Oct 2 2008 4:14 am
From: Maxim Yegorushkin
On Oct 1, 6:40 pm, Pete Becker <p...@versatilecoding.com> wrote:
> On 2008-10-01 10:23:13 -0400, Ioannis Vranos
> <ivra...@no.spam.nospamfreemail.gr> said:
>
>
>
> > Victor Bazarov wrote:
> >> Ioannis Vranos wrote:
> >>> Victor Bazarov wrote:
>
> >>>> Store first, then sort, then search (using 'std::binary_search'), you
> >>>> could just use 'std::vector'.
>
> >>> For that case, I think std::list is a better option, since the sorting
> >>> will be faster,
>
> >> Do you have any proof of that?
>
> > Lists are implemented using pointers to point to the previous and to
> > the next elements, so list::sort(), is more efficient by changing
> > pointer values, while sorting a vector involves copying objects.
>
> In other words, no. <g> One could also point out that quicksort can be
> used to sort a vector but can't be used on a list, so obviously sorting
> a vector is faster.
Not always so.
You are correct that as lists do not provide random-access iterators
quicksort can not be used. Instead, lists are normally sorted using
merge sort. Merge sort has better worst-case performance than
quicksort. The drawback of merge sort is that it normally requires
extra memory, whereas quicksort does not.
http://en.wikipedia.org/wiki/Merge_sort
<quote>
In the worst case, merge sort does about 39% fewer comparisons than
quicksort does in the average case; merge sort always makes fewer
comparisons than quicksort, except in extremely rare cases, when they
tie, where merge sort's worst case is found simultaneously with
quicksort's best case. In terms of moves, merge sort's worst case
complexity is O(n log n)—the same complexity as quicksort's best case,
and merge sort's best case takes about half as many iterations as the
worst case.
</quote>
--
Max
== 3 of 12 ==
Date: Thurs, Oct 2 2008 6:00 am
From: Ioannis Vranos
Hendrik Schober wrote:
> Ioannis Vranos wrote:
>> [...]
>> We must think generally. In general, sorting a list is faster than
>> sorting a vector, because the list sorting does not involve the
>> construction or destruction of any object.
>>
>> Regarding ints, I think sorting a vector of ints and as list of ints,
>> both have about the same efficiency.
>
> Why don't you just measure before you doubt the statements
> of those who already went and did this?
>
> On my platform, this
[ Non-portable code...]
>
> and thus again disagrees with you.
>
> Eagerly awaiting your counter example,
#include <iostream>
#include <ctime>
#include <vector>
#include <list>
#include <cstddef>
#include <algorithm>
class SomeClass
{
typedef std::vector<int> TypeVector;
TypeVector vec;
enum { VectorSize= 1000 };
public:
SomeClass();
bool operator<(const SomeClass &argSomeClass) const
{
return vec[0]< argSomeClass.vec[0];
}
};
int main()
{
using namespace std;
srand(time(0));
const size_t SIZE=10000;
typedef vector<SomeClass> Vector;
typedef list<SomeClass> List;
cout<< "\nCreating vector with "<< SIZE<< " elements..."<< flush;
Vector vec(SIZE);
cout<<" Done!\n\n"<< flush;
List lis(vec.size());
cout<< "Filling list with vector elements..."<< flush;
for(Vector::size_type i= 0; i< vec.size(); ++i)
lis.push_back(vec[i]);
cout<< " Done!\n\n"<< flush;
clock_t timeBeginVector, timeEndVector, timeBeginList, timeEndList;
cout<< "Timing the sorting of the vector..."<< flush;
timeBeginVector= clock();
sort(vec.begin(), vec.end());
timeEndVector= clock();
cout<< " Done!\n\n"<< flush;
cout<< "Timing the sorting of the list..."<< flush;
timeBeginList= clock();
lis.sort();
timeEndList= clock();
cout<< " Done!\n\n"<< flush;
cout<< "The sorting of the vector took "
<< static_cast<double>((timeEndVector- timeBeginVector))/
CLOCKS_PER_SEC
<< " seconds\n\n";
cout<< "The sorting of the list took "
<< static_cast<double>((timeEndList- timeBeginList))/
CLOCKS_PER_SEC
<< " seconds\n\n";
}
SomeClass::SomeClass():vec(VectorSize)
{
using namespace std;
for(TypeVector::size_type i= 0; i< vec.size(); ++i)
vec[i]= rand();
sort(vec.begin(), vec.end());
}
== 4 of 12 ==
Date: Thurs, Oct 2 2008 6:14 am
From: Hendrik Schober
Ioannis Vranos wrote:
> Hendrik Schober wrote:
>> Ioannis Vranos wrote:
>>> [...]
>>> We must think generally. In general, sorting a list is faster than
>>> sorting a vector, because the list sorting does not involve the
>>> construction or destruction of any object.
>>>
>>> Regarding ints, I think sorting a vector of ints and as list of ints,
>>> both have about the same efficiency.
>> Why don't you just measure before you doubt the statements
>> of those who already went and did this?
>>
>> On my platform, this
>
>
> [ Non-portable code...]
>
>
>
>> and thus again disagrees with you.
>>
>> Eagerly awaiting your counter example,
>
>
> [code]
I had to add another zero in order to get sensible results:
Creating vector with 100000 elements... Done!
Filling list with vector elements... Done!
Timing the sorting of the vector... Done!
Timing the sorting of the list... Done!
The sorting of the vector took 0.016 seconds
The sorting of the list took 0.468 seconds
HTH,
Schobi
== 5 of 12 ==
Date: Thurs, Oct 2 2008 6:24 am
From: Ioannis Vranos
Hendrik Schober wrote:
> Ioannis Vranos wrote:
>> Hendrik Schober wrote:
>>> Ioannis Vranos wrote:
>>>> [...]
>>>> We must think generally. In general, sorting a list is faster than
>>>> sorting a vector, because the list sorting does not involve the
>>>> construction or destruction of any object.
>>>>
>>>> Regarding ints, I think sorting a vector of ints and as list of
>>>> ints, both have about the same efficiency.
>>> Why don't you just measure before you doubt the statements
>>> of those who already went and did this?
>>>
>>> On my platform, this
>>
>>
>> [ Non-portable code...]
>>
>>
>>
>>> and thus again disagrees with you.
>>>
>>> Eagerly awaiting your counter example,
>>
>>
>> [code]
>
> I had to add another zero in order to get sensible results:
>
> Creating vector with 100000 elements... Done!
> Filling list with vector elements... Done!
> Timing the sorting of the vector... Done!
> Timing the sorting of the list... Done!
> The sorting of the vector took 0.016 seconds
> The sorting of the list took 0.468 seconds
Your computer is faster than mine and probably with more RAM.
In my computer with SIZE 10000:
john@john-desktop:~/Projects/src$ ./foobar_cpp
Creating vector with 10000 elements... Done!
Filling list with vector elements... Done!
Timing the sorting of the vector... Done!
Timing the sorting of the list... Done!
The sorting of the vector took 2.55 seconds
The sorting of the list took 0.02 seconds
john@john-desktop:~/Projects/src$
In my computer with SIZE 100000 (uses swap):
john@john-desktop:~/Projects/src$ ./foobar_cpp
Creating vector with 100000 elements... Done!
Filling list with vector elements... Done!
Timing the sorting of the vector... Done!
Timing the sorting of the list... Done!
The sorting of the vector took 27.46 seconds
The sorting of the list took 4.58 seconds
john@john-desktop:~/Projects/src$
==> The timings less than 1 second are not conclusive. Add 0s until you
exceed 1-2 seconds.
== 6 of 12 ==
Date: Thurs, Oct 2 2008 6:31 am
From: Ioannis Vranos
The program had a serious bug.
corrected:
Ioannis Vranos wrote:
> Hendrik Schober wrote:
>> Ioannis Vranos wrote:
>>> [...]
>>> We must think generally. In general, sorting a list is faster than
>>> sorting a vector, because the list sorting does not involve the
>>> construction or destruction of any object.
>>>
>>> Regarding ints, I think sorting a vector of ints and as list of ints,
>>> both have about the same efficiency.
>>
>> Why don't you just measure before you doubt the statements
>> of those who already went and did this?
>>
>> On my platform, this
>
>
> [ Non-portable code...]
>
>
>
>>
>> and thus again disagrees with you.
>>
>> Eagerly awaiting your counter example,
#include <iostream>
#include <ctime>
#include <vector>
#include <list>
#include <cstddef>
#include <algorithm>
class SomeClass
{
typedef std::vector<int> TypeVector;
TypeVector vec;
enum { VectorSize= 1000 };
public:
SomeClass();
bool operator<(const SomeClass &argSomeClass) const
{
return vec[0]< argSomeClass.vec[0];
}
};
int main()
{
using namespace std;
srand(time(0));
const size_t SIZE=10000;
typedef vector<SomeClass> Vector;
typedef list<SomeClass> List;
cout<< "\nCreating vector with "<< SIZE<< " elements..."<< flush;
Vector vec(SIZE);
cout<<" Done!\n\n"<< flush;
===> List lis;
cout<< "Filling list with vector elements..."<< flush;
for(Vector::size_type i= 0; i< vec.size(); ++i)
lis.push_back(vec[i]);
cout<< " Done!\n\n"<< flush;
clock_t timeBeginVector, timeEndVector, timeBeginList, timeEndList;
cout<< "Timing the sorting of the vector..."<< flush;
timeBeginVector= clock();
sort(vec.begin(), vec.end());
timeEndVector= clock();
cout<< " Done!\n\n"<< flush;
cout<< "Timing the sorting of the list..."<< flush;
timeBeginList= clock();
lis.sort();
timeEndList= clock();
cout<< " Done!\n\n"<< flush;
cout<< "The sorting of the vector took "
<< static_cast<double>((timeEndVector- timeBeginVector))/
CLOCKS_PER_SEC
<< " seconds\n\n";
cout<< "The sorting of the list took "
<< static_cast<double>((timeEndList- timeBeginList))/
CLOCKS_PER_SEC
<< " seconds\n\n";
}
SomeClass::SomeClass():vec(VectorSize)
{
using namespace std;
for(TypeVector::size_type i= 0; i< vec.size(); ++i)
vec[i]= rand();
sort(vec.begin(), vec.end());
}
== 7 of 12 ==
Date: Thurs, Oct 2 2008 6:31 am
From: Hendrik Schober
Ioannis Vranos wrote:
> [...]
> ==> The timings less than 1 second are not conclusive. Add 0s until you
> exceed 1-2 seconds.
If I add a single one more, the program runsout of memory.
Schobi
== 8 of 12 ==
Date: Thurs, Oct 2 2008 6:34 am
From: Hendrik Schober
Ioannis Vranos wrote:
> The program had a serious bug.
>
>
> corrected:
> [...]
Creating vector with 100000 elements... Done!
Filling list with vector elements... Done!
Timing the sorting of the vector... Done!
Timing the sorting of the list... Done!
The sorting of the vector took 0.015 seconds
The sorting of the list took 0.437 seconds
Schobi
== 9 of 12 ==
Date: Thurs, Oct 2 2008 6:38 am
From: Ioannis Vranos
Ioannis Vranos wrote:
> The program had a serious bug.
>
>
> corrected:
>
>
>
> #include <iostream>
> #include <ctime>
> #include <vector>
> #include <list>
> #include <cstddef>
> #include <algorithm>
>
>
> class SomeClass
> {
> typedef std::vector<int> TypeVector;
>
> TypeVector vec;
>
> enum { VectorSize= 1000 };
>
> public:
>
> SomeClass();
>
> bool operator<(const SomeClass &argSomeClass) const
> {
> return vec[0]< argSomeClass.vec[0];
> }
> };
>
>
>
>
>
> int main()
> {
> using namespace std;
>
> srand(time(0));
>
> const size_t SIZE=10000;
>
> typedef vector<SomeClass> Vector;
> typedef list<SomeClass> List;
>
>
> cout<< "\nCreating vector with "<< SIZE<< " elements..."<< flush;
> Vector vec(SIZE);
>
> cout<<" Done!\n\n"<< flush;
>
> ===> List lis;
>
>
> cout<< "Filling list with vector elements..."<< flush;
>
> for(Vector::size_type i= 0; i< vec.size(); ++i)
> lis.push_back(vec[i]);
>
> cout<< " Done!\n\n"<< flush;
>
>
> clock_t timeBeginVector, timeEndVector, timeBeginList, timeEndList;
>
>
> cout<< "Timing the sorting of the vector..."<< flush;
>
> timeBeginVector= clock();
>
> sort(vec.begin(), vec.end());
>
> timeEndVector= clock();
>
> cout<< " Done!\n\n"<< flush;
>
>
> cout<< "Timing the sorting of the list..."<< flush;
>
> timeBeginList= clock();
>
> lis.sort();
>
> timeEndList= clock();
>
>
> cout<< " Done!\n\n"<< flush;
>
>
> cout<< "The sorting of the vector took "
> << static_cast<double>((timeEndVector- timeBeginVector))/
> CLOCKS_PER_SEC
> << " seconds\n\n";
>
> cout<< "The sorting of the list took "
> << static_cast<double>((timeEndList- timeBeginList))/
> CLOCKS_PER_SEC
> << " seconds\n\n";
> }
>
>
>
> SomeClass::SomeClass():vec(VectorSize)
> {
> using namespace std;
>
> for(TypeVector::size_type i= 0; i< vec.size(); ++i)
> vec[i]= rand();
>
> sort(vec.begin(), vec.end());
> }
And my results:
1. const size_t SIZE= 90000;
john@john-desktop:~/Projects/src$ ./foobar_cpp
Creating vector with 90000 elements... Done!
Filling list with vector elements... Done!
Timing the sorting of the vector... Done!
Timing the sorting of the list... Done!
The sorting of the vector took 24.79 seconds
The sorting of the list took 0.1 seconds
john@john-desktop:~/Projects/src$
2. const size_t SIZE= 100000;
john@john-desktop:~/Projects/src$ ./foobar_cpp
Creating vector with 100000 elements... Done!
Filling list with vector elements... Done!
Timing the sorting of the vector... Done!
Timing the sorting of the list... Done!
The sorting of the vector took 26.8 seconds
The sorting of the list took 0.1 seconds
john@john-desktop:~/Projects/src$
== 10 of 12 ==
Date: Thurs, Oct 2 2008 6:42 am
From: Ioannis Vranos
Hendrik Schober wrote:
> Ioannis Vranos wrote:
>> The program had a serious bug.
>>
>>
>> corrected:
>> [...]
>
> Creating vector with 100000 elements... Done!
> Filling list with vector elements... Done!
> Timing the sorting of the vector... Done!
> Timing the sorting of the list... Done!
> The sorting of the vector took 0.015 seconds
> The sorting of the list took 0.437 seconds
Again, increase the number of const size_t SIZE so as to exceed 1-2
seconds for the sorting of one container, and then post your results.
For example try
const size_t SIZE= 400000;
== 11 of 12 ==
Date: Thurs, Oct 2 2008 6:48 am
From: Victor Bazarov
Ioannis Vranos wrote:
> Hendrik Schober wrote:
>> Ioannis Vranos wrote:
>>> Hendrik Schober wrote:
>>>> Ioannis Vranos wrote:
>>>>> [...]
>>>>> We must think generally. In general, sorting a list is faster than
>>>>> sorting a vector, because the list sorting does not involve the
>>>>> construction or destruction of any object.
>>>>>
>>>>> Regarding ints, I think sorting a vector of ints and as list of
>>>>> ints, both have about the same efficiency.
>>>> Why don't you just measure before you doubt the statements
>>>> of those who already went and did this?
>>>>
>>>> On my platform, this
>>>
>>>
>>> [ Non-portable code...]
>>>
>>>
>>>
>>>> and thus again disagrees with you.
>>>>
>>>> Eagerly awaiting your counter example,
>>>
>>>
>>> [code]
>>
>> I had to add another zero in order to get sensible results:
>>
>> Creating vector with 100000 elements... Done!
>> Filling list with vector elements... Done!
>> Timing the sorting of the vector... Done!
>> Timing the sorting of the list... Done!
>> The sorting of the vector took 0.016 seconds
>> The sorting of the list took 0.468 seconds
>
>
>
> Your computer is faster than mine and probably with more RAM.
>
>
> In my computer with SIZE 10000:
>
>
> john@john-desktop:~/Projects/src$ ./foobar_cpp
>
> Creating vector with 10000 elements... Done!
>
> Filling list with vector elements... Done!
>
> Timing the sorting of the vector... Done!
>
> Timing the sorting of the list... Done!
>
> The sorting of the vector took 2.55 seconds
>
> The sorting of the list took 0.02 seconds
>
> john@john-desktop:~/Projects/src$
>
>
>
>
>
> In my computer with SIZE 100000 (uses swap):
>
>
> john@john-desktop:~/Projects/src$ ./foobar_cpp
>
> Creating vector with 100000 elements... Done!
>
> Filling list with vector elements... Done!
>
> Timing the sorting of the vector... Done!
>
> Timing the sorting of the list... Done!
>
> The sorting of the vector took 27.46 seconds
>
> The sorting of the list took 4.58 seconds
>
> john@john-desktop:~/Projects/src$
>
>
>
> ==> The timings less than 1 second are not conclusive. Add 0s until you
> exceed 1-2 seconds.
This exercise is pointless. I made 200K elements (no swap, but the
computer uses up to 2.5G of RAM, probably mostly due to the need to keep
all the pointers in the list elements) and I still consistently get
Creating vector with 200000 elements... Done!
Filling list with vector elements... Done!
Timing the sorting of the vector... Done!
Timing the sorting of the list... Done!
The sorting of the vector took 0.015 seconds
The sorting of the list took 0.156 seconds
What is it you're trying to prove? That your computer and your
implementation are dilapidated? Get a better compiler.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
== 12 of 12 ==
Date: Thurs, Oct 2 2008 6:56 am
From: Ioannis Vranos
Victor Bazarov wrote:
>
> This exercise is pointless. I made 200K elements (no swap, but the
> computer uses up to 2.5G of RAM, probably mostly due to the need to keep
> all the pointers in the list elements) and I still consistently get
>
>
> Creating vector with 200000 elements... Done!
>
> Filling list with vector elements... Done!
>
> Timing the sorting of the vector... Done!
>
> Timing the sorting of the list... Done!
>
> The sorting of the vector took 0.015 seconds
>
> The sorting of the list took 0.156 seconds
>
> What is it you're trying to prove? That your computer and your
> implementation are dilapidated? Get a better compiler.
The specific code had a serious bug (list had double elements than
vector). Also differences in milliseconds have no point (are inconclusive).
==============================================================================
TOPIC: Map losing elements!?
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/609ccdff4903d004?hl=en
==============================================================================
== 1 of 1 ==
Date: Thurs, Oct 2 2008 4:18 am
From: Johannes Bauer
Hello everyone again,
Johannes Bauer schrieb:
> Can anyone explain this behaviour?
Of course you could :-\
Thank you very much for your kind suggestions, each and every one of you
has pointed out the correct solution (my broken operator<)... I really
looked over it over and over again, but really didn't see the mistake
(that the for loop should only continue when a[i] == b[i]).
Guess I should stop writing code after 3 am...
Thanks again!
Kind regards,
Johannes
--
"Meine Gegenklage gegen dich lautet dann auf bewusste Verlogenheit,
verlästerung von Gott, Bibel und mir und bewusster Blasphemie."
-- Prophet und Visionär Hans Joss aka HJP in de.sci.physik
<48d8bf1d$0$7510$5402220f@news.sunrise.ch>
==============================================================================
TOPIC: extern const variable in case label
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/d0ae89b0e42f5a54?hl=en
==============================================================================
== 1 of 3 ==
Date: Thurs, Oct 2 2008 4:52 am
From: Martin Eisenberg
Christian Meier wrote:
> Do you have any suggestions how I can compile all my code
> without having more than one symbol for "iValue" in my program?
> Or is it not possible what I am trying to reach?
How about this?
enum { iValue = int(5) };
Martin
--
Quidquid latine scriptum est, altum videtur.
== 2 of 3 ==
Date: Thurs, Oct 2 2008 5:17 am
From: "Christian Meier"
"Martin Eisenberg" <martin.eisenberg@udo.edu> wrote:
> Christian Meier wrote:
>
>> Do you have any suggestions how I can compile all my code
>> without having more than one symbol for "iValue" in my program?
>> Or is it not possible what I am trying to reach?
>
> How about this?
>
> enum { iValue = int(5) };
>
Thanks for your answer!
Ok, you're right, that could be a solution for "int".
To tell a bit more of the truth, I have these constants for quite all
built-in types (double, long int, short...) and IIRC enum values must have
type int.
== 3 of 3 ==
Date: Thurs, Oct 2 2008 6:29 am
From: James Kanze
On Oct 2, 11:23 am, "Christian Meier" <chris@no_spam.com> wrote:
> I have the following code:
> file1.h:
> static const int iValue = 5;
> <EOF>
> file2.cpp
> #include <iostream>
> #include "file1.h"
> int main(int args, char* argv[])
> {
> switch(args) {
> case iValue:
> std::cout << "Hello\n";
> }
> }
> <EOF>
> This works fine as the value of the constant "iValue" is known
> when compiling the main()-function in file2.cpp.
> I have some more cpp-files which include file1.h. Therefore I
> have a copy of "iValue" in each translation unit as it has
> internal linkage. In the executable which is made with these
> object files (translation units) I have several copies of that
> variable; all having the same value.
Maybe. Maybe not.
> Now, I would like to change the linkage of "iValue" to extern
> so that there is only one symbol for this constant in my
> executable. When I change the keyword "static" to "extern" I
> have the problem that the symbol is more than once defined in
> my executable. When I only declare the variable "iValue" in
> file1.h with external linkage ("extern const int iValue;") and
> define it in a new file called file1.cpp ("extern const iValue
> = 5;"), then I have no problem with multiple definitions but I
> have a new problem in my function main() because the value of
> "iValue" is not known when compiling file2.cpp.
> Do you have any suggestions how I can compile all my code
> without having more than one symbol for "iValue" in my
> program? Or is it not possible what I am trying to reach?
Do you have some valid reason for wanting iValue to have the
same address in every translation unit? It seems strange to me
to give an int identity, especially if you're not going to
change it. And otherwise, what's the problem with what you have
written initially?
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
==============================================================================
TOPIC: throwing dtors...
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/ec97ab562016d016?hl=en
==============================================================================
== 1 of 3 ==
Date: Thurs, Oct 2 2008 5:35 am
From: "Chris M. Thomasson"
"Chris M. Thomasson" <no@spam.invalid> wrote in message
news:k4XEk.16199$hX5.2021@newsfe06.iad...
> Is it every appropriate to throw in a dtor? I am thinking about a simple
> example of a wrapper around a POSIX file...
[...]
Thank you all (e.g., anon, James Kanze and Paavo Helde) for your excellent
insight. After absorbing your input, I think the way to go would be
something like; thread-safety wrt the `file::m_handle' member aside for a
moment:
_________________________________________________________________
#if ! defined(FILE_DTOR_UNEXPECTED)
# define FILE_DTOR_UNEXPECTED(mp_file) assert(false)
No comments:
Post a Comment