Resize the array

[mrsh]

hi, i need help in resizing size of array. I have two dimensional array which is i write as

[code]
 for (i = 0; i < M; i++)
	{
		for (j = 0; j < M; j++)
		{
			if (i + j <= KMAX)
			{


				cout << "InitialPopulation[" << i << "][" << j << "]=" << InitialPopulation[i][j] << endl;


			}
		}
	}

the result is

InitialPopulation[0][0]=1.0000
InitialPopulation[0][1]=0.0000
InitialPopulation[0][2]=0.0000
InitialPopulation[1][0]=0.0000
InitialPopulation[1][1]=0.0000
InitialPopulation[2][0]=2.0000

how can i edit or change so that the array is like this

InitialPopulation[0][0]=1.0000
InitialPopulation[1][0]=0.0000
InitialPopulation[2][0]=0.0000
InitialPopulation[3][0]=0.0000
InitialPopulation[4][0]=0.0000
InitialPopulation[5][0]=2.0000

here is my full code

#include <stdio.h>

#include <iostream>
#include <fstream>
#include <math.h>
#include <conio.h> //===define getch
#include <iomanip>
#include <fstreaM>
#include <string>
#include <map>
#include <random>
#include <chrono>
#include <vector>



#define m 3
#define N 10    //===number of cells



using namespace std;


void main()

{
	int i, j,max,count;
	

	int a[m];
	int freq[100];
	

	cout.setf(ios::fixed);
	cout.precision(4);

	//===value of X-axis===========

	double X_axis[m];
	for (i = 1; i <= m; i++)
	{
		X_axis[i] = ((i - 1) / 4.0);
		
	}

	//===random number follow poisson distribution=========

	cout << "some Poisson-distributed results:" << endl;

	unsigned seed = std::chrono::system_clock::now().time_since_epoch().count();
	std::default_random_engine generator(seed);
	std::poisson_distribution<int> distribution(2 * X_axis[m]);

	int KMAX;

	for (i = 0; i < m; ++i)
	{
		a[i] = distribution(generator);
		
	}

	//=======maximum number of DSB===========

	max = a[1];
	for (int i = 0; i < m; ++i)
	{
		if (max <= a[i])
			max = a[i];
		KMAX = max;

	}


	//-------------------- count frequency of a[i]----------------------


	for (i = 0; i<m; i++)
	{
		count = 1;
		for (j = i + 1; j<m; j++)
		{
			if (a[i] == a[j])
			{
				count++;
				freq[j] = 0;
			}
		}

		if (freq[i] != 0)
		{
			freq[i] = count;
		}
	}


	//-------------Initial Population-----------------
	int M = ((KMAX + 1)*(KMAX + 2)) / 2;

	vector <double> IP(M, 0);
	vector < vector <double> >InitialPopulation(M, IP);



	for (i = 0; i < m; i++)
	{
		if (freq[i] != 0)
		{
			InitialPopulation[a[i]][0] = freq[i];

		}
	}


	cout << "Vector of Initial population" << endl;



	for (i = 0; i < M; i++)
	{
		for (j = 0; j < M; j++)
		{
			if (i + j <= KMAX)
			{


				cout << "InitialPopulation[" << i << "][" << j << "]=" << InitialPopulation[i][j] << endl;


			}
		}
	}







	_getch();

}

[TheIdeasMan]

hi, i need help in resizing size of array. I have two dimensional array which is i write as

You can't resize an array. Consider using a std::vector instead, they were invented to fix problems with arrays.

Other problems with your code:

Don't use conio.h it's not standard, there are other ways of keeping the window open at the end. Look at the stickied post on the beginners forum.

Don't use defines, make them const variables instead.

Avoid using namespace std; it will bite you on the ass one day, so may as well fix it now. Put std:: before each std thing - believe me, it's the easiest thing n the end.

It's int main , not void main.

You need to make use of functions, your comments show quite well what should be in a function.

This:

double X_axis[m];
	for (i = 1; i <= m; i++)
	{
		X_axis[i] = ((i - 1) / 4.0);
		
	}

Misses the first item in the array. Arrays start at zero, so the for loop should too:

for (i = 0; i < m; i++)

Good Luck !!

[xxvms]

TheIDeasMan - what is the reason why don't recommend using namepace std?
Did you experience issues with this?

thanks :)

[TheIdeasMan]

Hi,

TheIDeasMan - what is the reason why don't recommend using namepace std?

You can Google this, there is plenty written online about it, at this website, Stack Overflow etc.

Ideally one should put their own code in it's own namespaces :+)

[Alex1993]

I'll tell you in short why namespace std; may become problematic. You do not have any issues now because your program is not that long but when you use "using namespace std" you dump some function in the global space. In the future you may use more than one library and you will have function A in library 1 and function B in library 2 and everything will be fine. However, one day library 1 is upgraded to include function A and function B. Now you call function B from both libraries and here is where you will get a conflict. I know the explanation is not rigorous, but it should be clear why std::cout std::cin etc. is preferred by many.

