Do I need a singleton here? Or can I use std::move

[Jim Langston]

I am developing a font class for my opengl graphics library and I came
across a quandry. I have a font which is simply a value for font id and
wrapper code to load the font and kill it. Works fine, then I notice I
don't have a virtual destructor, nor any destructor at all. So I throw in a
virtual destructor and call the code to unload the glfont. I run the
program, now no fonts are visible.

The problem is that my fonts are stored in a map by font name and the font,
and of course std::maps along with most containers use copy.

I've been bitten by this before and wound up using pointers so I could
control when the destructor was called. This was okay since polymophism was
involved and I needed pointers anyway.

I thought about using some variant of a smart pointer but I would still be
working with pointer logic.

My next idea was to use some variant of the singlton pattern which in
implementation I wouldn't be using it more than a smart pointer anyway.

I have heard somethign about std::move being in 0x and that std::vector and
other containers were supposed to use std::move instead of copy. But if
that was the case I wouldn't be having this problem.

Any suggestions? I am willing to use any feature of 0x that Express 2010
uses.

 

[Jorgen Grahn]

I am developing a font class for my opengl graphics library and I came
across a quandry. I have a font which is simply a value for font id and
wrapper code to load the font and kill it. Works fine, then I notice I
don't have a virtual destructor, nor any destructor at all. So I throw in a
virtual destructor and call the code to unload the glfont. I run the
program, now no fonts are visible.

The problem is that my fonts are stored in a map by font name and the font,
and of course std::maps along with most containers use copy.

Put differently: the problem is that you provided a copy constructor
and/or operator=() for something that wasn't really copyable. Always
consider if those should be disabled for new classes you write.

I can't comment on the rest, except I don't see why you want run-time
polymorphism for a font handle class.

/Jorgen

 

[Yakov Gerlovin]

If I understand correctly, the only data your wrapper (font) class
contain is a font id. In this case, returning a font instance by
value, for example, would seem perfectly valid. When an object is
returned by value a copy constructor and destructor are called, so it
doesn't look logically correct to unload glfont in wrapper's
destructor.

I would suggest to unload the font when it is removed from the map you
mentioned.
May be subclass the map and load the glfont when a new (id,name) pair
is added and unload glfont when the pair is removed.

Singletons can't be stored in map (as it is a map requirement,among
others, a default constructor for the objects), so you can only put a
pointer to your singleton.

 

[Jim Langston]

Put differently: the problem is that you provided a copy constructor
and/or operator=() for something that wasn't really copyable. Always
consider if those should be disabled for new classes you write.

Actually: How can I use a non-copyable class in a standard container?

The problem is that the class can't be copied, at least as it is, because of
the destructor, but containers are loaded by copy. This problem is common
enough that, as I understand it, in C++0x the std containers will use
std::move instead of copy. Then I could simply disable the copy constructor
(create one and make it private).

I can't comment on the rest, except I don't see why you want run-time
polymorphism for a font handle class.

I don't.

 

[Jim Langston]

If I understand correctly, the only data your wrapper (font) class
contain is a font id. In this case, returning a font instance by
value, for example, would seem perfectly valid. When an object is
returned by value a copy constructor and destructor are called, so it
doesn't look logically correct to unload glfont in wrapper's
destructor.

I originally wasn't.

I would suggest to unload the font when it is removed from the map you
mentioned.

That is orignally how I was doing it.

May be subclass the map and load the glfont when a new (id,name) pair
is added and unload glfont when the pair is removed.

Can you explain this more?

Singletons can't be stored in map (as it is a map requirement,among
others, a default constructor for the objects), so you can only put a
pointer to your singleton.

One solution I've used in the past, but am not really happy with, is to use
pointers in the map. Then I can control exactly when the destructor is
called. I.E. Instead of: std::map<std::wstring, jglFont> I would make it
std::map<std::wstring, jglFont*>

