local variables

[ze_viru$]

Hi,

below is my unfinished code.what i realy want help on is how do i display or take the values of a and b to main?

#include<iostream>

using namespace std;

int ReadInput (int,int);

float CalcIceCreamCost ();

float CalcDeliveryCost ();

float DisplayCosts ();

int main()
{
	int flava,cart,delivery;

	flava = 0;
	cart = 0;

	cout<<"			Mulaudzi Ice-Cream Limited\n"
		<<"			--------------------------\n";

	ReadInput(flava,cart);

	cout<<"Ur flava is : "<<flava<<endl;
	cout<<"Ur # of cartoons is : "<<cart<<endl;

	return 0;

}

int ReadInput (int a,int b)
{
	
	cout<<"Please enter flavour(1=choco,2=caramel,3=mint) : ";
	cin>>a;

	cout<<"Please enter number of cartoons(1-20) : ";
	cin>>b;

	return a,b;
	
}

[Bench]

You can't return multiple values from a function, you probably want to pass your variables by reference instead. ie

void ReadInput (int& a,int& b)
{
	
	cout<<"Please enter flavour(1=choco,2=caramel,3=mint) : ";
	cin>>a;

	cout<<"Please enter number of cartoons(1-20) : ";
	cin>>b;
}

Notice the ampersands (highlighted inred), to denote 'pass by reference' ... also, the function has no retun statement, since it is modifying variables elsewhere in the prgram and not returning a value, hence the function's return type is now void

[Grunt]

Also change the prototype of function to
void ReadInput (int&,int&);
I guess it's pretty obvious but I am still reminding.

[WaltP]

My preferred solution:

#include<iostream>
using namespace std;
int ReadInputFlava ();
int ReadInputCart ();

int main()
{
    int flava,cart,delivery;

    flava = 0;
    cart = 0;

    cout<<"            Mulaudzi Ice-Cream Limited\n"
        <<"            --------------------------\n";

    flava = ReadInputFlava();
     cart  = ReadInputCart();

    cout<<"Ur flava is : "<<flava<<endl;
    cout<<"Ur # of cartoons is : "<<cart<<endl;

    return 0;

}

int ReadInputFlava ()
{
    int a;
    cout<<"Please enter flavour(1=choco,2=caramel,3=mint) : ";
    cin>>a;

    return a;
}


int ReadInputCart ()
{
    int b;
    cout<<"Please enter number of cartoons(1-20) : ";
    cin>>b;

    return b;
}

This makes the program a little more modular. And I prefer not to pass values via the parameter list unless it can't be avoided. Personal choice.

[~s.o.s~]

This makes the program a little more modular.

Well forgive me for butting in, but here modularity is not an issue since he is not building a Library module but a small program.

As far as writing normal programs are concerned the coder should always be concerned with the best and the fast implementataion wrt to both memory requirements and speed.

But still this is just me, I thought just wanted to let you know.
Any constructive criticisms appreciated.

[Bench]

Well forgive me for butting in, but here modularity is not an issue since he is not building a Library module but a small program.

As far as writing normal programs are concerned the coder should always be concerned with the best and the fast implementataion wrt to both memory requirements and speed.

But still this is just me, I thought just wanted to let you know. Any constructive criticisms appreciated.

Modularity doesn't mean that its a library module, he means breaking a program down into smaller, more managable chunks. I agree that it doesn't matter so much for a small toy program, but since maintainability and readability are generally the 2 most important goals for any coder to aspire to (usually far more important than optimum speed & memory usage), its a good habit to get into.

[~s.o.s~]

Maintainability and readability are generally the 2 most important goals for any coder to aspire to (usually far more important than optimum speed & memory usage), its a good habit to get into.

Actully that is not true in all the cases.
For places or applications where the performance is of peak importance, optimum speed and memory do make a large amount of difference.

I dont mean that modularty is not important or you should go for speed more than modularity, just that it depends on the area of application in which the program is used.

[Ancient Dragon]

speed is sometimes much more important than modularity or maintainability. I worked several years on a program that had to get data real-time from barcode readers on packages as the packages moved along an assembly line. Then the program had to look-up data in a database whose key was the barcode, format the data, and send it to a large-character printer that would print information on the side of the packages when they moved past the printer. All that had to be done in less than 1/2 second and management thought that was too slow. We even resorted to assembly language to squeeze out every millisecond we could.

[~s.o.s~]

speed is sometimes much more important than modularity or maintainability. I worked several years on a program that had to get data real-time from barcode readers on packages as the packages moved along an assembly line. Then the program had to look-up data in a database whose key was the barcode, format the data, and send it to a large-character printer that would print information on the side of the packages when they moved past the printer. All that had to be done in less than 1/2 second and management thought that was too slow. We even resorted to assembly language to squeeze out every millisecond we could.

Thats exactly the point i was trying to put forward, but as i belong to the new generation couldnt find a real world example. Thanks, this was the kind of example i was looking for.

*but in the end these ppl will say that nowadays as the computing speed and memory has increased the optimizations dont matter. Well in this case the argument continues...*

[Bench]

Actully that is not true in all the cases.

Which is exactly the point i was making, there are no "always do" or "never do" rules. it depends entirely on the platform you're developing for

[Ancient Dragon]

>> there are no "always do" or "never do" rules

Never ever use gets():mrgreen:

[Grunt]

Never ever use gets():mrgreen:

What if the programmer does have adequate control over the input :mrgreen:

Even standard says 7.19.7.7 The gets function
Because gets does not check for buffer overrun, it is generally unsafe to use when its input is not under the programmer’s control. This has caused some to question whether it should appear in the Standard at all. The Committee decided that gets was useful and convenient in those special circumstances when the programmer does have adequate control over the input, and as 35 longstanding existing practice, it needed a standard specification. In general, however, the preferred function is fgets (see §7.19.7.2).

[Ancient Dragon]

name even one case where the programmer has control over gets(). The standards committee probably left it in because taking it out might break a lot of programs that already use it. The statement you quoted is just a bunch of frabridated bull****.

[Grunt]

Maybe it's bull**** but as long as it is in the standards I can't deny it.

[~s.o.s~]

Maybe it's bull**** but as long as it is in the standards I can't deny it.

... and neither do you use it. ;)

[Grunt]

... and neither do you use it. ;)

Right :cheesy: