please fix this code, Thank you friends ..!!

[smackthat1]

Create a structure of type date that contains three members: the day of the month, the month, and the year, all of type int. Have the user enter a date in the format dd.mm.yyy, store it in a variable of type struct date. Then retrieve the values from the variable and print them out in the same format.


#include<iostream.h>
#include<conio.h>
#include<iomanip.h>

struct date
{
int day; int month; int year;
};

main()
{
cout<<"-------------------------------------------------------------------------------\n"<<endl;

date x; char c;

do{
cout<<"Enter the date : "; cin >>x.day;
cout<<"Enter the Month : "; cin >>x.month;
cout<<"Enter the Year : "; cin >>x.year;
cout<<"The date is : "; cout<<x.day<<"/"<<x.month<<"/"<<x.year;
cout<<"\n\n !Press c to continue or any key to exit."<<endl<<endl;
}while(getch()=='c');

system("pause");
}

[suppa]

Here is what i did and it ran correctly. And for future refrence make your code neater. The cout and cin should be on seperate lines so its easier to follow through.

#include<iostream>
#include<iomanip>

using namespace std;

struct date
{
int day; int month; int year;
};

main()
{
cout<<"-------------------------------------------------------------------------------\n"<<endl;

date x; 
char c;

cout<<"Enter the date : "; 
cin >>x.day;
cout<<"Enter the Month : "; 
cin >>x.month;
cout<<"Enter the Year : ";
cin >>x.year;
cout<<"The date is : "; 
cout<<x.day<<"/"<<x.month<<"/"<<x.year;


return 0;
}

[Vibgyor]

#include<iostream.h>
#include<conio.h>
#include<iomanip.h>

struct date
{
int day; int month; int year;
};

void main()
{
cout<<"-------------------------------------------------------------------------------\n"<<endl;

date x; char c;

do{
cout<<"Enter the date : "; cin >>x.day;
cout<<"Enter the Month : "; cin >>x.month;
cout<<"Enter the Year : "; cin >>x.year;
cout<<"The date is : "; cout<<x.day<<"/"<<x.month<<"/"<<x.year;
cout<<"\n\n !Press c to continue or any key to exit."<<endl<<endl;
}while(getch()=='c');

getch();// Here was the error.
}

Was this the error?

Function 'system' should have a prototype

This was the only error according to my compiler.

Why is system("pause"); used?

[smackthat1]

Thank you Very much Suppa, its a great help. I will correct my mistakes :), have a nice time.

[Vibgyor]

suppa wrote:

The cout and cin should be on separate lines so its easier to follow through.

I don't follow you. All the time I am doing the opposite.

If you ask me I'll say that if cin is going to be used just after cout then you must keep them in same line, so that becomes easy to analyse that which cin is of which cout in one go(especially if you have chained too many of them like in above code).

[smackthat1]

Vibgyor Thanks a lot my friend, your help is highly appreciated :)..!!

[Vibgyor]

@ smackthat1 you are always welcome dude:)

[YFGHNG]

In regards to the cout and cin, there's probably several dissenting opinions on this. However, it's always good to go for clarity. So change your formatting based on the goal of the project.

Stylistically, I've seen so far three distinct ways of formatting cin and cout statements:
1)

cin >> stuff;
cout << stuff;
// whitespace here kept for separation of variables
cin >> stuff2;
cout << stuff2;

2)

cin >> stuff;
cin >> stuff2;
//whitespace here to separate different method calls
cout << stuff;
cout << stuff2;

3)

cin >> stuff; cout << stuff;
// or vice versa  

My personal preference is #1 because it keeps groups of similarly working functions or variables/functions that call on each other organized in one distinct group. You can tell very easily what that group of functions is supposed to do.

[Vibgyor]

YFGHNG wrote:

it keeps groups of similarly working functions or variables/functions that call on each other organized in one distinct group. You can tell very easily what that group of functions is supposed to do.

Exactly! For the sake of clarity I find #3 is the best.

cout<<"Enter your name:"; gets(name);
cout<<"Enter your ID:"; cin>>id;
cout<<"Enter your section:"; getchar(sec);

