I'm writing a program to count how many solution there is in the Eight Queens puzzle, I defined an array in the main function, and tried to use function to check them, but the array is not defined in the function. Is there a way that I can let the function to read the array in the main function?
Thanks,
Roger
> Is there a way that I can let the function to read the array in the main function?
Sure... just pass the array along with its size to the function.(size nor required if it is an std::array)
If you aren't sure about how to do that...read up more on function calls.
Make use of a function parameter :)
Passing size is evil! We can let the compiler do it for us:Quote:
Originally Posted by manasij7479
Code:#include <iostream>
template<size_t N>
void foo(int (&bar)[N])
{
std::cout << N << std::endl;
}
int main()
{
int bla[50];
foo(bla);
}
Why ?Quote:
Originally Posted by Elysia
Showing templates so soon is the fastest way to scare beginners away from C++.
And do you really want a specialized version of your function for each possible array size?
What if the size is determined at runtime?
Because beginners make mistakes. Like not passing in the proper correct size.Quote:
Originally Posted by manasij7479
It also lessens the need to manually pass in the size (which is errorprone) and have the compiler handle that job. We always want the compiler to handle as much stuff as possible.
This template, I think, is hardly enough to scare people away. When you really get into template classes, that's where you scare people away, I think.
As for the first, I don't see a problem unless you really find out it's a bottleneck.Quote:
Originally Posted by CornedBee
If the size is determined at runtime, you're better off using std::vector.
(Almost) Agreed ...but...Quote:
Originally Posted by Elysia
You're starting to exhibit symptoms of the Steve Jobs Syndrome !
Why would you say such a thing?
*User doesn't need to know anything*Quote:
Originally Posted by Elysia
*User isn't allowed to change anything*
*Let (*this) handle everything...(and/or) take credit for it.*
Analogous to
[(>Why?)Because beginners make mistakes]
Templates fix everything at compile time.
[...want the compiler to handle as much stuff as possible]
What I dislike about Steve is that he takes away freedom from people and treat them like dumb idiots who needs to be put in place. I also dislike how they are abusing their position to use bully competitors.
This is different from what symptoms I exhibit.
I don't take away people their choice. They can do what they want. I provide a solution, perhaps not always the best. I never condone to robbing people the freedom of choosing solutions or tools.
I don't treat people as things that need to be put in place. People make mistakes. Mistakes can cause grief, cost money or cause inconvenience to others. Therefore, I teach methods that minimize the amount of bugs that occur in code. This is not treating people as dumb; we all make mistakes, and the more we can abstract that, the better.
I'm not sure I understand. With respect to fixed size arrays:Quote:
Originally Posted by Elysia
The compiler handles this code too, and I made it so it cannot be changed.Code:const size_t mysize = sizeof somethings / sizeof somethings[0];
/* or... */
foo(somethings, sizeof somethings / sizeof somethings[0]);
Is the template really even necessary?
I will admit that passing size that way (if you know how to) is not much more difficult or errorprone (unless you change variable name and forget to change that statement!).
Still, it is something of an eyesore, you will have to admit.
Instead you can shift it to your declaration and hide it from view (and also eliminates the possibilities of errors with passing in incorrect size).
Mostly, using C-style arrays is just plain dumb unless there is a special reason for it. One should generally keep to the containers.
So, to summarize: it is slightly less errorprone to do it that way and other than that, it's a matter of style.
I don't change variable names that often but if I need to I would have my editor help me. I don't agree with bringing in a complex feature when there is something easier to use available. To wit, I'm not sure how much help it is when you have to explicitly instantiate the template. So really, saying that you've moved the problem to the template is the way to look at it.Quote:
I will admit that passing size that way (if you know how to) is not much more difficult or errorprone (unless you change variable name and forget to change that statement!).
Still, it is something of an eyesore, you will have to admit.
Instead you can shift it to your declaration and hide it from view (and also eliminates the possibilities of errors with passing in incorrect size).
I would say that considering a division statement to be an eyesore is a matter of your style.Quote:
So, to summarize: it is slightly less errorprone to do it that way and other than that, it's a matter of style.
Well... I use C Style arrays only in analogy to pointers (...otherwise..nothing beats std::vector or std::array !)
That is why I brought up passing size in the first place.
Explicitly instantiate?Quote:
Originally Posted by whiteflags
The above example I posted clearly shows how to use it and how it's more fool-proof than passing in size.
What do you mean?Quote:
Originally Posted by manasij7479
Mm, well I'm not sure it still works if what you pass is an alias.Quote:
Originally Posted by Elysia
Well, obviously, this kind of thing won't work:
But as long as you keep the type information through proper references, it will work.Code:#include <iostream>
template<size_t N>
void foo(int (&bar)[N])
{
std::cout << N << std::endl;
}
int main()
{
int bla[50];
int* r = bla;
foo(*r);
}
Though, I am not entirely sure of what scenario you had in mind.
>Well... I use C Style arrays only in analogy to pointers...
>>What do you mean?
Foo* foo = new Foo[n];
But what was your point? How do you relate it to the ongoing discussion?
You can't use templates in this scenario...and need some stuff created on the heap...(So.. using containers would be a bit kludgy here)Quote:
Originally Posted by Elysia
I stated it before the ongoing discussion about instantiating the function explicitly.
But you can use std::vector. So why don't you?
Eyesore ...your logic ! :DQuote:
Originally Posted by Elysia
vsCode:Foo* foo = new Foo[n];
Code:std::vector<Foo>* vfoo = new std::vector<Foo>();
vfoo->reserve(n);
vector as well as most STL containers (except array in fact) use the heap.
You want an array of n elements, so why don't you just doQuote:
Originally Posted by manasij7479
std::vector v(n);
Or just push n items into a vector?
Why the need for new at all?
Are you sure about that ?Quote:
Originally Posted by whiteflags
Then why is it said that C++ does not automatically manage memory ?
(I've almost never delete `d a container....and AFAIK..that is a common practice)
C++ does not manage memory in the sense that what you new, you must delete (though there are tools that help you do that, such as smart pointers).
If you use containers, they manage that memory for you. There is almost never any need to allocate a container on the heap.
I didn't know...and am still sceptical ..that std::vectors are created on the heap.Quote:
Originally Posted by Elysia
std::vector and almost all other containers need to dynamically allocate memory. Hence, the data they store is often allocated on the heap. The vector itself is up to you to place (ie, on the stack or the heap).
When there is?Quote:
Originally Posted by Elysia
Suppose...
As of my current project: I have a class that privately stores a std::vector of std::map `s ...of which 3 Global Objects are declared to be used from all the other modules somewhat like environment variables.
Whenever I am adding a map to one of those, I'm allocating ..and then passing its value to the relevant function to 'push' it.
I'm not sure.. but would it work if I just create a map and pass it ?
Are you asking if you can push a map into a vector?
A simple code example might help. It's difficult interpreting what you are asking.
Consider the 'scope' class from here:Quote:
Originally Posted by Elysia
http://cboard.cprogramming.com/cplus...ate-error.html
I have some global objects of that type.
Wouldn't it be bad to do the following and expect the map at the back() to be valid at a different scope?
Code:std::map<std::string,std::string > m = {{"foo","bar"},{"xip","bas"}};
global_object.new_local(m);
No.
Why? Because a vector follows an invariant. Whatever you push into that vector must be valid until that element is destroyed or the vector is destroyed.
Since you push a map into it, it will remain valid until one of those conditions are met.
This is implemented by a container copying whatever you push into its own storage (hence you need proper copy semantics).
This is no different from when pushing integers or strings into a vector.
Beware of pointers, though. Since the value is copied, only the pointer's value persists.
If you delete what it points to, the pointer will point to an invalid object. But that is a user error, not an error in the vector invariant. It does its job as it should.
Thanks.. that makes my work a bit simpler.
(Any special kind of copy/move bug I've to be aware about when changing dynamically containers to 'normal' ones ...in this case ?)
As in ... changing vector * myvec to vector myvec or std::vector<T*> to std::vector<T>?
If the later, just be aware that copies of your objects will be made. To gain efficiency, use move semantics.
Yes I am.Quote:
Originally Posted by manasij7479
Because it still does not manage memory. STL uses an allocator: there are a few standard ones such as alloc.Quote:
Then why is it said that C++ does not automatically manage memory ?
(I've almost never delete `d a container....and AFAIK..that is a common practice)
The only exception that I know about is std::array, which can be implemented in such a way that it has a do-nothing destructor.