The main advantage of this is it allows me to leave my font class alone. I
shouldn't have to fenagle a class to use it in a container. I am very glad
that C++0x is using std::move instead of copy in containers as it gets rid
of this entire mess, but it seems that express 2010 isn't implementing it
yet (or I don't know how to get it to).

The main disadvantage is that I have to manually destroy the objects when I
am unloading the map. I can't even count on the maps destructor destroying
each element, because it would call the destructor on the pointer, not the
object. Which is why I'm looking for a better solution, but may have to
wait for my compiler to implement it.

 

[SG]

I am developing a font class for my opengl graphics library and I came
across a quandry.  I have a font which is simply a value for font id and
wrapper code to load the font and kill it.  Works fine, then I notice I
don't have a virtual destructor, nor any destructor at all.  So I throw in a
virtual destructor and call the code to unload the glfont.   I run the
program, now no fonts are visible.

The problem is that my fonts are stored in a map by font name and the font,
and of course std::maps along with most containers use copy.

I've been bitten by this before and wound up using pointers so I could
control when the destructor was called.  This was okay since polymophism was
involved and I needed pointers anyway.

I thought about using some variant of a smart pointer but I would still be
working with pointer logic.
[...]

Any suggestions? I am willing to use any feature of 0x that Express 2010
uses.

You could test whether this implementation already supports putting
std::unique_ptr<> objects into a map. This is supposed to work in the
upcoming C++ version but last time I checked it didn't work using GCC
4.5.1 in C++0x mode because the std:air implementation wasn't able

I have heard somethign about std::move being in 0x and that std::vector and
other containers were supposed to use std::move instead of copy.

Yes. The containers won't require the types to be copyable anymore.
Move-only types will be fine, too.

Cheers!
SG

 

[James Kanze]

Actually: How can I use a non-copyable class in a standard container?

You can't, at least not directly. The most general solution
would be a variant on the Letter/Envelope idiom, using deep copy
(which maintains copy semantics). Alternatively, using
boost::shared_ptr works (but with reference semantics).

In your specific case, I imagine that the actual font objects
will be immutable once they've been created and fully
initialized. This simplifies things a lot, since for immutable
objects, you can use either value or reference semantics, with
no change in behavior. Depending on how "clean" you want to be,
I'd either settle for shared_ptr, or wrap the shared_ptr in some
sort of handle, along the lines of the letter/envelope idiom (so
that it looks like an object, and not a pointer, to the client
code).

The problem is that the class can't be copied, at least as it
is, because of the destructor, but containers are loaded by
copy. This problem is common enough that, as I understand it,
in C++0x the std containers will use std::move instead of
copy. Then I could simply disable the copy constructor
(create one and make it private).

I don't.

Then why do you want to ban copy? (I would have imagined
polymorphism as the means of supporting different font formats,
e.g. a derived class for TrueType, another for Metafont, etc.)

 

[Jorgen Grahn]

Actually: How can I use a non-copyable class in a standard container?

I was unclear ... I meant:

If you had asked yourself "can this class be copied?" when you wrote
it, answered "no" and immediately made those two private, then you
would have gotten a compile-time error when you tried to use it in a
std::map.

Much better than a runtime error.

/Jorgen

 

[Jim Langston]

You can't, at least not directly. The most general solution
would be a variant on the Letter/Envelope idiom, using deep copy
(which maintains copy semantics). Alternatively, using
boost::shared_ptr works (but with reference semantics).

The problem with a deep copy is that creating the font is extremely
expensive. I'm loading something like 10,000 chars and it takes noticable
time to load the fonts. If I had to do a deep copy use of the font would be
prohibitive.

I've been thinking about a shared pointer, but I remember that C++'s
implementation of the shared pointer was broken in places which is why I
don't use it, and I don't like using boost. I understand that 2010 uses
0x's shared pointers which fix the issues so I may use them, although I
think getting the move to work would be best.

In your specific case, I imagine that the actual font objects
will be immutable once they've been created and fully
initialized. This simplifies things a lot, since for immutable
objects, you can use either value or reference semantics, with
no change in behavior. Depending on how "clean" you want to be,
I'd either settle for shared_ptr, or wrap the shared_ptr in some
sort of handle, along the lines of the letter/envelope idiom (so
that it looks like an object, and not a pointer, to the client
code).

This is how I've handled this situation in the past, although with a wrapped
naked pointer and not a shared pointer. I may wind up using this method.

Then why do you want to ban copy? (I would have imagined
polymorphism as the means of supporting different font formats,
e.g. a derived class for TrueType, another for Metafont, etc.)

I want to ban copy because of the prohibitive time taken to initialize a
font.

 

[Jim Langston]

I am developing a font class for my opengl graphics library and I came
across a quandry. I have a font which is simply a value for font id and
wrapper code to load the font and kill it. Works fine, then I notice I
don't have a virtual destructor, nor any destructor at all. So I throw in
a virtual destructor and call the code to unload the glfont. I run the
program, now no fonts are visible.

The problem is that my fonts are stored in a map by font name and the
font, and of course std::maps along with most containers use copy.

Resolution:
I used Microsoft Express 2010 C++0x utilization of std::move for containers.

I had a problem implementing this because when I first created a move
constructor I was still using assignment in my code. I disbled the
assignment operator and fixed my code and it works as advertised. I had to
change the elegant line of:
world.fonts[L"Normal"] = jmlGL::jglFont( hDC, L"Courier New", 24 );
to the no where near as elegant line of:
world.fonts.insert(std:air<std::wstring, jmlGL::jglFont>( L"Normal",
jmlGL::jglFont( hDC, L"Courier New", 24 ) ) );

my program worked as expected and I am able to use non-copyable objects in a
container.

 

[Öö Tiib]

The problem with a deep copy is that creating the font is extremely
expensive.  I'm loading something like 10,000 chars and it takes noticable
time to load the fonts.  If I had to do a deep copy use of the font would be
prohibitive.

I've been thinking about a shared pointer, but I remember that C++'s
implementation of the shared pointer was broken in places which is why I
don't use it, and I don't like using boost.  I understand that 2010 uses
0x's shared pointers which fix the issues so I may use them, although I
think getting the move to work would be best.

OpenGL just follows what you order it to do, move just moves,
shared_ptr is pointer with refcount attached to it and map is a
weighted tree of pairs.

Therefore when writing graphics library then it is *you* who has to
manage both GPU and CPU resources and these above tools just may help
you. If you have lot of multimedia then everything does not fit in
memory at once anyway.

For example: Why you load in 10,000 glyphs? It sounds like for 200 x
50 text with all symbols unique. Do such things lazily, load the
glyphs on hint you may need them, say 100 per portion. Other example:
map of such fonts? Do you plan in perspective to have so long list of
different fonts loaded that you need a map to navigate among them?

 

[Jim Langston]

(e-mail address removed)...


OpenGL just follows what you order it to do, move just moves,
shared_ptr is pointer with refcount attached to it and map is a
weighted tree of pairs.

Therefore when writing graphics library then it is *you* who has to
manage both GPU and CPU resources and these above tools just may help
you. If you have lot of multimedia then everything does not fit in
memory at once anyway.

For example: Why you load in 10,000 glyphs? It sounds like for 200 x
50 text with all symbols unique. Do such things lazily, load the
glyphs on hint you may need them, say 100 per portion. Other example:
map of such fonts? Do you plan in perspective to have so long list of
different fonts loaded that you need a map to navigate among them?

Yes, I plan on having so long a list of different fonts loaded that I need a
map to navigate them. I will also allow the end user to choose their own
fonts to use. I plan on supporting multiple languages. although I'm quite
sure I'll need more than std::wstring for this. The new u16 and u32 look
promising. If I do use u16 and/or u32 I plan on using them the exact same
way I'm using string and wstring (although I know there are a lot of issues.
character sizes may not always be consistant).

