Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #83667 > unrolled thread

This code is effective for modest-sized numbers, but can you tell what it does?

Back to article view | Back to comp.lang.c++

Contents

  This code is effective for modest-sized numbers, but can you tell what it does? "Graeme C." <graec58@gmail.com> - 2022-04-22 04:41 -0700
    Re: This code is effective for modest-sized numbers, but can you tell what it does? Christian Gollwitzer <auriocus@gmx.de> - 2022-04-22 17:19 +0200
      Re: This code is effective for modest-sized numbers, but can you tell what it does? "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-04-22 17:42 +0200
        Re: This code is effective for modest-sized numbers, but can you tell what it does? red floyd <no.spam.here@its.invalid> - 2022-04-22 09:16 -0700
    Re: This code is effective for modest-sized numbers, but can you tell what it does? Frederick Gotham <cauldwell.thomas@gmail.com> - 2022-04-22 09:22 -0700
      Re: This code is effective for modest-sized numbers, but can you tell what it does? "Graeme C." <graec58@gmail.com> - 2022-04-22 10:24 -0700
        Re: This code is effective for modest-sized numbers, but can you tell what it does? Christian Gollwitzer <auriocus@gmx.de> - 2022-04-22 20:33 +0200
          Re: This code is effective for modest-sized numbers, but can you tell what it does? "Graeme C." <graec58@gmail.com> - 2022-04-22 17:57 -0700
    Re: This code is effective for modest-sized numbers, but can you tell what it does? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-22 19:18 -0700
      Re: This code is effective for modest-sized numbers, but can you tell what it does? "Graeme C." <graec58@gmail.com> - 2022-04-22 19:40 -0700
        Re: This code is effective for modest-sized numbers, but can you tell what it does? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-22 20:00 -0700
          Re: This code is effective for modest-sized numbers, but can you tell what it does? "Graeme C." <graec58@gmail.com> - 2022-04-23 04:21 -0700
    Re: This code is effective for modest-sized numbers, but can you tell what it does? Juha Nieminen <nospam@thanks.invalid> - 2022-04-25 05:48 +0000
      Re: This code is effective for modest-sized numbers, but can you tell what it does? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-04-25 05:27 -0700
        Re: This code is effective for modest-sized numbers, but can you tell what it does? Öö Tiib <ootiib@hot.ee> - 2022-04-25 05:40 -0700
          Re: This code is effective for modest-sized numbers, but can you tell what it does? Vir Campestris <vir.campestris@invalid.invalid> - 2022-04-25 16:48 +0100
            Re: This code is effective for modest-sized numbers, but can you tell what it does? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-04-30 03:51 -0700
              Re: This code is effective for modest-sized numbers, but can you tell what it does? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-30 08:28 -0700
                Re: This code is effective for modest-sized numbers, but can you tell what it does? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-30 10:30 -0700
                Re: This code is effective for modest-sized numbers, but can you tell what it does? Manfred <noname@add.invalid> - 2022-04-30 19:20 +0200
                  Re: This code is effective for modest-sized numbers, but can you tell what it does? Manfred <noname@add.invalid> - 2022-04-30 23:20 +0200
                  Re: This code is effective for modest-sized numbers, but can you tell what it does? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-30 10:40 -0700
                Re: This code is effective for modest-sized numbers, but can you tell what it does? Manfred <noname@add.invalid> - 2022-04-30 19:12 +0200
          Re: This code is effective for modest-sized numbers, but can you tell what it does? Juha Nieminen <nospam@thanks.invalid> - 2022-04-26 05:20 +0000
            Re: This code is effective for modest-sized numbers, but can you tell what it does? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-04-29 16:12 -0700
        Re: This code is effective for modest-sized numbers, but can you tell what it does? Paavo Helde <eesnimi@osa.pri.ee> - 2022-04-25 15:44 +0300
          Re: This code is effective for modest-sized numbers, but can you tell what it does? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-05-10 07:18 -0700
            Re: This code is effective for modest-sized numbers, but can you tell what it does? scott@slp53.sl.home (Scott Lurndal) - 2022-05-10 14:34 +0000
              Re: This code is effective for modest-sized numbers, but can you tell what it does? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-05-24 05:43 -0700
            Re: This code is effective for modest-sized numbers, but can you tell what it does? Paavo Helde <eesnimi@osa.pri.ee> - 2022-05-10 20:34 +0300
              Re: This code is effective for modest-sized numbers, but can you tell what it does? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-06-04 07:57 -0700

