concatenate int value from vector to long long int

how can i concatenate value from a int vector to long long int i found a way i don't know it is the good way or not

Code:

---

#include <iostream>
#include <vector>


using namespace std;


int main(){

        vector<int> a = { 4, 5, 8, 7, 4, 5, 1 };

        long long int g = 0;
        const int Cn = 10;
        int x = 0;
        int szii = a.size();
        for (int i = 0; i < szii; i++){

                if (i == 0){

                        g = a[i];

                }
                else
                {
                        x = a[i];
                        g = Cn * g + x;
                }

        }

        return 0;
}

---

Quote:

---

Originally Posted by Ramees219

how can i concatenate value from a int vector to long long int

---

What exactly does that mean? Perhaps you should provide example input and expected output.

I think something like this. Consider

Code:

---

#include <iostream>
#include <vector>
#include <algorithm>
using namespace std;

int main()
{
        const vector<int> a = { 4, 5, 8, 7, 4, 5, 1 };
        const int Cn = 10;

        long long int g = 0;

        for_each(a.begin(), a.end(), [&](int i) {g = Cn * g + i;});

        cout << g << endl;

        return 0;
}

---

This produces the same value as your original code.

PS You might want to consider making g unsigned.

You should also consider using accumulate. It takes care of a few more details for you, such as not having to create a variable to accumulate into, or creating a capture in your lambda:

Code:

---

#include <iostream>
#include <vector>
#include <algorithm>
using namespace std;

int main()
{
        const vector<int> a = { 4, 5, 8, 7, 4, 5, 1 };
        const long int Cn = 10;

        long long int g =
                accumulate(a.begin(), a.end(), 0, [](int seed, int value) {return Cn * seed + value;});

        cout << g << endl;
}

---

Quote:

---

Originally Posted by monarch_dodra

You should also consider using accumulate. It takes care of a few more details for you, such as not having to create a variable to accumulate into, or creating a capture in your lambda:

Code:

---

#include <iostream>
#include <vector>
#include <algorithm>
using namespace std;

int main()
{
        const vector<int> a = { 4, 5, 8, 7, 4, 5, 1 };
        const long int Cn = 10;

        long long int g =
                accumulate(a.begin(), a.end(), 0, [](int seed, int value) {return Cn * seed + value;});

        cout << g << endl;
}

---

---

Thanks for showing me a new way . But i wonder how its work long long int to a vector

Quote:

---

But i wonder how its work long long int to a vector

---

Consider

Code:

---

#include <iostream>
#include <vector>
#include <algorithm>
#include <numeric>
using namespace std;

int main()
{
        const vector<int> a = { 4, 5, 8, 7, 4, 5, 1 };
        constexpr int Cn = 10;

        auto g = accumulate(a.begin(), a.end(), 0LL, [&](long long int seed, int value) {return Cn * seed + value;});

        cout << g << endl;
}

---

g has type of long long int.

Note that the lamda needs a capture for Cn.

PS Also consider specifying the type of the vector and the type of the required value as

Code:

---

#include <iostream>
#include <vector>
#include <algorithm>
#include <numeric>
using namespace std;

int main()
{
        using req_type = long long int;
        using vec_type = int;

        const vector<vec_type> a = { 4, 5, 8, 7, 4, 5, 1 };
        constexpr int Cn = 10;

        auto g = accumulate(a.begin(), a.end(), req_type(0), [&](req_type seed, vec_type value) {return Cn * seed + value;});

        cout << g << endl;
}

---

Quote:

---

Originally Posted by 2kaud

Note that the lamda needs a capture for Cn.

---

I don't know what the speck say exactly, but given that Cn is const and compile time known, I do not think you need to capture it. Rather, it gets "baked" into the lambda. The code you posted works just as well if you explicitly say "capture nothing" ("[]"). gcc accepts it anyways.

True about the unsigned long thing.

Quote:

---

gcc accepts it anyways.

---

but VS2015 doesn't :(

error C3493: 'Cn' cannot be implicitly captured because no default capture mode has been specified

Quote:

---

Originally Posted by 2kaud

error C3493: 'Cn' cannot be implicitly captured because no default capture mode has been specified

---

VS2015 is right. [] means no capture at all. To get implicit capture you need to specify either [=] for value or [&] for reference.

Capture by value is generally safer and there's never a reason to capture a constant primitive (like Cn) by reference anyway. So in this case [=] is better and the more specific [Cn] is even better still.

But I would like to make another point.

The OP may get the impression that there's something wrong with the explicit looping approach and that the standard function approach is inherently better. I don't agree. What's wrong with the plain range-based for-loop?

Code:

---

int main() {
        vector<int> a = { 4, 5, 8, 7, 4, 5, 1 };
        const int Cn = 10;

        long long int g = 0;
        for (auto x : a) {
                g = Cn * g + x;
        }

        cout << g << endl;
        return 0;
}

