Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411977 Posts in 69438 Topics- by 58486 Members - Latest Member: Fuimus

June 15, 2024, 02:22:05 PM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsDeveloperTechnical (Moderator: ThemsAllTook)Playing it silly with Singleton and static
Pages: 1 [2]
Print
Author Topic: Playing it silly with Singleton and static  (Read 4393 times)
muku
Level 10
*****


View Profile
« Reply #20 on: June 24, 2010, 08:41:47 AM »

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.
Logged
Average Software
Level 10
*****

Fleeing all W'rkncacnter


View Profile WWW
« Reply #21 on: June 24, 2010, 08:57:51 AM »

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()?
Logged



What would John Carmack do?
muku
Level 10
*****


View Profile
« Reply #22 on: June 24, 2010, 09:01:42 AM »

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
}
Logged
Average Software
Level 10
*****

Fleeing all W'rkncacnter


View Profile WWW
« Reply #23 on: June 24, 2010, 09:04:27 AM »

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.
Logged



What would John Carmack do?
muku
Level 10
*****


View Profile
« Reply #24 on: June 24, 2010, 09:11:55 AM »

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.
Logged
Average Software
Level 10
*****

Fleeing all W'rkncacnter


View Profile WWW
« Reply #25 on: June 24, 2010, 09:12:35 AM »

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.
« Last Edit: June 24, 2010, 09:23:39 AM by Average Software » Logged



What would John Carmack do?
Linus
Level 0
***


View Profile
« Reply #26 on: June 27, 2010, 11:48:55 PM »

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. Shrug
Logged
Jonathan Whiting
Level 2
**



View Profile WWW
« Reply #27 on: June 28, 2010, 01:06:36 AM »

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.
Logged

BorisTheBrave
Level 10
*****


View Profile WWW
« Reply #28 on: June 28, 2010, 12:36:33 PM »

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.
Logged
Jonathan Whiting
Level 2
**



View Profile WWW
« Reply #29 on: June 28, 2010, 11:13:39 PM »

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.
Logged

Linus
Level 0
***


View Profile
« Reply #30 on: June 28, 2010, 11:22:11 PM »

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. Shrug

@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. Cool
Logged
Pages: 1 [2]
Print
Jump to:  

Theme orange-lt created by panic