Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Convert from std::vector<double> to std::vector<int>

Reply
Thread Tools

Convert from std::vector<double> to std::vector<int>

 
 
Anonymous
Guest
Posts: n/a
 
      03-28-2005
Is there a non-brute force method of doing this?
transform() looked likely but had no predefined function object.


std::vector<double> src;
std::vector<int> dest;

std::vector<double>::size_type size = src.size();
dest.reserve(size);
for (std::vector<int>::size_type i = 0;
i < size;
i++)
{
dest[i] = static_cast<int>(src[i]);
}
 
Reply With Quote
 
 
 
 
Andrew Koenig
Guest
Posts: n/a
 
      03-28-2005
"Anonymous" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...

> Is there a non-brute force method of doing this?
> transform() looked likely but had no predefined function object.


> std::vector<double> src;
> std::vector<int> dest;
>
> std::vector<double>::size_type size = src.size();
> dest.reserve(size);
> for (std::vector<int>::size_type i = 0;
> i < size;
> i++)
> {
> dest[i] = static_cast<int>(src[i]);
> }


How about this?

std::vector<int> dest(src.begin(), src.end());

I can't recall any requirement that the iterators used to initialize a
vector must refer to values of the same type as the vector elements.


 
Reply With Quote
 
 
 
 
Malte Starostik
Guest
Posts: n/a
 
      03-28-2005
Andrew Koenig schrieb:
> "Anonymous" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>
>
>>Is there a non-brute force method of doing this?
>>transform() looked likely but had no predefined function object.

>
>
>>std::vector<double> src;
>>std::vector<int> dest;
>>
>>std::vector<double>::size_type size = src.size();
>>dest.reserve(size);
>>for (std::vector<int>::size_type i = 0;
>> i < size;
>> i++)
>>{
>> dest[i] = static_cast<int>(src[i]);
>>}

>
>
> How about this?
>
> std::vector<int> dest(src.begin(), src.end());
>
> I can't recall any requirement that the iterators used to initialize a
> vector must refer to values of the same type as the vector elements.


Right, that's the straightforward way and it works, but can result in a
rather longish warning about the double->int conversion:

/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/include/g++-v3/bits/stl_algobase.h:
In
function `_OutputIter std::__copy(_RandomAccessIter, _RandomAccessIter,
_OutputIter, std::random_access_iterator_tag) [with _RandomAccessIter =
double*, _OutputIter = int*]':
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/include/g++-v3/bits/stl_algobase.h:266:
instantiated from `_OutputIter std::__copy_aux2(_InputIter,
_InputIter, _OutputIter, __true_type) [with _InputIter = double*,
_OutputIter = int*]'
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/include/g++-v3/bits/stl_algobase.h:303:
instantiated from `_OutputIter std::__copy_ni2(_InputIter, _InputIter,
_OutputIter, __false_type) [with _InputIter = double*, _OutputIter = int*]'
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/include/g++-v3/bits/stl_algobase.h:314:
instantiated from `_OutputIter std::__copy_ni1(_InputIter, _InputIter,
_OutputIter, __true_type) [with _InputIter =
__gnu_cxx::__normal_iterator<double*, std::vector<double,
std::allocator<double> > >, _OutputIter = int*]'
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/include/g++-v3/bits/stl_algobase.h:349:
instantiated from `_OutputIter std::copy(_InputIter, _InputIter,
_OutputIter) [with _InputIter = __gnu_cxx::__normal_iterator<double*,
std::vector<double, std::allocator<double> > >, _OutputIter = int*]'
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/include/g++-v3/bits/stl_uninitialized.h:76:
instantiated from `_ForwardIter
std::__uninitialized_copy_aux(_InputIter, _InputIter, _ForwardIter,
__true_type) [with _InputIter = __gnu_cxx::__normal_iterator<double*,
std::vector<double, std::allocator<double> > >, _ForwardIter = int*]'
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/include/g++-v3/bits/stl_uninitialized.h:112:
instantiated from `_ForwardIter std::uninitialized_copy(_InputIter,
_InputIter, _ForwardIter) [with _InputIter =
__gnu_cxx::__normal_iterator<double*, std::vector<double,
std::allocator<double> > >, _ForwardIter = int*]'
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/include/g++-v3/bits/stl_vector.h:829:
instantiated from `void std::vector<_Tp,
_Alloc>::_M_range_initialize(_ForwardIterator, _ForwardIterator,
std::forward_iterator_tag) [with _ForwardIterator =
__gnu_cxx::__normal_iterator<double*, std::vector<double,
std::allocator<double> > >, _Tp = int, _Alloc = std::allocator<int>]'
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/include/g++-v3/bits/stl_vector.h:807:
instantiated from `void std::vector<_Tp,
_Alloc>::_M_initialize_dispatch(_InputIter, _InputIter, __false_type)
[with _InputIter = __gnu_cxx::__normal_iterator<double*,
std::vector<double, std::allocator<double> > >, _Tp = int, _Alloc =
std::allocator<int>]'
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/include/g++-v3/bits/stl_vector.h:289:
instantiated from `std::vector<_Tp, _Alloc>::vector(_InputIterator,
_InputIterator, typename std::_Vector_base<_Tp,
_Alloc>::allocator_type&) [with _InputIterator =
__gnu_cxx::__normal_iterator<double*, std::vector<double,
std::allocator<double> > >, _Tp = int, _Alloc = std::allocator<int>]'
foo.cpp:6: instantiated from here
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/include/g++-v3/bits/stl_algobase.h:241:
warning: converting
to `int' from `double'

