comp.lang.c++.moderated Google Group

Re: std::vector of const values

2009-11-22T16:07:14Z

you should simply add one missing const :
int main()
{
int i1, i2, i3;
std::vector< const int* > ints; // note to the const before int
ints.push_back( &i1 );
ints.push_back( &i2 );
ints.push_back( &i3 );
doStuff( ints );
return 0;

Re: std::vector of const values

2009-11-22T13:11:29Z

I wouldn't worry about const correctness in this particular case. It
could
be an issue if you would write an interface for other programmer to
implement
and you wouldn't want him to mess data you pass to him. In this case I
can
think of two solutions:
1. Easy way - provide doStuff virtual method for one parameter:

Re: istringstream constructor performance

2009-11-22T13:16:28Z

<snip>
Did You remember to test performances with optimization turned on?
It makes a big difference with the C++ standard library. At least with
gcc.
Regards, Claudio Pacati

Re: std::vector of const values

2009-11-22T13:15:32Z

Dave wrote:
vectors instantiated with different types. int const * and int* are
completely different types. If you want to be able to deal with vectors of
different types write a template function:
template <typename type>
void doStuff(const std::vector<type *> & instances){
for( size_t i(0); i != instances.size(); ++i )

Re: std::vector of const values

2009-11-22T13:14:58Z

Dave =D0=BD=D0=B0=D0=BF=D0=B8=D1=81 =D0=B0=D0=B2(=D0=BB=D0=B0):
#include <vector>
I propose to use iterators:
template <typename Iter>
void doStuff(Iter begin, Iter end)
{
for(Iter it = begin; it != end; ++it)
{
std::cout << **it << std::endl;
}
...
doStuff( ints.begin(), insts.end());

Re: std::vector of const values

2009-11-22T13:16:37Z

consider
void doStuff( std::vector< const int* >& ints )
This would be able to add const int* to what is actually
std::vector<int*>
Of course since it is actually passed as an immutable vector that
cannot happen but I think that that is getting too sophisticated.
One way to go would be to redefine doStuff as a template method taking

Re: istringstream constructor performance

2009-11-22T13:13:28Z

The basic problem is that you are imposing the overhead for
construction/destruction on your use. Stream classes of all kinds have
relatively expensive ctors/dtors. When you switch to static instnaces you
only pay the overhead once rather than every entry to the function.
If speed is an issue, you might try inlining ToDouble. Many compilers will

Re: removing from set - does it have to be so ugly?

2009-11-22T04:53:08Z

I think in-place-erasing totally corrupt the iterator.
The code erases all odd elements from a set<int>....
but replace in "for(...; i <= 25; ...)" 25 with 55
now "7" stays UN-erased
using namespace std;
void print(int elem) {
cout << elem << endl;
int main() {
set<int> r;
for (int i = 0; i <= 25; i += 5) r.insert(i);

istringstream constructor performance

2009-11-22T04:55:06Z

I have written some C style static methods that convert strings to
doubles, ints, longs, etc. using the C++ string stream objects. Each
of the converter methods use a locally constructed istringstream
object which uses the >> operator to make the conversions. A typical
method looks like:
double ToDouble( const string & str)

std::vector of const values

2009-11-22T04:52:27Z

Hi all,
I have run into this problem a few times and was hoping there was a
more elegant solution than what I was doing. Suppose I have the
following code:
void doStuff( const std::vector< const int* >& ints )
{
for( size_t i = 0; i != ints.size(); ++i )
std::cout << *ints[ i ] << std::endl;

Re: Copy C'tor - doubt

2009-11-22T04:50:49Z

No, only a single heap allocation will occur, as written.

Re: Question on goto with try/catch

2009-11-20T21:10:26Z

Yes its Ok.
What you cannot do is jump into a try block or a catch handler. But
jumping out is OK and should do the clean-up. Part of 15/2 has:
"...A goto, break, return, or continue statement can be used to transfer
control out of
a try block or handler. When this happens, each variable declared in the

Re: Article: On Iteration

2009-11-20T21:10:54Z

On 11 Nov, 06:20, Andrei Alexandrescu <SeeWebsiteForEm...@erdani.org >
wrote:
Great article. A step-by-step introduction to the new concepts makes
it very easy to follow.
I have one question regarding infinite RandomAccessRange concept.
It has method
RandomAccessRange slice(int i, int j);
So it'll produce a finite range, right? Why there is no way to produce

Re: Question on goto with try/catch

2009-11-20T21:08:38Z

That does work correctly. In general:
{
TYPE var(params);
goto end;
end:
It does not matter whether a {} block is a "try" block or not, there
is no problem. It would have been horrible if goto broke automatic
object cleanup.
That said, authors did not know how to write C++. This is not
uncommon, especially for old code, or for stubborn C people. One

Re: Question on goto with try/catch

2009-11-20T21:09:47Z

If the "bad thing" really is an exception then by all means throw an
exception.
No more and no less than leaving any other block by goto or even
return.
As far as the goto goes it is fine.
Destructors for anything declared in the try block are called on exit
however and whereever you exit the block.