468,780 Members | 2,278 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,780 developers. It's quick & easy.

Write a transform_until template

Hi,
I am trying to write a transform_until template. It is bascially doing
what transform is doing except if UnaryOperation return NULL, it will
break out from the loop.

Here is the code, but it has compile error, can you please tell me what
did I do wrong?

template <class _InputIter, class _OutputIter, class _UnaryOperation>
_OutputIter
transform_until (_InputIter __first, _InputIter __last, _OutputIter
__res,
_UnaryOperation __unary_op)
{
for (; !(__first == __last); ++__res, ++__first) {
// this line does not compile:
_OutputIter::value_type obj = __unary_op (*__first);

if (obj != NULL) {
*__res = obj;
} else {
return __res;
}

}
return __res;
}

Here is the compile error:
.../Utils.h: In function '_OutputIter transform_until(_InputIter,
_InputIter, _OutputIter, _UnaryOperation)':
.../Utils.h:88: error: expected `;' before 'obj'
.../Utils.h:90: error: 'obj' was not declared in this scope

Feb 21 '06 #1
15 1253
si***************@gmail.com wrote:
[..]
// this line does not compile:
_OutputIter::value_type obj = __unary_op (*__first);
typename _OutputIter:: ...

And don't use names that begin with an underscore and a capital letter,
they are reserved by the implementation.
[..]


V
--
Please remove capital As from my address when replying by mail
Feb 21 '06 #2

Victor Bazarov wrote:
si***************@gmail.com wrote:
> [..]
// this line does not compile:
_OutputIter::value_type obj = __unary_op (*__first);


typename _OutputIter:: ...

And don't use names that begin with an underscore and a capital letter,
they are reserved by the implementation.


As are names containing two adjacent _ _ at any position.

Regards,
Michiel Salters

Feb 23 '06 #3
si***************@gmail.com wrote:
Here is the code, but it has compile error, can you please tell me what
did I do wrong?
Lots of things...
template <class _InputIter, class _OutputIter, class _UnaryOperation>
_OutputIter
transform_until (_InputIter __first, _InputIter __last, _OutputIter
__res,
_UnaryOperation __unary_op)
First of all, all names starting with an underscore followed by
a capital letter or containing two adjacent underscores are
reserved for the implementation in all contexts. That is, *all*
of the names used above are reserved and shall not be used! I'd
guess you have just copied this style from one of the standard
library's headers. Note, however, that these headers are not
intended for teaching and copying code from there might even be
considered a copyright violation.
{
for (; !(__first == __last); ++__res, ++__first) {
The return type of comparing two iterators for equality has to
be convertible to 'bool' but is not required to be 'bool'. Thus,
the above condition should be written as

!bool(first == last)

This error is quite common even in standard library implementations,
however. On the other hand, I don't think that any of the standard
library implementers is really willing to fix it...
// this line does not compile:
_OutputIter::value_type obj = __unary_op (*__first);


The 'value_type' is a dependent name and thus require qualification
with the 'typename' keyword:

typename OutputIterator::value_type obj = unary_op(*first);

However, iterators are not required to provide any nested typedefs
as this is e.g. impossible to achieve when using pointers. Thus,
the class template 'iterator_traits' is used to infer types
associated with iterators. In addition, true output iterators
define their value type as 'void' causing yet another problem. Thus,
the above line shall actually read

typename std::iterator_traits<InputIterator>::value_type obj
= unary_op(*first);

(assuming, of course, that I have not introduced a type into the
above statement).
--
<mailto:di***********@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.eai-systems.com> - Efficient Artificial Intelligence
Feb 23 '06 #4

Dietmar Kuehl wrote:
The return type of comparing two iterators for equality has to
be convertible to 'bool' but is not required to be 'bool'. Thus,
the above condition should be written as

!bool(first == last)


C-Style cast? Hmmm...

Feb 23 '06 #5
ro**********@gmail.com wrote:
Dietmar Kuehl wrote:

The return type of comparing two iterators for equality has to
be convertible to 'bool' but is not required to be 'bool'. Thus,
the above condition should be written as

!bool(first == last)

C-Style cast? Hmmm...


It's not. It's called "explicit type conversion (functional notation)".
A C-style cast ("explicit type conversion (cast notation)") would be

!(bool)(first == last)

V
--
Please remove capital As from my address when replying by mail
Feb 23 '06 #6
ro**********@gmail.com wrote:
Dietmar Kuehl wrote:
The return type of comparing two iterators for equality has to
be convertible to 'bool' but is not required to be 'bool'. Thus,
the above condition should be written as

!bool(first == last)


C-Style cast? Hmmm...


No, just an explicit conversion: this explicitly constructs a temporary
of type 'bool' initialized with the [possibly converted] result of
'first == last'. The above syntax is not permitted in C at all. A
C-style cast would look like this: '(bool)(first == last)'.
--
<mailto:di***********@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.eai-systems.com> - Efficient Artificial Intelligence
Feb 23 '06 #7

Dietmar Kuehl wrote:
ro**********@gmail.com wrote:
Dietmar Kuehl wrote:
The return type of comparing two iterators for equality has to
be convertible to 'bool' but is not required to be 'bool'. Thus,
the above condition should be written as

!bool(first == last)


C-Style cast? Hmmm...


No, just an explicit conversion: this explicitly constructs a temporary
of type 'bool' initialized with the [possibly converted] result of
'first == last'. The above syntax is not permitted in C at all. A
C-style cast would look like this: '(bool)(first == last)'.


"If the expression list is a single expression, the type conversion
expression is equivalent (in definednedd, and if defined in meaning) to
the corresponding cast expression."

In other words there is no functional difference between bool(expr) and
(bool)(expr).

Also, I believe you are wrong about C but I can't recall for sure.

Feb 23 '06 #8
TB
ro**********@gmail.com skrev:
Dietmar Kuehl wrote:
ro**********@gmail.com wrote:
Dietmar Kuehl wrote:
The return type of comparing two iterators for equality has to
be convertible to 'bool' but is not required to be 'bool'. Thus,
the above condition should be written as

!bool(first == last)
C-Style cast? Hmmm...

No, just an explicit conversion: this explicitly constructs a temporary
of type 'bool' initialized with the [possibly converted] result of
'first == last'. The above syntax is not permitted in C at all. A
C-style cast would look like this: '(bool)(first == last)'.


"If the expression list is a single expression, the type conversion
expression is equivalent (in definednedd, and if defined in meaning) to
the corresponding cast expression."

In other words there is no functional difference between bool(expr) and
(bool)(expr).

Also, I believe you are wrong about C but I can't recall for sure.


int main() {
int a = 0;
int b = int(a);
return 0;
}

Comeau C/C++ 4.3.3 (Aug 6 2003 15:13:37) for ONLINE_EVALUATION_BETA1
Copyright 1988-2003 Comeau Computing. All rights reserved.
MODE:strict errors C99

"ComeauTest.c", line 3: error: expected an expression
int b = int(a);
^

1 error detected in the compilation of "ComeauTest.c".

--
TB @ SWEDEN
Feb 23 '06 #9
ro**********@gmail.com wrote:
"If the expression list is a single expression, the type conversion
expression is equivalent (in definednedd, and if defined in meaning) to
the corresponding cast expression."
Of course, it is! The C-style even happens to do this right thing for
many cases. E.g. if 'static_cast<T>(expr)' is a valid choice, the
C-style cast has exactly the same semantics as the above! In fact,
the C-style cast per se is not really that bad. What is bad about it
is that it may have the same meaning as 'reinterpret_cast<T>(expr)'
if no other suitable cast is available. However, the same does not
apply to explicit conversions a la 'bool(expr)': these are always
equivalent to 'static_cast<T>(expr)'.
In other words there is no functional difference between bool(expr) and
(bool)(expr).
OK. ... and? Nor is there is a function difference with any of the
other alternatives like 'static_cast<bool>(expr)'.
Also, I believe you are wrong about C but I can't recall for sure.


I'm pretty sure that C does not support function style casts.
--
<mailto:di***********@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.eai-systems.com> - Efficient Artificial Intelligence
Feb 23 '06 #10
* Dietmar Kuehl:

Of course, it is! The C-style even happens to do this right thing for
many cases. E.g. if 'static_cast<T>(expr)' is a valid choice, the
C-style cast has exactly the same semantics as the above! In fact,
the C-style cast per se is not really that bad. What is bad about it
is that it may have the same meaning as 'reinterpret_cast<T>(expr)'
if no other suitable cast is available. However, the same does not
apply to explicit conversions a la 'bool(expr)': these are always
equivalent to 'static_cast<T>(expr)'.


Re the last sentence above: are you sure?

int main()
{
typedef char* CharPtr;

int* p = 0;
char* q1 = CharPtr( p );
char* q2 = static_cast<CharPtr>( p );
}

Don't know what you mean by " la", but for q1 you have what various
compilers say is an OK reinterpret_cast, whereas for q2 you have what
the same compilers say is an invalid static_cast.

I'm pretty sure (:-)) the standard says the same thing, but have so many
windows up and and running that Acrobat would be just too much.

In other words there is no functional difference between bool(expr) and
(bool)(expr).


OK. ... and? Nor is there is a function difference with any of the
other alternatives like 'static_cast<bool>(expr)'.


I think Noah's point here relates to earlier discussion, where the
C-style of the cast was cast in doubt... ;-)
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Feb 23 '06 #11
In article <11**********************@o13g2000cwo.googlegroups .com>,
"si***************@gmail.com" <si***************@gmail.com> wrote:
Hi,
I am trying to write a transform_until template. It is bascially doing
what transform is doing except if UnaryOperation return NULL, it will
break out from the loop.

Here is the code, but it has compile error, can you please tell me what
did I do wrong?

template <class _InputIter, class _OutputIter, class _UnaryOperation>
_OutputIter
transform_until (_InputIter __first, _InputIter __last, _OutputIter
__res,
_UnaryOperation __unary_op)
{
for (; !(__first == __last); ++__res, ++__first) {
// this line does not compile:
_OutputIter::value_type obj = __unary_op (*__first);

if (obj != NULL) {
*__res = obj;
} else {
return __res;
}

}
return __res;
}


Even if the above worked, IMHO it's not a good idea. It would be
impossible to transform int's to 0 using it. Better would be something
like this (IMO.)

transform( first1, find_if( first1, last1, pred ), first2, op );

Where, first1 and last1 are iterators in a range, and first2 is an
iterator in a different range. 'pred' returns true if applying 'op' to
the element would return NULL (and may even use 'op' in its
implementation,) and 'op' does the actual transformation.

--
Magic depends on tradition and belief. It does not welcome observation,
nor does it profit by experiment. On the other hand, science is based
on experience; it is open to correction by observation and experiment.
Feb 23 '06 #12

Dietmar Kuehl wrote:
ro**********@gmail.com wrote:
"If the expression list is a single expression, the type conversion
expression is equivalent (in definednedd, and if defined in meaning) to
the corresponding cast expression."
Of course, it is! The C-style even happens to do this right thing for
many cases. E.g. if 'static_cast<T>(expr)' is a valid choice, the
C-style cast has exactly the same semantics as the above! In fact,
the C-style cast per se is not really that bad. What is bad about it
is that it may have the same meaning as 'reinterpret_cast<T>(expr)'
if no other suitable cast is available. However, the same does not
apply to explicit conversions a la 'bool(expr)': these are always
equivalent to 'static_cast<T>(expr)'.


But now you are mixing styles. Much better to use one or the other.
Otherwise you have to remember to use one when you can and the other
when you can't (or shouldn't) and this is messy. Better to use new
style even when C-Style is guaranteed to work as expected.
In other words there is no functional difference between bool(expr) and
(bool)(expr).


OK. ... and? Nor is there is a function difference with any of the
other alternatives like 'static_cast<bool>(expr)'.


Well, static_cast is easier to find. I don't see a whole lot of
difference in grepability of XX(XXX) vs (XX)(XXX). In fact if you
where trying to find all casts in a project function style might be
MORE difficult to establish as it looks like a function call. Only
times when it would work at all is when you want to find a cast to a
specific type. Compare vs. "static_cast" is going to turn up any
static cast to any type at all (and possibly some comments). So they
are actually not functionally equivelent.

Also, bool(expr) could cast away constness unexpectedly just as C-Style
can. New style can't so again, not functionally equivelent.

Feb 23 '06 #13
Daniel T. wrote:
Even if the above worked, IMHO it's not a good idea. It would be
impossible to transform int's to 0 using it. Better would be something
like this (IMO.)

transform( first1, find_if( first1, last1, pred ), first2, op );


Note, however, that this approach does not work for input iterators:
the corresponding sequence can only be traversed once. However, I
would separate the transformation and the predicate, too.
--
<mailto:di***********@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.eai-systems.com> - Efficient Artificial Intelligence
Feb 24 '06 #14
Alf P. Steinbach wrote:
* Dietmar Kuehl:

Of course, it is! The C-style even happens to do this right thing for
many cases. E.g. if 'static_cast<T>(expr)' is a valid choice, the
C-style cast has exactly the same semantics as the above! In fact,
the C-style cast per se is not really that bad. What is bad about it
is that it may have the same meaning as 'reinterpret_cast<T>(expr)'
if no other suitable cast is available. However, the same does not
apply to explicit conversions a la 'bool(expr)': these are always
equivalent to 'static_cast<T>(expr)'.
Re the last sentence above: are you sure?


Since 'bool(expr)' is obviously not equivalent to
'static_cast<T>(expr)', I'm not quite sure :-) If the 'T' is
replaced by 'bool', however, I'm quite sure they are. ... and this
is definitely the case in the context of generic algorithms where
certain expressions are required to be convertible to 'bool' but
not required to be 'bool'.
int main()
{
typedef char* CharPtr;

int* p = 0;
char* q1 = CharPtr( p );
char* q2 = static_cast<CharPtr>( p );
}

Don't know what you mean by " la", but for q1 you have what various
compilers say is an OK reinterpret_cast, whereas for q2 you have what
the same compilers say is an invalid static_cast.


Yes, this is correct. I made a too strong generalization.
--
<mailto:di***********@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.eai-systems.com> - Efficient Artificial Intelligence
Feb 24 '06 #15
ro**********@gmail.com wrote:
But now you are mixing styles. Much better to use one or the other.
I consider it more important to fit certain expression on just one
line because it have trouble reading multi-line expressions. The
'static_cast<bool>(expr)' is much longer than 'bool(expr)'.
Otherwise you have to remember to use one when you can and the other
when you can't (or shouldn't) and this is messy. Better to use new
style even when C-Style is guaranteed to work as expected.
I have to remember to put in the conversion and not rely on the
operations to always return 'bool'. This is the hard part. The use
of an appropriate conversion is trivial and I manage to remember
the rule that it is safe to convert an expression
"convertible to 'bool'" explicitly to 'bool'. This doesn't take
much remembering for me.
> In other words there is no functional difference between bool(expr) and
> (bool)(expr).


OK. ... and? Nor is there is a function difference with any of the
other alternatives like 'static_cast<bool>(expr)'.


Well, static_cast is easier to find.


Right. ... and multi-line expressions are harder to read. Since I
rarely search for the explicit conversions to 'bool' but frequently
read the code using them, I prefer to fit things on one line.
Also, bool(expr) could cast away constness unexpectedly just as C-Style
can. New style can't so again, not functionally equivelent.


'bool(expr)' yields an r-value as 'static_cast<bool>(expr)' does.
Also, which 'const' is exactly cast away or retain in either of
these expression...?
--
<mailto:di***********@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.eai-systems.com> - Efficient Artificial Intelligence
Feb 24 '06 #16

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

3 posts views Thread by db | last post: by
8 posts views Thread by daniel.w.gelder | last post: by
2 posts views Thread by David | last post: by
10 posts views Thread by roberts.noah | last post: by
3 posts views Thread by Grzegorz Smith | last post: by
1 post views Thread by Petterson Mikael | last post: by
reply views Thread by zhoujie | last post: by
2 posts views Thread by Marin | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.