[jonnin]

#define cout std::cout

:P

seriously though, something went way wrong somewhere that you have to type std:: a billion times a day. There has to be a better answer than that, whether at the c++ standards committee level or a clever work around.

[gunnerfunner]

something went way wrong somewhere that you have to type std:: a billion times a day.

jonnin – you are, of course, entitled to your opinion but consider how much flexibility a bit of added typing provides in allowing programmers to give their functions whatever name they want without checking a central database, as such, if that name's already taken and also use external libraries etc
http://stackoverflow.com/questions/1452721/why-is-using-namespace-std-considered-bad-practice
what might be an alternative that would retain current flexibility && do away with typing std::?

[xxvms]

Gunnerfunner - yes true, but... (wait for it.. ;P)

1. Mr Bjarne Stroustrup uses as default entry namespace std; in his book(s).
2. Is that not the point of having SLT? so such basic part of language is covered?

going to extreme end something something always could go wrong and the best way is to write in such a way that this will not be the case. However, that would lead to situation that only safe way to write is in assembler as machine code. As this is the part that does not change no matter what, right?

or I can simply be wrong ;) bearing in mind that I am not developer just the begginer (not sure if I could even use developer and my name in same line .... yet.)

[gunnerfunner]

Mr Bjarne Stroustrup uses as default entry namespace std; in his book(s).

xxvms – it doesn't matter what Stroustrup may or may have done in textbook(s) and I haven't read the book(s) carefully enough to check if he's done so only with a caveat in the preface or a footnote.
the reasons are spelt out clearly in the link I'd sent out earlier and it's here once again for reference:
http://stackoverflow.com/questions/1452721/why-is-using-namespace-std-considered-bad-practice
you're, of course, welcome to include n'space std in your programs if you wish to but be aware of the inherent risks of doing so

[48T7M4Gy]

#define cout std::cout
There has to be a better answer than that, whether at the c++ standards committee level or a clever work around.

There is a better workaround and that is using std::cout

The general view emerges that after a while of doing that just using std:: everywhere is quicker and easier.

Stroustrup comments in criticism he received over using namespace std in his textbooks that prefixing std:: didn't add to readability https://isocpp.org/blog/2013/01/stroustrups-tour-of-c-third-chapter-posted so it is an editorial choice and not a dis-endorsement of the recommended practice for all the reasons given above.

See also https://isocpp.org/wiki/faq/coding-standards#using-namespace-std

[xxvms]

Gunneffunner and Kemort

thanks for your time and reply.
I think this is one of the how long is the string questions ;) no relation to string type ;)

It sounds that there is same amount good reasons to use namespace std as good reason why not to.

for as beginner less typing makes code easier to read, on the other hand I like argument used in one of the links provided by kemort:

Here, it's obvious that "compose" doesn't come from the standard library (since the "compose" function is defined right there, just before its use), but in general the std:: prefix helps to distinguish between standard library (std::) / core language (no prefix) / user-defined (lib-maintainer/dev-chosen-prefix::) names at a quick glance.

It might be especially helpful for the beginners who are still trying to learn what the standard library offers (and thus won't be able to tell whether "compose" is a user-defined function or something from the standard C++).

this argument makes sense to me, in this example it gives me extra information which can be useful, and save time or trouble when there is a problem.

so once again thank you for the advise.

[mbozzi]

It sounds that there is same amount good reasons to use namespace std as good reason why not to.

No.

Importing namespaces introduces the potential for a third party to make silent changes to your program's behavior at the whim of the implementation.
It is extremely difficult to justify importing namespaces in all but the most limited cases.

[JLBorges]

Sutter and Alexandrescu in 'C++ Coding Standards: 101 Rules, Guidelines, and Best Practices'

Don't write namespace usings in a header file or before an #include.

Summary
Namespace usings are for your convenience, not for you to inflict on others: Never write a using declaration or a using directive before an #include directive.
Corollary: In header files, don't write namespace-level using directives or using declarations; instead, explicitly namespace-qualify all names. (The second rule follows from the first, because headers can never know what other header #includes might appear after them.)

Discussion
In short: You can and should use namespace using declarations and directives liberally in your implementation files after #include directives and feel good about it. Despite repeated assertions to the contrary, namespace using declarations and directives are not evil and they do not defeat the purpose of namespaces. Rather, they are what make namespaces usable.
...
But using declarations and directives are for your coding convenience, and you shouldn't use them in a way that affects someone else's code. In particular, don't write them anywhere they could be followed by someone else's code: Specifically, don't write them in header files (which are meant to be included in an unbounded number of implementation files, and you shouldn't mess with the meaning of that other code) or before an #include (you really don't want to mess with the meaning of code in someone else's header).

Having quoted that, let me quote this too (from the LLVM Coding Standards):

