How is s1 defined?Code:for(int y=0 ; y<b+1; y++) s1[y]=*(function(4,n,b,s)+y);
What are you trying to do with:Why are you adding y to the function return value?Code:function(4,n,b,s)+y
Jim
How is s1 defined?Code:for(int y=0 ; y<b+1; y++) s1[y]=*(function(4,n,b,s)+y);
What are you trying to do with:Why are you adding y to the function return value?Code:function(4,n,b,s)+y
Jim
I feel bad no one is paying attention to you.thank you both but I have like 5 or 6 arrays in my program and I have wrote the whole program with arrays. if I wanna change them to vectors then I'll have to develop the program from the beginning. I've got a question here. if I use vector in my function then I should return vector<int>. and I have to assign it to an array later, when the function is called. can I do such a thing?
You can use vectors and arrays interchangeably, sure. The copy algorithm can help you move things around.
But let's talk about why your program doesn't work.Code:int s[1000]; size_t size; std::copy(thevector.begin(), thevector.end(), s); size = thevector.size(); thevector.clear(); // use s
Returning arrays from functions is funny business. Unless they are allocated on the free store or in static storage (declared with the static keyword) you cannot return an array. You return a dangling pointer (a pointer that points to released memory).Code:int* function1(int a,int c, int b) { int s[1000]; . . . . return s; }
Now, the static keyword is the swiss army knife of C and C++. In this context, a static variable will persist for the duration of the program, even though it is only accessible in function -- even after the function returns, s is still alive, so you can return pointers to it and therefore extend its scope. One problem with this approach is that no matter how often function is called, it will operate on the same array. If you need it to work with several different arrays, then allocate the pointer on the free store. static does other things in other different contexts, and this may not be what you want after all.Code:int* function(int a, int c, int b) { static int s[1000]; return s; }
Another way to return arrays is to just return the array a function was passed as an argument.
This is the best approach, because it leaves the caller with the responsibility of allocating and releasing base's memory. This is a lot more flexible because you can store base however you like, and function can still do what it needs to do.Code:int* function (int*base, int a, int c, int b); // return base
I'd been using arrays for years too and together with assembly I consider it a good experience. With a low level programming knowledge I could easily understand all the benefits of containers, every new thing was coming with "oh yes, finally I get what I missed so much".
If I had learnt vectors first, I wouldn't have bothered with arrays at all probably, and I wouldn't have gained this knowledge and experience.
I know there are. C++ is a language which allows you to mix low level concepts with high level and modern techniques, so I wouldn't be so sure if starting with the second one is always a "proper way".There are many here who would disagree with you, and I am one of them.
Learn the language properly, then move into the advanced parts (ie C arrays and C api).
It's something similar to learning Pascal (or C++ alternatively) after PHP - "why do we need these types at all?"
Well, at least there is one thing I know - no matter what way you choose, you have to gain experience.
And if you damn all the low level concepts so much, why won't you just move to C# or Java?
I don't say I use them, I know how they can affect my design badly. But because of the experience gained with them, I know when and how to use them.
Last edited by kmdv; 02-28-2011 at 01:34 PM.
my whole function is this: (it is supposed to divide a by c and puts the fractional parts-up to b digits- in the following elements of array s)
it returns s which is a pointer to the first element of array s.Code:int* function(int a,int c, int b, int[]) { int i=0; int q; while(i<=b+2) { q=a/c; s[i]=q; i++; if (i==1) { s[i]=-1; //determines the place of "." i++; } a=(a-c*q)*10; } return s; }
by writing this:
int s1[1000];
for(int y=0 ; y<b+1; y++)
s1[y]=*(function(4,n,b,s)+y);
I meant the values of the array s(which are now changed) to be placed in array s1.
since function(4,n,b,s) returns a pointer, I use ] a * operator to refer to it's value. and I'm adding y to the returned pointer so that it goes to the next spaces of memory(array spaces are in a sequence) in each iteration.(should I write 4*y or y?)...I thought the values of the elements of the array could be assigned to array s1 this way.
It most certainly is, since it saves time, frustration and bugs, and it is what makes C++ C++. Otherwise you can just start off with C. What's the point? Low-level stuff is only necessary for the advanced stuff in C++ due to abstraction and encapsulation.
I don't damn them. I just damn the way of teaching newbies those techniques before they're ready.And if you damn all the low level concepts so much, why won't you just move to C# or Java?
I don't say I use them, I know how they can affect my design badly. But because of the gained experience with them, I know when and how to use them.
I've used a lot of low-level techniques to implement things such as smart pointers and containers.
But I'm not a newbie.
I thank you all, esp whiteflags!
thank to you, I think I'm gettin a deeper undrestanding of arrays, static arrays and stuff.
I know about vectors and I do use them in my programs but I just thought it would be more convenient to use arrays in this case.
Yes, that will copy over the array just fine. But you are also calling the function b + 1 times and changing s b + 1 times. Even if function works when you tested it, did you test using it this way? Calling function so many times messes up function's math, because each time, s is different. Call function exactly once, and then copy over s to s1.I meant the values of the array s(which are now changed) to be placed in array s1.Code:int s1[1000]; for(int y=0 ; y<b+1; y++) s1[y]=*(function(4,n,b,s)+y);
@Elysia:
So, he probably knew about vectors yet before arrays. And this is the result I mentioned. If he doesn't learn about arrays and (try to) use them now, he will not know how bad they are.
To be clear: I am not trying to convince you that starting with low level things is just better. I want to show advantages of starting with low level stuff.
EDITED
Using arrays over vectors is never convenient. If it is, you are doing something very wrong.
Yes. Complicated programs, lots of bugs and frustration.
It's akin to learning something by hand in a complicated way. Then, a much more easier and better way is revealed and you will cry out "why didn't we do this in the first place?!".
Sigh. Ugh. Whatever. Frustration creeps over me.
Forget this discussion now. I know I intend to.
Btw, gender assuming is bad. Remember that lesson!
No need to write huge, obfuscated and complicated programs with tons of bugs. I think he made a good step to try out regular arrays and feel their weaknesses on his own.
As I already said, the benefit of this is the expierience, which you might not feel like to get later.
Sorry if I'm starting to offtop.
AFAIK it's HE. Is he?
Not to stoke the fire, but I think my earlier post got lost in the shuffle so Farnaz be sure you read everything.