---

I'm heavily into functional programming so I'm no stranger to functions but in this case the use of a function just adds complexity and obscurity without offering any additional benefits.

Quote:

---

the more specific [=Cn] is even better still

---

With VS2015 this gives "error C2146: syntax error: missing ']' before identifier 'Cn'". Although [&Cn] is OK.

Quote:

---

What's wrong with the plain range-based for-loop?

---

Yet another way! This though is probably the easier to read. I would be interested in guru's views regarding the performance of these various methods.

Quote:

---

Originally Posted by 2kaud

With VS2015 this gives "error C2146: syntax error: missing ']' before identifier 'Cn'". Although [&Cn] is OK.

---

Sorry, it's a typo. I should be [Cn]. This means Cn is captured by value. I'll modify my post.

Quote:

---

Yet another way! This though is probably the easier to read. I would be interested in guru's views regarding the performance of these various methods.

---

It's not just "yet another way". There's a huge qualitative difference where in my view the range-based for-loop is the outstanding winner in this particular example. It's much easier to understand and get right than the function approach where the increased code complexity adds an extra layer of potential mistakes.

Regarding performance, I'd say an optimizing compiler most likely will generate pretty much the same code in both cases.

Quote:

---

Originally Posted by tiliavirga

VS2015 is right. [] means no capture at all. To get implicit capture you need to specify either [=] for value or [&] for reference.

---

I'm not sure that is right, as Cn is never ODR-used to begin with, meaning it does not need to be captured at all. Clang also seems to accept it.

I found this bug report, though it hasn't been accepted.
https://connect.microsoft.com/Visual...expr-variables

Finding more info on this is hard though :/

EDIT: This seems like a good post about the issue:
http://stackoverflow.com/questions/2...scope-variable

Quote:

---

Originally Posted by monarch_dodra

I'm not sure that is right, as Cn is never ODR-used to begin with, meaning it does not need to be captured at all. Clang also seems to accept it.

---

Okay, VS2015 may be wrong then but this only emphasizes my point that in this case the function-with-lambda approach is far more convoluted than the for-loop approach.

I think it's a good programming principle to use the simplest among functionally equal and equally efficient solutions and in this case the for-loop approach is the winner. The OP should know that there's no general consensus that a function always beats a loop.

Quote:

---

Originally Posted by monarch_dodra

I'm not sure that is right, as Cn is never ODR-used to begin with, meaning it does not need to be captured at all. Clang also seems to accept it.

---

AFAIK, clang is right because const int's ( and unscoped enumerations ) initialized by a constant expression are like constant expressions themselves when converted to rvalues ( eg. if no address is taken ), so there's no implicit capture even if the variable is automatic.

but note that this situation is quite brittle though

Code:

---

const int x = 123; // or constexpr, it's the same in this case ...
// static const int x = 123; // this would always work, but would give a linker error if at class scope and ODR used

[]{ x+x; }; // OK
[]{ std::max(x,x); }; // error, needs default capture
[]{ std::max(+x,+x); }; // OK, converted to rvalue
// ...

---

Quote:

---

Originally Posted by superbonzo

AFAIK, clang is right because const int's ( and unscoped enumerations ) initialized by a constant expression are like constant expressions themselves when converted to rvalues ( eg. if no address is taken ), so there's no implicit capture even if the variable is automatic.

but note that this situation is quite brittle though

Code:

---

const int x = 123; // or constexpr, it's the same in this case ...
// static const int x = 123; // this would always work, but would give a linker error if at class scope and ODR used

[]{ x+x; }; // OK
[]{ std::max(x,x); }; // error, needs default capture
[]{ std::max(+x,+x); }; // OK, converted to rvalue
// ...

---

---

Those work for me though, as you can always pass a const expression to functions taking const refs.

I can see it being an issue if you want to pass your x to a value taking by const pointer though.

Quote:

---

Originally Posted by monarch_dodra

Those work for me though, as you can always pass a const expression to functions taking const refs.

---

uhm, unless I'm missing something, no, because a reference to an automatic const int is not a constant expression ( triggering an implicit capture and hence an error ). Are you using a c++14 standard library ? ( std::max is constexpr from c++14 on ... in this case no error would happen of course )

Quote:

---

Originally Posted by superbonzo

uhm, unless I'm missing something, no, because a reference to an automatic const int is not a constant expression ( triggering an implicit capture and hence an error ). Are you using a c++14 standard library ? ( std::max is constexpr from c++14 on ... in this case no error would happen of course )

---

Well, "those work for me" is never proof of anything :) I was using godbolt to test different compiler versions, always with C++11 exclusively (-std=c++11).

Anyways, it would appear gcc accepts the code, for both C++11 and C++14, whereas Clang rejects it for both versions :/