アカウント名:
パスワード:
こういう問題は授業で定義してる前提条件があるから、授業の外での定義を当てはめてはいけない。(1)だってそう。「情報の最小単位を何といいますか」。「情報」ってなんだよwとなる。
C 言語や Python の実習で strlen や len すれば間違っていると速攻でバレるんだけど、なんて説明するんだ?・・・馬鹿だろ
何を言いたいんだろう・・・
ちなみにlenとstrlenどっちも同じ文字数を返す関数だけど、pythonのlen("abcあいう")は6を返す。全角も半角も「1」cのstrlen("abcあいう")は9を返す。半角は「1」、全角は「2」文字エンコードという前提条件が違うから結果も変わる。
cのstrlen("abcあいう")は9を返す。半角は「1」、全角は「2」文字エンコードという前提条件が違うから結果も変わる。
C11以降のUTF8な処理系なら12だよ。strlenはあくまでバイト数を返す。全角とか半角の区別などない。
リテラル文字列がUTF8認識されるの?うそだろ。そんなの不具合の元じゃん。やめろよ
VC2022だとソースコードがUTF8でもシフトJISとして扱われる。ソースコードを自動でUTF8に変換する機能もあるし、過去のソースとの互換性問題もあるから、そういうものという認識で使ってたけど冷静になって考えてみるととんでも仕様だな。
ソースファイルのエンコーディングと、コンパイル後のオブジェクトファイルに文字列リテラルを埋め込む際のエンコーディング、異なるものを選べることはとんでも仕様とは思えないけど。
たとえばgccだと--input-charsetと--exec-charsetでそれぞれ選べる。
数十年後には負の遺産になりそう今後の世代にさんざ叩かれるんだろうなー
その点では、別に元の話の挙動もVC2022で始まったことではなく、それ以前のバージョンからそうだった。いま軽くググったら、VC2005でBOM無しUTF-8のソースファイルでエラーになるという話が出てきたから、たぶんVC2005からの挙動ではないだろうか。
VC2022かその少し前での変化といえば、gccみたいな/source-charsetや/execution-charsetコマンドラインオプションが増えたことかな。それ以前はオプションでは選べなくて、おそらくコンパイル時のWindowsの言語によって決まっていたのだと思われる。
全部UTF-8にするには/utf-8オプション(なお/source-charset:utf-8 /execution-charset:utf-8と指定することとと同じとドキュメントに書いてある)を指定したり、#4279029に書いてあるu8プレフィックスで個別にUTF-8文字列リテラルにしたりという方法となる。
MSVCは以前から #pragma execution_character_set を使えば実行時の文字コードを指定できましたよ。ただ、pragma の書かれたソースコードだけに有効なので、混在するとひどい目に遭いますが。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「科学者は100%安全だと保証できないものは動かしてはならない」、科学者「えっ」、プログラマ「えっ」
前提条件がある (スコア:1)
こういう問題は授業で定義してる前提条件があるから、授業の外での定義を当てはめてはいけない。
(1)だってそう。「情報の最小単位を何といいますか」。「情報」ってなんだよwとなる。
Re: (スコア:0)
C 言語や Python の実習で strlen や len すれば
間違っていると速攻でバレるんだけど、なんて説明するんだ?
・・・馬鹿だろ
Re: (スコア:0)
何を言いたいんだろう・・・
ちなみにlenとstrlenどっちも同じ文字数を返す関数だけど、
pythonのlen("abcあいう")は6を返す。全角も半角も「1」
cのstrlen("abcあいう")は9を返す。半角は「1」、全角は「2」
文字エンコードという前提条件が違うから結果も変わる。
Re: (スコア:0)
cのstrlen("abcあいう")は9を返す。半角は「1」、全角は「2」
文字エンコードという前提条件が違うから結果も変わる。
C11以降のUTF8な処理系なら12だよ。
strlenはあくまでバイト数を返す。全角とか半角の区別などない。
Re: (スコア:0)
リテラル文字列がUTF8認識されるの?うそだろ。そんなの不具合の元じゃん。やめろよ
Re:前提条件がある (スコア:0)
VC2022だとソースコードがUTF8でもシフトJISとして扱われる。
ソースコードを自動でUTF8に変換する機能もあるし、過去のソースとの互換性問題もあるから、そういうものという認識で使ってたけど冷静になって考えてみるととんでも仕様だな。
Re: (スコア:0)
ソースファイルのエンコーディングと、コンパイル後のオブジェクトファイルに文字列リテラルを埋め込む際のエンコーディング、異なるものを選べることはとんでも仕様とは思えないけど。
たとえばgccだと--input-charsetと--exec-charsetでそれぞれ選べる。
Re: (スコア:0)
数十年後には負の遺産になりそう
今後の世代にさんざ叩かれるんだろうなー
Re: (スコア:0)
その点では、別に元の話の挙動もVC2022で始まったことではなく、それ以前のバージョンからそうだった。いま軽くググったら、VC2005でBOM無しUTF-8のソースファイルでエラーになるという話が出てきたから、たぶんVC2005からの挙動ではないだろうか。
VC2022かその少し前での変化といえば、gccみたいな/source-charsetや/execution-charsetコマンドラインオプションが増えたことかな。それ以前はオプションでは選べなくて、おそらくコンパイル時のWindowsの言語によって決まっていたのだと思われる。
全部UTF-8にするには/utf-8オプション(なお/source-charset:utf-8 /execution-charset:utf-8と指定することとと同じとドキュメントに書いてある)を指定したり、#4279029に書いてあるu8プレフィックスで個別にUTF-8文字列リテラルにしたりという方法となる。
Re: (スコア:0)
MSVCは以前から #pragma execution_character_set を使えば実行時の文字コードを指定できましたよ。
ただ、pragma の書かれたソースコードだけに有効なので、混在するとひどい目に遭いますが。