C++相談室 part152
■ このスレッドは過去ログ倉庫に格納されています
EEPROM知らねえらしいな マジ頭の更新止まってやんのw >>673 呼ばれた側は自動変数かどうかなんて意識する必要ないだろ… それ自動変数へのポインタを引数にして呼ぶ側のコード考えたらわかると思うけど >>674 ん? EEPROM知らないとかどこから出てきたんだ? EP-ROMでバカにされて発狂の図?w >>675 自動変数かどうかわからんものへのアクセスをSP相対にできるのかって話だよ 重箱の隅ではないごく一般的なケースだぞ ここC++スレだぜ? this->すげー多用するんだが UV-EPROMのまま更新が止まった頭じゃ思い至らんかったか >>676 > 自動変数かどうかわからんものへのアクセスをSP相対にできるのかって話だよ だから自動変数へのポインタを求めるのは呼び出し側でSP相対で計算してるだろ 呼ばれた側は単なるアドレスになってるから関係ない C/C++の基礎だぞ、まじでわかってないのか? EP-ROMとか言う前にちょっとは考えろよw >>667 > 8bit時代からの組込み屋でテープもEP-ROMも使ってた このスレ凄い人おるんやな 素直に感心したわ >>678 ごめんなホレリスカード使ってたわ それと2500feetのオープンリールとかね >>678 別に凄くはないよ そういう時代に仕事してたってだけの話 もうすぐ定年だけど正直仕事としては当時の方が面白かったな まあ時代が上り坂だったせいもあるけど >>677 this->がどう翻訳されているのか覗いてみたことがないから スタックへのアクセスはほとんどがSP相対だなんて大きく出たんだろ おまえマジC++でROM焼きしてねえだろ >>681 > this->がどう翻訳されているのか覗いてみたことがないから C++はスタティックとかヒープとかにインスタンス置けるから一概には言えんけど自動変数としてインスタンスを生成したらthisポインタはSP相対になるだろ ならない例があるとでも言うのか? > おまえマジC++でROM焼きしてねえだろ まあC++のROM焼は確かにあまりないな ROM焼きするのは8bitはほぼアセンブラだし、16bitでもC言語だったし ただC言語でもスタック上に生成した構造体へのポインタはC++のthisポインタと同じだしな アセンブルリスト見たらすぐわかる話 >>679 褒めて欲しいん? >>680 謙遜しなさんな(`・ω・´)ゞ 俺も含めてオッサンしかいないスレw オッサン同士仲良くしようぜ。 >>682 C++でROM焼きしてねえんだな? このスレではゴミだぜ、クズだぜ そこ弁えろな、ゴミクズ thisがSPとか寝言ぬかしてんじゃねえ スタックに必要なサイズを求めるのはとても面倒だった。 だから、予め決まった領域を割り当てるのは不可能に近かったので、 データ領域とは逆さまに、データ領域が最後まで使わない部分をスタック 領域とし、暴走しない限りはスタックが足りていると判断する(笑)と言う 当時としては合理的な方法が採用された。 この方式だと、スタックサイズが見積もれなくても、問題が無い。 本等はスタックが足りているかどうかは、暴走したかどうかではなく、 機械語モニタなどで、スタック付近をダンプしてみて、00h以外の値が ある部分がスタックが使用されている領域とみなすことが出来た。 >>682 もちろん、その関数の中ではsp相対になる。 しかし、C言語では、ローカル変数のアドレスを他の関数に渡す。 一方、グローバル変数のアドレスも同じ方式で他の関数に渡す。 で、どちらからきたアドレス化を区別する方法が基本的には無い。 区別するためには、far pointer といって、普通のアドレス以外にセグメントアドレス を合わせた長いポインタを渡す必要があった。 しかし、それは何かと効率が悪かった。 そこで、Windowsは32BIT化したときに、far pointerを使わずに済ますため、 (大体で言えば)セグメントを全て共通のベースアドレスとサイズを持つようにし、 「Full Flat」方式を採用した。 これで、ポインタ渡したり記録したりするための領域が短くて済み、 効率が上がった。 >>685 で、SP相対にならない例はあるんか? >>679 見る限り汎用機のオペレーターさんみたいだからあまり無理すんなw >>689 だからthisな どっから値もらってきたかは関係ねえの わかったか? ゴミクズ >>688 sp 相対アドレッシングって 6809 以外にはなにがあるのですか? >>691 x86系は、[esp+xxx]が使える。 [ebp+xxx]も、ebpを関数の先頭でespを記録するから、同じこと。 >>688 申し訳ないけどfarポインタの話は頓珍漢だしややこしくなるだけだよ セグメントレジスタはSSとDSだけじゃなくてCSやESもあるし、そもそもローカル変数とグローバル変数を区別するためのもんじゃないし >>690 >>663 w けんかをやめて 二人をとめて私のために 争わないで もうこれ以上 thisの話は何をモメてるかよくわからないが、単順にブート時のSP初期化値の変更で 後ろのスタックをアクセスするコードを修正する必要があるかないかという話。 彼はSP相対(←この表現がおかしい?)だから変更する必要がないと言ってる。 まぁ、基本手はにはそうだが、処理系によってはバンク切り替えでスタックエリアが裏に回る可能性も否定できない。 そして今時のカーネル開発のようにコンテキスト保持のために同期てんこ盛りになるわけだ。 >>691 6800とかでもTSX命令でSPをインデックスレジスタにコピーして相対アクセスできる 8080ならSPHLでSPをHLレジスタにコピーできる、オフセットの処理は自前でやるしかないけど まあ6809や8086に比べたらかなり効率悪いコードになるけどね x86のC言語では、スタックに積み込まれた自動変数のデータは、SPが変更されてもスタックフレームを復元すれば、変更前と変わらずアクセスできる。SPの値もプッシュ・ポップできる訳であって。 >>698 > 処理系によってはバンク切り替えでスタックエリアが裏に回る可能性も否定できない。 そんな特殊な例を出されても… 一般的な日本の8bitPCで64KB空間しかないのにROMだけでもあれこれと数百キロバイト積んでるし、 VRAMもでかい。基本、z80も6502もフラットを要求するCとの相性はよくない。 6800てw ワイが学生時代演習で使ったのが68000だったなぁ 今となっては何一つ覚えてないけど >>693 おまえさんが使う空疎な罵倒語とは違うぞ なぜゴミクズなのかきちんと説明したうえで言っているからな >>705 > スタック領域変わったからと言ってSPの初期値以外に一体何を書き換えるんだよw の答えはまだかな? > 許して欲しいならちゃんとそう言えよ > まあ逃げても追わねえでやるけど そのまま返してやるからさw >>706 答えはまだかなって、そもそも俺は聞かれてないんだが? レスの流れをもっぺん追ってみな >>707 お前が誰か知らんがなw 関係ないならいちいち絡んでくるなよ、気持ち悪いわ >>708 では「答えはまだかな」は引っ込めるんだな? しがみついてた梯子を外されて可哀想にw >>709 馬鹿なの? お前に対しては聞かないというだけの話 >>653 が早く答えればいいだけ まあ無理だからゴミクズとか言い出してるんろうけどw >>710 おまえさんがゴミクズなのはC++でROM焼きしてないからだ それをすり替えようったってそうはさせねえよ わかったか? ゴミクズ 何だこいつ? いきなり絡んできて意味不明なこと言い出すとか通り魔かよw ここはC++スレだ ゆえにC++でコード書いてないやつは価値ゼロだ もう一度言う おまえさんがゴミクズなのはC++でROM焼きしてないからだ 8080であろうが6809であろうが関係ない C++でコード書いて得た知見を言え それ以外の戯れ言はいらん >>713 ROM焼きしてないだけでC++はガンガン使ってるけど? thisポインタなんてstructへのポインタを自動生成してるだけ 初期のC++処理系でC言語に変換したコードとか見たことないのか? >>714 おまえさん6800だの8080だの持ち出してドヤってたろ 6800でC++書いてんのかよ? え、おい >>715 6800とか8080の話は>>691 からの流れな 話の流れも読めないバカは黙ってなよw スタック上にある構造体を指すポインタはスタック領域を指すっていう それだけの話で100レス以上も盛り上がれるなんて楽しそうで羨ましい 上から目線で頓珍漢な結論を開陳してる君の方が幸せそうだがw 話の流れも読めないバカがなんか言ってるなw 惨めにならないんだろうか? 上から目線で頓珍漢な結論を開陳 上から目線で頓珍漢な結論を開陳 上から目線で頓珍漢な結論を開陳 >>716 633とかの黒歴史はなかったことにしたいんだろw C++使ったことない環境の話でドヤるなと牽制されて なあID:cdg8K9Zmよ >>722 ん? 633のどこがおかしいの? 結局、 >> 設定値を変えるだけだろとか簡単に言われても困る。 > スタックへのアクセスってよほどトリッキーなことをしない限りSP相対だぞ > スタック領域変わったからと言ってSPの初期値以外に一体何を書き換えるんだよw の回答もないんだけど、君が答えてくれるのかな?w 当初は技術論をぶつけあってるようで興味深く読ませてもらってた 難しくて理解できないことも多かったけど いまはもうただの罵倒合戦になっちゃったね残念です >>723 説明したとおり、昔の処理系は移動した先のスタックエリアがそこに常にあるとは保証されないからその対応は必要。 今はユーザーモードならOSがスレッドコンテキストを保証してるから頭使わないだけ。 >>725 > 説明したとおり、昔の処理系は移動した先のスタックエリアがそこに常にあるとは保証されないからその対応は必要。 申し訳ないけど全然状況が想像できん、具体例で説明してくれ スレッドセーフだったAPIがスレッドセーフじゃなくなりました!! って言われて、はぁ?と言いながらソースを修正する、みたいな。こんな具体例でいいですか? ワイはそこまで昔のことは知らんし、組み込み系の話もわからんけど、 MS-DOS (16bit) 時代のプログラミングの知識だと データの位置はスタックポインタからの相対というだけではなく セグメントレジスタの内容も加算される。 スタックセグメントレジスタとデータセグメントレジスタが一致するときは 単純なのだが、そうでないときはセグメントの値とセグメント内のオフセットを組にして ポインタとして扱わなければならない。 (いわゆる far pointer のこと。 Windows SDK のヘッダファイルの中に near と far がマクロ定義されているのはたぶんそのなごり。) C のプログラムとして書く分にはメモリモデル (セグメントの扱い) を決め打ちして、 コンパイラはそれに従って整合性を取ってくれるから素直な C プログラムなら問題にならないが、 凝ったメモリ管理をしようとするとそう単純にはいかないことはあったかもしれん。 >>727 ごめん、全然わからん そもそもスレッドとかがある時代の話なの? >>728 あなたも書いてる通りfarポインタでも > コンパイラはそれに従って整合性を取ってくれるから素直な C プログラムなら問題にならない のが普通 よほどトリッキーなことをすれば駄目なケースがあるのかも知れんが俺には思いつかん >>730 スタック領域にメモリーコンパクション? 昔の処理系の割にスレッドとかメモリーコンパクションとかなかなか凝ったシステムやねw メモリーコンパクションて昔の処理系でしょ 今の処理系でやるやつあんの?w 昔といえば昔かな、>>725 はもっと昔の話かと思ってたけど で、メモリーコンパクションがどう関係するって? これだけ説明して何も分からないならそれまででしょう。 OSに感謝してC++富豪プログラミングを謳歌してください。 説明できずに遁走 と言うことでいいかなw まあそうだろうとは思ってたけど もちろんだ。それでキミの自尊心が傷つかないで済むならそれでいい。 >>729 ひとつのプログラムの中では整合性は維持されるけど、 別のタスクとやりとりするときにメモリモデルが違うと near pointer と far pointer を明示的に使い分けないといけないことがある。 わかってればとりたてて難しいことではないのだけど、 言語仕様に沿ってれば後はコンパイラにお任せというわけにはいかない。 知ってる必要はあった。 話題の発端 (よりは少し後?) でスタックポインタとの相対番地は 呼出し側で計算するんだから……という話が出ていたので、 他の要素 (セグメント) が絡むアーキテクチャのことを思い出したなぁという余談。 >>739 理解しているだけでなく、far というキーワードを char far *ptr; のように書いたりしなくてはいけなくて、面倒だった。 far ポインタ、今ここで見なければたぶん一生わすれたままだったのに ちなみにMS-DOS時代は全部のセグメントをひとつにまとめた .COM っていう実行形式あったな いまでも動くのかしらんけど >>741 Windows では今でも com 形式を実行できるよ。 環境変数 PATHEXT の Windows でのデフォルト設定を見ればわかるが、先頭に com が入ってる。 (同じ名前であれば exe より com が優先されるということ。) C:\Windows\System32 の下にはいくつか com 形式の実行ファイルはあるし。 ただ (com 形式に限らず) 昔のプログラムは直接にデバイスを叩いていたりして、 さすがにサポートしきれていない場合もあるから、昔のプログラムが何もかもそのまま 動くというほどではない。 >>739 別に一つのプログラムの中でもnearとfarを混在できる メモリーモデルはディフォルトのnear/farを決めてるだけだから異なるメモリーモデルのプログラムを混在させたなら相互に使用するデータやコードには個々にnear/farの指定をする必要があるのは当たり前 それを含めて言語仕様だし >>740 char near * far f(); とか書き方がややこしいのは認める >>743 たとえばC:\Windows\System32\format.comなんかあるけど dumpbin /headers format.comとやると中身はexeだと出てくるぞ masmに付いてたexe2binで出力した本当のtinyモデルのやつは x86までで、x64のwindowsでは実行できんぞ >>745 えっ、そうなんや!? それは知らんかった。 じゃあ拡張子が com なのはなんかの互換性とかの都合なのかな。 format.comはdosの時代からずっと拡張子.comのままだね int 21h, ah=4bhで指定するファイル名が変わると困るから ちなx64で16bitプログラムが実行できないのはm$の恣意的な制限で ホストx64、ゲストx86のvmアンダーなら.com形式のプログラムも実行できる Windows 95 の command.com ですら exe 形式 ライブラリ含むと64KB制限は結構きつい 確か、int 21hのDOS Function Callは、今のWindowsではサポートされなく なったと聞いた様な。 じじいは昔話しだすと止まらなくなる ボケてないんだったら自覚して自重しろ .comはCPMの名残だけど 全セグメントを一つにまとめたってのは ちょっと違くないか? 別に違うセグメントにアクセスしても問題無く動いてたろ? >>754 今でいうセクションみたいなことを言おうとしたんでしょ。 実行環境の話ではなくあくまでもファイルフォーマット。 >>754 たぶん *.com と *.exe の違いはMS-DOS のイメージローダの都合、というものじゃないでしょうか? *.exe はテキストの前に、セグメントアロケーション情報を持っていて、実行ファイルをロードする歳に、関係するセグメントオフセットを実セグメントに変更します *.com にはそれがなく、生のテキストがメモリ上に配置されるだけ *.com であってもプログラマが自分でオフセット・セグメントを把握したり、スタックポインタ・スタックセグメントを設定しているのだったら、それはそれで問題なく動くでしょう 簡単な実験 echo テ>test.com test.com PC9801の頃に、漢字 2字? のファイルを comで保存して、IPLん走らせるみたいのあったな たしかその 4バイトは 0番地に分岐する命令だったような How many files (0-15) ? NEC N88-BASIC Version 2.1 Copyright (C) 1981 by Microsoft 56548 bytes free Ok _DEBUG で区切っているコードがあり、 releaseモードで実行したのに _DEBUGで切っているコードを実行されてしまいます。 プロジェクトプロパティにて宣言していないのは確認しています。 なにか解決になるヒントだけでもいただけないでしょうか? >>763 大ヒント: それはC++の機能じゃない。Visual Studioのスレで聞け。 あとビルド構成 Releaseモードにしたとき自動で入るのはNDEBUGだろ その昔、ソースコードの中で#undefしてる大タコなやつがいた 間接話法による自己紹介とはなんと慎み深いお方なんだ ここ見てるとC++使いは性格悪いのが多いって感じがする 昔はこのスレももっとまともな人が多かったと思うけど、いつの間にか一部のガラの悪い奴らの下らない罵り合いばかり見せられて人が去っていったのかなと思う。 ここで聞くより調べたほうが大抵早いし なんでこんなところに来るのかわかんない 入り組んだ仕様の組み合わせで起こることならともかく、 簡単に調べられることだと回答も仕様 (またはどっかの解説) をコピペするか URL を貼るだけになるからつまらんのだよなー。 そのワンステップ必要? という気持ちにはなる。 本物の初心者がそれすらできないことがあるのも知ってるから、 あまり無碍にはしないようにしてるけど、 つまらんなーという気持ちは残る。 別に質問しに来てるわけじゃないからな 質問する人がどういう経路で来るのか気になる ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる