#define int long long

はじめに

この記事はこの記事はプログラミングラボ部アドベントカレンダープロ部門 11日目の記事として書かれています。

https://adventar.org/calendars/4410

昨日の記事は面白かったですね。超絶大事ではない話をします。

競技プログラミング

僕の2年生までの部活動はすべて競技プログラミングでした。3年生になってからは本格的にすることは少なくなりましたが、毎週コンテストの問題を見て考察するくらいはしていました。いくつか大会にも出ています。まとめると結構長い時間競技プログラミングをやっていたということです。

そんな僕が最近知った非常に便利なマクロがあります。それがこちら、

#define int long long

長い時間競技プログラミングをやっていた僕が最近知ったので、おそらくこの記事を読んでいる人たちは知らないんじゃないですかね。今回はこの便利なマクロについて話していこうと思います。

何がうれしいか

競技プログラミングで出題される問題には、int型に格納できる値より大きい値を扱わないといけないものがあります。数え上げとかがそうですね。その場合、int型の代わりにlong long型というものを使う必要があるのですが、このマクロを使うことでintと書くとlong longとみなしてくれるようになります。桁あふれを気にしなくてよくなるわけですね。

こんなに便利なんだから何かデメリットがあるかと思ったら特にないんですよね。1つは

int main(void)

を

signed main(void)

と書かないといけなくなることです。めんどくさいですが慣れればデメリットでもなんでもないですね。あとは、少しだけ実行時間が伸びてしまうことなんですが、そのせいでTLEが出たみたいな話はほとんど聞かないので(全くないわけではない)、気にしなくていいと思います。

おわり

こんな感じで便利なのでみんな使おう。

明日ははと君の記事です。「うわぁぁぁぁぁぁぁぁぁぁぁ」と書いてありますが何の記事を書くんでしょうか？

おまけ

このままだと情報量0なので、なんで#define int long longについて書いたかを話します。

この前ICPCという大会に出ました。結果は下から1/4くらいだったと思います。

問題が結構多く、最初の2問だけ難易度順に並んでいるので、まずははじめの2問を解いてから簡単な問題に取り掛かるというのが基本的な戦術だと思います。僕たちのチームも同じ戦術をとりました。

Bがすごく簡単だったのに対し、A問題が意外に難しくて少し時間がかかったのですが、何とかAとBを通してほかの問題を解き始めました。ちなみに問題文の英訳はchocobo333とgedorinku先輩がやってくれました。僕は英語ができないのでかなり助かりました。

明らかに難しそうな問題でなく、他のチームが多く解いている問題だったのでH問題に手を付けることにしました。適当に考察していると解法っぽいものが浮かんだので実装開始、数分後に嘘だとわかったので考察しなおし、今度こそは解法が浮かんだので実装再開、みたいな流れだったと思います。

とりあえず実装が終わってサンプルも通ったので提出。WA
えーなんでーとか思いながらデバッグ。20分くらいでバグがわかりなおして提出。WA

ここから何が間違っているのか分からないまま、コードを眺めたり自作サンプルを試したりする時間が一時間くらい続きました。実装をしたのが久しぶりだったので超難解なコードを書いてしまい、僕以外デバッグできないみたいになって最悪でした。

一時間くらいがたったくらいでgedorinku先輩が「これ最大ケースでオーバーフローするくない？」みたいなことをつぶやきました。僕は頭が真っ白になりました。intをlong longに変えて提出。AC

残り時間1時間くらいだったのでとりあえず考察を始めたのですが、あまり集中できずにそのまま大会終了。悲しいですね。

正直、#define int long long をはじめから書いていたからといって正解数が増えていたことはないと思いますが。チームメンバーに迷惑をかけてしまったのでかなり反省しました。この経験で「これからのコードは絶対に#define int long longを書くぞ」と誓いました。二回目ですけどね、これを誓ったのは。というわけで、皆さんも#define int long longをしましょうね。

おまけ2

久しぶりに競プロをしたので最近思っていることを話します。僕が一番競技プログラミングを楽しんでいたのは、おそらく初めてすぐか、JOI非公式難易度表の10くらいを埋めているときだったと思います。初めたばかりのころは、自分が考えた通りにプログラムが動くのがただただ楽しくて競プロをしていました。10を埋めている頃は、何とか自力で解ける難易度の問題を解くのが楽しかったですね。ただ、そのころから考察に対して実装が重くなってきたと感じることが多くなりました。考察をしているときは楽しいのですが、それを実装に移そうとすると面倒くさくて次の問題の考察に移ってしまう、ということもしばしばありました。実装して初めて自分の考えがあっているのかがわかるというのに...。ちなみに考察より実装が重いと思っていたのは僕だけではなく、某先輩も同じことを思っていたそうです。

当時はそんなことを考えていたのですが、最近は考え方が変わってきていています。アルゴリズムを考えることも大切だけど、うまい実装法を考えることこそが、競技プログラミングに求められていることなのではないか、みたいな感じに変わってきています。実際、強い人のコードはシンプルで短く読みやすい印象があります。しばらく競技プログラミングをすることはないと思いますが、また競技プログラミングを始めることがあれば、ここら辺を頭において精進しようと思っています。