http://groups.google.com/group/comp.lang.c++?hl=en
comp.lang.c++@googlegroups.com
Today's topics:
* throwing dtors... - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/ec97ab562016d016?hl=en
* STL container question - 15 messages, 7 authors
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/d2af39d060636197?hl=en
* 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 - 4 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/56ed90f231762d03?hl=en
* unsupported function problem - WinCE - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/77baf79338e0b00a?hl=en
* www.502dating.com - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/9e0890a30e582b71?hl=en
* templates - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/72aa4d4f4ae0f080?hl=en
* extern const variable in case label - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/d0ae89b0e42f5a54?hl=en
==============================================================================
TOPIC: throwing dtors...
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/ec97ab562016d016?hl=en
==============================================================================
== 1 of 2 ==
Date: Thurs, Oct 2 2008 7:03 am
From: "Chris M. Thomasson"
"James Kanze" <james.kanze@gmail.com> wrote in message
news:c9742b5f-9a15-442d-8f4d-0ebcdac70647@r66g2000hsg.googlegroups.com...
> On Oct 2, 2:35 pm, "Chris M. Thomasson" <n...@spam.invalid> wrote:
> > "Chris M. Thomasson" <n...@spam.invalid> wrote in
> > messagenews: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...
>
> > [...]
> > Although James Kanze seems to suggest that `file::close()'
> > should return a error code; perhaps the value from errno.
> I said "error code" because the expression "return a return
> code" sounded funny. It should return as much information as is
> necessary, but not necessarily any more. Typically, it will
> return a class local enum. Depending on the intended audience,
> this can be as simple as:
> enum ErrorCode
> {
> succeeded,
> failed
> } ;
> Alternatively, you can categorize the errors in a somewhat finer
> way.
Humm, perhaps something like:
class file {
public:
struct error_code {
enum value {
succeeded = 0x0,
failed = 0x1,
bad_descriptor = failed | 0x2,
exceeds_offset = failed | 0x4,
process_orphaned = failed | 0x8,
no_free_space = failed | 0x10,
pipe_not_for_reading = failed | 0x20,
non_existing_device = failed | 0x40,
already_closed = failed | 0x80,
unknown = failed | 0x100
};
};
};
That way you can combine several error codes in a single value; sometimes
that ability might be fairly "useful" and/or convenient. However, IMVHO, how
does this improve on my example with fine-grain exceptions? Do C++
programmers tolerate having to examine return values for error-codes? I
think some of them would be fine with a simple boolean in certain cases, but
more than that would perhaps sound too C`ish?
> In some cases, I also provide a means of accessing a system
> dependent error code, in addition to the above. In such cases,
> I'll also typically provide a way of mapping that error code to
> a message.
Yeah; that's definitely convenient!
== 2 of 2 ==
Date: Thurs, Oct 2 2008 8:50 am
From: Andre Kostur
"Chris M. Thomasson" <no@spam.invalid> wrote in
news:X5_Ek.12946$ex3.3200@newsfe02.iad:
> "anon" <anon@no.invalid> wrote in message
> news:gc1n78$kks$1@news01.versatel.de...
>> Chris M. Thomasson wrote:
>>> Is it every appropriate to throw in a dtor? I am thinking about a
>>> simple example of a wrapper around a POSIX file...
>>
>> Take a look here:
>> http://www.parashift.com/c++-faq-lite/dtors.html#faq-11.13
>
> Okay; I will give it a look.
>
> [...]
>
>> How would you handle it in C?
> [...]
>
>> What can you do when fclose fails?
>
> Well, it depends on the error:
>
> http://www.opengroup.org/onlinepubs/007908775/xsh/fclose.html
>
> For instance, fclose can get interrupted by a signal. In this case,
> you need to reissue the operation; e.g:
> ______________________________________________________________
> struct file {
> FILE* handle;
> };
>
> int file_close(
> struct file* const this
> ) {
> int status;
> do {
> status = fclose(this->handle);
> } while (status == EOF && errno == EINTR);
> return status;
> }
> ______________________________________________________________
>
>
>
>
> Or, what if it returns `EAGAIN', well, this certainly needs to be
> handled. However, it would be better to let the application to handle
> this, not do it implicitly within the `file_close()' function. There
> are many ways to handle this. That's not the problem. The problem is
> when a retarded program does not handle it! IHO, any program that does
> not explicitly handle errors from `fclose()' is severely broken and
> VERY dangerous. Let me give you a example... Imagine a C++ wrapper
> around a C FILE... Fine. Imagine the dtor looks like this:
>
>
>
> class file {
> FILE* m_handle;
>
> public:
> ~file() throw() {
> fclose(m_handle);
> }
> };
>
>
>
> Fine... Now, a user needs to copy a file to a disk, and destroy the
> original. Okay. It creates two file objects (e.g., src and dest:)
>
>
>
> {
> file src(...);
> file dest(...);
>
> // Then it performs the copy operation:
>
> [copy src to dest]
> }
>
>
>
> Now the code-block goes out of scope, and no exceptions were thrown
> during the copy process, HOWEVER, the call to `fclose()' in the dest
> object failed!!!! Well, the user thinks everything is fine because the
> completely retarded ignorant moron file object did not report the
> fuc%ing error! So the user operates in ignorance and happily destroys
> the original file thinking that the file was COMPLETELY copied onto
> the disk! WRONG! The file was partially copied because `fclose()'
> failed to do its thing and properly flush the buffers, or whatever...
> Now, the missing file data is LOST __forever__! OUCH!!!
>
>
> This is why its ESSENTIAL to report and handle errors from
> `fclose()'... If `fclose()' fails, you can't be so sure that the file
> is 100% coherent...
>
>
> Any thoughts?
>
Yep, you're not using exceptions appropriately. What should be
happening is your loop around fclose should be in the destructor itself.
By throwing an exception out of the destructor you are effectively
saying that the object was unable to be destroyed. Now you're in for a
whole world of hurt. How can you possibly recover from that? The
object is already on its way out of scope, and now you can't destroy it.
You can't abort the object going out of scope. Really, if the caller
really was ready to handle errors from fclose, then they should be using
whatever method of the file class that just does fclose before allowing
the object to fall out of scope.
Additionally a whole different world of hurt happens is you have an
array of these things. Let's assume an array of 10 of them. Also let's
assume that object #7 throws an exception during construction. So the
program dutifully destroys all of the previous objects that it had
previously fully constructed. And object #3 throws an exception during
its destructor. Now you have 2 active exceptions running around.
That's a short trip to a terminated program. You can't catch it. This
is probably the best example of why allowing exceptions to propogate out
of destructors is a Bad Thing.
==============================================================================
TOPIC: STL container question
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/d2af39d060636197?hl=en
==============================================================================
== 1 of 15 ==
Date: Thurs, Oct 2 2008 7:00 am
From: Ioannis Vranos
Ioannis Vranos wrote:
>
>> The program had a serious bug.
>
> [...]
>
>
> 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$
Just for the record, my system is:
OS: Ubuntu 8.04 x86.
Compiler: gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)
Hardware: Pentium III 1 GHz, 1 GB RAM.
== 2 of 15 ==
Date: Thurs, Oct 2 2008 7:03 am
From: Victor Bazarov
Ioannis Vranos wrote:
> 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;
-------------- a debug build:
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.203 seconds
The sorting of the list took 4.602 seconds
-------------- a release build:
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.016 seconds
The sorting of the list took 0.062 seconds
-------------- another release build:
Creating vector with 300000 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.125 seconds
---------------------------------------------------------
Tell me again, what does your example prove? And, again, get a better
compiler and a better library. Whatever version you're using is *crap*,
obviously.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
== 3 of 15 ==
Date: Thurs, Oct 2 2008 7:05 am
From: Ioannis Vranos
Victor Bazarov wrote:
> What is it you're trying to prove? That your computer and your
> implementation are dilapidated? Get a better compiler.
Apart from the bug, sorting a list, does not involve the construction or
destruction of any object, while in the case of vector, element objects
are copied.
== 4 of 15 ==
Date: Thurs, Oct 2 2008 7:07 am
From: Ioannis Vranos
Victor Bazarov wrote:
>
> Tell me again, what does your example prove? And, again, get a better
> compiler and a better library. Whatever version you're using is *crap*,
> obviously.
Do you agree that sorting a list does not involve object creation, while
sorting a vector involves the copying of the object elements?
== 5 of 15 ==
Date: Thurs, Oct 2 2008 7:08 am
From: Ioannis Vranos
Ioannis Vranos wrote:
> Victor Bazarov wrote:
>>
>> Tell me again, what does your example prove? And, again, get a better
>> compiler and a better library. Whatever version you're using is
>> *crap*, obviously.
>
>
> Do you agree that sorting a list does not involve object creation
or assignment,
> while
> sorting a vector involves the copying of the object elements?
== 6 of 15 ==
Date: Thurs, Oct 2 2008 7:11 am
From: Victor Bazarov
Ioannis Vranos wrote:
> Ioannis Vranos wrote:
>>
>>> The program had a serious bug.
>>
> > [...]
> >
> >
>> 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$
>>
>
> Just for the record, my system is:
>
>
> OS: Ubuntu 8.04 x86.
>
> Compiler: gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)
>
> Hardware: Pentium III 1 GHz, 1 GB RAM.
The system I tested on is DELL T7400 (dual Intel Xeon quad core), Vista
Ultimate 64, Visual C++ 2008 sp1, 4 gigs of RAM. Since no parallelizing
is done in your program, the number of cores doesn't matter, but the CPU
is faster, and while I would love to try it on a 16-gigabyte machine or
better, I don't have access to one. My machine is what our clients are
getting, so the results stand. You're free to speculate what makes it
so *bad* on your machine, but I'd seriously think about switching to a
real OS and a real compiler, if I got such bad results as you do.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
== 7 of 15 ==
Date: Thurs, Oct 2 2008 7:15 am
From: Victor Bazarov
Ioannis Vranos wrote:
> Ioannis Vranos wrote:
>> Victor Bazarov wrote:
>>>
>>> Tell me again, what does your example prove? And, again, get a
>>> better compiler and a better library. Whatever version you're using
>>> is *crap*, obviously.
>>
>>
>> Do you agree that sorting a list does not involve object creation
>
> or assignment,
>
>> while sorting a vector involves the copying of the object elements?
Whatever it involves (and I'd think it would actually be *swapping* and
not assignment or copying), apparently *your library* does it in a very
unacceptable manner.
You can theorize as much as you want, but in the end the results only
prove that one needs to measure before coming to any conclusions. Logic
does not always work well...
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
== 8 of 15 ==
Date: Thurs, Oct 2 2008 7:43 am
From: "Chris M. Thomasson"
"Victor Bazarov" <v.Abazarov@comAcast.net> wrote in message
news:gc2l17$jqi$2@news.datemas.de...
> Ioannis Vranos wrote:
>> Ioannis Vranos wrote:
>>> Victor Bazarov wrote:
>>>>
>>>> Tell me again, what does your example prove? And, again, get a better
>>>> compiler and a better library. Whatever version you're using is
>>>> *crap*, obviously.
>>>
>>>
>>> Do you agree that sorting a list does not involve object creation
>>
>> or assignment,
>>
>>> while sorting a vector involves the copying of the object elements?
>
> Whatever it involves (and I'd think it would actually be *swapping* and
> not assignment or copying),
Doesn't a swap sort of imply a copy of "something"?
struct object {
int x;
};
object objs[2] = { { 0 }, { 1 } };
How do you swap `obj[0]' with `obj[1]' without copying "something"?
> apparently *your library* does it in a very unacceptable manner.
> You can theorize as much as you want, but in the end the results only
> prove that one needs to measure before coming to any conclusions. Logic
> does not always work well...
;^)
== 9 of 15 ==
Date: Thurs, Oct 2 2008 7:39 am
From: Richard Herring
In message <gc26jq$ksb$1@ulysses.noc.ntua.gr>, Ioannis Vranos
<ivranos@no.spam.nospamfreemail.gr> writes
>Juha Nieminen wrote:
>> Ioannis Vranos wrote:
>>> 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.
>> The original poster talked about storing integer values. I highly
>> doubt sorting a list of integers will be faster than sorting an array of
>> integers. In fact, I'm pretty sure of the contrary.
>
>
>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.
So how many constructions and destructions does std::sort involve?
>
>Regarding ints, I think sorting a vector of ints and as list of ints,
>both have about the same efficiency.
How many integer assignments to swap two ints in a vector?
How many pointer assignments to swap two elements in a list?
>
>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.
What would he have to change with a vector?
--
Richard Herring
== 10 of 15 ==
Date: Thurs, Oct 2 2008 7:55 am
From: Lars Tetzlaff
Ioannis Vranos schrieb:
> 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());
> }
This program doesn't sort at all, because the vec is initialized with
one constant! Change the list filling code to
for(Vector::size_type i= 0; i< vec.size(); ++i) {
vec[i]= SomeClass();
lis.push_back(vec[i]);
}
and you have something to sort.
My result on OpenSuse 11 64Bit with Phenom 9850 and 4GB RAM, gcc 4.3.1,
const size_t SIZE=100000, compiled with g++ -O3 :
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 1.12 seconds
The sorting of the list took 0.12 seconds
Lars
== 11 of 15 ==
Date: Thurs, Oct 2 2008 8:03 am
From: Jerry Coffin
In article <aeb09adf-92fc-45ce-aa7f-
80f4ba2e6e3d@l62g2000hse.googlegroups.com>, maxim.yegorushkin@gmail.com
says...
[ ... ]
> You are correct that as lists do not provide random-access iterators
> quicksort can not be used.
Actually, that's not true. It's entirely possible to implement a
quicksort on a linked list. You can't (efficiently) use a median-of-
three (or whatever) pivot selection, but the quicksort itself has no
need for random-access iteration.
> Instead, lists are normally sorted using merge sort.
This, however, is true. Even though you _can_ use quicksort on a linked
list, the potential gains from doing so are much smaller than the
potential losses.
> 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.
When applied to arrays/vectors, that's true. For a linked list, they
both require essentially the same extra memory.
--
Later,
Jerry.
The universe is a figment of its own imagination.
== 12 of 15 ==
Date: Thurs, Oct 2 2008 8:24 am
From: Juha Nieminen
Ioannis Vranos wrote:
> list::sort is faster than any sort on vector, because it does not
> involve the construction or destruction of any object.
This is true even if the elements being sorted are ints?
What do you think is faster, copying and assigning individual ints, or
updating pairs of pointers at each stage of the sorting?
== 13 of 15 ==
Date: Thurs, Oct 2 2008 8:27 am
From: Juha Nieminen
Jerry Coffin wrote:
> You can't (efficiently) use a median-of-three (or whatever) pivot selection
Not true.
Granted, you can't do it for the *first* partition, but there's no
problem in getting the median-of-three pivot in subsequent partitions.
== 14 of 15 ==
Date: Thurs, Oct 2 2008 8:50 am
From: Ioannis Vranos
Chris M. Thomasson wrote:
>
>
> Doesn't a swap sort of imply a copy of "something"?
>
> struct object {
> int x;
> };
>
> object objs[2] = { { 0 }, { 1 } };
>
> How do you swap `obj[0]' with `obj[1]' without copying "something"?
>
A vector::swap() can be a shallow swap. For example if a vector is
implemented as a pointer pointing to an array on the free store, swap
could just swap the pointer values, without interfering with the contents.
== 15 of 15 ==
Date: Thurs, Oct 2 2008 8:54 am
From: Ioannis Vranos
Lars Tetzlaff wrote:
> Ioannis Vranos schrieb:
>> 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());
>> }
>
> This program doesn't sort at all, because the vec is initialized with
> one constant!
? Yes it is initalised with its number of elements, which are SomeClass
objects created with their default constructor.
> Change the list filling code to
>
> for(Vector::size_type i= 0; i< vec.size(); ++i) {
> vec[i]= SomeClass();
> lis.push_back(vec[i]);
> }
Why?
==============================================================================
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 7:12 am
From: ytrembla@nyx.nyx.net (Yannick Tremblay)
In article <42111dc3-5386-4239-a21e-26fbfccb9f08@2g2000hsn.googlegroups.com>,
James Kanze <james.kanze@gmail.com> wrote:
>On Oct 1, 9:15 pm, Hendrik Schober <spamt...@gmx.de> wrote:
>> Juha Nieminen wrote:
>> > James Kanze wrote:
>> >> So I write one line which makes each of the following lines
>> >> shorter. One line which might make the difference between
>> >> having to break an expression into two lines or not (because my
>> >> coding guidelines don't allow lines longer than 80 characters).
>
>> This is the only reason I ever used using declarations.
>
>> > If a code line is so long that it exceeds 80 characters, in my opinion
>> > it *should* be broken into several lines.
>
>> Sometimes this hinders readability more than many other
>> things could.
>
>Not if the tool you're using to look at the code truncates the
>line at 80 characters:-).
But in that case, where is the problem?
a) The tool you are using to look at the code is inadequate
b) the code is inadequate
Should all code be written to the lowest common denominator or should
a sensible compromise be taken to write at a useful and fairly common
denominator but not necessarily the lowest common one if the lowest
common denominator makes the code worse for above minimal users?
The huge majority will be able to use a code viewing tool that is able
to wrap lines and produce a readable display. So chopping lines to 80
chars then may result in less readable code for the huge majority of
cases while helping only a very small minority?
I once had a programmer tell me that he disliked small files because
it forced him to open more than one file to follow the logic and
lookup a different function. The guy was coding using vi in a
terminal window but making no use whatsoever of tools like ctags and
the vi ctags integration. What should have been the correct answer?
Put guidelines that all modules should consist only of one file so that
Mr-I-Don't-Know-How-To-Use-My-Tools would be conveniently served and
not have to open anymore files but could find his functions by
scrolling or using the '/' or '?' vi command which was maybe the limit
of his knowledge? Or should files be kept small and the
aforementioned be told to either change his tools or learn to use
them?
Yannick
==============================================================================
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 4 ==
Date: Thurs, Oct 2 2008 7:19 am
From: James Kanze
On Oct 2, 12:21 pm, Hendrik Schober <spamt...@gmx.de> wrote:
> James Kanze wrote:
> > On Oct 1, 11:59 am, Ioannis Vranos <ivra...@no.spam.nospamfreemail.gr>
> > wrote:
> >> Hi, I am currently learning QT, a portable C++ framework which
> >> comes with both a commercial and GPL license, and which
> >> provides conversion operations to its various types to/from
> >> standard C++ types.
> >> For example its QString type provides a toWString() that
> >> returns a std::wstring with its Unicode contents.
> > In what encoding format? And what if the "usual" encoding for
> > wstring isn't Unicode (the case on many Unix platforms).
> <curious>
> What are those implementations using for 'wchar_t'?
> </curious>
EUC. EUC (= Extended Unix Codes) is originally a multi-byte
code, but exists as a 32 bit code as well, see
http://docs.sun.com/app/docs/doc/802-1950/6i5us7asn?l=en&a=view.
It's apparently the standard encoding for wchar_t under Solaris
and HP/UX, and perhaps elsewhere as well. Thus, LATIN SMALL
LETTER E WITH ACUTE has the code 0x00E9 in Unicode, but
0x30000069 under Solaris. (``printf( "%04x\n", (unsigned
int)L'é''') -- the compiler apparently recognizes my
LC_CTYPE=iso_8859_1 locale for the file input.)
--
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
== 2 of 4 ==
Date: Thurs, Oct 2 2008 7:21 am
From: James Kanze
On Oct 2, 12:39 pm, Ioannis Vranos <ivra...@no.spam.nospamfreemail.gr>
wrote:
> 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.
And break their existing code base? They're not that
irresponsible (most of them, anyway). And the basic idea behind
wchar_t is that it is suppose to be locale independent, at least
for the encoding.
> In other words, C++0x could require all implementations to
> provide specific Unicode locales that will work with existing
> facilities (wchar_t, wstring, etc).
It could. It would also be ignored by most major implementors
if it did.
--
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
== 3 of 4 ==
Date: Thurs, Oct 2 2008 7:27 am
From: Ioannis Vranos
James Kanze wrote:
>
> And break their existing code base? They're not that
> irresponsible (most of them, anyway). And the basic idea behind
> wchar_t is that it is suppose to be locale independent, at least
> for the encoding.
How would they "break" their existing code base, by adding some
additional locales and even changing the size of wchar_t?
== 4 of 4 ==
Date: Thurs, Oct 2 2008 8:23 am
From: ytrembla@nyx.nyx.net (Yannick Tremblay)
In article <gc0a5o$2rdr$1@ulysses.noc.ntua.gr>,
Ioannis Vranos <ivranos@no.spam.nospamfreemail.gr> wrote:
>REH wrote:
>> On Oct 1, 5:59 am, Ioannis Vranos <ivra...@no.spam.nospamfreemail.gr>
>> wrote:
>>>
>>> I think what is needed is a "unicode" locale or at the most, some
>>> unicode locales.
>>>
>>> I don't consider being compatible with C99 as an excuse.
>>
>> If I understand what you are asking...
>>
>> wstring in the standard defines neither the character set, nor the
>> encoding. Given that Unicode is currently a 21-bit standard, how can
>> wstring support the largest character set on a system where wchar_t is
>> 16-bits (assuming a one-character-per-element encoding)? You could
>> only support the BMP (which is exactly what most systems and language
>> that "claim" Unicode support are really capable of).
>
>
>I do not know much about encodings, only the necessary for me stuff, but
>the question does not sound reasonable for me.
>
>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?
There is no system that support "Unicode". you should go to:
http://www.unicode.org/standard/WhatIsUnicode.html
Unicode is basically a catalog of glyphs and associated numeric value.
for a computer system, it only make sense to be precise and talk about
UTF8, UTF16 or UTF32.
http://www.unicode.org/faq/utf_bom.html
A "Unicode" locale makes no sense because the
locale represent much more than simply the character encoding that is
being used.
http://www.unicode.org/reports/tr35/#Locale
How, and finally, MS-Windows misused the word Unicode to mean UTF16
(nowadays, in the past, they meant UCS2)
Yannick
==============================================================================
TOPIC: unsupported function problem - WinCE
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/77baf79338e0b00a?hl=en
==============================================================================
== 1 of 1 ==
Date: Thurs, Oct 2 2008 7:51 am
From: yoavrofe
Hello all,
I'm trying to run a small program on both PPC and CE devices.
I am calling SHGetAutoRunPath only when running on a PPC platform.
However, since this function depends on aygshell.dl, which doesn't
exist on the CE platform, the program does not run at all on the CE
platform.
if(lstrcmpi(lpCmdLine, _T("install")) == 0)
{
// Card has been inserted. We NEVER get here on a CE platform!
TCHAR szSDAutorunFullPath[MAX_PATH+1]; // Compact Flash path
SHGetAutoRunPath(szSDAutorunFullPath);
.....
}
Is there a way to make the program run on both platforms without
recompiling it?
Thanks a lot,
Yoav.
==============================================================================
TOPIC: www.502dating.com
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/9e0890a30e582b71?hl=en
==============================================================================
== 1 of 1 ==
Date: Thurs, Oct 2 2008 8:03 am
From: www502datingcom
setup a free profile today!
www.502dating.com
==============================================================================
TOPIC: templates
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/72aa4d4f4ae0f080?hl=en
==============================================================================
== 1 of 1 ==
Date: Thurs, Oct 2 2008 8:03 am
From: Jeff Schwab
James Kanze wrote:
> On Oct 1, 10:46 pm, Pete Becker <p...@versatilecoding.com> wrote:
>> On 2008-10-01 16:20:02 -0400, Jeff Schwab <j...@schwabcenter.com> said:
>>> James Kanze wrote:
>>>> On Oct 1, 2:58 pm, Jeff Schwab <j...@schwabcenter.com> wrote:
>>>>> puzzlecracker wrote:
>>>>> The export feature never caught on because it requires much
>>>>> more powerful linkers than people actually have, or else some
>>>>> heavy-handed work-arounds in the build environment.
>>>> Comeau seems to do it without any problems. With the system
>>>> standard linker.
>>> Either
>>> all tranlation units (that rely on exported template definitions) have
>>> to be available at the same time, or else a special linker
>>> must be used.
>> one approach would be for a driver program to parse the error
>> messages from the linker to figure out which template
>> instantiations to generate next.
> There is a sense in which Jeff is right:
Kind words.
> the information in a typical object file (.o or .obj)
> isn't sufficient, and that's all typical linkers deal with. But
> there's no rule that a compiler can only generate object files;
> if I look in a directory where I've compiled with VC++, I find
> not only my sources, the .obj and the .exe, but also .ilk and
> .pdb, and there's nothing to prevent compilers from doing
> likewise under Unix. And there's nothing to prevent the
> compiler from using some other mechanism---didn't Visual Age use
> a data base for such things?
>
> It's clear that you need more than the classical compile and
> link. But that's why you invoke g++ instead of gcc (or CC
> instead of cc---VC++ uses a different technique to decide what
> to do, but you still invoke cl to link, and not link); the
> driver invokes whatever additional steps are necessary.
This sounds like a perfect opportunity for a 3rd-party tool. I'm
curious: If there is just not much demand for "export", how did it get
through committee in the first place? It seems like a low-ROI feature.
==============================================================================
TOPIC: extern const variable in case label
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/d0ae89b0e42f5a54?hl=en
==============================================================================
== 1 of 1 ==
Date: Thurs, Oct 2 2008 8:33 am
From: "Christian Meier"
"James Kanze" <james.kanze@gmail.com> wrote:
> Do you have some valid reason for wanting iValue to have the
> same address in every translation unit?
No...
> It seems strange to me to give an int identity, especially if you're not
> going to
> change it.
What else would you use for a global integer constant? Would you use a
#define?
> And otherwise, what's the problem with what you have written initially?
With my compiler and linker I have these symbols over 10 000 times in my
executable and I was able to reduce the program size a bit with changing
these constants to extern which are not used in case labels.
==============================================================================
You received this message because you are subscribed to the Google Groups "comp.lang.c++"
group.
To post to this group, visit http://groups.google.com/group/comp.lang.c++?hl=en
To unsubscribe from this group, send email to comp.lang.c+++unsubscribe@googlegroups.com
To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.c++/subscribe?hl=en
To report abuse, send email explaining the problem to abuse@googlegroups.com
==============================================================================
Google Groups: http://groups.google.com/?hl=en
No comments:
Post a Comment