Page 1 of 2  [1] 2  Next page →

#83667 — This code is effective for modest-sized numbers, but can you tell what it does?

// (Without running it)
#include <iostream>
#include <sstream>
#include <string>
#include <vector>

using namespace std;

typedef long long Int;

class Facs {
public:
    Int     a;
    Int     b;
            Facs(Int a, Int b)
                : a(a), b(b) {
            }
};

int
main(int argc, char **argv) {
    
    Int N;
    {
        Int P = 1601;           // default debugging values            
        Int Q = 1901;
        if (1<argc) {
            string s(argv[1]);
            istringstream iss(s);
            iss >> N;           // we'll try this one
            if (0==N%2) {
                cout << "at least give me an odd number" << endl;
                exit(1);
            }
            cout << "working on "<< N << endl;
        } else {
            N = P*Q;            // the default product to work on
        }
    }
    vector<vector<Facs> > vf;
    vf.push_back(vector<Facs>());
    vf[0].push_back(Facs(1,1)); // the only solution for gen zero
    Int lo = 2;
    Int hi = 4;
    Int gen = 1;
    while (N > lo) {          
        cout << "generation " << gen << endl;
        cout.flush();
        const Int tgt = N%hi;
        vf.push_back(vector<Facs>());       // for next generation
        for (int i=0; i<vf[gen-1].size(); i++) { // from previous gen
            const Int& a = vf[gen-1][i].a;
            const Int& b = vf[gen-1][i].b;
            if (tgt==(a*b)%hi) {
                vf[gen].push_back(Facs(a,b));
            }
            if (tgt==((a+lo)*b)%hi) {
                vf[gen].push_back(Facs(a+lo,b));
            }
            if (tgt==(a*(b+lo))%hi) {
                vf[gen].push_back(Facs(a,b+lo));
            }
            if (tgt==((a+lo)*(b+lo))%hi) {
                vf[gen].push_back(Facs(a+lo,b+lo));
            }
        }
        cout << vf[gen].size() << " pairs" << endl;
        cout.flush();
        lo=hi;
        hi*=2;
        gen++;
    }
    // done calculating - scan final gen for result
    vector<Facs> rslt;
    for (int i=0; i<vf[gen-1].size(); i++) {
        if (N == vf[gen-1][i].a * vf[gen-1][i].b) {
            rslt.push_back(vf[gen-1][i]);
            cout << N << " == " 
                 << vf[gen-1][i].a << " * " 
                 << vf[gen-1][i].b << endl;
        }
    }
    return 0;
}

// Can you predict what it does before compiling and running it?
// Regards, Graeme.

[toc] | [next] | [standalone]

#83668

Am 22.04.22 um 13:41 schrieb Graeme C.:
> // (Without running it)
> ...
> // Can you predict what it does before compiling and running it?
> // Regards, Graeme.

When you don't provide the slightest hint what this is good for, why 
should we bother to go through this mess and figure it out?

	Christian

[toc] | [prev] | [next] | [standalone]

#83669

On 22 Apr 2022 17:19, Christian Gollwitzer wrote:
> Am 22.04.22 um 13:41 schrieb Graeme C.:
>> // (Without running it)
>> ...
>> // Can you predict what it does before compiling and running it?
>> // Regards, Graeme.
> 
> When you don't provide the slightest hint what this is good for, why 
> should we bother to go through this mess and figure it out?