Cheers,
Malte
 
Reply With Quote
 
Donovan Rebbechi
Guest
Posts: n/a
 
      03-28-2005
On 2005-03-28, Anonymous <(E-Mail Removed)> wrote:
> Is there a non-brute force method of doing this?
> transform() looked likely but had no predefined function object.


I'd just wrap static_cast in a function object, e.g.

template <typename T>
struct Static_cast {
template <typename U>
T operator () (const U& x) const { return static_cast<T> (x); }
};

Not pretty, but gets the job done and shuts the compiler up. I happen to
believe that being able to explicitly "cast" one container to another is a
good enough reason to write a 5 line function object.

Cheers,
--
Donovan Rebbechi
http://pegasus.rutgers.edu/~elflord/
 
Reply With Quote
 
Malte Starostik
Guest
Posts: n/a
 
      03-28-2005
Donovan Rebbechi schrieb:
> On 2005-03-28, Anonymous <(E-Mail Removed)> wrote:
>
>>Is there a non-brute force method of doing this?
>>transform() looked likely but had no predefined function object.

>
>
> I'd just wrap static_cast in a function object, e.g.
>
> template <typename T>
> struct Static_cast {
> template <typename U>
> T operator () (const U& x) const { return static_cast<T> (x); }
> };
>
> Not pretty, but gets the job done and shuts the compiler up. I happen to
> believe that being able to explicitly "cast" one container to another is a
> good enough reason to write a 5 line function object.


I totally agree. Minor nitpick though: no need to use static_cast to
convert int to double. The functional notation is enough and IMHO
conveys less of the feeling of doing something bad
return T( x );
Of course that limits a function object like the one above.

Cheers,
Malte
 
Reply With Quote
 
Pete Becker
Guest
Posts: n/a
 
      03-28-2005
Malte Starostik wrote:
>
> Right, that's the straightforward way and it works, but can result in a
> rather longish warning about the double->int conversion:


So turn of that G** D***** warning. Just because some compiler writer
thinks you can't be trusted to convert doubles to ints doesn't mean you
have to believe it.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
 
Reply With Quote
 
Pete Becker
Guest
Posts: n/a
 
      03-28-2005
Donovan Rebbechi wrote:

>
> Not pretty, but gets the job done and shuts the compiler up. I happen to
> believe that being able to explicitly "cast" one container to another is a
> good enough reason to write a 5 line function object.
>


Even better is to use the built-in conversions as they were designed to
be used. Writing a five line function object just to satisfy some
compiler writer's notion of good form is a waste of time.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
 
Reply With Quote
 
Donovan Rebbechi
Guest
Posts: n/a
 
      03-28-2005
On 2005-03-28, Pete Becker <(E-Mail Removed)> wrote:
> Donovan Rebbechi wrote:
>
>>
>> Not pretty, but gets the job done and shuts the compiler up. I happen to
>> believe that being able to explicitly "cast" one container to another is a
>> good enough reason to write a 5 line function object.
>>

>
> Even better is to use the built-in conversions as they were designed to
> be used. Writing a five line function object just to satisfy some
> compiler writer's notion of good form is a waste of time.


But chasing some error that the compiler warned you about is a potential
timesink, because you turned down warning levels, or because the warnings
were hidden among dozens of lines of noise is an even bigger waste of time.
Writing a small wrapper around static_cast is a minor inconvenience at worst.
Of course you understand this -- so how would you go about managing the
problem of noisy warnings ?

