comp.lang.c++
http://groups.google.com/group/comp.lang.c++?hl=encomp.lang.c++@googlegroups.com
Today's topics:
* syncronization - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/b83eb8425cee1175?hl=en
* Logical Value Of A Pointer - 5 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/e9c0b3e622d74ae6?hl=en
* STL map with "count" method - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/44ba4e1927010e5f?hl=en
* Header files with "header.h" or <header.h> ?? - 5 messages, 5 authors
http://groups.google.com/group/comp.lang.c++/t/02f708a44830afbc?hl=en
* C++0x: unique_ptr and std::move - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/8fb40687c0b160b9?hl=en
* A question about iterators - 4 messages, 4 authors
http://groups.google.com/group/comp.lang.c++/t/8e6025132806498c?hl=en
* abstract base class containing class - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/5bfe26b47a4e6f79?hl=en
* templated function help - 5 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/5b281279cd4b281c?hl=en
* don't want to retype the base class ctor - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/685377ed59f258c2?hl=en
==============================================================================
TOPIC: syncronization
http://groups.google.com/group/comp.lang.c++/t/b83eb8425cee1175?hl=en
==============================================================================
== 1 of 2 ==
Date: Fri, Jan 30 2009 10:00 pm
From: Chunekit Pong
On Fri, 30 Jan 2009 20:06:48 -0800, red floyd
<no.spam.here@example.com> wrote:
>Chunekit Pong wrote:
>> when when I run the VirtualScreen.cpp code, it will crash like this
>> (screen shot captured)
>>
>> http://www.oniva.com/upload/1356/crash.jpg
>>
>> it is something related to pointers which i am no familiar with.
>>
>> Basically,
>> 1) RFIDSock Class - i defined a key value pair - ID / timestamp, then
>> I insert the key value pair into a queue.
>>
>> 2) VirtualScreen Class - I have a reference to RFIDSock object
>> (pointer) and I am accessing RFIDSock's "queue" object (*IDs) and pop
>> any object the timestamp is old enough.
>>
>> since both RFIDSock / VirtualScreen Class - both function is keep
>> calling every seconds or miliseconds.
>>
>> RFIDSock - is inserting to the queue
>> VirtualScreen - is removing element from the queue
>>
>> will there be some syncrohization problem for both function accessing
>> the queue every mililseconds / seconds?
>>
>> I am very messed up in pointers, is the crash related to just simple
>> mistake in pointers?
>>
>> =====================
>> RFIDSock.h
>> =====================
>> #include <map>
>> #include <list>
>> #include <string>
>> #include <queue>
>> #include "VirtualScreen.h"
>>
>> typedef const char* id_type;
>> typedef unsigned int timestamp_type;
>> typedef std::pair<id_type, timestamp_type> entry_type;
>>
>> //class CVirtualScreen;
>> class CVirtualScreen;
>>
>> class RFIDSock
>> {
>> public:
>> std::queue< entry_type > *IDs;
>>
>> };
>>
>> =====================
>> RFIDSock.cpp
>> =====================
>> #include "RFIDSock.h"
>> #include <queue>
>> #include <time.h>
>>
>> class CVirtualScreen;
>>
>> //--------------------------------------------------------------
>> void RFIDSock::OnDataReceived(const LPBYTE lpBuffer, DWORD dwCount)
>> {
>> entry_type entry;
>> entry.first = (const char*)m_bReceiveBuffer;
>> entry.second = seconds;
>>
>> IDs->push( entry );
>>
>> }
>> =====================
>> VirtualScreen.h
>> =====================
>> RFIDSock *rfidsock;
>>
>> =====================
>> VirtualScreen.cpp
>> =====================
>> void VirtualScreen::ProcessMessages()
>> {
>> unsigned int current = time (NULL);
>> while ( current - rfidsock->IDs->front().second > duration){
>> rfidsock->IDs->pop();
>> }
>> }
>>
>
>What Kai-Uwe said, plus the obvious. ARe you initializing IDs properly
>in the constructor? Why are you using a pointer to a queue?
>
>To do what Kai-Uwe suggests, rewrite the loop:
>
> while (!rfidsock->IDs->empty())
> {
> if (current - rfidsock->IDs->front().second > duration)
> rfidsock->IDs->pop();
> else
> break;
> }
I don't know how to initialize IDs object (a pointer)
do I do somethign like
std::queue< entry_type > *IDs = new queue():
== 2 of 2 ==
Date: Sat, Jan 31 2009 4:47 am
From: SG
On 31 Jan., 07:00, Chunekit Pong <worlman...@yahoo.com> wrote:
> I don't know how to initialize IDs object (a pointer)
>
> do I do somethign like
> std::queue< entry_type > *IDs = new queue():
You can't expect people to teach you these basics. Get a book and
learn for yourself. It is important for you to show that you put some
effort into solving your problems. Otherwise you may not get helpful
comments besides "Read a book about C++".
Cheers!
SG
==============================================================================
TOPIC: Logical Value Of A Pointer
http://groups.google.com/group/comp.lang.c++/t/e9c0b3e622d74ae6?hl=en
==============================================================================
== 1 of 5 ==
Date: Sat, Jan 31 2009 2:00 am
From: Lionel B
On Fri, 30 Jan 2009 16:00:41 -0800, James Kanze wrote:
> On 30 jan, 14:08, Lionel B <m...@privacy.net> wrote:
>> On Thu, 29 Jan 2009 17:07:41 +0000, Andrew Koenig wrote:
>> > "James Kanze" <james.ka...@gmail.com> wrote in message
>> >news:11b0ce6c-69ed-4764-aa5a-
c3f8b971e2d5@s1g2000prg.googlegroups.com...
>> > On Jan 13, 8:46 am, Nosophorus <Nosopho...@gmail.com> wrote:
>
>> >> For historical reasons, a pointer implicitly converts to bool, with
>> >> a null pointer converting to false, and all other pointer values
>> >> converting to true. In general, it's better to avoid the implicit
>> >> convertion, and write what you mean:
>> >> if ( a != NULL ) ...
>
>> > Why do you think it's better? I don't think so, but maybe you can
>> > convince me.
>
>> It makes the intent of the coder clearer?
>
>> If I see "if (a != NULL)" I immediately know that a is a pointer and
>> that we're checking that it's not a null pointer. Or more precisely, if
>> this is /not/ the case, then I'm dealing with such a perverse coder
>> that all bets are off...
>
>> If I see "if (a != 0)" then I have fewer clues what's going on and
>> quite likely have to check a lot of other code to find out.
>
> That wasn't the point.
Yes, I jumped into he middle of the thread.
> While I also prefer NULL to 0 when pointers are
> involved, there are serious problems with both solution, and I
> understand the arguments for 0. I don't think that there is a
> conclusive argument one way or the other there---it's a question of
> which problems you consider the most serious.
Sure, that's been done to death (repeatedly) on this ng.
> The issue is
> if ( a == NULL )
> or if ( a == 0 )
> vs if (!a)
> ; the implicit conversion to bool.
See my posts else thread.
--
Lionel B
== 2 of 5 ==
Date: Sat, Jan 31 2009 2:05 am
From: Lionel B
On Sat, 31 Jan 2009 00:09:17 +0000, Andrew Koenig wrote:
> "Lionel B" <me@privacy.net> wrote in message
> news:gluu3l$hhg$2@south.jnrs.ja.net...
>
>> It makes the intent of the coder clearer?
>
>> If I see "if (a != NULL)" I immediately know that a is a pointer and
>> that we're checking that it's not a null pointer. Or more precisely, if
>> this is /not/ the case, then I'm dealing with such a perverse coder
>> that all bets are off...
>
> To me, "if (a != NULL)" is saying the same thing twice.
Pardon?
To me, it just looks like comparing 'a' with something called 'NULL'
which is a bit of bodge, but nonetheless associated with pointers. So I
would /suspect/ that 'a' is something pointer-like, although to be sure I
would have to check some code.
> That is... I
> don't think that code should mention a variable's type more than once if
> it is reasonably possible to avoid doing so.
--
Lionel B
== 3 of 5 ==
Date: Sat, Jan 31 2009 3:39 am
From: peter koch
On 31 Jan., 01:07, "Andrew Koenig" <a...@acm.org> wrote:
> "James Kanze" <james.ka...@gmail.com> wrote in message
>
> news:13127edb-2688-44f0-820b-75b9603b06a7@i24g2000prf.googlegroups.com...
> On Jan 29, 6:07 pm, "Andrew Koenig" <a...@acm.org> wrote:
>
> >>> For historical reasons, a pointer implicitly converts to
> >>> bool, with a null pointer converting to false, and all other
> >>> pointer values converting to true. In general, it's better
> >>> to avoid the implicit convertion, and write what you mean:
> >>> if ( a != NULL ) ...
> >> Why do you think it's better? I don't think so, but maybe you
> >> can convince me.
> > For the same reason implicit conversions in general are to be
> > avoided. A pointer isn't a bool, so it doesn't make sense to
> > use it as one; doing so only leads to confusion. Say what you
> > mean, and mean what you say.
> > (BTW: you're the co-author of the original proposal for bool.
> > And there, unless I'm remembering wrong, you proposed
> > deprecating the above conversion. Have you changed your mind?
> > And if so, what made you change it?)
>
> I'd love to deprecate conversion of pointers to bool ... but I don't
> consider
>
> if (p) { /* ... */ }
>
> to be an instance of such a conversion. After all, this usage was around
> for years before anyone considered the conversion!
>
> Rather, I consider
>
> if (p) { /* ... */ }
>
> to be an abbreviation for
>
> if (p != 0) { /* ... */ }
>
> which is an implicit conversion of 0 to a pointer, not of p to bool.
>
> I understand that the standard doesn't describe it that way, but that's just
> a matter of descriptive convenience, and doesn't affect how I personally
> think about it.
I have mixed feelings about if (ptr): when I began programming C, I
always wrote if (ptr != NULL). That was many years ago, and I have now
changed attitude and consider it idiomatic (replacing NULL with 0 and
C with C+++) and in line with other common shorthands such as while
(stream >> i).
What is a big shame in my opinion is the automatic conversion to (and
also from) bool: It has caused so many problems and inconveniences for
everyone. I wonder what the rationale was.
/Peter
== 4 of 5 ==
Date: Sat, Jan 31 2009 4:45 am
From: James Kanze
On 31 jan, 01:07, "Andrew Koenig" <a...@acm.org> wrote:
> "James Kanze" <james.ka...@gmail.com> wrote in message
> news:13127edb-2688-44f0-820b-75b9603b06a7@i24g2000prf.googlegroups.com...
> On Jan 29, 6:07 pm, "Andrew Koenig" <a...@acm.org> wrote:
> >>> For historical reasons, a pointer implicitly converts to
> >>> bool, with a null pointer converting to false, and all other
> >>> pointer values converting to true. In general, it's better
> >>> to avoid the implicit convertion, and write what you mean:
> >>> if ( a != NULL ) ...
> >> Why do you think it's better? I don't think so, but maybe you
> >> can convince me.
> > For the same reason implicit conversions in general are to be
> > avoided. A pointer isn't a bool, so it doesn't make sense to
> > use it as one; doing so only leads to confusion. Say what you
> > mean, and mean what you say.
> > (BTW: you're the co-author of the original proposal for bool.
> > And there, unless I'm remembering wrong, you proposed
> > deprecating the above conversion. Have you changed your mind?
> > And if so, what made you change it?)
> I'd love to deprecate conversion of pointers to bool ... but I don't
> consider
> if (p) { /* ... */ }
> to be an instance of such a conversion.
But the standard does. And IIRC, so did your original paper.
> After all, this usage was around for years before anyone
> considered the conversion!
Yes, because early C was rather flippant about types. An
attitude left over from B, I suppose. (In B, and in other
"untyped" languages, like AWK, I have no problems with this.
Although even in AWK, if I'm using a variable as a number or a
string, rather than as a boolean, I'll write the test out.)
> Rather, I consider
> if (p) { /* ... */ }
> to be an abbreviation for
> if (p != 0) { /* ... */ }
Why?
> which is an implicit conversion of 0 to a pointer, not of p to
> bool.
> I understand that the standard doesn't describe it that way, but that's just
> a matter of descriptive convenience, and doesn't affect how I personally
> think about it.
I'm not sure I follow you: are you saying that anytime a
variable (pointer or arithmetic type) is used in a condition, it
should automatically be treated as if there was a != 0 behind
it? A sort of a short cut way of writing it?
--
James Kanze
== 5 of 5 ==
Date: Sat, Jan 31 2009 5:05 am
From: James Kanze
On 31 jan, 06:50, Jeff Schwab <j...@schwabcenter.com> wrote:
> Andrew Koenig wrote:
> > I consider
> > if (p) { /* ... */ }
> > to be an abbreviation for
> > if (p != 0) { /* ... */ }
> > which is an implicit conversion of 0 to a pointer, not of p to bool.
> > I understand that the standard doesn't describe it that way,
> > but that's just a matter of descriptive convenience, and
> > doesn't affect how I personally think about it.
> This may go without saying, but you obviously have a very deep
> understanding of how C++ syntax can be used to reflect
> high-level semantic meaning. I wish that level of
> understanding were more widespread.
> To a human reader, the != 0 ought to be considered noise,
> AFAICS.
It specifies what you are testing for. If a pointer only had
two possible values, it would be noise. Since that's not the
case, it's important information.
> The ability to test things other than raw bools is not just
> for pointers, either; e.g: while (std::cin >> s) { ... }. I
> don't consider p != 0 any better than b != false. And don't
> even get me started on NULL. :)
> This argument seems to be a perennial favorite on Usenet. It
> seems to come down to a division between people who think
> generically, and others who think (or at least code)
> orthogonally.
The argument goes back long before generic programming. The
argument is between those who believe in static type checking,
and those who are too lazy to type.
Just kidding, of course---but the issue IS type checking.
With regards to "generic" programming, I can understand the need
for some sort of "generic" is valid. The problem is that we
don't have it. Whether you write "if ( p == NULL )", or just
"if (p)", the constraints on p are identical. The difference is
that in the first case, it's clearly apparent what those
constraints are.
> The first of these camps, the Generics, believe that syntax
> should convey abstract meaning, with low-level details
> supplied by context. The second camp, the Orthogonals,
> believe that a particular syntax should mean exactly the same
> thing in all contexts, and that even (or especially) subtly
> things should always look different.
I don't think you've understood the argument. In a well
designed language, pointers aren't boolean values (since they
have more than two values), and can't be used as such. And type
checking is strict, because that reduces the number of errors.
The problem is that the implicit conversion doesn't cover all of
the cases. Even in the case of pointers, we have three cases
which can legally occur: the pointer points to an object, it
points to one behind the end of an array of objects, or it is
null. So which one do you priviledge by the conversion?
> I consider myself in the Generic camp. The advantage of this
> style is that similar ideas are implemented by similar-looking
> code. A single piece of source code can often be reused in
> multiple contexts, even if the compiler generates wildly
> different object code for each of them. For example, I like
> the fact that the following all look the same:
> throw_if(!p, "null pointer");
> throw_if(!cin, "input error");
> throw_if(!divisor, "attempted division by zero");
throw_if( p != 0, "null pointer");
throw_if( cin != 0, "input error");
throw_if( divisor != 0, "attempted division by zero");
They all look the same to me. Even better:
throw_if( isValid( p ), "null pointer");
throw_if( isValid( cin ), "input error");
throw_if( isValid( divisor ), "attempted division by zero");
With isValid defined with an appropriate overload (which would
return false for a pointer one past the end as well---except
that I don't know how to implement that).
> Once I understand the pattern, I don't want to have to
> optically grep the details of expressions like p == NULL,
> !cin.good(), and divisor == 0. They all have the same
> high-level meaning, and that's usually what I care about.
The problem is that no one really knows what that high-level
meaning is, since it is radically different for each type.
> The apparent down side to this style is that subtle mistakes
> can hide in it. It's easy for the reader to see the author's
> intent,
The problem is that it's impossible for the reader to see the
author's intent (except from the string literal in your
example---but that's not typically present). It's a recepe for
unreadable code.
> but relatively difficult to see the bit-level reality.
> However, I would argue that this is the price we pay for
> abstraction, and attempts to include context-specific
> information in our code without loss of abstraction give only
> the illusion of clarity.
> The ostensible advantage of something like p != NULL is that p
> is clearly a pointer.
No. The advantage is that it isn't "p != 0", and that 0 clearly
isn't a pointer.
The whose system is broken. The problem is that both "p != 0"
and "p != NULL" are lies. The next version of the standard will
fix it somewhat, with nullptr (but for historical reasons, of
course, 0 and NULL must still remain legal).
> Or is it? The compiler has no problem with a comparison of
> the form std::cin != NULL. In p != NULL, the word NULL seems
> to hint that p is a pointer, but that information is neither
> relevant to the expression, nor enforceable by the compiler.
G++ warns if you use NULL in a non-pointer context. It could
just as easily generate an error. So this is enforceable by the
compiler.
> When it becomes necessary to understand that p is a pointer,
> the fact should become evident, as in an expression like
> p->size(). Even then, p might be a raw pointer, an iterator,
> or some kind of fancy smart pointer. In decent C++ code, IMO,
> we shouldn't have to know.
Except that we do, since neither "if (p)" nor "if ( p != NULL )"
nor "if ( p != 0 )" work if p is an iterator.
The real solution here is an appropriate set of overloaded
functions. I use Gabi::begin(), and Gabi::end(), for example;
they work with C style arrays, and are easily made to work with
STL containers. (In other words, if the STL had been designed
for genericity, it would have defined a function begin(
std::vector<> ), and not std:vector<>::begin().)
--
James Kanze
==============================================================================
TOPIC: STL map with "count" method
http://groups.google.com/group/comp.lang.c++/t/44ba4e1927010e5f?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Jan 31 2009 5:42 am
From: Joe Gottman
Victor Bazarov wrote:
> thomas wrote:
>> A STL map doesn't allow two keys having the same value.
>
> But std::multimap does.
>
>> That's to say, a "count()" method will always return 1 or 0.
>> So why a "count()" is needed while we better call it "exist()"?
>
> Could it be for the consistency's sake? std::multimap would *not*
> always return only 1 or 0, yes?
>
> You're free to define a stand-alone function 'exist' and implement it in
> terms of 'count'. Curiously, for both std::map and std::multimap you
> could either use 'count() != 0' or 'find() != end()' ...
>
Both would give correct results, but 'find() != end()' would be more
efficient in the multimap case. If count() equaled 100 the first
implementation would have to actually count to 100, while the second
could return true as soon as the first was found. This is the same
reason why empty() is implemented as 'begin() != end()' and not 'count()
> 0'.
Joe Gottman
==============================================================================
TOPIC: Header files with "header.h" or <header.h> ??
http://groups.google.com/group/comp.lang.c++/t/02f708a44830afbc?hl=en
==============================================================================
== 1 of 5 ==
Date: Sat, Jan 31 2009 6:35 am
From: "mlt"
I have a header only library containing various .h files. One of the header
files, all.h, includes all the other header files. When I include all.h I
therefore get all the other header files.
all.h looks like this:
#include <header1.h>
#include <header2.h>
#include <header3.h>
#include <header4.h>
When I include the all.h in my application:
#include "all.h"
I get an error that header1.h cannot be found. But if I change all.h to:
#include "header1.h"
#include "header2.h"
#include "header3.h"
#include "header4.h"
I works fine. But I don't want to change all.h, so how do I use all.h
unchanged (with <> instead of "")??
== 2 of 5 ==
Date: Sat, Jan 31 2009 6:49 am
From: "Bo Persson"
mlt wrote:
> I have a header only library containing various .h files. One of
> the header files, all.h, includes all the other header files. When
> I include all.h I therefore get all the other header files.
>
> all.h looks like this:
>
> #include <header1.h>
> #include <header2.h>
> #include <header3.h>
> #include <header4.h>
>
>
> When I include the all.h in my application:
>
> #include "all.h"
>
> I get an error that header1.h cannot be found. But if I change
> all.h to:
> #include "header1.h"
> #include "header2.h"
> #include "header3.h"
> #include "header4.h"
>
>
> I works fine. But I don't want to change all.h, so how do I use
> all.h unchanged (with <> instead of "")??
You have to check with your compiler!
The only difference is that "" tells the compiler to first look
somewhere (implementation specific) and, if not found there, perform
another search just like for <>.
Bo Persson
== 3 of 5 ==
Date: Sat, Jan 31 2009 6:54 am
From: Jean-Marc Bourguet
"mlt" <asdf@asd.com> writes:
> I have a header only library containing various .h files. One of the header
> files, all.h, includes all the other header files. When I include all.h I
> therefore get all the other header files.
>
> all.h looks like this:
>
> #include <header1.h>
> #include <header2.h>
> #include <header3.h>
> #include <header4.h>
>
>
> When I include the all.h in my application:
>
> #include "all.h"
>
> I get an error that header1.h cannot be found. But if I change all.h to:
>
> #include "header1.h"
> #include "header2.h"
> #include "header3.h"
> #include "header4.h"
>
>
> I works fine. But I don't want to change all.h, so how do I use all.h
> unchanged (with <> instead of "")??
Short answer: add -Idir to your compilation options (or equivalent with
your IDE GUI).
Long answer: the standard doesn't define where included files (the "" form)
and headers (the <> form) are searched, excepted that if no file is found
an header is searched.
In practice, most compilers will search files included with ""
- in the same directory as the file containing the directive
- in a user specified list of directories
- in a list of default directories
while header included with <> are searched in the two last lists. But
there are variations on that which may break your build if you depend too
much on the search order to resolve ambiguities. And most compilers also
have other possibilities.
Yours,
--
Jean-Marc
== 4 of 5 ==
Date: Sat, Jan 31 2009 6:57 am
From: Sam
mlt writes:
> I have a header only library containing various .h files. One of the header
> files, all.h, includes all the other header files. When I include all.h I
> therefore get all the other header files.
>
> all.h looks like this:
>
> #include <header1.h>
> #include <header2.h>
> #include <header3.h>
> #include <header4.h>
>
>
> When I include the all.h in my application:
>
> #include "all.h"
>
> I get an error that header1.h cannot be found. But if I change all.h to:
>
> #include "header1.h"
> #include "header2.h"
> #include "header3.h"
> #include "header4.h"
>
>
> I works fine. But I don't want to change all.h, so how do I use all.h
> unchanged (with <> instead of "")??
With most compilers, use the -I option to specify where the header files are
installed.
== 5 of 5 ==
Date: Sat, Jan 31 2009 7:46 am
From: Pete Becker
On 2009-01-31 09:35:35 -0500, "mlt" <asdf@asd.com> said:
>
>
> I works fine. But I don't want to change all.h, so how do I use all.h
> unchanged (with <> instead of "")??
You really should change it. The convention is that < ... > is for
system-supplied headers and " ... " is for everything else. That way
your users won't run into the problem you've just seen.
--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)
==============================================================================
TOPIC: C++0x: unique_ptr and std::move
http://groups.google.com/group/comp.lang.c++/t/8fb40687c0b160b9?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Jan 31 2009 7:37 am
From: SG
I searched the GCC bug database and it seems there is already a report
on a similar case (#36744)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36744
Even in the case of a missing move constructor the copy must not be
elided because the object in question is not a temporary.
Cheers!
SG
==============================================================================
TOPIC: A question about iterators
http://groups.google.com/group/comp.lang.c++/t/8e6025132806498c?hl=en
==============================================================================
== 1 of 4 ==
Date: Sat, Jan 31 2009 9:20 am
From: hagai
Hi,
I am doing all sorts of stuff with iterators, I am passing an iterator
to the start and end to generic functions. All iterators are at least
bi-directional.
My question is how do I get an iterator to the item before the end? I
am currently doing it like this:
_It itOneBeforeEnd = itEnd;
--itOneBeforeEnd;
This is not really comfortable, is there another short way of doing
it?
Thanks,
Hagai.
== 2 of 4 ==
Date: Sat, Jan 31 2009 9:34 am
From: Pete Becker
On 2009-01-31 12:20:28 -0500, hagai <hagai.sela@gmail.com> said:
> I am doing all sorts of stuff with iterators, I am passing an iterator
> to the start and end to generic functions. All iterators are at least
> bi-directional.
> My question is how do I get an iterator to the item before the end? I
> am currently doing it like this:
>
> _It itOneBeforeEnd = itEnd;
> --itOneBeforeEnd;
>
> This is not really comfortable, is there another short way of doing
> it?
>
No, that's it. If you had a random access iterator you could use itEnd
- 1, but for bidirectional iterators all you can do is increment and
decrement.
--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)
== 3 of 4 ==
Date: Sat, Jan 31 2009 9:50 am
From: Jeff Schwab
hagai wrote:
> Hi,
> I am doing all sorts of stuff with iterators, I am passing an iterator
> to the start and end to generic functions. All iterators are at least
> bi-directional.
> My question is how do I get an iterator to the item before the end? I
> am currently doing it like this:
>
> _It itOneBeforeEnd = itEnd;
> --itOneBeforeEnd;
>
> This is not really comfortable, is there another short way of doing
> it?
Well, you could get that onto one line with something like:
iterator const next_to_last = advance(a_collection.end(), -1);
std::advance is in <iterator>. A better alternative might be a little
utility function:
template<class Iterator>
Iterator prior(Iterator i) {
return --i;
}
iterator const next_to_last = prior(a_collection.end());
Of course, these both assume the collection is large enough for "one
before the end" to make sense. You might prefer a next_to_last function
template that accepts the collection, rather than just its end-iterator,
in order to detect out-of-range errors.
iterator const next_to_last = penultimate(a_collection);
One other thing you might want to consider is changing your naming
convention. Any identifier beginning with and underscore and a capital
letter is supposed to be reserved for use in system libraries. There
are other restrictions on leading underscores (and double underscores),
as well.
== 4 of 4 ==
Date: Sat, Jan 31 2009 10:19 am
From: "Andrew Koenig"
"hagai" <hagai.sela@gmail.com> wrote in message
news:6eef8841-03b9-45b6-a273-1e0ac693d308@35g2000pry.googlegroups.com...
> My question is how do I get an iterator to the item before the end? I
> am currently doing it like this:
> _It itOneBeforeEnd = itEnd;
> --itOneBeforeEnd;
> This is not really comfortable, is there another short way of doing
> it?
The real question is why you want to do this. Note in particular that it
will fail if the iterator refers to an empty container.
If you are trying to iterate backward through a container, it is tempting to
do this:
It = itEnd;
--It;
while (It != itBegin) {
// do something with *It
--It;
}
but this technique doesn't work -- not only does it fail immediately if the
container is empty, but it ultimately attempts to decrement a value equal to
itBegin, which will also fail if itBegin refers to the first element of a
nonempty container.
Here's the right way to step backward through a container:
It = itEnd;
while (It != itBegin) {
--It;
// do something with *It
}
General rule: Decrement before you use the iterator; increment after you use
it.
==============================================================================
TOPIC: abstract base class containing class
http://groups.google.com/group/comp.lang.c++/t/5bfe26b47a4e6f79?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Jan 31 2009 9:50 am
From: scg_
What follows is a question by an absolute beginner – you have been warned:
I am using the following class layout, which is inspired by Bruce
Eckel's "Thinking in C++":
template <class T>
class B {
private:
T* data_;
int size_;
public:
int size() const {return size_;}
class iterator;
friend class iterator;
class iterator {
T* p;
public:
iterator(): p(0) {}
iterator(const B<T>& x): p(x.data) {}
T& operator*() {return *p;}
T* operator++(){return ++p;}
};
iterator begin() const {return iterator(*this);}
\\...
};
Furthermore, I define a function operating on B objects,
essential_function(const B &), which relies on the member function
explicitly listed above. Since I recently decided to change the
implementation of some of the details of B, I thought setting up an
abstract base class would be auspicious. In particular, I was hoping to
implement the algorithm in terms of the purely virtual member functions
of the abstract class:
template <class T>
class A {
public:
virtual int size() const = 0;
class iterator;
friend class iterator;
class iterator {
public:
virtual T& operator*() const = 0;
virtual T* operator++() = 0;
};
virtual iterator begin() const = 0; // error
};
class B : public A<T> {
//...
};
Unfortunately, this class A layout does not compile due to covariant
return type issues, i.e. B<T>::iterator B<T>::begin() overrides
A<T>::iterator A<T>::begin().
When I comment the line "virtual iterator begin() const = 0", it
compiles. However, not much is gained, since I can not implement
essential_function(const A &) in terms of the abstract class A:
template <class T>
void essential_function(const A<T>& x) {
typename A<T>::iterator iter;
iter = x.begin();
}
error: cannot declare variable `iter' to be of type `A<T>::iterator'
because virtual functions are abstract ... and A<T> has no has no
member named 'begin'.
Don't get me wrong - I am not particularly surprised about the errors
(now that I spend some time thinking about it).
Still, how can I implement what I (in essence) suggest above?
Thanks
==============================================================================
TOPIC: templated function help
http://groups.google.com/group/comp.lang.c++/t/5b281279cd4b281c?hl=en
==============================================================================
== 1 of 5 ==
Date: Sat, Jan 31 2009 10:45 am
From: Francesco Montorsi
Hi,
I'm quite new to templates... I was asked to transform the following macro
#define DECLARE_STRING_CHECK(func) \
inline bool func##String(const MyString& val) \
{ \
for ( MyString::const_iterator i = val.begin(); \
i != val.end(); \
++i ) \
if (func(*i) == 0) \
return false; \
return true; \
}
DECLARE_STRING_CHECK(isalpha) // declares isalphaString()
DECLARE_STRING_CHECK(isalnum)
DECLARE_STRING_CHECK(isdigit)
in a template.
I blindly tried:
template<typename T>
inline bool StringCheck(const MyString& val)
{
for ( MyString::const_iterator i = val.begin();
i != val.end();
++i )
if (T(*i) == 0)
return false;
return true;
}
Needless to say it doesn't work. I.e. if I write
if (!StringCheck<isalpha>(str))
return false;
I get "error: no matching function for call to 'StringCheck(const MyString&)'"
with GCC...
Can you help me with some hints :) ?
Thanks!!
Francesco
== 2 of 5 ==
Date: Sat, Jan 31 2009 11:09 am
From: Daniel Pitts
Francesco Montorsi wrote:
> Hi,
> I'm quite new to templates... I was asked to transform the following
> macro
>
> #define DECLARE_STRING_CHECK(func) \
> inline bool func##String(const MyString& val) \
> { \
> for ( MyString::const_iterator i = val.begin(); \
> i != val.end(); \
> ++i ) \
> if (func(*i) == 0) \
> return false; \
> return true; \
> }
>
> DECLARE_STRING_CHECK(isalpha) // declares isalphaString()
> DECLARE_STRING_CHECK(isalnum)
> DECLARE_STRING_CHECK(isdigit)
>
> in a template.
> I blindly tried:
>
> template<typename T>
> inline bool StringCheck(const MyString& val)
> {
> for ( MyString::const_iterator i = val.begin();
> i != val.end();
> ++i )
> if (T(*i) == 0)
> return false;
> return true;
> }
>
> Needless to say it doesn't work. I.e. if I write
>
> if (!StringCheck<isalpha>(str))
> return false;
>
> I get "error: no matching function for call to 'StringCheck(const
> MyString&)'" with GCC...
>
> Can you help me with some hints :) ?
>
> Thanks!!
> Francesco
>
>
I tried this in GCC.
template<int (T)(int)>
inline bool check(char * const str) {
return T(str[0]) == 0;
}
check<isalpha>("Foo"); seemed to work fine
--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
== 3 of 5 ==
Date: Sat, Jan 31 2009 11:19 am
From: SG
On 31 Jan., 19:45, Francesco Montorsi <f...@hotmail.com> wrote:
> template<typename T>
> inline bool StringCheck(const MyString& val)
> {
> for ( MyString::const_iterator i = val.begin();
> i != val.end();
> ++i )
> if (T(*i) == 0)
> return false;
> return true;
> }
>
> Needless to say it doesn't work. I.e. if I write
>
> if (!StringCheck<isalpha>(str))
> return false;
"isalpha" is not a type. There are several possibilities:
template<int (&T)(int)> // T is a reference to a function
int foo() { // with *external* linkage.
return T(42);
}
int main() { foo<isalpha>(); }
But this way you can only use functions with the exact same signature
and only functions that have external linkage. You can also make T a
type for a function pointer (or function object) and pass the pointer
(or object) as additional parameter. This would be the "STL style":
template<typename T> // T is type (function pointer
int foo(T some_func) { // or function object)
return some_func(42);
}
int main() { foo(isalpha); } // function decays to pointer
HTH,
SG
== 4 of 5 ==
Date: Sat, Jan 31 2009 1:02 pm
From: Francesco Montorsi
Daniel Pitts ha scritto:
> I tried this in GCC.
>
> template<int (T)(int)>
> inline bool check(char * const str) {
> return T(str[0]) == 0;
> }
>
> check<isalpha>("Foo"); seemed to work fine
Thanks!! I've managed to fix it using "int (T)(int)" declaration!!
Francesco
== 5 of 5 ==
Date: Sat, Jan 31 2009 1:05 pm
From: Francesco Montorsi
Hi,
SG ha scritto:
> "isalpha" is not a type.
indeed :/
> There are several possibilities:
>
> template<int (&T)(int)> // T is a reference to a function
> int foo() { // with *external* linkage.
> return T(42);
> }
>
> int main() { foo<isalpha>(); }
>
> But this way you can only use functions with the exact same signature
> and only functions that have external linkage.
Thanks for the explanation! I think I'll go for this approach as the linkage is
not an issue for me.
> You can also make T a
> type for a function pointer (or function object) and pass the pointer
> (or object) as additional parameter. This would be the "STL style":
>
> template<typename T> // T is type (function pointer
> int foo(T some_func) { // or function object)
> return some_func(42);
> }
>
> int main() { foo(isalpha); } // function decays to pointer
Useful to know. Just out of curiosity: unless I'm wrong this second method
allows you to call functions also with internal linkage but they still need to
have the same exact signature as those of the function pointer type T, right?
Thanks!
Francesco
==============================================================================
TOPIC: don't want to retype the base class ctor
http://groups.google.com/group/comp.lang.c++/t/685377ed59f258c2?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Jan 31 2009 12:21 pm
From: "Victor Bazarov"
Daniel T. wrote:
> Victor Bazarov <v.Abazarov@comAcast.net> wrote:
>
>> By the same token, B could be a template:
>>
>> template<int initialiser> class B {
>> protected:
>> B(int param = initialiser) : b(param) {}
>> public:
>> int b;
>> };
>>
>> class D1 : public B<42> {};
>> class D2 : public B<666> {};
>>
>> #include <iostream>
>> #include <ostream>
>> int main() {
>> D1 d1;
>> D2 d2;
>>
>> std::cout << d1.b << std::endl;
>> std::cout << d2.b << std::endl;
>> }
>>
>> Or you could even give the 'initialiser' template argument some
>> default value and not define it for those who should have the
>> default:
>>
>> template<int initialiser = 42> class B {
>> protected:
>> B(int param = initialiser) : b(param) {}
>> public:
>> int b;
>> };
>>
>> class D1 : public B<> {};
>> class D2 : public B<666> {};
>> class D3 : public B<> {};
>>
>> #include <iostream>
>> #include <ostream>
>> int main() {
>> D1 d1;
>> D2 d2;
>> D3 d3;
>>
>> std::cout << d1.b << std::endl;
>> std::cout << d2.b << std::endl;
>> std::cout << d3.b << std::endl;
>> }
>>
>> The problem, however, is that you still need to spell out the
>> template argument or rely on some default. You either do it in the
>> constructor of each Dx class or do it using your scheme or the
>> template.
>
> Another problem is that D1, D2 and D3 above all derive from different
> base classes.
All? No, only two of them. D1 and D3 derive from the same type.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
==============================================================================
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