I share the sentiment. This looks like someone's homework. But the code 
does hint strongly that it finds two factors of a number.

- Alf

[toc] | [prev] | [next] | [standalone]

#83670

On 4/22/2022 8:42 AM, Alf P. Steinbach wrote:
> On 22 Apr 2022 17:19, Christian Gollwitzer wrote:
>> Am 22.04.22 um 13:41 schrieb Graeme C.:
>>> // (Without running it)
>>> ...
>>> // Can you predict what it does before compiling and running it?
>>> // Regards, Graeme.
>>
>> When you don't provide the slightest hint what this is good for, why 
>> should we bother to go through this mess and figure it out?
> 
> I share the sentiment. This looks like someone's homework. But the code 
> does hint strongly that it finds two factors of a number.
> 
> - Alf

I suspect his homework assignment was "What was this do, and how would 
you improve it?"

[toc] | [prev] | [next] | [standalone]

#83671

On Friday, April 22, 2022 at 12:41:21 PM UTC+1, g wrote:

> // (Without running it) 


Every few months I post a test message to Google Groups to see if it will end up in comp.lang.c++ or comp.lang.c

This post is supposed to go to c++ but it might end up in c.

[toc] | [prev] | [next] | [standalone]

#83673

On Saturday, 23 April 2022 at 02:23:06 UTC+10, Frederick Virchanza Gotham wrote:
> On Friday, April 22, 2022 at 12:41:21 PM UTC+1, g wrote: 
> 
> > // (Without running it) 
> 
> 
> Every few months I post a test message to Google Groups to see if it will end up in comp.lang.c++ or comp.lang.c 
> 
> This post is supposed to go to c++ but it might end up in c.

Pardon me for not going through a full object oriented design for something that
is basically manipulating a few numbers.  The vectors are useful and avoid a lot
of mucking about with pointers. IMNSHO It only looks a mess because of the
(lack of) formatting.  Feel free to run it through astyle, or your favourite code 
formatting program. Run it if you choose, but at least look at the code that 
generates the numbers.  

This is nobody's homework.

Regards, Graeme.

[toc] | [prev] | [next] | [standalone]

#83676

Am 22.04.22 um 19:24 schrieb Graeme C.:
> On Saturday, 23 April 2022 at 02:23:06 UTC+10, Frederick Virchanza Gotham wrote:
>> On Friday, April 22, 2022 at 12:41:21 PM UTC+1, g wrote:
>>
>>> // (Without running it)
>>
>>
>> Every few months I post a test message to Google Groups to see if it will end up in comp.lang.c++ or comp.lang.c
>>
>> This post is supposed to go to c++ but it might end up in c.
> 
> Pardon me for not going through a full object oriented design for something that
> is basically manipulating a few numbers.  

That's not the point.

> Run it if you choose, but at least look at the code that
> generates the numbers.

Why? Convince us!



	Christian

[toc] | [prev] | [next] | [standalone]

#83677

On Saturday, 23 April 2022 at 04:44:25 UTC+10, Christian Gollwitzer wrote:
> Am 22.04.22 um 19:24 schrieb Graeme C.:
> > On Saturday, 23 April 2022 at 02:23:06 UTC+10, Frederick Virchanza Gotham wrote: 
> >> On Friday, April 22, 2022 at 12:41:21 PM UTC+1, g wrote: 
> >> 
> >>> // (Without running it) 
> >> 
> >> 
> >> Every few months I post a test message to Google Groups to see if it will end up in comp.lang.c++ or comp.lang.c 
> >> 
> >> This post is supposed to go to c++ but it might end up in c. 
> > 
> > Pardon me for not going through a full object oriented design for something that 
> > is basically manipulating a few numbers.
> That's not the point.
> > Run it if you choose, but at least look at the code that 
> > generates the numbers.

> Why? Convince us! 

I don't feel the need to convince you.  I wrote this code and thought
you people might be interested to see what I'd done but if that's not
the case then I can certainly go on living without your feedback.