But, even if I don't use a map, I want to be able to use a font in a map, or
vector, or set, or whatever container I want it in. For a useful class not
to be used in a container is a terrible thing to me and since I have
resolved the issue with assignable it works well. I can now use my class
anywhere I want. Well, as long as no one tries to copy it, which is
prohibitively expensive anyway. If a font is already loaded in opengl I see
no reason to need to load it again. Just use the one that's already loaded.

 

[James Kanze]

The problem with a deep copy is that creating the font is extremely
expensive. I'm loading something like 10,000 chars and it takes noticable
time to load the fonts. If I had to do a deep copy use of the font would be
prohibitive.

I susected as much.

I've been thinking about a shared pointer, but I remember that
C++'s implementation of the shared pointer was broken in
places which is why I don't use it, and I don't like using
boost. I understand that 2010 uses 0x's shared pointers which
fix the issues so I may use them, although I think getting the
move to work would be best.

C++ doesn't (yet) have an implementation of shared pointer, and
move isn't present in all compilers yet either. If you do have
access to a compiler which more or less implements C++0x, then
I think that unique_ptr can be put into a vector; that might
solve your solution.

But there might be an even easier solution. You load fonts, but
do you ever unload them? If not, just use a raw pointer, and
forget about the delete.

This is how I've handled this situation in the past, although
with a wrapped naked pointer and not a shared pointer. I may
wind up using this method.

