next »

[muku]

How is that any different than just using a local object?

You have to declare the class first, that's a lot of boilerplate code. Especially if many of these uses are one-off things, you litter your code with classes which you don't really needed in the first place. Look at the example you posted further up: 14 lines for the Finalizer struct. If you want to execute just one line of code at the end of the scope, that's a hell of a lot of overhead.

[Average Software]

How is that any different than just using a local object?

You have to declare the class first, that's a lot of boilerplate code. Especially if many of these uses are one-off things, you litter your code with classes which you don't really needed in the first place. Look at the example you posted further up: 14 lines for the Finalizer struct. If you want to execute just one line of code at the end of the scope, that's a hell of a lot of overhead.

I guess I just don't understand the language then, what are acquire() and dispose()?

[muku]

I guess I just don't understand the language then, what are acquire() and dispose()?

Ah sorry, that's not part of the language. Those were just examples to illustrate a possible use. More real life example:

Code:

void main()
{
  SDL_Init();
  scope(exit) SDL_Terminate();

  // game main loop etc
}

[Average Software]

I guess I just don't understand the language then, what are acquire() and dispose()?

Ah sorry, that's not part of the language. Those were just examples to illustrate a possible use. More real life example:

Code:

void main()
{
  SDL_Init();
  scope(exit) SDL_Terminate();

  // game main loop etc
}

Ah, so it's like C's atexit() function, but locally scoped.

[muku]

Ah, so it's like C's atexit() function, but locally scoped.

Yup, you might say so, minus the runtime overhead (I imagine atexit() puts something into a table or list which has to be checked when the program exits, while scope() is completely static). Plus you get scope(success) and scope(failure) which trigger only when no exception/an exception occurs.

[Average Software]

I guess I just don't understand the language then, what are acquire() and dispose()?

Ah sorry, that's not part of the language. Those were just examples to illustrate a possible use. More real life example:

Code:

void main()
{
  SDL_Init();
  scope(exit) SDL_Terminate();

  // game main loop etc
}

Ah, so it's like C's atexit() function, but locally scoped.

As a point of interest, you could do the same thing in C++0x like so:

Code:

template <typename Callable>
struct ScopedCleanup
{
    ScopedCleanup(Callable &callable)
    :callable(callable)
    {
    }

    ~ScopedCleanup()
    {
        callable();
    }

    Callable &callable;
};

#define CALL_AT_EXIT(cleanup) ScopedCleanup<decltype(cleanup)> sc##cleanup(cleanup)

void funk()
{
    CALL_AT_EXIT(SomeFunction);

    // stuff
}

With C++0x variadic templates and C99/C++0x variadic macros, you could even attach parameters to them.

[Linus]

Each entry in the menu was a separate class

It strikes me that this was your real problem.

...That was uncalled for?
Each menu item is a disparate scene setup with different logic and structure, which is rendered in an off-screen buffer to a quad texture and displayed in the menu. Moving to a scripting language, which could allow me to merge the scenes into a single class, is not an interesting option as of now either, since there's too much work involved in such a move.
Can you still uphold your baseless statement?

In a more relevant discussion, boost also has some nice examples of scoped features, most prominently I like their scoped mutex implementations that also come in recursive versions that add another level of 'Oooh'.

At the same time, they also have a completely different solution to on scope exit where they use a macro to build the previously mentioned classes, with the added differentiation that you specify the code to execute on exit in place, rather than in an external function. May suit some tastes.

[Jonathan Whiting]

Each entry in the menu was a separate class

It strikes me that this was your real problem.

...That was uncalled for?
Each menu item is a disparate scene setup with different logic and structure, which is rendered in an off-screen buffer to a quad texture and displayed in the menu. Moving to a scripting language, which could allow me to merge the scenes into a single class, is not an interesting option as of now either, since there's too much work involved in such a move.
Can you still uphold your baseless statement?

I'm sorry, I have an impulsive dislike of OOP 'tricks' like the ones you described in the initial post (in a similar vein I prefer straight C to C++, though I use both).  I pretty strongly believe that when you start trying to answer complicated architecture questions as above you should step back and start asking why you've reached that point in the first place.

I genuinely didn't mean to cause offense, just to point out the area that to me the assumptions looked shakier than the solution.  I was overly blunt.  Sorry again.

[BorisTheBrave]

Each menu item is a disparate scene setup with different logic and structure,

I think that's the source of confusion. When I think of menu's I think homogenous buttons, for which classes are inappropriate.

[Jonathan Whiting]

Each menu item is a disparate scene setup with different logic and structure,

I think that's the source of confusion. When I think of menu's I think homogenous buttons, for which classes are inappropriate.

Yes, that was certainly the mental image that it conjured for me.

[Linus]

I'm sorry, I have an impulsive dislike of OOP 'tricks' like the ones you described in the initial post (in a similar vein I prefer straight C to C++, though I use both).  I pretty strongly believe that when you start trying to answer complicated architecture questions as above you should step back and start asking why you've reached that point in the first place.

I genuinely didn't mean to cause offense, just to point out the area that to me the assumptions looked shakier than the solution.  I was overly blunt.  Sorry again.

Hah, I get your point, no worries.
The factory in itself isn't all that uncommon though, and as I understand, it often implies building a list of factory entries in some place. I just wanted to see if it was possible to skip that step, which was, to my surprise, successful.
The previous solution I had was simply building the menu in-place:

Code:

menu.addEntry(new Scene1());
menu.addEntry(new Scene2());
//...
menu.addEntry(new SceneN());

Pretty much an equivalent solution, but I had a few different reasons to move to a factory in the first place. Most prominently, things like setting a starting scene in a configuration file to skip recompilation.

@BorisTheBrave:
Truth. It's not a very common setup I'm using. The program is basically a test bench for my thesis project where I do a lot of different rendering setups to test stereo and head tracking. The menu gave me an excuse to do both with portals.