How simple it looks now, that is in the first line all the statements are regarding the entry of name(so for big programs you just read the console output strings to know what's in that whole line).

And while programing our primary focus is to make it short and not lengthy, that's why we create functions.

If total statements are 4 then according to #1&#2 they will accommodate in 4 lines(or more) but according to #3 the number of lines will reduce to 2!

And if anyone feels that #1 or #2 are better than #3 then answer a simple question: Why we cascade cin and cout then?
Why we do it like this cout<<"Enter your ID:"; and not like this

cout<<"Enter";
cout<<" ";
cout<<"your";
cout<<" ID";
cout<<":";

huh?

[YFGHNG]

Your last example there is arguable. It's not for shortness's sake; it's for clarity's sake. It's the same reason why some people prefer

function
{
}

over

function{
}

A major focus of programming, among other things, is simplicity and clarity, not shortness. Most of the times, it leads into shortness due to being succinct and having logical flow, sure. But if we have to, we make it long. Preferably we just look for ways to shorten it afterwards.

[Vibgyor]

YFGHNG wrote:

It's not for shortness's sake; it's for clarity's sake. It's the same reason why some people prefer

function
{
}

over

function{
}

I prefer doingvoid function(parameters) {Statement1;}for short programs and

void function(parameters)
{  Statement1;
   Statement2;
   Statement3; }

for long programs.
And I think most of the people prefer it this way.

YFGHNG wrote:

A major focus of programming, among other things, is simplicity and clarity, not shortness.

A short program is clear and simple, and that's what I have learnt.
Although we can write the whole program(regardless of it's length) in one line, the compiler gives no error, but I am not saying that you should write the whole program in few lines, just I am saying that you should shorten it to possible extents so that it becomes more simple.

YFGHNG wrote:

But if we have to, we make it long. Preferably we just look for ways to shorten it afterwards.

Once the program is running successfully what is the need of making changes in it. We need to shorten it while we are making the program so that going through the code becomes easier.


According to me clear and simple programming is indenting the code properly and shortening the program(where it is possible).
If you think I am wrong then please will you define 'clarity' and 'simplicity' for me.............

[YFGHNG]

We'll agree to disagree then. However,

Once the program is running successfully what is the need of making changes in it.

See, that's an engineer's perspective. If it works, it works. Why do you think there are maintenance programmers? It's because people like them go in and check to see if there's formulas that can be combined, containers that can be reduced in memory usage. Someone in the past wrote it in FORTRAN or COBOL, and new guys are hired to maintain that base instead of recoding it in an entirely different language. Granted, that's as far from simplicity as it can get, but you get my meaning.

clear and simple programming is indenting the code properly and shortening the program(where it is possible).

Where it is possible, therein lies the ambiguity. But again, I respect your opinion because everyone has different aesthetic senses. I was taught to have code be read like a book, organized in a table-like structure so that it looks kind of like a list you can follow very easily. But everyone's read different kinds of books with different kinds of formatting. So again, everyone thinks differently how "beautifully formatted" code is supposed to look like.

[Vibgyor]

YFGHNG wrote:

See, that's an engineer's perspective. If it works, it works. Why do you think there are maintenance programmers? It's because people like them go in and check to see if there's formulas that can be combined, containers that can be reduced in memory usage. Someone in the past wrote it in FORTRAN or COBOL, and new guys are hired to maintain that base instead of recoding it in an entirely different language. Granted, that's as far from simplicity as it can get, but you get my meaning.

Yeah I know it, you are 110% correct. But dude, don't you think that you are including strong points just to make your point stronger. I mean maintenance programmers as you also said cut things so that memory usages get reduced but I don't think writing like this cout<<"Enter number: "; cin>>num; or like this

cout<<"Enter number: ";
cin>>num;

makes any difference in the memory usages.
If I had said that you need not to control number of variables and objects, then I must have been crossed out by what you said, but I never said that.

YFGHNG wrote:

Where it is possible, therein lies the ambiguity.

Oh! if that wasn't clear then let me explain ya what exactly I meant:)
I meant that you should reduce

cout<<"Enter number: ";
cin>>num;
cout<<"Enter power: ";
cin>>power;

to

cout<<"Enter number: "; cin>>num;
cout<<"Enter power: "; cin>>power;

but not to

      cout<<"Enter number: "; cin>>num; cout<<"Enter power: "; cin>>power;

So..........................

[suppa]

To me i said to keep cin and cout on two separate lines because for me it is easier to follow it. I tend to write my code line by line or step by step as you will.

[doug4]

I prefer doing void function(parameters) {Statement1;}for short programs and

void function(parameters)
{ Statement1;
Statement2;
Statement3; }


for long programs.
And I think most of the people prefer it this way.

I think you are mistaken. I don't think most people prefer it this way.

Everywhere I've been, the religious wars are between

function
{
}

and

function{
}

I personally avoid the one-liner void function(parameters) {Statement1;} because it is too easy to miss the fact that is is a function definition during cursory reading. I will always split this into 4 lines (the 1st religious war option). I have seen 1-liners, but corporate coding standards that I have worked with generally discourage it. I have never seen your second choice. I have always seen the closing curly line up vertically with the beginning of the function definition. I strongly disagree that "most of the people prefer it this way."

I could go into why I prefer my style for function definitions, but that's not really germane to the discussion. The important thing is clarity and consistency, not the number of lines of code.

I will weigh in on the cout/cin issue only to say I disagree with putting them on the same line. The arguments have been made by others.

[Vibgyor]

I scrolled up and realized that I pressed space bar in place of enter button.
okay it's

void function(parameters)
{ Statement1;
  Statement2;
  Statement3; 
}

and not

void function(parameters)
{ Statement1;
Statement2;
Statement3; }

suppa wrote:

To me i said to keep cin and cout on two separate lines because for me it is easier to follow it.

Oh! so you were asking smackthat1 to put cin and cout in separate lines so that it's easier for you to go through.

suppa wrote:

And for future refrence make your code neater. The cout and cin should be on seperate lines so its easier to follow through.

After reading this I thought you were suggesting him to put cin and cout in separate lines for more clarity, so I pointed that out as I feel his program is already neat and clean.

doug4 wrote:

I think you are mistaken. I don't think most people prefer it this way.
I strongly disagree that "most of the people prefer it this way".

I am not claiming that everyone do it this way but still I think that most people prefer it 'this' way as
1. I posted it on 25th and I am getting reply of denial on 30th.
2. I can't just drop this thought as many people around me do it the same way as I mentioned.

And I personally avoid

function{
}

because I don't see any point in placing the braces after parenthesis, as I feel both the opening and closing brackets/braces/parentheses should be indented equally.

doug4 wrote:

I will always split this into 4 lines (the 1st religious war option). I have seen 1-liners, but corporate coding standards that I have worked with generally discourage it.

Do you really mean always........ seriously, also when you overload functions like this.

void print(int x)
{
cout<<x;
}
void print(int x, int y)
{
cout<<x+y;
}
void print(int x, float y)
{
cout<<x<<"≈"<<y;
}
void print(float x, float y)
{
cout<<x*y;
}

You mean you do like this...... well then this one was comical.
I find this way it's less chaotic than that one.

void print(int x) {cout<<x;}

void print(int x, int y) {cout<<x+y;}

void print(int x, float y) {cout<<x<<"≈"<<y;}

void print(float x, float y) {cout<<x*y;}

And honestly speaking, with those I worked, never came up with a negative attitude regarding this way.

doug4 wrote:

The important thing is clarity and consistency

Define those words confining their meaning within creating a program and you'll contradict yourself yourself.

doug4 wrote:

I will weigh in on the cout/cin issue only to say I disagree with putting them on the same line. The arguments have been made by others.

You just can't simply deny it. Many times I have seen it and so I started liking it even more.

Don't misunderstand me that I am forcing you to change your perspectives, I am not. No one is going to change his way of making programs just because most of the people don't do as he does.
But if he hasn't chosen any particular way, then which one he should choose, the discussion is about this only. So far the exact way is yet to be decided here. Deplorably can't create a poll :D

[doug4]

Do you really mean always........ seriously, also when you overload functions like this.

void print(int x)
{
cout<<x;
}
void print(int x, int y)
{
cout<<x+y;
}
void print(int x, float y)
{
cout<<x<<"≈"<<y;
}
void print(float x, float y)
{
cout<<x*y;
}

You mean you do like this...... well then this one was comical.

No, I don't code like that. I use proper indentation and I put white space between the function definitions like this:

void print(int x)
{
    cout<<x;
}

void print(int x, int y)
{
    cout<<x+y;
}

void print(int x, float y)
{
    cout<<x<<"≈"<<y;
}

void print(float x, float y)
{
    cout<<x*y;
}

There is never any doubt about where a function definition begins/ends. If you think it's comical, so be it.

[imii]

I dont see any error except it not neatly written . that system("pause"); is used used in dev cpp ide i think. else all right program works on dev cpp ide. it may give error in other ide depends on compiler of ide.

[Vibgyor]

@doug4

void print(int x)
{
    cout<<x;
}

void print(int x, int y)
{
    cout<<x+y;
}

void print(int x, float y)
{
    cout<<x<<"≈"<<y;
}

void print(float x, float y)
{
    cout<<x*y;
}

For me this one isn't that good either, I find this one better for short function definitions.

void print(int x)  { cout<<x; }

void print(int x, int y)  { cout<<x+y; }

void print(int x, float y)  { cout<<x<<"≈"<<y; }

void print(float x, float y)  { cout<<x*y; }

But that's my perspective.
By the way this one didn't provoke my laughter :D



@imii
I have a Turbo C++ IDE Version 3.0 so maybe you are right.

imii wrote:

I dont see any error except it not neatly written

My compiler reported the corresponding error so I told him.
"not written neatly" is not an error :D atleast not according to my compiler xD