4

So my understanding is that this: 1e3 Equates to 1000.0.

My question is, is there a similar shorthand for integers? I realize that I can do: static_cast<int>(1e3). Is there anything available to me outside of this?

Jonathan Mee
  • 37,899
  • 23
  • 129
  • 288
  • Are you okay with creating a UDL? I believe it could be done – Justin Aug 21 '18 at 21:27
  • 1
    *Is there anything available to me outside of this?* I am guessing you are asking for something that's already built into the language or the standard library. – R Sahu Aug 21 '18 at 21:42
  • Binary is already an exponential shorthand for integers. Unary would be the long form: X = 1, XX = 2, XXX = 3, etc. – stark Aug 21 '18 at 21:45
  • 1
    @stark That's completely irrelevant – Justin Aug 21 '18 at 21:51
  • @RSahu Yeah I was hoping for something that was built into the language. – Jonathan Mee Aug 22 '18 at 12:16
  • @Justin Hmmm... I assume that UDL meant User Defined Literals. I hadn't considered that. But looking at [user2079303's answer](https://stackoverflow.com/a/51957160/2642059) I have to say it looks like a strong solution. – Jonathan Mee Aug 22 '18 at 12:18
  • `static_cast(some_double_constant)` can lack precision when the precision of `double` with whole number values is less than the integer width. Consider `static_cast(some_long_double_constant)`. – chux - Reinstate Monica Aug 22 '18 at 13:41
  • @chux Sure that's another whole problem. I was really just looking for the convenience of that "e" notation. Sounds like user defined literals would be my only hope, which of course would incur all the drawbacks you mention. – Jonathan Mee Aug 22 '18 at 14:49
  • Note: Various ideas mentioned incurred a fixed type via `static_cast()` or `int operator "" _i()`. `2.147483648e9` will not become a `long` like `2147483648` does (unless `int` is more than 32 bit). – chux - Reinstate Monica Aug 22 '18 at 15:10

1 Answers1

6

No, there is no syntax for scientific notation integer literal in C++.

You could shorten the conversion with a user defined literal:

constexpr int operator "" _i(long double d) noexcept {
    return d;
}

int main() {
    auto big = 1e3_i; // is int
}

However, this does (at least on GCC that I tested) prevent the compiler from noticing overflow in the initialization so in those cases where possible, prefer the more conventional:

int big = 1e30; // compiler should yell at you
eerorika
  • 232,697
  • 12
  • 197
  • 326
  • 1
    That can be `constexpr` right? There are significant advantages to a "constant integral expression", such as being usable in array bounds, template parameters, etc. – Ben Voigt Aug 21 '18 at 21:53
  • 1
    @BenVoigt as far as I know, yes. It can be `noexcept` too. – eerorika Aug 21 '18 at 21:57
  • Very interesting - and good use of `long double`. The function could also detect if the conversion is not _exact_. – chux - Reinstate Monica Aug 22 '18 at 13:44
  • @chux Would you suggest that the function should throw in that case? – eerorika Aug 22 '18 at 13:58
  • As the use case for your nifty `operator "" _i()` applies to forming an _integer literal_, I'd recommend code should throw on inexact, (also for out of range, NAN). I'm on the fence about `-0.0`, yet lean toward throwing on that too. Expect that precules `noexcept`. Hmmm. – chux - Reinstate Monica Aug 22 '18 at 14:38
  • 1
    The compiler will yell at you if you mark the variable as `constexpr` for `constexpr int big = 1e30_i;`. Basically, if the `operator""_i()` is evaluated as `constexpr`, you'll get a compilation error because overflow isn't allowed in `constexpr`. – Justin Aug 22 '18 at 17:06
  • With C++20 you can use `consteval` instead of `constexpr` in operator definition and compiler will always yell at your on overflow, even when using non-constexpr variables. – sklott Dec 09 '22 at 21:35