Is it legal to have functions within functions?

Same question as above. Is it legal to have functions within functions, within functions, within functions, to the x power?

What do you mean by "have"? You can call a function from within a function but you can't decalare/initialise a function from a function.

What would be the point?

Quote:

---

Originally Posted by yaya

What do you mean by "have"? You can call a function from within a function but you can't decalare/initialise a function from a function.

---

I was asking basically what you just answered...i.e. if I could declare/initialise a function within another function.
Damn! That sucks...I was hoping I could.
The reason is, because I wanted to have a function (of "protected" status) inside a class, for the purpose of adding members to the class from outside the class, if you catch my drift...
I figured if I did something like this, it would work:

Code:

---

class main_window_form //declare a class for the main window of the form, which will store all of the different 'parts' of the main window
{
    public:
      main_window_form() //this will be the constructor of the class
      ~main_window_form() //this will be the desctructor for the class
    protected:
      char menu_bar; //declare variable to hold the *names* of the menus of the program, which will be clickable
      void add_members_to_class_function(void); //declare function of "protected" type of the class for the purpose of adding members to class

};
      //do not forget the trailing semi-colon

  main_window_form::main_window_form(add_members_to_class_function(void)) //modify prototype of named function in class
  { //BEGIN brace for add_members_to_class_function

    void function_to_declare_variables_of_class() //declare function within that function for the sole purpose of declaring variables
      {
      char menu_bar; //modify the "menu_bar" variable which is stored in the class as a private member
      char file_menu; //declare File menu variable (which will store the parts of the File menu visible to the user)
      char edit_menu; //declare Edit menu variable (which will store the parts of the Edit menu visible to the user)
      char slide_show_menu; //declare Slide Show menu variable (which will store the parts of the Slide Show menu visible to the user)
      char menu_bar_array[4]; //declare menu_bar array (for storing the menus, which will be three)
      }

---

The idea here was to have a hierarchy of functions, each of which I wanted to store inside the class called "main_window_form", but I was hoping if I wanted to add members to the class later on, I could have a function outside the class which could be used for that purpose, to keep my program as clean as possible, and readable. Now, I'm sure there's other ways to do that, but that's the first way that came to mind of how to accomplish it. But everyone feel free to offer your thoughts.

If you need to add variables to the class, then you can't use a function anyways, since the variables inside the function will disappear when the function returns.

The most obvious way to add variables to a class is to make a derived class, inheriting from the original class.

--
Mats

>Is it legal to have functions within functions, within functions, within functions, to the x power?
No, it's not legal if you want to do it directly:

Code:

---

#include <iostream>

int main()
{
    void foo()
    {
        std::cout<<"Foo!\n";
    }

    foo();
}

---

Can you do it? Yes, thanks to the magic of classes and operator overloading. And the result isn't much more verbose than the previous example:

Code:

---

#include <iostream>

int main()
{
    struct foo {
        void operator()()
        {
            std::cout<<"Foo!\n";
        }
    };

    foo()();
}

---

>What would be the point?
Limiting the scope of a function can be useful and adds flexibility in structuring your code. It's not much different conceptually from nested classes.

Quote:

---

Originally Posted by Prelude

>Is it legal to have functions within functions, within functions, within functions, to the x power?
No, it's not legal if you want to do it directly:

Code:

---

#include <iostream>

int main()
{
    void foo()
    {
        std::cout<<"Foo!\n";
    }

    foo();
}

---

Can you do it? Yes, thanks to the magic of classes and operator overloading. And the result isn't much more verbose than the previous example:

Code:

---

#include <iostream>

int main()
{
    struct foo {
        void operator()()
        {
            std::cout<<"Foo!\n";
        }
    };

    foo()();
}

---

>What would be the point?
Limiting the scope of a function can be useful and adds flexibility in structuring your code. It's not much different conceptually from nested classes.

---

Ok, so what you're saying basically is create a structure inside int main() and inside that structure create the other functions I need? Would the same technique work if the function was not int main()?
Also, I noticed you used double parentheses in the last example, i.e.

Code:

---

()()

---

instead of just

Code:

---

()

---

Why is that?

Quote:

---

Originally Posted by Programmer_P

Ok, so what you're saying basically is create a structure inside int main() and inside that structure create the other functions I need? Would the same technique work if the function was not int main()?

---

Yes.

Quote:

---

Also, I noticed you used double parentheses in the last example, i.e.

Code:

---

()()

---

instead of just

Code:

---

()

---

Why is that?

---

You first have to create an object (explicit constructor call, foo()) and then you can call the function call operator on it, so it's foo()().

That said, I wouldn't look kindly on such code. The correct way to privatize functionality is by putting it into its own file.

Quote:

---

Originally Posted by CornedBee

Yes.



You first have to create an object (explicit constructor call, foo()) and then you can call the function call operator on it, so it's foo()().

That said, I wouldn't look kindly on such code. The correct way to privatize functionality is by putting it into its own file.

---

Well, that's what I was already planning to do, i.e. have each major function in its own file, which I then include in the main source code file. But I was hoping I could have a function within the main.cpp file that would be part of the class "main_window_form" for the purpose of adding variables to the class.
I guess I'll have to try the method matsp suggested, i.e. use a derived class for adding variables.
Thanks everyone for your help. I really appreciate it. :)

Aside from the legality, a function can NEVER add variables to a class.

[At least not if we tgalk regular variables - you could of course make your own dynamic variables (e.g a map or vector storing pairs of "name" and "value"), but I doubt that is what you actually meant].

--
Mats

Ok, it seems I may have to forget the whole "add variables to class from outside the class" idea, and just add them the standard way, i.e. directly.
The reason I was wanting to do it was because I thought it might be more readable if I had most of the variables for the program I'm writing in its own block of code. But nevermind...that's what comments are for, I guess. So I can keep track of whatever the hell it is that I wrote so far, and not forget what I was thinking at the time that I wrote it. :D

Quote:

---

Originally Posted by Programmer_P

Ok, it seems I may have to forget the whole "add variables to class from outside the class" idea, and just add them the standard way, i.e. directly.
The reason I was wanting to do it was because I thought it might be more readable if I had most of the variables for the program I'm writing in its own block of code. But nevermind...that's what comments are for, I guess. So I can keep track of whatever the hell it is that I wrote so far, and not forget what I was thinking at the time that I wrote it. :D

---

That's what variable names are for imo

Quote:

---

Originally Posted by ಠ_ಠ

That's what variable names are for imo

---

That too. :D

Quote:

---

Originally Posted by cpjust

What would be the point?

---

We're not talking about standard C or C++, but nested functions are provided as an extension by several compilers. The point is two-fold. First, limitation of the scope of the name (which can be accomplished in other more standard ways, at least in C++).

Second is inheritance of the local scope itself. In all implementations of nested C/C++ functions I've seen, the inner function has access to the local variables of the outer function.

This imposes some strange requirements on the compiler. How do you pass a pointer to a nested function while still allowing access to the enclosing function's local variables? It's pretty awful, and involves writing code onto the stack.

IMO, the feature is simply not useful enough to justify 1) writing grossly nonstandard code and 2) forcing the stack to be executable just to implement a strange corner case.