Yes. The classical letter/envelope uses a raw pointer, and deep
copy, since it supports mutable objects; the goal is to have
both polymorphism and value semantics. Since your objects are
immutable once built, the value semantics vs. reference
semantics don't play a role, and there's absolutely no reason to
do the deep copy. If you need to destruct the font objects at
some time, however, you must maintain some sort of reference
count (and ensure that font objects don't point to other font
objects, or if they do, that there are no cycles).

 

[Jorgen Grahn]

.

But, even if I don't use a map, I want to be able to use a font in a map, or
vector, or set, or whatever container I want it in. For a useful class not
to be used in a container is a terrible thing to me and since I have
resolved the issue with assignable it works well. I can now use my class
anywhere I want.

I'm sure this isn't a problem in your current design, but that
argument is dangerous.

A class should be tailored to its real, current environment, not to
all conceivable uses. Otherwise you risk making every class a
potential base class for inheritance, thread-safe, serializable ...
adding complexity and untested code. I've seen frightening examples
of this over and over.

All IMHO, of course.

/Jorgen

 

[Bo Persson]

I am developing a font class for my opengl graphics library and I
came across a quandry. I have a font which is simply a value for
font id and wrapper code to load the font and kill it. Works
fine, then I notice I don't have a virtual destructor, nor any
destructor at all. So I throw in a virtual destructor and call
the code to unload the glfont. I run the program, now no fonts
are visible. The problem is that my fonts are stored in a map by
font name and
the font, and of course std::maps along with most containers use
copy.

Resolution:
I used Microsoft Express 2010 C++0x utilization of std::move for
containers.
I had a problem implementing this because when I first created a
move constructor I was still using assignment in my code. I
disbled the assignment operator and fixed my code and it works as
advertised. I had to change the elegant line of:
world.fonts[L"Normal"] = jmlGL::jglFont( hDC, L"Courier New",
24 ); to the no where near as elegant line of:
world.fonts.insert(std:air<std::wstring, jmlGL::jglFont>(
L"Normal", jmlGL::jglFont( hDC, L"Courier New", 24 ) ) );

my program worked as expected and I am able to use non-copyable
objects in a container.

Wouldn't another soultion be to implement a move assignment operator
for foo?

foo& operator=(foo&&);

That would let you assign a temporary (rvalue only) to the mapped
object.



Bo Persson

 

[Jim Langston]

I am developing a font class for my opengl graphics library and I
came across a quandry. I have a font which is simply a value for
font id and wrapper code to load the font and kill it. Works
fine, then I notice I don't have a virtual destructor, nor any
destructor at all. So I throw in a virtual destructor and call
the code to unload the glfont. I run the program, now no fonts
are visible. The problem is that my fonts are stored in a map by font
name and
the font, and of course std::maps along with most containers use
copy.

Resolution:
I used Microsoft Express 2010 C++0x utilization of std::move for
containers.
I had a problem implementing this because when I first created a
move constructor I was still using assignment in my code. I
disbled the assignment operator and fixed my code and it works as
advertised. I had to change the elegant line of:
world.fonts[L"Normal"] = jmlGL::jglFont( hDC, L"Courier New",
24 ); to the no where near as elegant line of:
world.fonts.insert(std:air<std::wstring, jmlGL::jglFont>(
L"Normal", jmlGL::jglFont( hDC, L"Courier New", 24 ) ) );

my program worked as expected and I am able to use non-copyable
objects in a container.

Wouldn't another soultion be to implement a move assignment operator for
foo?

foo& operator=(foo&&);

That would let you assign a temporary (rvalue only) to the mapped object.

