Take the 2-minute tour ×

Is there a (more or less at least) standard int class for c++?

If not so, is it planned for say C++13 and if not so, is there any special reasons?

OOP design would benefit from it I guess, like for example it would be nice to have an assignment operator in a custom class that returns an int:

int i=myclass;

and not

int i=myclass.getInt();

OK, there are a lot of examples where it could be useful, why doesn't it exist (if it doesn't)?

[edit] Thanks for all the good answers and sorry for the crappy question (I'll accept as soon as I can). I'm happy to see that I Can do what I wanted (It is for dead reckoning and other lag-compensating schemes and treating those values as 'normal' variables will be nice, hopefully anyway!).

ps. 30 upvotes on answers (thanks for all those nice answers!) and zero for the question, shouldn't there be a badge for that ;-D ?

share|improve this question
Nothing planned, and the reason is that C++ is not a certain language that shoehorns everything into objects. –  Xeo Mar 6 '12 at 16:01
If there are so many examples I would like to read some. Also: What is the mechanism you want to achieve in your example? Is the first better than the second just because it is shorter? I think the second one visualizes its purpose much better than the first. –  Nobody Mar 6 '12 at 16:02
What’s wrong with plain int?! –  Konrad Rudolph Mar 6 '12 at 16:02
What specifically are you looking for that int does not provide? –  tenfour Mar 6 '12 at 16:06
@eda An int variable is an object, but 42 is not an object. –  FredOverflow Mar 7 '12 at 1:44
show 11 more comments

9 Answers

up vote 18 down vote accepted


You can do that with a conversion operator:

class myclass {
    int i;
    myclass() : i(42) {}

    // Allows implicit conversion to "int".
    operator int() {return i;}

myclass m;
int i = m;

You should usually avoid this, as the extra implicit conversions can introduce ambiguities, or hide category errors that would otherwise be caught by the type system. In C++11, you can prevent implicit conversion by declaring the operator explicit; then the class can be used to initialise the target type, but won't be converted implicitly:

int i(m);    // OK, explicit conversion
i = m;       // Error, implicit conversion
share|improve this answer
You must think twice when you want to use the conversion operators, because they make your code less obvious –  Alecs Mar 6 '12 at 16:04
@Alecs: The OP must think thrice atleast why he wants such semantics. –  Xeo Mar 6 '12 at 16:08
I think I have a valid use case for this behaviour. I want to have a wrapper class for int which notifies a Java object (via JNI) of any changes in its value. By using conversion operators, I am able to overload assignment/modification operators (=, ++, --) to notify the Java object, without breaking the functionality of existing references to the object as an int. Without being able to extend int as it is a primitive data type and not a class, this seems to be a good solution. Am I missing something, or is this a good solution to my problem? –  StockB Jan 23 '13 at 17:31
add comment

If you want to allow your class to implicitly convert to int, you can use an implicit conversion operator (operator int()), but generally speaking implicit conversions cause more problems and debugging than they solve in ease of use.

share|improve this answer
Explicit conversions are in C++11. –  Puppy Mar 6 '12 at 16:13
Although you could always simulate them with methods. –  Mark B Mar 6 '12 at 16:18
add comment

If your class models an int, then the conversion operator solution presented by other answers is fine, I guess. However, what does your myclass model?

What does it mean to get an integer out of it?

That's what you should be thinking about, and then you should come to the conclusion that it's most likely meaningless to get an integer without any information what it represents.

Take std::vector<T>::size() as an example. It returns an integer. Should std::vector<T> be convertible to an integer for that reason? I don't think so. Should the method be called getInt()? Again, I don't think so. What do you expect from a method called getInt()? From the name alone, you learn nothing about what it returns. Also, it's not the only method that returns an integer, there's capacity() too.

share|improve this answer
add comment

This can be realized by the cast operator. E.g:

class MyClass {
    int someint;
    operator const int() {
        return this->someint;
share|improve this answer
add comment

No there isn't any standard int class. For things such as BigDecimal you can look at Is there a C++ equivalent to Java's BigDecimal?

As for int, if you really need it, you can create your own. I have never come across an instance where I needed an Integer class.

share|improve this answer
add comment

No, and there won't be any. What you want to do can be done with conversion operator:

#include <iostream>

struct foo {
    int x;
    foo(int x) : x(x) {}
    operator int() { return x; }

int main() {
    foo x(42);
    int y(x);
    std::cout << y;
share|improve this answer
However, it should not be done. –  sbi Mar 6 '12 at 16:24
@sbi: That depends. If you are writing a type for restricted integer ranges, implicit conversion to int is exactly the right thing to do. Of course you very rarely do that. –  celtschk Mar 6 '12 at 22:37
@celtschk: I once thought that, too. But I have been bitten by this too often. Every single one of the few implicit conversions I have written which are part of codebases still in use got removed over the years because they caused trouble. –  sbi Mar 9 '12 at 9:04
@sbi: Then maybe you had problems with inappropriate implicit conversions (note that many of the standard implicit conversions in C++ are wrong in my opinion). Note especially that my example is a restricted int class, something which few people dare to implement (just using an int is much simpler). An implicit conversion from an extended integer class ("bigint") to int is clearly wrong. –  celtschk Mar 9 '12 at 21:16
@celtschk: If those were inappropriate (well, IMO they certainly were, because we had too remove them), then I have, in almost 20 years of writing C++ code, not come across a single case of implicit conversions being appropriate. All the cases I have seen sooner or later were found to be the culprit for some very hard to diagnose errors, caused by implicit conversions implicitly kicking in. (This does include a Byte class, BTW.) –  sbi Mar 9 '12 at 23:55
show 1 more comment

No, and there probably won't be.

int i=myclass;

This is covered by conversion operators:

struct MyClass {
    operator int() {
        return v;
    int v;
} myclass = {2};
int i = myclass; // i = 2

Not everything has to be 'object oriented'. C++ offers other options.

share|improve this answer
add comment

There's no reason to have one, and so there won't be any.

share|improve this answer
Please see my comment to Mike Seymour. –  StockB Jan 23 '13 at 17:28
Looks like it's technically possible (correct me please) to convert C++ type-system to have only objects. If we pretend that int is a final class with overloaded operators with built-in support for literals. So 5 creates an object of class int. Why would you want to do that? Well, if, C++ also adds a couple of methods like repeat you would be able to write something like 5.repeat([]{ your_code; }); Aren't there only a few backward compatibility problems such as type_traits and ... ? –  sasha.sochka Feb 7 at 22:05
You would also be able to write repeat(5, []{ your code; }); right now. Even the C++ committee aren't sufficiently insane to make int into a class. The C++ type system is already composed of only objects (except references). There's no reason to change the existing primitives, which are already objects. –  Puppy Jul 4 at 9:01
add comment

Implement operator int () for your class

share|improve this answer
add comment

Your Answer