Regards, Graeme.

[toc] | [prev] | [next] | [standalone]

#83678

On 4/22/2022 4:41 AM, Graeme C. wrote:
>              const Int& a = vf[gen-1][i].a;
>              const Int& b = vf[gen-1][i].b;

This is valid in the context of the code presented (albeit somewhat 
risky in general case), but still kinda weird. Why by reference?

-- 
Best regards,
Andrey Tarasevich

[toc] | [prev] | [next] | [standalone]

#83679

On Saturday, 23 April 2022 at 12:19:02 UTC+10, Andrey Tarasevich wrote:
> On 4/22/2022 4:41 AM, Graeme C. wrote: 
> > const Int& a = vf[gen-1][i].a; 
> > const Int& b = vf[gen-1][i].b;
> This is valid in the context of the code presented (albeit somewhat 
> risky in general case), but still kinda weird. Why by reference? 

By reference because it seemed the most concise method of accessing
those numbers (the previous generation never changes) given that the
code soon accesses them multiple times.  I guess it could be changed to 
keep a local copy of vf[gen-1][i] but that's the way I wrote it.  The inherent 
inefficiency of the method completely dwarfs the gains to be had here.

Regards, Graeme.

[toc] | [prev] | [next] | [standalone]

#83680

On 4/22/2022 7:40 PM, Graeme C. wrote:
> On Saturday, 23 April 2022 at 12:19:02 UTC+10, Andrey Tarasevich wrote:
>> On 4/22/2022 4:41 AM, Graeme C. wrote:
>>> const Int& a = vf[gen-1][i].a;
>>> const Int& b = vf[gen-1][i].b;
>> This is valid in the context of the code presented (albeit somewhat
>> risky in general case), but still kinda weird. Why by reference?
> 
> By reference because it seemed the most concise method of accessing
> those numbers (the previous generation never changes) given that the
> code soon accesses them multiple times.  I guess it could be changed to
> keep a local copy of vf[gen-1][i] but that's the way I wrote it.  The inherent
> inefficiency of the method completely dwarfs the gains to be had here.

Well, it might have efficiency-related implications, but I'm not talking 
about efficiency, I'm talking about readability of the code. You asked 
us to analyze the code by eye. So, the readability matters.

It will immediately catch they eye of any professional programmer, even 
on a passing glance: you are storing references into a vector and at the 
same time `push_back`ing something into a... um... very similar vector. 
This triggers the question: do these references survive those `push_back`s?

Your code is fine in that regard, since closer inspection immediately 
reveals that the references in question refer into `[gen - 1]` vector 
and `push_back` always go into `[gen]` vector, but still... The question 
still pops up and distracts from reading the code. It is unnecessarily 
disruptive.

-- 
Best regards,
Andrey Tarasevich

[toc] | [prev] | [next] | [standalone]

#83683

On Saturday, 23 April 2022 at 13:01:15 UTC+10, Andrey Tarasevich wrote:
> On 4/22/2022 7:40 PM, Graeme C. wrote: 
> > On Saturday, 23 April 2022 at 12:19:02 UTC+10, Andrey Tarasevich wrote: 
> >> On 4/22/2022 4:41 AM, Graeme C. wrote: 
> >>> const Int& a = vf[gen-1][i].a; 
> >>> const Int& b = vf[gen-1][i].b; 
> >> This is valid in the context of the code presented (albeit somewhat 
> >> risky in general case), but still kinda weird. Why by reference? 
> > 
> > By reference because it seemed the most concise method of accessing 
> > those numbers (the previous generation never changes) given that the 
> > code soon accesses them multiple times. I guess it could be changed to 
> > keep a local copy of vf[gen-1][i] but that's the way I wrote it. The inherent 
> > inefficiency of the method completely dwarfs the gains to be had here.
> Well, it might have efficiency-related implications, but I'm not talking 
> about efficiency, I'm talking about readability of the code. You asked 
> us to analyze the code by eye. So, the readability matters. 
> 
> It will immediately catch they eye of any professional programmer, even 
> on a passing glance: you are storing references into a vector and at the 
> same time `push_back`ing something into a... um... very similar vector. 
> This triggers the question: do these references survive those `push_back`s? 
> 
> Your code is fine in that regard, since closer inspection immediately 
> reveals that the references in question refer into `[gen - 1]` vector 
> and `push_back` always go into `[gen]` vector, but still... The question 
> still pops up and distracts from reading the code. It is unnecessarily 
> disruptive.
> -- 
> Best regards, 
> Andrey Tarasevich