I was thinking about this, but if every time I did an assignment I moved
ownership I wouldn't like that. Java does that and it bugs the heck out of
me. As I understand it if I have operator=(&&) then the compiler will use
this instead of operator= (although I might be mistaken in that). I just
don't like the idea of accidently changing ownership without realzing it
since that is not the "normal" behavior of operator=. I'll have to research
that more before I implement it, and I had thought about implementing it
also but am not aware of all the effects. Disabling operator= and creating
the move constructor allow me to use the object as intended. Only one real
copy of the object exists, almost like a singleton pattern.

 

[Luc Danton]

I am developing a font class for my opengl graphics library and I
came across a quandry. I have a font which is simply a value for
font id and wrapper code to load the font and kill it. Works
fine, then I notice I don't have a virtual destructor, nor any
destructor at all. So I throw in a virtual destructor and call
the code to unload the glfont. I run the program, now no fonts
are visible. The problem is that my fonts are stored in a map by
font name and
the font, and of course std::maps along with most containers use
copy.

Resolution:
I used Microsoft Express 2010 C++0x utilization of std::move for
containers.
I had a problem implementing this because when I first created a
move constructor I was still using assignment in my code. I
disbled the assignment operator and fixed my code and it works as
advertised. I had to change the elegant line of:
world.fonts[L"Normal"] = jmlGL::jglFont( hDC, L"Courier New",
24 ); to the no where near as elegant line of:
world.fonts.insert(std:air<std::wstring, jmlGL::jglFont>(
L"Normal", jmlGL::jglFont( hDC, L"Courier New", 24 ) ) );

my program worked as expected and I am able to use non-copyable
objects in a container.

Wouldn't another soultion be to implement a move assignment operator
for foo?

foo& operator=(foo&&);

That would let you assign a temporary (rvalue only) to the mapped object.

I was thinking about this, but if every time I did an assignment I moved
ownership I wouldn't like that. Java does that and it bugs the heck out
of me. As I understand it if I have operator=(&&) then the compiler
will use this instead of operator= (although I might be mistaken in
that). I just don't like the idea of accidently changing ownership
without realzing it since that is not the "normal" behavior of
operator=. I'll have to research that more before I implement it, and I
had thought about implementing it also but am not aware of all the
effects. Disabling operator= and creating the move constructor allow me
to use the object as intended. Only one real copy of the object
exists, almost like a singleton pattern.

Bo Persson

You are indeed mistaken. One of the reason rvalue refs are in the
upcoming C++0x standard is because they make moving semantics safe.
Consider auto_ptr, where ownership *can* accidentally be lost. On the
other hand, this can't happen with unique_ptr (its replacement). To move
a unique_ptr through assignment from an lvalue, you have to request it,
as in:

std::unique_ptr<T> original = /* initialize here */
std::unique_ptr<T> dest = original; // won't compile
std::unique_ptr<T> safe_dest = std::move(original);
// don't use original anymore

So if you class has an operator=(&&), but not a copy assignment operator
(operator=(const&), but also operator=(&)), you can't accidentally
invalidate your objects. Although check that your implementation
actually *does* that since the specs for rvalue refs have been in flux
for some time.

As a final note, don't forget that std::move is an innocent call: in my
example, it resolves to a static_cast<T&&>. It doesn't actually do any
move: it's up to your operator=(&&) to do the right thing (i.e. it can
safely assume that it can pilfer its argument), but the compiler won't
do anything for you (unless you default the operator if this is supported).

 

[Jim Langston]

Jim Langston wrote:
I am developing a font class for my opengl graphics library and I
came across a quandry. I have a font which is simply a value for
font id and wrapper code to load the font and kill it. Works
fine, then I notice I don't have a virtual destructor, nor any
destructor at all. So I throw in a virtual destructor and call
the code to unload the glfont. I run the program, now no fonts
are visible. The problem is that my fonts are stored in a map by
font name and
the font, and of course std::maps along with most containers use
copy.

Resolution:
I used Microsoft Express 2010 C++0x utilization of std::move for
containers.
I had a problem implementing this because when I first created a
move constructor I was still using assignment in my code. I
disbled the assignment operator and fixed my code and it works as
advertised. I had to change the elegant line of:
world.fonts[L"Normal"] = jmlGL::jglFont( hDC, L"Courier New",
24 ); to the no where near as elegant line of:
world.fonts.insert(std:air<std::wstring, jmlGL::jglFont>(
L"Normal", jmlGL::jglFont( hDC, L"Courier New", 24 ) ) );

