help

[reepakmajhi.com]

is this 2 program code right of two matrix addition



1st program







#include<iostream.h>
#define row 4
#define col 4

int main()
{
int i[row][col],j[row][col],k[row][col];
int a,b,c,d,e,f,g,h;

for(a=0;a<row-1;a++)
{ cout<<"\n";
for(b=0;b<col-1;b++)
cin>>i[a];
}
for(a=0;a<row-1;a++)
{ cout<<"\n";
for(b=0;b<col-1;b++)
cin>>j[a];
}

for(a=0;a<row-1;a++)
{ cout<<"\n";
for(b=0;b<col-1;b++)
k[a]= j[a]+i[a]; }


for(a=0;a<row-1;a++)
{cout<<"\n";
for(b=0;b<col-1;b++)
cout<<"\t";
cout<<k[a];}

system("pause"); }





2nd program

#include<iostream.h>


int main()
{
int i[10][10],j[10][10],k[10][10];
int a,b,c,d,e,f;
cin>>c>>d;
cin>>e>>f;
for(a=0;a<c;a++)
{ cout<<"\n";
for(b=0;b<d;b++)
cin>>i[a];
}
for(a=0;a<e;a++)
{ cout<<"\n";
for(b=0;b<f;b++)
cin>>j[a];
}

for(a=0;a<c;a++)
{ cout<<"\n";
for(b=0;b<d;b++)
k[a]= j[a]+i[a]; }


for(a=0;a<c;a++)
{cout<<"\n";
for(b=0;b<d;b++)
cout<<"\t";
cout<<k[a];}

system("pause"); }

 

[Lionel B]

is this 2 program code right of two matrix addition

1st program

#include<iostream.h>

Make that

#include <iostream>

(no ".h"). The ".h" form is deprecated (some might diagree...). Then your
code shouldn't compile, since cin, cout are in the "std" namespace. So
either refer to them as std::cin, std::cout or put a

using namespace std;

statement here.

#define row 4
#define col 4

In C++ use const definitions in favour of #defines for constants:

int main()
{

const int row = 4;
const int col = 4;

int i[row][col],j[row][col],k[row][col];
int a,b,c,d,e,f,g,h;

Bad C++ style to declare all variables at top of function (have you been
programming in C by any chance?). Rather declare before first use. Also,
use meaningful variable names if you can (you don't seem to use
c,d,r,f,g,h anyway).

for(a=0;a<row-1;a++)

Prefer to define loop counters in loop expression.

Also, your termination condition is wrong (throughout code). Try:

for(int a=0;a<row;a++)

{ cout<<"\n";

May as well be '\n' (single quotes), since \n is a single character
rather than a string.

for(b=0;b<col-1;b++)
cin>>i[a];
}
for(a=0;a<row-1;a++)
{ cout<<"\n";
for(b=0;b<col-1;b++)
cin>>j[a];
}

for(a=0;a<row-1;a++)
{ cout<<"\n";
for(b=0;b<col-1;b++)
k[a]= j[a]+i[a]; }


for(a=0;a<row-1;a++)
{cout<<"\n";
for(b=0;b<col-1;b++)
cout<<"\t";
cout<<k[a];}

system("pause"); }

missing a closing }

2nd program

This is so awful it caused me physical pain ;-) Rewrite with suggestions
as above, maybe comment your code a bit and we'll see...

Hint: matrices have to be the same "shape" for matrix addition to make
sense.

#include<iostream.h>


int main()
{
int i[10][10],j[10][10],k[10][10];
int a,b,c,d,e,f;
cin>>c>>d;
cin>>e>>f;
for(a=0;a<c;a++)
{ cout<<"\n";
for(b=0;b<d;b++)
cin>>i[a];
}
for(a=0;a<e;a++)
{ cout<<"\n";
for(b=0;b<f;b++)
cin>>j[a];
}

for(a=0;a<c;a++)
{ cout<<"\n";
for(b=0;b<d;b++)
k[a]= j[a]+i[a]; }


for(a=0;a<c;a++)
{cout<<"\n";
for(b=0;b<d;b++)
cout<<"\t";
cout<<k[a];}

system("pause"); }

 

[red floyd]

Make that

#include <iostream>

(no ".h"). The ".h" form is deprecated (some might diagree...). Then your
code shouldn't compile, since cin, cout are in the "std" namespace. So
either refer to them as std::cin, std::cout or put a

It was never part of a standard, so it *can't* be deprecated. It's
simply a non-standard header.

 

[Alf P. Steinbach]

* Lionel B:

Make that

#include <iostream>

(no ".h"). The ".h" form is deprecated (some might diagree...).

Yeah, some might...

What you probably intended to /communicate/ is OK, but the word "deprecated" is
a very technical one with a very narrow and very technical meaning.

It implies that something may stop being a part of the standard, whereas
[iostream.h] has never been part of the standard in the first place, and thus is
not deprecated and never will be deprecated. ;-)


Cheers, & hth.,

- Alf

 

[James Kanze]

It was never part of a standard, so it *can't* be deprecated.
It's simply a non-standard header.

