206. Reverse Linked List #8

Ryotaro25 · 2024-05-26T07:25:25Z

問題へのリンク
https://leetcode.com/problems/reverse-linked-list/description/
問題文(プレミアムの場合)

備考

次に解く問題の予告
Kth Largest Element in a Stream

フォルダ構成
LeetCodeの問題ごとにフォルダを作成します。
フォルダ内は、step1.cpp、step2.cpp、step3.cppとmemo.mdとなります。

memo.md内に各ステップで感じたことを追記します。

fhiyo · 2024-05-26T14:23:16Z

206.ReverseLinkedList/memo.md

+空間計算量
+O(1)


O(ノード数) だと思います

@fhiyo
レビュー有難うございます。全て開始側のブラケットの場合O(n)になりますね。失礼しました。
下記にて修正しました。
fb59e1a

fhiyo · 2024-05-26T14:42:35Z

206.ReverseLinkedList/step1.cpp

+ *     ListNode(int x, ListNode *next) : val(x), next(next) {}
+ * };
+ */
+#include <stack>


includeディレクティブのブロックの終わりの後は1行空ける方が主流だと思います。
(いまいち参考になるリンクが見つからなかった)

大体1行空いていますね。https://source.chromium.org/chromium/chromium/src/+/main:base/hash/hash.h
なおLeetCode上ではincludeは不要です。

@fhiyo @liquo-rice
レビュー有難うございます。LeetCodeではヘッダーファイルの読み込みとusing namespace stdが自動的に行われているのですね。

step1に対する修正をstep4.cppに、step3に対する修正をstep5.cppに追加しました。
fb59e1a

fhiyo · 2024-05-26T14:50:18Z

206.ReverseLinkedList/step2.cpp

+        }
+
+        stack<ListNode*> vals;
+        while (head) {


15行目では head == nullptr としているので、どちらかに統一した方が良いと思います。

@fhiyo
head もしくは!headに統一しました。

fhiyo · 2024-05-26T15:01:36Z

206.ReverseLinkedList/step2.cpp

+            return head;
+        }
+
+        stack<ListNode*> vals;


ListNodeへのポインタが格納されるstackの変数名としてvalsは少し分かりにくい気がします。
nodesでどうでしょうか

@fhiyo
nodesに変更しました。もう少し伝わるよう考えないとですね。

fhiyo · 2024-05-26T15:13:18Z

206.ReverseLinkedList/step1.cpp

+        ListNode* reverse_node = new ListNode();
+        node = reverse_node;


ヒープにメモリを確保する必要がなさそうです。今のコードだとreverse_nodeはメモリリークしますね

Suggested change

ListNode* reverse_node = new ListNode();

node = reverse_node;

ListNode reverse_node = ListNode();

node = &reverse_node;

参考：
automatic storage duration (stack) vs dynamic storage duration (heap)
https://en.cppreference.com/w/cpp/language/storage_duration
https://en.wikipedia.org/wiki/Automatic_variable

@fhiyo @liquo-rice
指摘&&資料有難うございます。
メモリに対する意識がまだ低いようです。

質問です。
new演算子を使う場合は、deleteをつける対応でも良いのでしょうか？
もしくはheapメモリを使う必要のない場合はできるだけstackメモリを使うものでしょうか？

もしくはheapメモリを使う必要のない場合はできるだけstackメモリを使うものでしょうか？

自分は基本こっちだと思っています。ヒープにメモリを確保するのは単にスタックポインタをずらすだけのローカル変数の定義よりもコストがかかるので。あとnewするとどこでそのメモリを解放するのかを気にするので読み手の負荷が高くなる気はします

nittoco · 2024-05-26T15:35:29Z

206.ReverseLinkedList/step3.cpp

+        if (head == nullptr) {
+            return head;
+        }
+


この例外処理なくても結果的に通りますね。
あった方が安心感はあるのかもしれません。

あと気にするとしたら、stack, ListNode のコンストラクタが走るので、これはあってもいいかもしれません。

while (head) としているので、if (!head) のほうが統一感があるかもしれません。

@nittoco @oda
統一しました。何度か注意されているので、意識づけられるように工夫します。
step1に対する修正をstep4.cppに、step3に対する修正をstep5.cppに追加しました。
fb59e1a

nittoco · 2024-05-26T15:36:45Z

206.ReverseLinkedList/step3.cpp

+        while (head) {
+            vals.push(head);
+            head = head->next;
+        }


個人的なものですが、headという変数が動くのは違和感があります

nodeの変数を使うようにしました。

liquo-rice · 2024-05-26T15:46:04Z

206.ReverseLinkedList/memo.md

+new演算子を使えばコンストラクターによって次のnodeにnullptrを設定してくれる。
+
+## 他の解法
+他には、再帰や特別な構造を使わないでポインタの付け替えだけでの対応などがあった。


別解も実装してみてください。

@liquo-rice
memoに記載漏れておりすみません。
iterative.cpp内に実装しております。
LeetCodeの回答タイトルがrecursionとなっていたので再帰かなと思ったのですが中身は、ポインタの付け替えで同じものでした🙇

oda · 2024-05-27T11:03:03Z