my program worked as expected and I am able to use non-copyable
objects in a container.

Wouldn't another soultion be to implement a move assignment operator
for foo?

foo& operator=(foo&&);

That would let you assign a temporary (rvalue only) to the mapped
object.

I was thinking about this, but if every time I did an assignment I moved
ownership I wouldn't like that. Java does that and it bugs the heck out
of me. As I understand it if I have operator=(&&) then the compiler
will use this instead of operator= (although I might be mistaken in
that). I just don't like the idea of accidently changing ownership
without realzing it since that is not the "normal" behavior of
operator=. I'll have to research that more before I implement it, and I
had thought about implementing it also but am not aware of all the
effects. Disabling operator= and creating the move constructor allow me
to use the object as intended. Only one real copy of the object
exists, almost like a singleton pattern.

Bo Persson

You are indeed mistaken. One of the reason rvalue refs are in the upcoming
C++0x standard is because they make moving semantics safe. Consider
auto_ptr, where ownership *can* accidentally be lost. On the other hand,
this can't happen with unique_ptr (its replacement). To move a unique_ptr
through assignment from an lvalue, you have to request it, as in:

std::unique_ptr<T> original = /* initialize here */
std::unique_ptr<T> dest = original; // won't compile
std::unique_ptr<T> safe_dest = std::move(original);
// don't use original anymore

So if you class has an operator=(&&), but not a copy assignment operator
(operator=(const&), but also operator=(&)), you can't accidentally
invalidate your objects. Although check that your implementation actually
*does* that since the specs for rvalue refs have been in flux for some
time.

I just tried it out and it seems that in Express 2010 anyway my concern was
justified. Without an operator=(&&) this will not compile (as it shouldn't).

world.fonts[L"Normal"] = jmlGL::jglFont( hDC, L"Courier New", 24 );
error C2248: 'jmlGL::jglFont:perator =' : cannot access private member
declared in class 'jmlGL::jglFont'

However, when I add
jglFont& operator=(jglFont&& rhs) { /*.real code here..*/ }

my program compiles and runs. I did not have to use std::move.

 

[Luc Danton]

I just tried it out and it seems that in Express 2010 anyway my concern
was justified. Without an operator=(&&) this will not compile (as it
shouldn't).

world.fonts[L"Normal"] = jmlGL::jglFont( hDC, L"Courier New", 24 );
error C2248: 'jmlGL::jglFont:perator =' : cannot access private member
declared in class 'jmlGL::jglFont'

However, when I add
jglFont& operator=(jglFont&& rhs) { /*.real code here..*/ }

my program compiles and runs. I did not have to use std::move.

But jglFont is your type, so the expression jmlGL::jglFont( hDC,
L"Courier New", 24 ) is a constructor call that results in an rvalue of
this type, right?

What you need to check is:
jglFont lval = /* whatever */;
jglFont destination; /* or another init if not DefaultConstructible */
destination = lval;

 

[Jim Langston]

I just tried it out and it seems that in Express 2010 anyway my concern
was justified. Without an operator=(&&) this will not compile (as it
shouldn't).

world.fonts[L"Normal"] = jmlGL::jglFont( hDC, L"Courier New", 24 );
error C2248: 'jmlGL::jglFont:perator =' : cannot access private member
declared in class 'jmlGL::jglFont'

However, when I add
jglFont& operator=(jglFont&& rhs) { /*.real code here..*/ }

my program compiles and runs. I did not have to use std::move.

But jglFont is your type, so the expression jmlGL::jglFont( hDC, L"Courier
New", 24 ) is a constructor call that results in an rvalue of this type,
right?

What you need to check is:
jglFont lval = /* whatever */;
jglFont destination; /* or another init if not DefaultConstructible */
destination = lval;

You are correct. This will not compile:
world.fonts[L"Normal"] = world.fonts[L"Bold"];
error C2248: 'jmlGL::jglFont:perator =' : cannot access private member
declared in class 'jmlGL::jglFont'

Okay. I think I understand. If the object being assigned from is a
temporary operator=(&&) will be called. If it's not a temporary then
operator=(&) will be called.