In implementation files (e.g. .cpp files), the rule is more of a stylistic rule, but is still important. Basically, using explicit namespace prefixes makes the code clearer, because it is immediately obvious what facilities are being used and where they are coming from. And more portable, because namespace clashes cannot occur between LLVM code and other namespaces. The portability rule is important because different standard library implementations expose different symbols (potentially ones they shouldn't), and future revisions to the C++ standard will add more symbols to the std namespace. As such, we never use 'using namespace std;' in LLVM.

[48T7M4Gy]

And here's what cppreference notes at http://en.cppreference.com/w/cpp/language/namespace which is another cut on the same theme.

Notes

The using-directive using namespace std; at any namespace scope introduces every name from the namespace std into the global namespace (since the global namespace is the nearest namespace that contains both std and any user-declared namespace), which may lead to undesirable name collisions. This, and other using directives are generally considered bad practice at file scope of a header file.

[gunnerfunner]

Sorry xxvms, I'm afraid you've brought the heavy artillery upon yourself (I know the feeling!) but, rest assured, once you pick up good coding practices as suggested these will help you tremendously to become a better, more thoughtful programmer. Stay tuned and good luck!

[48T7M4Gy]

Don't feel alone though, when it was first pointed out to me I stuck with using namespace std for a long time until I took the plunge after people said it becomes second nature, which it std::does. Sometimes it's so second nature I don't even know I'm doing it.

I must admit though Stroustrup is right, std:: everywhere makes the code look pretty much unreadable for a simple learning type program..

[xxvms]

JLBorges, Kemort and GunnerFunner :) and of course Mobzzi

In short your answers are overwhelming ;)
I am not writing this to be arrogant or know all approach. However, speaking not from my developer experience but from common sense (ie playing devils advocate)
C++ is or was created as C with classes to improve on existing language, so following this logic its a reasonable argument to that if something is in SLT its in order to help and makes people life easier.
I hear your argument that its perfectly feasible situation where 2 libraries will have conflicting functions, which is hard to predict, there is no easy way to check that someone somewhere creates new version or new library and will use exactly same name as I in mine but....

if something is in SLT should that have special status ie "protected" so if I develop library I must follow rules of not using same function names and its my responsibility to keep my library compatible with SLT??

:)
speak your mind :)

[48T7M4Gy]

I think the point about (not) using namespace std:: is due to the widespread and vast nature of std:: functionality especially if it is used in a header rather than the reverse situation where a custom library is produced. Of course if that custom library becomes part of std:: then off we go again

Decide for yourself and your development team what is the best course of action. Whatever it is hopefully you have a clear(er) understanding why it is not good practice as a general rule.

BTW Is it SLT or STL-standard template library?

[JLBorges]

> if something is in SLT the standard C++ library should that have special status
> ie "protected" so if I develop library I must follow rules of not using same function names
> and its my responsibility to keep my library compatible with SLT the standard C++ library??

Trying to avoid names in the namespace std in our code is not a feasible proposition because of two reasons:

a. The namespace std contains a very large number of names; keeping track of all those names at all times would induce an unacceptable programmer overhead.

b. As pointed out earlier, "future revisions to the C++ standard will add more symbols to the std namespace"
For example, a perfectly usable name like lock was not part of namespace std before C++11.

The only sane solution when we develop libraries is:

[1] Use namespaces to express logical structure; §14.3.1.
[2] Place every nonlocal name, except main() , in some namespace; §14.3.1.
[3] Design a namespace so that you can conveniently use it without accidentally gaining access
to unrelated namespaces; §14.3.3.
[4] Avoid very short names for namespaces; §14.4.2.
[5] If necessary, use namespace aliases to abbreviate long namespace names; §14.4.2.
[6] Avoid placing heavy notational burdens on users of your namespaces; §14.2.2, §14.2.3.
[7] Use separate namespaces for interfaces and implementations; §14.3.3.
[8] Use the Namespace::member notation when defining namespace members; §14.4.
[9] Use inline namespaces to support versioning; §14.4.6.
[10] Use using-directives for transition, for foundational libraries (such as std ), or within a local
scope; §14.4.9.
[11] Don’t put a using-directive in a header file; §14.2.3.

Stroustrup in 'The C++ Programming Language (Fourth Edition)'

[mbozzi]

@xxvms, Thanks for not taking our (my) criticism personally. It's not, I promise. I'm sorry if my response came off as rude.

In my opinion, using declarations and namespace aliases are perfectly sufficient to "make namespaces usable", and so I'll continue qualifying names in even my own code, even if at some point this is just my opinion.

It seems like the real solution to the problem would be to introduce a notion of "packages" to the language, or some other mechanism which will make visible only a particular list of symbols that comprise the interface of some library. Such a solution would allow the compiler to diagnose name collisions between different packages.

There are some significant problems with that idea, though, because overload matching is complicated. Still, IIRC, there was a proposal for something similar a few years ago, but I couldn't find it.

Note:
Technically, the Standard Template Library (the STL) is (or was) different from the C++ standard library:
https://www.sgi.com/tech/stl/
The C++ standard library is based upon the original STL, which was developed at SGI. In my experience, everyone knows that you mean the C++ standard library if you just say "STL". Probably the meaning of the acronym has changed, but who am I to say?