125. Valid Palindrome by ryosuketc · Pull Request #5 · ryosuketc/leetcode_grind75

ryosuketc · 2025-08-13T21:00:58Z

125. Valid Palindrome

https://leetcode.com/problems/valid-palindrome/

oda · 2025-08-13T21:04:49Z

125_valid_palindrome/memo.md

+### step2
+
+*   https://github.com/colorbox/leetcode/pull/7/files
+    *   `+=` しながら `checker` 文字列を作っている。Python だと文字列コピーが発生する (ただし最適化の実装による) のでやりたくない感じなんだが、C++ だとどうなの？


C++ では文字列は mutable です。

oda · 2025-08-13T21:09:56Z

125_valid_palindrome/memo.md

+*   https://github.com/colorbox/leetcode/pull/7/files
+    *   `+=` しながら `checker` 文字列を作っている。Python だと文字列コピーが発生する (ただし最適化の実装による) のでやりたくない感じなんだが、C++ だとどうなの？
+    *   上記だと `checker` を reverse している。
+    *   step1 でのコメントも踏まえて `step2/Solution` はとりあえず書いてみた。関数では文字列コピーして返しているから冗長な感じはする。できればコピーはせずに使いたい気もする (できるのかな？無理そう)


まず、これは named return value optimization が働いてコピーが自動的に消える可能性があります。
コピーしたくなければ、リファレンスかポインターを引数に渡します。

