# what is wrong with my program?

Show 80 post(s) from this thread on one page
Page 2 of 2 First 12
• 02-28-2011
jimblumberg
Code:

```for(int y=0 ; y<b+1; y++)         s1[y]=*(function(4,n,b,s)+y);```
How is s1 defined?

What are you trying to do with:
Code:

`function(4,n,b,s)+y`
Why are you adding y to the function return value?

Jim
• 02-28-2011
whiteflags
Quote:

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?
I feel bad no one is paying attention to you.

You can use vectors and arrays interchangeably, sure. The copy algorithm can help you move things around.
Code:

```int s[1000]; size_t size; std::copy(thevector.begin(), thevector.end(), s); size = thevector.size(); thevector.clear(); // use s```

Code:

```int* function1(int a,int c, int b) { int s[1000];         .         .         .         .         return 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* function(int a, int c, int b) {   static 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.

Another way to return arrays is to just return the array a function was passed as an argument.

Code:

`int* function (int*base, int a, int c, int b); // return base`
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.
• 02-28-2011
Elysia
Quote:

Originally Posted by jimblumberg
[
What are you trying to do with:
Code:

`function(4,n,b,s)+y`
Why are you adding y to the function return value?

Pointer arithmetic.
*(p + n) = p[n]

Quote:

Originally Posted by whiteflags
I feel bad no one is paying attention to you.

I blame it on not getting an email notification.
• 02-28-2011
kmdv
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.

Quote:

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).
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".

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.
• 02-28-2011
Farnaz
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)
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; }```
it returns s which is a pointer to the first element of array 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.
• 02-28-2011
Elysia
Quote:

Originally Posted by kmdv
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".

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.

Quote:

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 don't damn them. I just damn the way of teaching newbies those techniques before they're ready.
I've used a lot of low-level techniques to implement things such as smart pointers and containers.
But I'm not a newbie.
• 02-28-2011
Farnaz
I thank you all, esp whiteflags!
thank to you, I think I'm gettin a deeper undrestanding of arrays, static arrays and stuff.
• 02-28-2011
Elysia
Quote:

Originally Posted by Farnaz
thank to you, I think I'm gettin a deeper undrestanding of arrays, static arrays and stuff...instead of learning proper modern C++ such as std::array, std::vector, et all! Thank you so much!

Fixed.
• 02-28-2011
Farnaz
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.
• 02-28-2011
whiteflags
Quote:

Code:

```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.
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.
• 02-28-2011
kmdv
Quote:

Originally Posted by Farnaz
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.

@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
• 02-28-2011
Elysia
Quote:

Originally Posted by Farnaz
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.

Using arrays over vectors is never convenient. If it is, you are doing something very wrong.

Quote:

Originally Posted by kmdv
To be clear: I am not trying to convince you that starting with low level things is just better. I want to say, that learning started with low level stuff has its advantages.

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!
• 02-28-2011
Farnaz
Quote:

Originally Posted by kmdv
@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.
EDITED

It's "She" actually!
• 02-28-2011
kmdv
Quote:

Originally Posted by Elysia
Yes. Complicated programs, lots of bugs and frustration.
It's akin to learning something by hand in a complicated way.

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.

Quote:

Originally Posted by Elysia
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?!".

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.

Quote:

Originally Posted by Farnaz
It's "She" actually!

AFAIK it's HE. Is he?
• 02-28-2011
whiteflags
Not to stoke the fire, but I think my earlier post got lost in the shuffle so Farnaz be sure you read everything.
Show 80 post(s) from this thread on one page
Page 2 of 2 First 12