HSPポータル
サイトマップ お問い合わせ


HSPTV!掲示板


未解決 解決 停止 削除要請

2015
0401
y.tackポインタの意味(CからHSPへ翻訳する時)7未解決


y.tack

リンク

2015/4/1(Wed) 22:41:59|NO.68293

現在CからHSPへ翻訳中なのですが
ポインタをどう表現するかあんまりわからないです

こんなかんじだと思いながらコーディングしてるんですけど
間違っていたらご指摘ください

1)
char* many_ch;
文字列っぽいデータがあってそこへのポインタ

2)
char** of_many_ch;
例えばmany_chへのポインタとか

3)
long long*
char* many_ch;のlong long int版

4)
int*
int変数へのポインタ

1と3 2と4が似てるかんじでOKですか?

void (**instruction_function)(char * parameter, int size);
関数ポインタっぽいけど全然わかんないです

*buffer = calloc(size, sizeof(char) + 1)
callocとmallocがどう違っているかわかってないです



この記事に返信する


anal

リンク

2015/4/1(Wed) 23:02:58|NO.68296

void (**instruction_function)(char * parameter, int size);

void a(char* p,int i){}

auto xx = a;
instruction_function x = &xx;

callocはスタックにメモリを管理する。
callocはfreeしなくてよいかわりに、その関数を抜けると自動的にメモリが消える
あと、大きい領域を確保するとスタックオーバフローする
mallocはヒープから確保する。



ht_ask

リンク

2015/4/1(Wed) 23:16:57|NO.68297

HSPでいうところのvarptrで取得できる値がその変数が使用しているメモリアドレスです。
そのメモリアドレスを格納する変数のことをポインタと呼びます。
用途は主に参照型です。HSPでは一般にdup/dupptrや#deffuncにvarを指定することで代用します。

> 1)
> char* many_ch;
> 文字列っぽいデータがあってそこへのポインタ
半分間違いです。文字列ではなく文字へのポインタです。
おさらいですが、Cは文字列をchar型の配列で管理しています。charは1バイトです。
HSPでいえば、一文字しか格納できない文字列型変数の配列によって文字列を管理し、
その配列の終端には通常は\0(文字コードだと0x00)が格納されるようになっています。
char str[64]; // 63バイト分の文字列(64バイト目は終端文字に使用する)
HSPと同様に、str[0] == str です。ゆえに配列の受け渡しはstrではなくstrのポインタで行います。

2, 3, 4は特にダメ出しする気にはなりませんでしたが、
1が3に似てて2や4に似ていないという理屈が分からないので、きっとどこか認識がおかしいと思います。

> void (**instruction_function)(char * parameter, int size);
> 関数ポインタっぽいけど全然わかんないです
HSPには関数型がないのでコールバックにはラベル型変数を使うしかありません。
一応訳すと、「char*型とint型の引数を持ち、戻り値の存在しない関数のポインタ」のポインタです。

> *buffer = calloc(size, sizeof(char) + 1)
> callocとmallocがどう違っているかわかってないです
callocはバッファを0で初期化しますが、mallocは初期化しません。
mallocだとHSPでいえば、dim a, 16 : mes a.0 とやったときに0が表示されるとは限らないということです。



ht_ask

リンク

2015/4/1(Wed) 23:25:12|NO.68300

> analさん
callocがスタック領域を消費するなんて仕様ありましたっけ?
浅学なので間違っていたらすみません。



y.tack

リンク

2015/4/1(Wed) 23:40:51|NO.68302

返信ありがとうございます

>ht_ask様
HSPに置き換えて考えると

1:sdim many_ch,64
3:Longint many_ch(64)

2:gv_of_many_ch=0:of_many_ch=gv_of_many_ch
4:gv_int=0:ptr_int=gv_int

なかんじで似てるかな。と
グローバル変数じゃなく
dupかsetter/getter
を使った方がいいのかは 思案中です

しかし
>用途は主に参照型です。HSPでは一般にdup/dupptrや#deffuncにvarを指定することで代用します。
と書いていましたですね



科学太郎

リンク

2015/4/2(Thu) 08:55:23|NO.68303

> > analさん
> callocがスタック領域を消費するなんて仕様ありましたっけ?
> 浅学なので間違っていたらすみません。
こちらも同意見です。
analさんは、何か別のものと思い違いをしていそうですね。
malloc、calloc はヒープ領域からメモリを確保しますが、
malloca、alloca はスタック領域からメモリを確保します。

これと混同してると思います。

・malloc
http://ja.wikipedia.org/wiki/Malloc#.E5.8E.9F.E7.90.86

昔は非標準関数がたくさんありましたね。
スタック領域からメモリを確保して、解放しなくて済む関数を知ったとき便利だと思いました。

y.tackさんへ
> なかんじで似てるかな。
ちょっと違うと思いますね。

> 1:sdim many_ch,64
> 3:Longint many_ch(64)
これは正しそうです。
Longint が long long int をサポートした何かなのでしょうね。

> 2:gv_of_many_ch=0:of_many_ch=gv_of_many_ch
違いますね。
「char** of_many_ch;」は「char*of_many_ch;」へのポインタと解釈します。
そうすると「char*」がHSPでは文字列型と解釈できるので文字列型へのポインタとなり、
sdim s
dup ps,s
ですか。

> 4:gv_int=0:ptr_int=gv_int
こちらも
dim n
sup pn,n
ですね。

ユーザ定義命令などでは「char** of_many_ch;」を「array」にして「int*」は「var」ですか。
つまり、「var」とは「void*」で void とは万能型を意味して char、int、short、long、float、double などが当てはまります。
HSPは変数は代入する記述で整数型(int)、実数型(double)、文字列型(str)になるのでC言語の void 型と見ることができます。
だから「var」はどの型にも当てはまる「void*」となるわけです。

よって

int* a var a short* a var a long* a var a float* a var a double* a var a
ただし「char*」は文字列と解釈すべきですから「char* s」は「str s」にすべきかな。



y.tack

リンク

2015/4/5(Sun) 16:30:00|NO.68396

返信ありがとうございます

僕自身ポインタに関しては独習Cでザックリ読んだくらいなので
>半分間違いです
>ちょっと違うと思いますね。
が、ガッツリあてはまってて 反論すべきではないです

>Longint が long long int をサポートした何かなのでしょうね。
Longint は公式サイトに載ってるプラグインで
多倍長整数で(たぶん)64bit整数の かわりに使ってます
勝手にintとして扱って不具合出ても手に負えなそうなので

> 2:> 4:
配列を示すっぽい処理じゃなさそうなので 変数でっちあげただけで
あてはまってなくとも 反論できないです

>> 4:gv_int=0:ptr_int=gv_int
>こちらも
>dim n
>sup pn,n
>ですね。
配列っぽくないな。とは思いましたが
配列っぽいのと 変数を指し示すのと
用途は絞れないみたいな印象ですね
sup は dup のタイポですか?

>HSPには関数型がないのでコールバックにはラベル型変数を使うしかありません。
なんとなくですが 同意です

>callocはバッファを0で初期化しますが、mallocは初期化しません。
動的に確保するのではなく最初に一回確保するだけなので
速度かわらなさそうなのでcallocが使われているのかもしれませんね



科学太郎

リンク

2015/4/5(Sun) 17:00:47|NO.68398

> sup は dup のタイポですか?
はい。
その通りです。
恥ずかしいですね。これ。



ONION software Copyright 1997-2021(c) All rights reserved.