It was never part of an ISO standard, so ISO can't deprecate it.
It was part of the de facto C++ standard that predated the ISO
standard; in this sense, "deprecated" pretty much describes its
de facto situation, whether the term is technically correct or
not.

 

[Christopher Dearlove]

It was part of the de facto C++ standard that predated the ISO
standard; in this sense, "deprecated" pretty much describes its
de facto situation, whether the term is technically correct or
not.

Except that if I use something still in the C++ standard but deprecated,
I expect it to still work. If I use <iostream.h> I have no such expectation,
and in at least some cases if I had such an expectation, I'd be wrong.
So it's quite unlike deprecated in that practical regard.

 

[James Kanze]

Except that if I use something still in the C++ standard but
deprecated, I expect it to still work. If I use <iostream.h> I
have no such expectation, and in at least some cases if I had
such an expectation, I'd be wrong. So it's quite unlike
deprecated in that practical regard.

Well, I'd expect it to work. And if it didn't, it's a pretty
strong sign from the compiler vendor that he doesn't care about
his customers.

 

[Noah Roberts]

Well, I'd expect it to work. And if it didn't, it's a pretty
strong sign from the compiler vendor that he doesn't care about
his customers.

1>------ Build started: Project: scratch, Configuration: Debug Win32 ------
1>Compiling...
1>main.cpp
1>e:\dev_workspace\experimental\scratch\scratch\main.cpp(2) : fatal
error C1083: Cannot open include file: 'iostream.h': No such file or
directory
1>Build log was saved at
"file://e:\dev_workspace\experimental\scratch\scratch\Debug\BuildLog.htm"
1>scratch - 1 error(s), 0 warning(s)


Of course, you can always say, "Well obviously Microsoft doesn't care
about their customers." That's what makes your philosophy here useless.

 

[Christopher Dearlove]

On Mar 16, 4:38 pm, "Christopher Dearlove"

Well, I'd expect it to work. And if it didn't, it's a pretty
strong sign from the compiler vendor that he doesn't care about
his customers.

Since I've had experience of it not working, I wouldn't expect it
to work. And the compiler vendor has to draw the line somewhere.
And I'm quite happy if <iostream.h> is over in the "don't care"
area, as I have no code that uses it, or I expect ever to. If I did
get involved in something that used it, yes, I'd have to pick my
compiler with a different set of criteria. As it is, <iostream.h>
working is nowhere on my list. This is quite different to a deprecated
feature.

 

[James Kanze]

1>------ Build started: Project: scratch, Configuration: Debug Win32 ------
1>Compiling...
1>main.cpp
1>e:\dev_workspace\experimental\scratch\scratch\main.cpp(2) : fatal
error C1083: Cannot open include file: 'iostream.h': No such file or
directory
1>Build log was saved at
"file://e:\dev_workspace\experimental\scratch\scratch\Debug\BuildLog.htm"
1>scratch - 1 error(s), 0 warning(s)

Of course, you can always say, "Well obviously Microsoft
doesn't care about their customers." That's what makes your
philosophy here useless.

Apparently they don't. Which doesn't mean that you necessarily
have a choice. But it does mean that you may end up having to
rewrite parts of the project that you hadn't planned on. (Note
that I'm not recommending using <iostream.h> in new code. But
you shouldn't have to modify existing code if it wasn't broken.
And I'm sure that there was working code written for VC++ before
<iostream> existed.)

 

[James Kanze]

"James Kanze" <[email protected]> wrote in message

On Mar 16, 4:38 pm, "Christopher Dearlove"

Since I've had experience of it not working, I wouldn't expect it
to work. And the compiler vendor has to draw the line somewhere.
And I'm quite happy if <iostream.h> is over in the "don't care"
area, as I have no code that uses it, or I expect ever to.

That's because you're younger than I am. If you don't have any
yet, of course, you shouldn't have any in the future. But my
customer has been developing with VC++ (and Sun CC) almost since
it first appeared. The result is that we still have copies of
VC++ 6.0 around, because there's a working code base we don't
want to touch, and it uses <iostream.h> (because there wasn't an
<iostream> back then).

Realistically, a compiler vendor will have to drop it some time.
But I'd consider anything less than 20 years as irresponsible on
his part.

If I did get involved in something that used it, yes, I'd have
to pick my compiler with a different set of criteria. As it
is, <iostream.h> working is nowhere on my list. This is quite
different to a deprecated feature.

Not really. You have to choose your compiler according to your
specific needs. Period. None of the compilers I use are
conformant, so I have to adopt my code, still using old features
today. All of the compilers I use support threading (although
the standard doesn't), which is a good thing, because my
applications are multi-threaded. The standard is a good basis
to start with (or it would be, if the vendors didn't just ignore
whatever they felt like in it), but it's not everything. If a
compiler once supported <iostream.h>, realistically, it should
continue to do so for a significant time afterwards.

 

[Christopher Dearlove]

On Mar 17, 6:43 pm, "Christopher Dearlove"

That's because you're younger than I am.

Maybe, maybe not, I don't know how old you are. Now if you'd said
that's because you've not been using C++ for as long as I have, that
would have been true. But I did first write software before Bjarne
Stroustrup started C with classes (but I think he had started before
I got paid for any). Fortran however.

Realistically, a compiler vendor will have to drop it some time.
But I'd consider anything less than 20 years as irresponsible on
his part.

But if he's also a new kid on the block, only been selling C++
compilers for, say, a decade, then there's no reason for him to
have ever added it.

But in contrast consider this deprecated code

bool b = false;
++b;

Now even if this hypothetical compiler writer were releasing his
first working version tomorrow, he should still support that, as
it's still part of the standard. (But a warning would be good
practice.)