std::string to_lower_alnum(std::string& s) { ... } bool isPalindrome(string s) { std::string lower_alnum_string = to_lower_alnum(s); ...

のような感じでしょうかね。(N)RVO の話はあまり考慮していませんでした。
https://cpprefjp.github.io/lang/cpp17/guaranteed_copy_elision.html
ちょっとフォローしきれていないので別途勉強します。

もともとここで意図していたのは、isPalindrome の引数 s の非連続 (である可能性がある) な部分文字列がlower_alnum_string であり、lower_alnum_string の中の文字 (char) はすべて s に含まれているはずなので、s のメモリを再利用して lower_alnum_string を (string_view のようなイメージで) 作れないのか、というものでした。
非連続な部分文字列なのでやはり難しい気がしました。

void to_lower_alnum(std::string& from, std::string* to); std::string lower_alnum_string; to_lower_alnum(s, &lower_alnum_string);

こうです。

長い文字列から数文字を消去した文字列を空間をできるだけ再利用して表現したいということですね。

Rope というデータ構造を思い出します。これは、木構造で文字列を管理して編集されていない部分木を共有します。split, concatenate が O(log n) でできます。
Piece Table はテキストエディターなどで使われるもので、変更履歴を追いかけていくものです。

一般的に連続したメモリーに対しての処理は速いので普通はコピーしたほうがいいでしょうが、テキストの編集は頻繁に行われてきたのでよく研究されています。

概ね連続したメモリーのコピーは 1 clock で4-8バイトくらいできるのではないかと思います。
木構造をたどるとどうしてもたどるたびに数クロックかかるでしょう。

結局、切り替えることによってどれくらい実際に速くなるかを見積もって、別のライブラリーを使う必要がでてくるデメリットなどと勘案するという比較衡量をして欲しいですね。

ありがとうございます！

こちらでもコメントいただいている箇所ですね。先に書き込み先を用意して関数にそこに書き込んでもらう、というのが馴染みないですが、慣れていきたいと思います。

#5 (comment)

string を引数に値渡しで渡すと、コピーが発生します。stringをコピーする場合、元の文字列が格納できるサイズのメモリをヒープに確保し、文字列をコピーします。できればこのストは避けたいです。 const string& と const 参照渡ししたほうが良いと思います。
また、戻り値を string の値型で返すと、同じようにコピーが発生することが多いと思います。引数に参照型の引数を追加し、そこに出力を渡すのが良いと思います。
サイズが十分小さかったり、定数倍の速度が求められないのであれば、値渡しをしたり、値型を返しても良いかもしれません。

概ね連続したメモリーのコピーは 1 clock で4-8バイトくらいできるのではないかと思います。
木構造をたどるとどうしてもたどるたびに数クロックかかるでしょう。

なるほど…このあたりの数字感覚がなかったのですが、どのようなロジックで推論されるものでしょうか。

追記: 後のコメントから辿って多少理解しました。32 or 64 ビット CPU の想定から 4-8 バイトと見ているんですね (ただのコピーなので機械語的にも 1 命令で、特にオーバーヘッドがない処理のはずなので)。
Ryotaro25/leetcode_first60#66 (comment)

結局、切り替えることによってどれくらい実際に速くなるかを見積もって、別のライブラリーを使う必要がでてくるデメリットなどと勘案するという比較衡量をして欲しいですね。

今回であれば 1 <= s.length <= 2 * 10^5 という制約で、ASCII で 1 char / 1 byte と仮定するなら、200KB くらいなので、丸ごとコピーすることになるとすると 4 bytes / clock と仮定して 50K clocks くらい必要。昨今の CPU なら数 GHz / sec くらいなので、1/100 秒 (10ms)とかそのくらいでしょうか。まあこのくらいならいいかな…という気がしてきます。

先に書き込み先を用意して関数にそこに書き込んでもらう

Google のスタイルガイドもともとこうだったんですが、最近はしないようになっているみたいです。NRVO が効く前提なんでしょうか。

数字感覚
実行時間の見積もりは、具体的な CPU によって異なる+上から抑えたいためかなり適当です。

2000年頃のアーキテクチャでも浮動小数点 double は64ビットなので64ビットは一命令で動かせるでしょう。これは遅い見積もりです。

変更なしでメモリーをコピーするならば SIMD 命令などではるかに速いでしょう。

サイズによっては L1/L2 キャッシュが効く。ないとメモリー帯域は 10 GB/s の桁。

Jeff Dean の表(2012年)は Read 1 MB sequentially from memory 250 us としていました。

なんていうか、見積もりは色々な傍証から「こんなものだよな」とやっているのでそんなにロジカルなものではないです。機械語でどうなりそうかを考えてアーキテクチャの知識と照らし合わせています。

oda · 2025-08-13T21:13:03Z

125_valid_palindrome/memo.md

+*   https://qiita.com/LdCqh1/items/92f286ceb0ab96dc3c09
+*   https://zenn.dev/reputeless/books/standard-cpp-for-competitive-programming/viewer/string
+    *   > C++ 標準ライブラリは、任意の文字型 Char に対して、便利な文字列処理を提供するためのクラステンプレート std::basic_string<Char> を定義しています。それを char 型に対して特殊化（std::basic_string<char>）したものが std::string です。
+        *   `Char` と `char` って C++ だと違うものな？(TODO)


ここでの Char は一般的に Char と書けば通じるものではありません。
template <class Char> で表現するように、wchar_t などを代入するという意味(変数 x みたいな意味)です。

oda · 2025-08-13T21:14:03Z

125_valid_palindrome/memo.md

+        *   `Char` と `char` って C++ だと違うものな？(TODO)
+        *   軽く検索してみたがよくわからん
+    *   `union` (TODO) とかあるんだ。。
+        *   `size_t` という型がある


sizeof の返す型。vector size もこの型のことが多いです。
「符号なし」なので引き算をするとたまにあふれてはまります。

austyhooong · 2025-08-14T08:29:29Z

125_valid_palindrome/step3.cpp

@@ -0,0 +1,27 @@
+class Solution {
+private:
+    std::string to_lower_alnum(std::string s) {


Suggested change

std::string to_lower_alnum(std::string s) {

std::string to_lower_alnum(const std::string& s) {

それかmodern C++ ではstring_viewを渡すことが多いかと思います。

あ、なるほど、string_view はこういうので使えるんですね。

austyhooong · 2025-08-14T08:30:27Z

125_valid_palindrome/step3.cpp

+class Solution {
+private:
+    std::string to_lower_alnum(std::string s) {
+        std::string lower_alnum_string;


もしsのサイズが大きれば、ここは先にcapacityをreserveするのも良いかと思います。

reserve の時間見積もりはこのあたりにあります。一行を加える管理コストに足るメリットがあるかという良し悪しを評価するという方向に頭を動かしたかということが大事です。
https://docs.google.com/document/d/11HV35ADPo9QxJOpJQ24FcZvtvioli770WWdZZDaLOfg/edit?tab=t.0#heading=h.isflp7vsmzk2

reserve をそもそも知らなかったのですがこれですね。
https://cpprefjp.github.io/reference/string/basic_string/reserve.html

「計算速度の見積もり」の項は何度か見ているものの、すべて身についている感じはしないので折に触れて確認していきたいと思います。
https://docs.google.com/document/d/11HV35ADPo9QxJOpJQ24FcZvtvioli770WWdZZDaLOfg/edit?tab=t.0#heading=h.xbcr3241jgv8

austyhooong · 2025-08-14T08:31:39Z

125_valid_palindrome/step3.cpp

@@ -0,0 +1,27 @@
+class Solution {
+private:


Google guideではpublicを先に宣言することがお勧めされております！

一応、プロダクションでは分割コンパイルをするというのを意識しておきましょう。
https://docs.google.com/document/d/11HV35ADPo9QxJOpJQ24FcZvtvioli770WWdZZDaLOfg/edit?tab=t.0#heading=h.cxz8lxsufnbn

ありがとうございます。このあたりを確認しました。分割コンパイルについての意識はまだ低いのでもう少し C++ に慣れたら、どういうヘッダファイルが想定されるか考えてみようと思います (production のコードでちょくちょく読んでいるので読む方の認識はあるのですが、書くほうがまだ今ひとつ)。

元の質問に戻ると、class 定義は .h に書かれてどういうクラスであるだけが書かれているので、外からのインターフェースが前で(サイズを決めるのに必要な) private 情報は後ろに来ます。ただ、普通は実体がさらに後ろに回っているので、半分は肯定ですね。

nodchip · 2025-08-14T10:25:58Z

125_valid_palindrome/step2.cpp

+
+class Solution {
+private:
+    string to_lower_alnum(string s) {


string を引数に値渡しで渡すと、コピーが発生します。stringをコピーする場合、元の文字列が格納できるサイズのメモリをヒープに確保し、文字列をコピーします。できればこのストは避けたいです。 const string& と const 参照渡ししたほうが良いと思います。
また、戻り値を string の値型で返すと、同じようにコピーが発生することが多いと思います。引数に参照型の引数を追加し、そこに出力を渡すのが良いと思います。
サイズが十分小さかったり、定数倍の速度が求められないのであれば、値渡しをしたり、値型を返しても良いかもしれません。

ありがとうございます。こちらの oda さんのコメントと合わせて確認しました。
https://github.com/ryosuketc/leetcode_grind75/pull/5/files#r2274872702

ryosuketc added 3 commits August 14, 2025 06:00

125. Valid Palindrome

8975ba3

https://leetcode.com/problems/valid-palindrome/

Merge branch 'main' into 125_valid_palindrome

da10b19

Merge branch 'main' into 125_valid_palindrome

b318e4d

oda reviewed Aug 13, 2025

View reviewed changes

ryosuketc added 3 commits August 14, 2025 06:17

Fix PR URL bug

7cf3621

Merge branch 'main' into 125_valid_palindrome

c4b9879

Merge branch 'main' into 125_valid_palindrome

5cc22f2

austyhooong reviewed Aug 14, 2025

View reviewed changes

nodchip reviewed Aug 14, 2025

View reviewed changes

ryosuketc added comments reviewed need re-review labels Aug 14, 2025

nodchip mentioned this pull request Dec 17, 2025

373. Find K Pairs with Smallest Sums hemispherium/LeetCode_Arai60#11

Open

	std::string to_lower_alnum(std::string s) {
	std::string to_lower_alnum(const std::string& s) {

Conversation

ryosuketc commented Aug 13, 2025

125. Valid Palindrome

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants