Does this look alright?(Representing variable scope on a stack)

HAI
I HAS A QUESTION

I'm trying to write a small && simple interpreter..of a lisp like language (Almost complete!)..and the following is what I'd build variable and symbol scopes on.
Any noticeable problem ?

Code:

---

namespace mm
{
    template<typename T>
    class scope
    {
        std::vector< std::map<std::string,T> > data;
    public:
        T* find(std::string s)
        {
            for(auto m=data.rbegin();m!=data.rend();m++)
            {
                auto p = (*m).find(s);
                if(p!=(*m).end())return &((*p).second);               
            }
            return nullptr;
        };
        void new_local(std::map<std::string,T> sm){data.push_back(sm);};
        void exit_scope(){data.pop_back();};
    };
}

---

Can the pointer returning be avoided ?
(Other than exceptions...since it'd complicate the error handling too much..Most running code will already be within some try `s)

PS: The following demonstrates my goal (It seems achieved..for now)

Code:

---

int main()
{
    mm::scope<int> s;
    std::map<std::string,int> s1 = {{"Hey",42},{"Foo",84}};
    std::map<std::string,int> s2 = {{"Buddy",43},{"Bar",85}};
    s.new_local(s1);s.new_local(s2);
    std::cout<<*s.find("Foo");
    return 0;
}

---

KTHXBYE

Firstly, how about you stop using the horrible (*p). syntax and go with the much cleaner p-> syntax?

You can also remove the extra semicolons after the function bodies.

Pass containers and strings that you don't need to modify by const-reference, not by value.

Quote:

---

Originally Posted by iMalc

Firstly, how about you stop using the horrible (*p). syntax and go with the much cleaner p-> syntax?

You can also remove the extra semicolons after the function bodies.

Pass containers and strings that you don't need to modify by const-reference, not by value.

---

Oh.. I didn't know iterators overloaded -> too. Thanks for pointing that out.
Ok.
Forgot to do so.

You can avoid returning pointers by returning an iterator. That is how the standard library does it.

Quote:

---

Originally Posted by Elysia

You can avoid returning pointers by returning an iterator. That is how the standard library does it.

---

Good idea.. didn't think of doing that.

Quote:

---

Originally Posted by Elysia

You can avoid returning pointers by returning an iterator.

---

I wouldn't do that in this case. Returning a map iterator leaks some information about the internals of this class, i.e. the fact that it uses a map internally.

It also means that if you change how things are stored inside this class then you are probably going to break the code that uses it because you're changing the interface. However, I guess he's already passing in a map so it's unlikely to change structure internally.

Lastly, it's very difficult to do this correctly by returning an iterator unless you throw an exception when the item is not found. This is because the first step after calling find and getting back an iterator would be to compare the iterator against the end() of something. It has to be compared against the end() from the correct internal map that the data came from because you can't compare iterators from different containers. So unless your find function also passes out the end of the correct map (e.g. as a std::pair), then you're stuck with what to compare it to.
Basically don't try to do this if the iterator being returned could be from more than one possible container.

Quote:

---

Originally Posted by iMalc

I wouldn't do that in this case. Returning a map iterator leaks some information about the internals of this class, i.e. the fact that it uses a map internally.

It also means that if you change how things are stored inside this class then you are probably going to break the code that uses it because you're changing the interface. However, I guess he's already passing in a map so it's unlikely to change structure internally.

Lastly, it's very difficult to do this correctly by returning an iterator unless you throw an exception when the item is not found. This is because the first step after calling find and getting back an iterator would be to compare the iterator against the end() of something. It has to be compared against the end() from the correct internal map that the data came from because you can't compare iterators from different containers. So unless your find function also passes out the end of the correct map (e.g. as a std::pair), then you're stuck with what to compare it to.
Basically don't try to do this if the iterator being returned could be from more than one possible container.

---

I think you're going off the wrong tangent here.
Returning some map's iterator isn't a good idea, sure....but making this class' own iterator probably is.
I did something like that for a linked list a week ago... and it worked nicely.
(Here the iterator would traverse the various pair `s is the correct order ...and return a reference to 'second' )

Quote:

---

Originally Posted by manasij7479

I think you're going off the wrong tangent here.
Returning some map's iterator isn't a good idea, sure....but making this class' own iterator probably is.
I did something like that for a linked list a week ago... and it worked nicely.
(Here the iterator would traverse the various pair `s is the correct order ...and return a reference to 'second' )

---

I simply don't know what you'd want to do that for. When really are you ever going to want to iterate over anything it returns, given what this is meant for? Anything that needs to iterate over the contents of that vector and its internal maps should probably belong to that class.
It seems to me that you'd just add overhead and complexity for something that ultimately wan't useful.

> When really are you ever going to want to iterate over anything it returns, given what this is meant for?
Maybe...Suppose I need to find a global variable that shares the same name with a local one..
Making methods sounding like find_last_of_if_exists() ...will be much more complicated that a iteration from begin() to before end()

>It seems to me that you'd just add overhead and complexity for something that ultimately wan't useful
I'd just stick with pointers then..