Not really. You have to choose your compiler according to your
specific needs. Period.

You say not really, but your comment says the same as mine. We
each pick our compilers according to our own criteria. Your criteria
have more backward compatibility issues than mine. (I didn't say I
don't have any.) If I had a different code base to support, my criteria
would change.

 

[Noah Roberts]

If I did
get involved in something that used it, yes, I'd have to pick my
compiler with a different set of criteria.

Or simply create the file. It's easy:

#include <iostream>

using namespace std;


Of course, the content of iostream.h is not standard so that may or may
not actually work for any EXTREMELY legacy code that uses it.

 

[James Kanze]

Maybe, maybe not, I don't know how old you are. Now if you'd
said that's because you've not been using C++ for as long as I
have, that would have been true. But I did first write
software before Bjarne Stroustrup started C with classes (but
I think he had started before I got paid for any). Fortran
however.

I wrote my first programs (admittedly, not as a professional)
somewhere around 1964. I don't think that there are many people
here whose experience goes back that far.

But you're right---what counts is that I have to deal with C++
code which is 15 or more years old. (Whether I was the one who
wrote it or not is really irrelevant. Although I do have some
C++ code that I wrote before 1990.)

But if he's also a new kid on the block, only been selling C++
compilers for, say, a decade, then there's no reason for him
to have ever added it.

True, but that's not the case for any of the vendors I know. In
fact, it depends on his target market. If he wants to capture
customers from other vendors, he might want to consider it.
Fully implementing a complete pre-standard <iostream.h> is a lot
of work, but some vendors do have a hacked version---the file
name is <iostream.h>, and it puts things like istream and
ostream in the global namespace, but the rest of the interface
is closer to the standard iostreams than to the classical ones.

In all cases, the issue of development costs must be considered.
If the vendor already has an implementation of <iostream.h>,
conform to the pre-standard defacto standard, it shouldn't be
too expensive to continue maintaining it; dropping it, or even
shifting to the hack above, is a bit irresponsible vis-a-vis his
clients. If a vendor doesn't have such, it's another issue.

Note that this affects a lot of things. I'm sure that most
vendors would prefer supporting pre-standard name lookup in
templates, to avoid breaking client code. But supporting two
completely different name lookups is expensive, and templates
weren't really that widely used before the standard was adopted,
so the trade offs are different.

But in contrast consider this deprecated code

bool b = false;
++b;

Now even if this hypothetical compiler writer were releasing
his first working version tomorrow, he should still support
that, as it's still part of the standard. (But a warning would
be good practice.)

Just because something is part of the standard doesn't mean that
vendors will implement it---look at export. In this case, you
can probably expect it because it is officially part of the
standard AND it is cheap to implement.

You say not really, but your comment says the same as mine. We
each pick our compilers according to our own criteria. Your
criteria have more backward compatibility issues than mine. (I
didn't say I don't have any.) If I had a different code base
to support, my criteria would change.

Yes. Most big companies do have some older code that they have
to maintain. But not necessarily everywhere.

 

[James Kanze]

Or simply create the file. It's easy:

#include <iostream>

using namespace std;

Of course, the content of iostream.h is not standard so that
may or may not actually work for any EXTREMELY legacy code
that uses it.

There was a de facto standard for the content of iostream.h, and
the above won't work in some specific cases. (I've actually
seen it fail, in several different ways.) Still, if you have no
other choice, it's better than nothing. But if you're reduced
to this, it's still a case of the vendor behaving irresponsibly
to his customer base.

 

[Christopher Dearlove]

Just because something is part of the standard doesn't mean that
vendors will implement it---look at export. In this case, you
can probably expect it because it is officially part of the
standard AND it is cheap to implement.

export is a special case. We all know (even if we don't admit it)
that the reality is that standard C++ without export is where the
language is practically at, and support was just about converging
on, plus extensions (some historic, some beyond the standard, such
as threads). export is in effect an extension that only one or two
compilers support (fewer, as you would probably point out,
than <iostream.h>).

Of course soon we'll be back in the world of significantly varying
support for the new standard. Probably in another ten years it'll
be clear what the effectively supported language is (i.e. if any of
the new features turn out to join export on the bench).

 

[Noah Roberts]

There was a de facto standard for the content of iostream.h, and
the above won't work in some specific cases. (I've actually
seen it fail, in several different ways.) Still, if you have no
other choice, it's better than nothing. But if you're reduced
to this, it's still a case of the vendor behaving irresponsibly
to his customer base.

Whatever.

 

[James Kanze]

export is a special case.

Why is it any different from anything else? Either the vendors
care about the standard (and implement export), or they don't.
Most don't.