Fair comment, Andrey.  There's no compelling reason to use references
there.  Just deleting the two associated ampersands is enough to bring
it back to 'normality'.

Regards, Graeme.

[toc] | [prev] | [next] | [standalone]

#83701

Graeme C. <graec58@gmail.com> wrote:
> using namespace std;

I'd stop using that. The prefixes increase code readability.
(Yes, they do.)

> typedef long long Int;

It's clearer if you use the newer alternative:

    using Int = long long;

>             string s(argv[1]);
>             istringstream iss(s);
>             iss >> N;           // we'll try this one

It's easier to just say N = std::atoll(argv[1]);
(Ostensibly we don't care about exact validity of the argument).

>     vector<vector<Facs> > vf;
>     vf.push_back(vector<Facs>());

Could just write:

    std::vector<std::vector<Facs>> vf(1);

>     Int lo = 2;
>     Int hi = 4;
>     Int gen = 1;
>     while (N > lo) {          
...
>         lo=hi;
>         hi*=2;
>         gen++;
>     }

Isn't that just the same thing as:

    Int gen = 1;
    for(Int lo = 2, hi = 4; lo < N; lo *= 2, hi *= 2, ++gen)

>         cout << "generation " << gen << endl;
>         cout.flush();

Outputting std::endl already flushes the stream. There's no need to flush
it again.

>         for (int i=0; i<vf[gen-1].size(); i++) { // from previous gen

std::vector::size() returns a value of type std::size_t. You shouldn't be
using an int with it.

>             const Int& a = vf[gen-1][i].a;
>             const Int& b = vf[gen-1][i].b;

As others have commented there's no need to use references here. In fact,
it's likely going to produce less efficient code (I'm not sure the compiler
is allowed to optimize the references away).

Handing elementary types by value is more efficient than handling them by
reference.

[toc] | [prev] | [next] | [standalone]

#83720

Juha Nieminen <nospam@thanks.invalid> writes:

> Graeme C. <graec58@gmail.com> wrote:

[...]

>>    for (int i=0; i<vf[gen-1].size(); i++) { // from previous gen
>
> std::vector::size() returns a value of type std::size_t.  You
> shouldn't be using an int with it.

I don't want to start a holy war, but in this particular case
there is no problem comparing a signed type to a size_t (which is
an unsigned type).  More generally, whenever a value of a signed
type has a non-negative value, as is obviously true in this
construct, then there is never a problem comparing a value of a
signed type to a value of an unsigned type.

Some people prefer using an unsigned type for indexing variables
like 'i' above, and that a reasonable style choice here IMO.  But
there is nothing logically wrong with giving 'i' a signed type
here instead.

[toc] | [prev] | [next] | [standalone]

#83721

On Monday, 25 April 2022 at 15:27:42 UTC+3, Tim Rentsch wrote:
> Juha Nieminen <nos...@thanks.invalid> writes: 
> 
> > Graeme C. <gra...@gmail.com> wrote: 
> 
> [...]
> >> for (int i=0; i<vf[gen-1].size(); i++) { // from previous gen 
> > 
> > std::vector::size() returns a value of type std::size_t. You 
> > shouldn't be using an int with it.
> I don't want to start a holy war, but in this particular case 
> there is no problem comparing a signed type to a size_t (which is 
> an unsigned type). More generally, whenever a value of a signed 
> type has a non-negative value, as is obviously true in this 
> construct, then there is never a problem comparing a value of a 
> signed type to a value of an unsigned type. 
> 
> Some people prefer using an unsigned type for indexing variables 
> like 'i' above, and that a reasonable style choice here IMO. But 
> there is nothing logically wrong with giving 'i' a signed type 
> here instead.

The issue as I read it was about chance that int is 32 bits, the 
vf[gen-1] has 2,200,000,000 elements and so the ++ will be 
applied to INT_MAX  that is undefined behavior.

[toc] | [prev] | [next] | [standalone]

#83731

On 25/04/2022 13:40, Öö Tiib wrote:
> The issue as I read it was about chance that int is 32 bits, the
> vf[gen-1] has 2,200,000,000 elements and so the ++ will be
> applied to INT_MAX  that is undefined behavior.

Some of us remember when int was only 16 bits...

There's actually no guarantee that int and size_t are the same size, 
never mind the signed problem.

for (int i = 0;
is however traditional. I suspect at least in part because int is 
easiest to type.

Andy

[toc] | [prev] | [next] | [standalone]

#83897

On Monday, 25 April 2022 at 16:48:28 UTC+1, Vir Campestris wrote:
> On 25/04/2022 13:40, Öö Tiib wrote: 
> > The issue as I read it was about chance that int is 32 bits, the 
> > vf[gen-1] has 2,200,000,000 elements and so the ++ will be 
> > applied to INT_MAX that is undefined behavior.
> Some of us remember when int was only 16 bits... 
> 
> There's actually no guarantee that int and size_t are the same size, 
> never mind the signed problem. 
> 
> for (int i = 0; 
> is however traditional. I suspect at least in part because int is 
> easiest to type. 
> 
If you need to interate in reverse

for (int i = (int) v.size()-1; i >= 0; i--)

you can't substitute a size_t.
You can do

size_t i = v.size();
while(i--)
so there's a workaround.

[toc] | [prev] | [next] | [standalone]

#83898

On 4/30/2022 3:51 AM, Malcolm McLean wrote:
> On Monday, 25 April 2022 at 16:48:28 UTC+1, Vir Campestris wrote:
>> On 25/04/2022 13:40, Öö Tiib wrote:
>>> The issue as I read it was about chance that int is 32 bits, the
>>> vf[gen-1] has 2,200,000,000 elements and so the ++ will be
>>> applied to INT_MAX that is undefined behavior.
>> Some of us remember when int was only 16 bits...
>>
>> There's actually no guarantee that int and size_t are the same size,
>> never mind the signed problem.
>>
>> for (int i = 0;
>> is however traditional. I suspect at least in part because int is
>> easiest to type.
>>
> If you need to interate in reverse
> 
> for (int i = (int) v.size()-1; i >= 0; i--)
> 
> you can't substitute a size_t.
> You can do
> 
> size_t i = v.size();
> while(i--)
> so there's a workaround.

If one needs to iterate in reverse one uses

   for (std::size_t i = v.size(); i > 0; )
   {
     --i;
     ...
   }

or

   for (std::size_t i = v.size(); i-- > 0; )
   {
     ...
   }

or even plain

   for (std::size_t i = v.size(); i != -1; --i)
   {
     ...
   }

These are not "workarounds". These are idioms.

-- 
Best regards,
Andrey Tarasevich

[toc] | [prev] | [next] | [standalone]

#83901

On 4/30/2022 10:12 AM, Manfred wrote:
> On 4/30/2022 5:28 PM, Andrey Tarasevich wrote:
>> On 4/30/2022 3:51 AM, Malcolm McLean wrote:
>>> On Monday, 25 April 2022 at 16:48:28 UTC+1, Vir Campestris wrote:
>>>> On 25/04/2022 13:40, Öö Tiib wrote:
>>>>> The issue as I read it was about chance that int is 32 bits, the
>>>>> vf[gen-1] has 2,200,000,000 elements and so the ++ will be
>>>>> applied to INT_MAX that is undefined behavior.
>>>> Some of us remember when int was only 16 bits...
>>>>
>>>> There's actually no guarantee that int and size_t are the same size,
>>>> never mind the signed problem.
>>>>
>>>> for (int i = 0;
>>>> is however traditional. I suspect at least in part because int is
>>>> easiest to type.
>>>>
>>> If you need to interate in reverse
>>>
>>> for (int i = (int) v.size()-1; i >= 0; i--)
>>>
>>> you can't substitute a size_t.
>>> You can do
>>>
>>> size_t i = v.size();
>>> while(i--)
>>> so there's a workaround.
>>
>> If one needs to iterate in reverse one uses
>>
>>    for (std::size_t i = v.size(); i > 0; )
>>    {
>>      --i;
>>      ...
>>    }
>>
>> or
>>
>>    for (std::size_t i = v.size(); i-- > 0; )
>>    {
>>      ...
>>    }
>>
>> or even plain
>>
>>    for (std::size_t i = v.size(); i != -1; --i)
>>    {
>>      ...
>>    }
>>
>> These are not "workarounds". These are idioms.
>>
> 
> Change the last one to:
> 
>    for (std::size_t i = v.size(); i != 0; --i)
>    {
>      ...
>    }

No, no, no.

There is an error in the last one indeed. It was supposed to be this

   for (std::size_t i = v.size() - 1; i != -1; --i)
   {
     ...
   }

This is the correct version. It is intended to illustrate the fact that 
unsigned indexing can be made to look as natural as the signed one. It 
has to be used with caution, since it won't work properly with "small" 
(i.e. promoted) unsigned types. But still...

-- 
Best regards,
Andrey Tarasevich

[toc] | [prev] | [next] | [standalone]

#83903

On 4/30/2022 7:12 PM, Manfred wrote:
> On 4/30/2022 5:28 PM, Andrey Tarasevich wrote:
>> On 4/30/2022 3:51 AM, Malcolm McLean wrote:
>>> On Monday, 25 April 2022 at 16:48:28 UTC+1, Vir Campestris wrote:
>>>> On 25/04/2022 13:40, Öö Tiib wrote:
>>>>> The issue as I read it was about chance that int is 32 bits, the
>>>>> vf[gen-1] has 2,200,000,000 elements and so the ++ will be
>>>>> applied to INT_MAX that is undefined behavior.
>>>> Some of us remember when int was only 16 bits...
>>>>
>>>> There's actually no guarantee that int and size_t are the same size,
>>>> never mind the signed problem.
>>>>
>>>> for (int i = 0;
>>>> is however traditional. I suspect at least in part because int is
>>>> easiest to type.
>>>>
>>> If you need to interate in reverse
>>>
>>> for (int i = (int) v.size()-1; i >= 0; i--)
>>>
>>> you can't substitute a size_t.
>>> You can do
>>>
>>> size_t i = v.size();
>>> while(i--)
>>> so there's a workaround.
>>
>> If one needs to iterate in reverse one uses
>>
>>    for (std::size_t i = v.size(); i > 0; )
>>    {
>>      --i;
>>      ...
>>    }
>>
>> or
>>
>>    for (std::size_t i = v.size(); i-- > 0; )
>>    {
>>      ...
>>    }
>>
>> or even plain
>>
>>    for (std::size_t i = v.size(); i != -1; --i)
>>    {
>>      ...
>>    }
>>
>> These are not "workarounds". These are idioms.
>>
> 
> Change the last one to:
> 
>    for (std::size_t i = v.size(); i != 0; --i)
>    {
>      ...
>    }

However, what you really should do is:

   using MyVector = std::vector<int>;

   ...

   for (MyVector::reverse_iterator it = v.rbegin(); v.rend() != it; ++it)
   {
     ...
   }

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c++

csiph-web