Suppose there is a "borderline" warning that is sometimes useful and sometimes
just annoying. (I'd consider this to be such an example) Do you turn warning
levels down, or do you turn them up, but then find some way to supress or
filter the resulting noise ? Or is it your opinion that my premise is just
plain wrong, and there is no such thing as a "borderling" warning ?

Cheers,
--
Donovan Rebbechi
http://pegasus.rutgers.edu/~elflord/
 
Reply With Quote
 
Pete Becker
Guest
Posts: n/a
 
      03-28-2005
Donovan Rebbechi wrote:

> On 2005-03-28, Pete Becker <(E-Mail Removed)> wrote:
>
>>Donovan Rebbechi wrote:
>>
>>
>>>Not pretty, but gets the job done and shuts the compiler up. I happen to
>>>believe that being able to explicitly "cast" one container to another is a
>>>good enough reason to write a 5 line function object.
>>>

>>
>>Even better is to use the built-in conversions as they were designed to
>>be used. Writing a five line function object just to satisfy some
>>compiler writer's notion of good form is a waste of time.

>
>
> But chasing some error that the compiler warned you about is a potential
> timesink, because you turned down warning levels, or because the warnings
> were hidden among dozens of lines of noise is an even bigger waste of time.


And chasing some error that the compiler didn't warn you about because
someone added a cast to get rid of the warning is a potential timesink,
made worse by wrapping the cast in dozens <g> of lines of otherwise
extraneous code.

> Writing a small wrapper around static_cast is a minor inconvenience at worst.\


Any time you're rewriting correct, meaningful code in order to silence a
warning you're wasting time. And, of course, you can't assume that
someone who added a cast had thought about what the code did; they might
have added it just to silence the warning. After all, that's the goal:
your code should compile without warnings. Doesn't matter if it's
correct, so long as it's quiet. <g>

> Of course you understand this -- so how would you go about managing the
> problem of noisy warnings ?


Turn 'em off.

>
> Suppose there is a "borderline" warning that is sometimes useful and sometimes
> just annoying. (I'd consider this to be such an example) Do you turn warning
> levels down, or do you turn them up, but then find some way to supress or
> filter the resulting noise ? Or is it your opinion that my premise is just
> plain wrong, and there is no such thing as a "borderling" warning ?
>


Too many programmers today treat the compiler as a surrogate brain, and
rely on warnings to remind them that they haven't thought about the
consequences of what they've done. If you're writing code that converts
a double to an int you'd better know what the limitations on that are,
and you'd better take the time to analyze where the double comes from
and assure yourself that the conversion will do what you need to do.
That's basic software engineering. Warnings don't change that. At best
they become a checklist of places where you haven't finished your work.
There are much more effective ways of doing that, beginning with not
leaving a piece of code until you understand it. That way you don't have
to remember to look at it again later.

Tom DeMarco, in a book called "Controlling Software Projects,"
recommended (perhaps tongue in cheek) that programmers not be allowed to
use compilers; compiling their code would be part of the test phase, not
the development phase.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
 
Reply With Quote
 
Yuriy Solodkyy
Guest
Posts: n/a
 
      03-28-2005
I was always wondering why compiler writers won't create a common
numeration or classification for at least common errors and warnings. In
this way developers would have been able to temporary disable and then
reenable a particular warning via #pragma (don't know how portable
pragmas are, but it's a nice way in some compilers to explicitly say to
compiler that you know what you are doing).

Yuriy

Donovan Rebbechi wrote:
> On 2005-03-28, Pete Becker <(E-Mail Removed)> wrote:
>
>>Donovan Rebbechi wrote:
>>
>>
>>>Not pretty, but gets the job done and shuts the compiler up. I happen to
>>>believe that being able to explicitly "cast" one container to another is a
>>>good enough reason to write a 5 line function object.
>>>

>>
>>Even better is to use the built-in conversions as they were designed to
>>be used. Writing a five line function object just to satisfy some
>>compiler writer's notion of good form is a waste of time.

>
>
> But chasing some error that the compiler warned you about is a potential
> timesink, because you turned down warning levels, or because the warnings
> were hidden among dozens of lines of noise is an even bigger waste of time.
> Writing a small wrapper around static_cast is a minor inconvenience at worst.
> Of course you understand this -- so how would you go about managing the
> problem of noisy warnings ?
>
> Suppose there is a "borderline" warning that is sometimes useful and sometimes
> just annoying. (I'd consider this to be such an example) Do you turn warning
> levels down, or do you turn them up, but then find some way to supress or
> filter the resulting noise ? Or is it your opinion that my premise is just
> plain wrong, and there is no such thing as a "borderling" warning ?
>
> Cheers,


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Qestion about convert Object to byte[] and convert it back davidxiongcn@gmail.com Java 5 11-04-2006 04:11 PM
IsNumeric: Convert.ToInt32 vs. Convert.ToInt64 sck10 ASP .Net 4 09-03-2006 09:40 PM
To convert to J2SE 6 or not to convert, that is the question... Jaap Java 4 07-10-2006 09:03 AM
convert list of strings to set of regexes; convert list of strings to trie Klaus Neuner Python 7 07-26-2004 07:25 AM
Do I need to Convert with Convert.ToInt32(session("myNumber")) ? Andreas Klemt ASP .Net 1 07-23-2003 02:59 PM



Advertisments