206.ReverseLinkedList/step3.cpp

+            head = head->next;
+        }
+
+        ListNode* reverse_node = new ListNode();


これはメモリーリークします。
ListNode reverse_node;
ListNode* node = &reverse_node;

@oda
fhiyoさん、liquo-riceさんのお二人からも指摘頂いておりました。まだメモリに対する意識が低いです。

質問です。
new演算子を使う場合は、deleteをつける対応でも良いのでしょうか？
もしくはheapメモリを使う必要のない場合はできるだけstackメモリを使うものでしょうか？
heapを使わないといけないタイミングに遭遇したことがないのですが。

うーむ。これ、一発レッドカード級なのですが、結構複雑な話なので調べてください。調べた結果もまとめて欲しいです。

@oda @fhiyo @liquo-rice
stackとheapについて調べてみました。

前提としてメモリリークの対策として、オブジェクトは可能な限りスタックに置くべき。

参照
メモリリークに対する対応議論
https://stackoverflow.com/questions/76796/general-guidelines-to-avoid-memory-leaks-in-c

他にも下記のような問題がございました。
ヒープのデメリット面
・処理時間がstackに比べて遅い
・メモリの解法はプログラマーが行う必要がある(fhiyoさん指摘の読み手の負荷が高くなることにも繋がるのかと思いました。)
・使用するメモリのサイズが大きい
・スレッドセーフでない(ABA問題など)

参照
stackとheapの比較
https://www.geeksforgeeks.org/stack-vs-heap-memory-allocation/
スレッドセーフについて
https://docs.oracle.com/cd/E19455-01/806-5257/6je9h033e/index.html
ABA問題
https://en.wikipedia.org/wiki/ABA_problem

結論
heapを使うことによりデメリットを考慮すると、どうしても使う必要があるとき以外はstackを使う。
そもそものメモリリークの対応策としてheapにオブジェクトを置かない方がいい。

どのような場面でHeapは必要になりますか？

@liquo-rice
再度独習c++を読み直してみました。Heap(new演算子)を使うタイミングは以下の二点。
・スコープから抜けた場合であっても破棄させない場合
・メモリを動的に確保したい場合

具体例が欲しかったので、改めて過去にnew演算子を使う必要がないと指摘を受けた箇所を見直しました。
別ページとなります🙇
step4.cpp
ここでのListNode dummy_head;は実際のオブジェクトを保持しているわけではなく、先頭のポインタを指し示すだけなのでnew演算子は必要ないです。
逆にそれ以降のforループないでは、heapに保存しておかないとスコープから出た場合(ここではforループ)にメモリの解放が行われるので値の参照を行うことが出来ません。

こちらには他の関数に渡したいときなどとございました。
https://stackoverflow.com/questions/5082680/when-should-i-use-the-new-operator-in-c

認識合ってますでしょうか？

オブジェクトのライフタイムをスコープと関連付けない場合については正しい理解だと思います。

メモリを動的に確保したい場合

メモリを動的に確保したいのは、具体的にはどんな時ですか？

ここでのListNode dummy_head;は実際のオブジェクトを保持しているわけではなく、先頭のポインタを指し示すだけなのでnew演算子は必要ないです。

この説明は少し怪しい気がします。「実際のオブジェクトを保持しているわけではなく」とはどういうことですか？

メモリを動的に確保したいのは、具体的にはどんな時ですか？

　入力値に左右される配列を扱う場合でしょうか。特段の理由がない限りコンテナクラスを使うと独習c++に記載ございました。
どういった場合に配列を使う必要があるのか調べてみました。
「下位レベルのレイヤーでは、動的確保で作成できるデータ構造は原始的な配列のみである。」と以下のページに記載ございました。これは知りませんでした。
https://ja.wikipedia.org/wiki/%E5%8B%95%E7%9A%84%E3%83%A1%E3%83%A2%E3%83%AA%E7%A2%BA%E4%BF%9D

「実際のオブジェクトを保持しているわけではなく」とはどういうことですか？

実際のオブジェクトを保持しているわけではなくというのはおかしいですね、、、dummy_headが動的にオブジェクトを追加しているのではなく、forループ内の各nodeがnew演算子を使って動的にメモリを確保しています。実際にはオブジェクトを保持していますが、それはnodeの先頭のポインターです。なかなか難しいですね。

finish problem7

75ad74f

fhiyo reviewed May 26, 2024

View reviewed changes

nittoco reviewed May 26, 2024

View reviewed changes

liquo-rice reviewed May 26, 2024

View reviewed changes

oda reviewed May 27, 2024

View reviewed changes

modify

fb59e1a

rihib mentioned this pull request Jun 23, 2024

Reverse Linked List rihib/leetcode#2

Merged

add step6

ff89134

Ryotaro25 merged commit 0790ce7 into main May 14, 2025

		ListNode* reverse_node = new ListNode();
		node = reverse_node;

		空間計算量
		O(1)

206. Reverse Linked List #8

206. Reverse Linked List #8

Uh oh!

Conversation

Ryotaro25 commented May 26, 2024

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!

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!

Ryotaro25 Jun 2, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Ryotaro25 Jun 2, 2024 •

edited

Loading