私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレ+ JavaScript の質問用スレッド vol.141 +
JavaScript スレッド一覧へ / JavaScript とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 :
レスフィルター : (試験中)
コードは長くなるけど変数使わないからメモリ消費しないんだぜ！
↑
そのコードを入れておくメモリが消費される
↑
そのコードを入れておくメモリが消費される
>>100
この質問の本質は、そういうコードを書きたくないということでしょう？
この質問の本質は、そういうコードを書きたくないということでしょう？
結局何をしたいのか分からん
C言語だって char *a = "abc"; と書いたとき、ポインタ a の分だけメモリ喰うわけだしな
したいことと、典型的なコードでなってしまうことの差が
具体的に分からないと何ともいえない
http://jsbin.com/yemedon/edit?html,js,console
こういうのとは違うみたいだし
C言語だって char *a = "abc"; と書いたとき、ポインタ a の分だけメモリ喰うわけだしな
したいことと、典型的なコードでなってしまうことの差が
具体的に分からないと何ともいえない
http://jsbin.com/yemedon/edit?html,js,console
こういうのとは違うみたいだし
無理矢理いえば test() の返値は必ず入る
アセンブラのときにレジスタに必ず入るかどうかは知らない
0 との比較の場合はアセンブラ的には即値0が必要とならないケースが多い、はず
RISCでどうなるか等は知らない
サボリのためCASLの仕様書は読んでない
アセンブラのときにレジスタに必ず入るかどうかは知らない
0 との比較の場合はアセンブラ的には即値0が必要とならないケースが多い、はず
RISCでどうなるか等は知らない
サボリのためCASLの仕様書は読んでない
変数は必ずしもメモリを消費しない
インライン化とエリミネーションで半分程度削減される
だからデバッガを有効にしてるとメモリを食う
インライン化とエリミネーションで半分程度削減される
だからデバッガを有効にしてるとメモリを食う
> 私は、いちいち if (element) element.value="piyo"; というふうな中身の確認をせずに、代入をできるようにしたい
そもそも、これって vanilla JS で実現できるの？
そもそも、これって vanilla JS で実現できるの？
入力があって、出力対象となるべき要素がなければ
parentNode に appendChild() するのが自然な考え方にもおもえる
無視して良いという仕様なのだろうか（そうだとしたら while で終わりか？）
メモリどうこうより仕様が気になるな
それとも「じつはライブラリ房でした」というオチなのか
parentNode に appendChild() するのが自然な考え方にもおもえる
無視して良いという仕様なのだろうか（そうだとしたら while で終わりか？）
メモリどうこうより仕様が気になるな
それとも「じつはライブラリ房でした」というオチなのか
Rubyには通称ぼっち演算子っていってね、
a=nil
a&.foo
# =>nil
みたいに、値がnilでもエラーにならない方法があるんだよ。
どうせこれのこと言ってるんっでしょ？
でもね、コード上メモリを使ってないように見えても、
アセンブラレベルで見れば「if nil だったら nil を返す」って
コードになってて、コードの分のメモリ使ってますからｗ
a=nil
a&.foo
# =>nil
みたいに、値がnilでもエラーにならない方法があるんだよ。
どうせこれのこと言ってるんっでしょ？
でもね、コード上メモリを使ってないように見えても、
アセンブラレベルで見れば「if nil だったら nil を返す」って
コードになってて、コードの分のメモリ使ってますからｗ
イケてる言語のNull条件演算子：
C#
?.
Swift
?.
Kotlin
?.
イケテナイ言語のNull条件演算子：
ﾌﾞﾋﾞｨ
&.
ムダな認知負荷の大きいクソ言語。
C#
?.
Swift
?.
Kotlin
?.
イケテナイ言語のNull条件演算子：
ﾌﾞﾋﾞｨ
&.
ムダな認知負荷の大きいクソ言語。
http://jsbin.com/hidafon/edit?html,css,js,output
ふむ…
あろうが無かろうが問題なく書ける場合もある、か
むしろ出力先等が無いのにスルーされると、バグが潜在化しそうな気もするけど、まあいいか
どういう場面で幸せになれる実装なのか分からん
strlcat / strlcpy みたいなものかしらん
ふむ…
あろうが無かろうが問題なく書ける場合もある、か
むしろ出力先等が無いのにスルーされると、バグが潜在化しそうな気もするけど、まあいいか
どういう場面で幸せになれる実装なのか分からん
strlcat / strlcpy みたいなものかしらん
> むしろ出力先等が無いのにスルーされると、バグが潜在化しそうな気もするけど、
それは設計思想がわかってないから。
CSSと同じだと考えればいい。
CSSは要素があろうがなかろうがエラーにならない。
これは宣言型プログラミングの思想だよ。
http://ja.wikipedia.org/wiki/%E5%AE%A3%E8%A8%80%E5%9E%8B%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0
> 宣言型プログラミング（英: Declarative programming）は、
> プログラミングパラダイムの名称だが、主として2種類の意味がある。
> 第1の意味は、処理方法ではなく対象の性質などを宣言することでプログラミングするパラダイムを意味する
出力先に対して処理するという設計思想ではない。
出力先はどういう性質かというのを記述する。
要素に対して値を入れるのではなく、その要素はこういう値であるという宣言を記述する。
そうすることでその要素があればそういう値であり、要素がなければないというだけの話になる。
処理ではなく宣言なのでわかりやすくバグも少なくなる。
それは設計思想がわかってないから。
CSSと同じだと考えればいい。
CSSは要素があろうがなかろうがエラーにならない。
これは宣言型プログラミングの思想だよ。
http://ja.wikipedia.org/wiki/%E5%AE%A3%E8%A8%80%E5%9E%8B%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0
> 宣言型プログラミング（英: Declarative programming）は、
> プログラミングパラダイムの名称だが、主として2種類の意味がある。
> 第1の意味は、処理方法ではなく対象の性質などを宣言することでプログラミングするパラダイムを意味する
出力先に対して処理するという設計思想ではない。
出力先はどういう性質かというのを記述する。
要素に対して値を入れるのではなく、その要素はこういう値であるという宣言を記述する。
そうすることでその要素があればそういう値であり、要素がなければないというだけの話になる。
処理ではなく宣言なのでわかりやすくバグも少なくなる。
>>113
> 「関数を書きたくない」というなら、巨大な関数である jQuety()を定義しているコードに魅力を感じるのは
jQueryを使うなら「関数を書かなくていい」じゃん
「関数を書きたくない」という要望を見事に満たしている。
> 「関数を書きたくない」というなら、巨大な関数である jQuety()を定義しているコードに魅力を感じるのは
jQueryを使うなら「関数を書かなくていい」じゃん
「関数を書きたくない」という要望を見事に満たしている。
>>114
「メモリも食わない」の要件を満たしてないじゃん
「メモリも食わない」の要件を満たしてないじゃん
>>116
それは「すべてのものはメモリを食う」という結論で終わったろ？
それは「すべてのものはメモリを食う」という結論で終わったろ？
そもそも、>>102は質問者なのか？
他人が悪のりしてるのか、質問者本人なのか分からん
他人が悪のりしてるのか、質問者本人なのか分からん
>>118
メモリ消費量が違う
メモリ消費量が違う
そんな面倒くさがりの君にプレゼント
Object(element).value = 'bar';
ライブラリ使うよりお手軽だよ！
メソッド呼び出しは要件にないから知らないよ！
そもそも、NullPointerExceptionはエラー検知として捉える向きもあるので、一概に悪いとはいえない(上で懸念されてるのはそういうことかと)
ポリシーの違いを他人を批判する理由にするのは止めよう >>1参照
Object(element).value = 'bar';
ライブラリ使うよりお手軽だよ！
メソッド呼び出しは要件にないから知らないよ！
そもそも、NullPointerExceptionはエラー検知として捉える向きもあるので、一概に悪いとはいえない(上で懸念されてるのはそういうことかと)
ポリシーの違いを他人を批判する理由にするのは止めよう >>1参照
無いときにエラーにしたくなくて、あるときに全ての要素を対象にしたければ
DOM APIには複数要素取得する手段がいくつもあるんだから
それでmapなんかで回せばいいだけじゃん
DOM APIには複数要素取得する手段がいくつもあるんだから
それでmapなんかで回せばいいだけじゃん
>>112
どうだろう
CSS はデザインの話で、コンテンツそのものの話とは区別されるんじゃないかと
> 出力先はどういう性質かというのを記述
これなんてまさにそれ
オブジェクトのプロパティに値をセットしたつもりが
そもそもオブジェクトありませんでしたー
でエラーが出なくて幸せになる具体的なシーンが思いつかない、というのもある
「『対象の性質を宣言』しようとしましたが、その対象は存在しませんでした」ってことでしょう？
どうだろう
CSS はデザインの話で、コンテンツそのものの話とは区別されるんじゃないかと
> 出力先はどういう性質かというのを記述
これなんてまさにそれ
オブジェクトのプロパティに値をセットしたつもりが
そもそもオブジェクトありませんでしたー
でエラーが出なくて幸せになる具体的なシーンが思いつかない、というのもある
「『対象の性質を宣言』しようとしましたが、その対象は存在しませんでした」ってことでしょう？
>>129
モダンブラウザは皆対応してる
モダンブラウザは皆対応してる
>>130-131
便利な世の中になったね
便利な世の中になったね
>>137
詳しく
詳しく
jQueryが消費するメモリ
→大した消費量じゃない！
自前で関数ちょこっと書くのに消費するメモリ→
とんでもないメモリ消費！
→大した消費量じゃない！
自前で関数ちょこっと書くのに消費するメモリ→
とんでもないメモリ消費！
その煽る気満々の内容で質問者に回答してやればいいのに、これだからマウント君は
>>137
ES全体的に前みたいに大量の草案をガツガツ進める雰囲気じゃなくて
細かい仕様をより小規模なミーティングを頻繁にして少しづつ着実に落ち着いて進める感じになってる
その上でオプショナルチェーンの進歩状況はやや鈍調
本来なら輸入構文で順調に行くはずだけど、
ついでにこれもセットで欲しい機能のオプショナルコールについて問題を抱えていたので
あまり進捗してこなかったのが、直近のミーティングで前に進んだ
もう一山か二山あるだろうけど、ゴールの明かりがちらりと見えた所
ES全体的に前みたいに大量の草案をガツガツ進める雰囲気じゃなくて
細かい仕様をより小規模なミーティングを頻繁にして少しづつ着実に落ち着いて進める感じになってる
その上でオプショナルチェーンの進歩状況はやや鈍調
本来なら輸入構文で順調に行くはずだけど、
ついでにこれもセットで欲しい機能のオプショナルコールについて問題を抱えていたので
あまり進捗してこなかったのが、直近のミーティングで前に進んだ
もう一山か二山あるだろうけど、ゴールの明かりがちらりと見えた所
firefox x64 + Stylus + Greasemonkey
とあるよく利用しているサイトが今一つ使いづらいので、
Stylusの自作スクリプトで必要以上の余計な広告を非表示にし、
非同期処理させて処理の高速化を図りました。
改めてそのサイトのソースを見たらsetTimeoutで特定の広告を少し時間差を置いて表示させ、
更に時間差を置いて記事部分を表示させるなんてことをやっていることが判明。
即時表示させる手段はないかと、StylusかGreasemonkeyでsetTimeoutの無効化とか、
そのスクリプト自体の上書きか無効化が出来ないか試行錯誤中。
どなたか、何かアドバイスなど頂ければ幸いです。
とあるよく利用しているサイトが今一つ使いづらいので、
Stylusの自作スクリプトで必要以上の余計な広告を非表示にし、
非同期処理させて処理の高速化を図りました。
改めてそのサイトのソースを見たらsetTimeoutで特定の広告を少し時間差を置いて表示させ、
更に時間差を置いて記事部分を表示させるなんてことをやっていることが判明。
即時表示させる手段はないかと、StylusかGreasemonkeyでsetTimeoutの無効化とか、
そのスクリプト自体の上書きか無効化が出来ないか試行錯誤中。
どなたか、何かアドバイスなど頂ければ幸いです。
元あるものを改変するのではなく記事の内容を取得して表示するリーダーアプリを作ったほうが聡い
…もともとがRuby房召喚のためだけの質問っぽいけど…
>>112
> 出力先はどういう性質かというのを記述する。
element がらみの場合は DOM ツリーの適切な場所に適切な要素を記述し
その要素にその性質を記述するものではないのかしらん
まとめたければ DocumentFragment 使うとか、元質問に即して言えば事前に createElement すれば良いんでないかい
ただ、元質問は「対象が存在しないときにスルー」って言ってるんだから「宣言型プログラミング」とやらは今回別に要らないでしょ
コレクションのアイテム数を数え、アイテム数を越える分は処理しなければ良いだけ
…ってのを >>111 のリンク先で書いてみたんだが…
>>112
> 出力先はどういう性質かというのを記述する。
element がらみの場合は DOM ツリーの適切な場所に適切な要素を記述し
その要素にその性質を記述するものではないのかしらん
まとめたければ DocumentFragment 使うとか、元質問に即して言えば事前に createElement すれば良いんでないかい
ただ、元質問は「対象が存在しないときにスルー」って言ってるんだから「宣言型プログラミング」とやらは今回別に要らないでしょ
コレクションのアイテム数を数え、アイテム数を越える分は処理しなければ良いだけ
…ってのを >>111 のリンク先で書いてみたんだが…
>>94
?. は、NULL 許容(エルビス)演算子だろ。
横から見ると、エルビスプレスリーに見える
Ruby では、関数名の最後の文字に、?, ! が使える
? は、真偽値を返すメソッド名に使う。
! は、レシーバーの内容を変えるメソッド名に使う
このルールがあるから、可読性が高い！
その代わりに、エルビスが使えないから、&. を使う
?. は、NULL 許容(エルビス)演算子だろ。
横から見ると、エルビスプレスリーに見える
Ruby では、関数名の最後の文字に、?, ! が使える
? は、真偽値を返すメソッド名に使う。
! は、レシーバーの内容を変えるメソッド名に使う
このルールがあるから、可読性が高い！
その代わりに、エルビスが使えないから、&. を使う
前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ
/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで / 
JavaScript スレッド一覧へ類似してるかもしれないスレッド
- + JavaScript の質問用スレッド vol.141 + (881) - [100%] - 2021/4/19 9:00
- + JavaScript の質問用スレッド vol.131 + (1004) - [97%] - 2018/3/7 13:30
- + JavaScript の質問用スレッド vol.121 + (1001) - [97%] - 2015/1/1 18:30
- + JavaScript の質問用スレッド vol.121 + (1001) - [97%] - 2022/11/29 16:30
- + JavaScript の質問用スレッド vol.131 + (1000) - [97%] - 2017/1/25 8:01
- + JavaScript の質問用スレッド vol.142 + (984) - [97%] - 2020/8/27 19:15
- + JavaScript の質問用スレッド vol.111 + (1001) - [97%] - 2013/11/4 6:00
- + JavaScript の質問用スレッド vol.101 + (1001) - [97%] - 2012/7/16 14:15
- + JavaScript の質問用スレッド vol.144 + (288) - [97%] - 2020/5/17 20:00
- + JavaScript の質問用スレッド vol.143 + (753) - [97%] - 2020/4/19 5:00
- + JavaScript の質問用スレッド vol.140 + (1001) - [97%] - 2019/9/19 10:45
- + JavaScript の質問用スレッド vol.142 + (926) - [97%] - 2019/12/23 13:15
- + JavaScript の質問用スレッド vol.115 + (1001) - [95%] - 2014/5/29 16:16
- + JavaScript の質問用スレッド vol.123 + (966) - [95%] - 2020/10/20 2:30
- + JavaScript の質問用スレッド vol.122 + (116) - [95%] - 2018/5/2 18:30
- + JavaScript の質問用スレッド vol.122 + (1004) - [95%] - 2015/2/14 4:45
- + JavaScript の質問用スレッド vol.120 + (1002) - [95%] - 2014/11/8 1:15
トップメニューへ / →のくす牧場書庫について