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


HSPTV!掲示板


未解決 解決 停止 削除要請

2015
1229
VelgailHSP++ライブラリ for C++11/14(仮称) の需要確認24解決


Velgail

リンク

2015/12/29(Tue) 14:00:29|NO.73833

HSPで作っていて、だんだんと「本格的な言語でやってみたい」と思った人ってどれくらいいるのかなと思ってスレ立て。

2015年の夏ごろ一旦作り始めて、途中で投げ出してしまったやつ(モチベ不足)のリテイクなのですが、
どうせやるなら他の人にも使いやすい形にまとめられたらいいかなと思って皆さんの意見を集約したいと思います。

一応、このようなライブラリの予定です
1. C++(11/14あたり)をベースとする。
2. とりあえず作るのはWin32API版。Qt, Direct2D版は作れるか微妙
3. 文法はHSPに出来る限り近づける(C++的に困難なものは再現しない)
3-2. でもC++らしい書き方もできていい。
4. Unicodeに対応。むしろUnicodeオンリー(希望としてはUTF-8)
5. ライセンスはQt以外BSDあたり。Qtは(嫌いだけど)LGPLなのかな。
6. Qt対応でLinuxに行くのも容易になる……といいなぁ

という感じです。
例として、sample\basic\clock2.hsp は

#include "hsp/hsp.hpp" #include "hsp/util.hpp" using namespace hsp; void hspMain(){ screen(0,320,80); font(msgothic,30,1); string t1="",t2=""; while(true){ gettimestr(t1); gettimestr(t2); redraw(0); color(255,255,255);boxf(); color(0,0,0); pos(0,0);mes(t1); pos(0,40);mes(t2); redraw(1); wait(100); } }

あるいはC++に近づけて、


#include "hsp/hsp.hpp" #include "hsp/util.hpp" using namespace hsp; void hspMain(){ Screen& clock=Screen(0,320,80); clock.font(msgothic,30,1); string t1="",t2=""; while(true){ t1=gettimestr(); t2=gettimestr(); clock.redraw(0); clock.color(255,255,255);clock.boxf(); clock.color(0,0,0); clock.pos(0,0);clock.mes(t1); clock.pos(0,40);clock.mes(t2); clock.redraw(1); wait(100); } }

あたり。C++への架け橋になれるようなそんなライブラリを目指したいなと。

そんな需要ってありますか?



この記事に返信する


pumpkin

リンク

2015/12/29(Tue) 14:19:09|NO.73834

面白いんじゃないですか?
自分はまだHSPさえうまく使えないので、C系はずっと先ですけど
いずれはC#とか使いこなしてみたいってひそかに思ってますしねぇ



kanamaru

リンク

2015/12/29(Tue) 14:37:06|NO.73835

これって、hspを元にして作った別言語みたいな位置づけですか?
それだったら、構造体や連想配列、DLL作成など対応して欲しい。
あと、c++との架け橋にしたいのなら、libファイルとか対応して欲しい。



Velgail

リンク

2015/12/29(Tue) 16:02:02|NO.73837

この案はC++用のライブラリです。但し、関数群は(ほぼ)すべてHSP互換とC++化されたHSP命令です。
C++上でコンパイル&実行するので、C++のすべての機能が使えます。
WindowsならVisual Studio 2015 CommunityのC++でコンパイルする形ですね。

ストアアプリには……できないと思います。

さて、C++なので、おおよそほしいと言われているすべての機能が使えます。
例えば:
・構造体
・オブジェクト指向プログラミング
・連想配列を含めたSTLのすべての機能
・ラムダ式

あとは、おそらくDLL作成も対応するでしょう。(原理的には。それはもはやC++)

逆に対応できない(もはやしない)機能として想定するのは以下の機能です。
・goto
・\演算子(C++では%演算子です)
・=等価演算子(C++では==と=は明確に区別されています)
・!不等価演算子(上述と同じ)
・プリプロセッサー命令の大半(C++に合わせてください)

gosubは実装される予定です。(但し関数ポインタに飛ぶ形に)



y.tack

リンク

2015/12/29(Tue) 18:50:29|NO.73842

>「本格的な言語でやってみたい」と思った人ってどれくらいいるのかな
なんか自分、HSPは向いてないんじゃないかと凹んでいます
なので本格的な言語(本格的じゃなくても)が
自分に合ってるのあるかな?なんて考えながらやってます

HSP形式のC++言語は使ってみたい気はしますね

後、やりたいことをNETに記述すると
それで目的が達成したみたくなるので
UPは現物+マニュアルが良さそうですね

そういう意味ではここでやるよりはgithubとかでやった方が良さそうです

専用pukiwiki(でふぉw)なら用意出来るので
そういうのが必要でしたら 書いてくださいw



科学太郎

リンク

2015/12/29(Tue) 20:21:59|NO.73846

> HSPで作っていて、だんだんと「本格的な言語でやってみたい」と思った人ってどれくらいいるのかなと思ってスレ立て。
私は正反対でしたね。
C言語→C++言語→HSPにハマった感じです。

VelgailさんのC++用のライブラリを上手く使えば、
HSPソースからC++ソースに変換するコンバータを作り、
コンパイラでコンパイルすることが可能でしょうね。

私ならば、このような使い方をしたいので、
No.73833 の上のソースが良いと思います。



beta

リンク

2015/12/29(Tue) 21:48:31|NO.73850

C++ライクではなくなってしいますが
こういうのがあったらいいナみたいな文法

Java or C#ぽい文法的にオブジェクト指向があったら便利かも
標準命令はインクルード不要
型なし
関数()はありでもなしでも加
一連の動作を簡略化できるようにする命令も追加

例えば...

Screen screen = scr(0,400,600) //引数がない場合自動的に new scr.show //表示、HSP同様自動gsel button "1",*Obj.kansu() //↓と同じ動作を簡略化できる初心者とそれ以上で使い分けられるように。 //------ボタン---- Button bt= new Button("1",Obj.*kansu()) scr.addObject(bt) //------ボタン---- #Object Obj XYZObj xyz #func kansu //関数の戻り値指定は不要 *xyz.smes() //関数呼び出し時*を追加(ないほうがいい?) return #func get return xyz #global #Object XYZObj x=0//プロパティ y=0 z=0 #ObjInit x,y,z//コンストラクタ this.x=0 this.y=0 this.z=0; return #func smes mes x +" : "+y+" : "+z return #global



Velgail

リンク

2016/1/1(Fri) 17:37:31|NO.73921

それでは、実際に作り始めることにします。

仕様云々はy.tackさんにぶん投げたpukiwiki上で固めつつ、GitHubで作っていこうと思います。
……Team Foundation Serverの方が好きなんですがねw



y.tack

リンク

2016/1/1(Fri) 20:19:51|NO.73924

pukiwiki用意しましたw
http://zuzazann.boy.jp/Velwiki/pukiwiki/index.php?FrontPage
ご自由にお使いくださいw
配色はどんながいいっすか?

パスワードとかやりとりしたいので
メルアド教えてくださいな

>仕様云々はy.tackさんにぶん投げたpukiwiki上で固めつつ
僕も某BBSで書きながら作成とか見事に失敗しつづけ
なので、どうしたらいいですかね

UPすることが目標ではない状態なら大丈夫そうですが



Velgail

リンク

2016/1/1(Fri) 20:56:24|NO.73927

どうでしょうね?
メールアドレスは……まずは 26b2a2@ahk.jp にお願いします。その後本メールアドレスをお知らせします。



可憐

リンク

2016/1/1(Fri) 21:57:42|NO.73932

HSP++ですか。とてもおもしろそうです
HSP++でほしい機能は自分的にはマルチタスクが欲しいかなと思ってます。



Noap

リンク

2016/1/1(Fri) 22:12:02|NO.73933

もしよろしければ答えてほしいですがライセンスがLGPLになった場合、HSP++を用いて作成したアプリケーションは配布する際にはソースを公開することになるのでしょうか。
LGPLは難しくてよく分からないので教えてくださると幸いです。

基本的には文法等はC++のままである程度ライブラリ命令を補完する形でHSPの命令を扱えたらいいなと思います。



y.tack

リンク

2016/1/1(Fri) 23:53:45|NO.73937

gccはGPLだったはずですが 使用は問題なかったと記憶しています
ライブラリへのLINKも
LGPLがgccのライブラリへの適用という流れで
出来たライセンスのはずなので
スクリプトの公開は義務づけられていない。と思います

しかし言語やライブラリを改造した時は公開は義務付けられると思います



Noap

リンク

2016/1/3(Sun) 13:11:29|NO.73966

教えてくださりありがとうございます

LGPLで検索するとそのことについて説明している用語解説のページが上にありました
http://e-words.jp/w/LGPL.html



zakki

リンク

2016/1/3(Sun) 18:28:23|NO.73967

LGPLだとプログラムのソース公開は不要ですが、オブジェクトファイルの配布やリバースエンジニアリングの許可を
プログラムに要求することになるので、プログラミング言語のランタイムライブラリでは
リンク時例外付きのGPLを採用することが多いかと思います。

HSPがBSDLなので、FSF大好きってわけでもなければ、BSDLのほうが相互にソースの利用出来て良いんじゃないでしょうか

http://www.gnu.org/licenses/gcc-exception-3.1-faq.ja.html
https://ja.wikipedia.org/wiki/GPL%E3%83%AA%E3%83%B3%E3%82%AF%E4%BE%8B%E5%A4%96



Velgail

リンク

2016/1/3(Sun) 22:01:43|NO.73974

>BSDLのほうが相互にソースの利用出来て良いんじゃないでしょうか
と思ったので、pukiwikiの方では書き換えてます。
多分、Qt(LGPL)→HSP++(MIT又はBSD)→プログラム(逆アセンブル禁止プロプライエタリ)は可だと思うので。(→は動的リンク)

Qtに直接アクセスしたくないがゆえのHSP++改変要求とかが飛んできそうですがね。

そもそもQt版作るかわからないので。基本版のWin32APIはBSDLの予定ですよ。



zakki

リンク

2016/1/4(Mon) 09:33:57|NO.73975

ちょっと別の切り口でhsp3r(dish用のランタイム)をライブラリとして使う方向のプロトタイプを作ってみました。

ラッパーだけでほとんどの既存の命令を使えるメリットはありますが、
- C++側でのクリーンさやUTF-8やマルチスレッドやQt対応
- HSP側での変数の型の自動変換や配列の自動拡張や独自制御構文
などのデメリットもあります。

変数型や配列については演算子のオーバーロードとユーザー定義リテラルでHspVarProcに振り分ければ
出来そうではありますが、だったらHSPそのまま使う方が…。
グローバルな各種状態変数へのアクセスあるのでスレッド対応はかなり面倒そうです。

https://github.com/zakki/openhsp/commit/f013746ebc433c47eefcba36da425623770087f6



y.tack

リンク

2016/1/4(Mon) 15:59:27|NO.73987

せっかくランタイムになってるので それを使えればいいなあ と妄想したこともありましたが
何をどうすればいいか 全然わかりませんでしたw

ぱっとみて 使用がintのみとかの命令は使えそうで
抽象化されて命令に処理を丸投げしてて
全体を把握しないと 僕には理解できなそうです
って全部で2000行くらいありそうで
ぱっとみて理解出来る人もいないかもですね

でも2000行くらいのソースコードなら
写経に挑戦してみたくなるソースコードですねw
って5000行くらいあるかもw

自分はvisualStudio2012持ってて
最近買った書籍が2008EE
なんですけど
VSのいくつが対象なんですか?

長いスクリプトの写経は元スクリプトと
全く同じにする方針なんですけど
tabを機械的にsapceに置き換えましたが大丈夫ですよね



zakki

リンク

2016/1/4(Mon) 17:44:21|NO.73988

使うだけなら hsp3rtest/testlib.cpp がユーザーコードで、それ以外は.libと.hを配布するような想定です。
無料版のCommunity 2015で開発してますが、それ以前のVSでもC++11対応してる環境なら大丈夫なはずです。

HSPインタプリタの流用部分が3万行ちょっと、それ以外の部分が8000行程度でした。
コメントなど含むので正味はもうちょい少ないですが。

C++のソースではインデントはタブでも2スペースでも4スペースでも特に影響ありませんが、
hsp3rtest/hsplib.h は本来は何らかの形で自動生成したい箇所だし
hsp3rtest/test.cpp はMIAさんのHSPコンテスト2008の作品のベタ移植なんで
あんまり新しいところないような



y.tack

リンク

2016/1/4(Mon) 20:14:32|NO.73993

>HSPインタプリタの流用部分が3万行ちょっと、それ以外の部分が8000行程度でした。
>コメントなど含むので正味はもうちょい少ないですが。
僕の写経ペースが月間1000行くらいだと思うので
38,000行あったら 三年かかりますなw
5,000行なら半年〜1年くらいだからちょうどいいかな。と思ったのですが
インタプリタは色々書籍があって そういうの読んで勉強してますが
ランタイムの仕組みが全くわからなくて 謎だったんですよね
5000行くらいでざっくり理解出来たらいいなーと思ったんですが

でも一回くらいOPEN HSPに触れたいなーと思い
OPEN HSP見てたら
ランタイム(WIN32 GUIフォルダ内)500KBくらいあって(ざっくり暗算ですw)
大変だー。と
挫折気分まんまんだったんですけど

HSP3CLのランタイムを見たら
(フォルダに収まってるのだけの計算ですが)
びっくりするくらい小さくて
勉強するならGUI勉強したいですが
巨大なのでとりあえずHSP3L写経しようかなー
というところに落ち着きましたw

>C++のソースではインデントはタブでも2スペースでも4スペースでも特に影響ありませんが、
HSPで変換したので文字コードの問題起きないかな?と思ったのですが
zakkiさんにそう書いていただいたなら大丈夫そうですね

>MIAさんのHSPコンテスト2008の作品のベタ移植なんで
>あんまり新しいところないような
MIAさんのスクリプトもHSPのスクリプトも
ほとんど読んだことないのでOKです



Velgail

リンク

2016/1/4(Mon) 22:54:45|NO.73994

本家インタープリターコードを使う気は毛頭ないですよ。
多少参考にはしますけど、そこでHSP本家に依存し過ぎると移植性が思いっきり低下する気がするので。

HSP++は、そういう意味では、「本家にある有用な命令がC++になければ移植する」というだけのものです。(例えばCOMとかは拾っていません。私が使わないからですが……)
HSP++にとって、本家コードは「参考にはするがコピーはほぼしない(ブロックレベルで拾うかもしれない)」ものです。

インタープリター部分なんてC++の速度を殺すだけのお荷物なので使いませんし。
オブジェクト指向的にGUIが書けるようにするのもHSP++の目標ですので、まるまる流用は出来ません。
どうせかなり改変するなら、一から書いたほうが移植性にも意味があるだろうと。

あと、C++11フルセットを使うきまんまんですので、HSP++はVS2015必須です。というか、constexprないC++とか使えない……



fuq

リンク

2016/1/5(Tue) 00:44:50|NO.73996

> インタープリター部分なんてC++の速度を殺すだけのお荷物なので使いませんし。
ん〜この発言を見るに、雲行きがあやC



Velgail

リンク

2016/1/5(Tue) 01:40:47|NO.73997

インタープリター部分に投げる動作で書いたうえで、「オブジェクト指向プログラミングと結合」させようとすると、無駄が大きいと見ていた。
Open HSPのソースを過去に見たフィーリングだけで回答したのがバレバレですね。

ただOpen HSPのソース自体、私の見た限りHSPのインタープリターのための構造体が蔓延っていて、これを再現する気もないのが私のスタンスで。

HSPでは学習コストが低い関数(screen関数とか)の敷居がC++ではえらく高いので、その部分を弄りやすくするということがHSP++の趣旨です。
それ以外の関数に関しては、優先順位は低いです。

他にもscreen 0 の謎仕様(固定サイズ限定)とかもあまり好ましくないと思っていたり、他にもソースを見て気分的にすきになれない部分が多々あるので、
やっぱり自分の学習のためにもスクラッチビルドはゴリゴリしていきます。

まあ、究極的には。


Screen& front=screen(0,640,480).line(0,0,640,480)
とか書きたいので。HSPそのものの流用でそう簡単にこれを実装できない以上、適切に書き写す・スクラッチするしかないのです。

私が作るHSP++とはそういうライブラリです。ついでに「嫌ならそう思う人自身でライブラリを作って勝手に使いましょう」。それがOSSです。

(なおOpenHSPは私の環境ではエラーだらけでまともに追跡できてません。やっぱり自分で書かなきゃダメっぽい。私の環境では)



zakki

リンク

2016/1/5(Tue) 09:23:45|NO.73998

73975に書いたようにメリット・デメリットあるので全面的なOpenHSPのコードの利用を薦めてるわけではありません。
OpenHSPのソースを使ってもUTF-8対応は出来そうですが、マルチスレッド対応は暗黙に状態変数にアクセスしているところが多すぎて無理そうですし、
今のgselやnoteselの仕様のままC++で使えて嬉しいかというと微妙だし。

ちなみにざっくりインタープリタ部と書きましたが前述のテストはHSP命令の実装だけ使っているので
計算や制御構文はC++ネイティブで動作してます。
が、colorやmesなどの命令を呼び出すとバリアントをスタックに積む処理が必要になって通常のC++関数実装と比べるとオーバヘッドがあります。
レイトレーシングでの雑なベンチマーク結果によると、HSPだと17秒、libhspブランチだと4秒、C++ネイティブだと1秒くらい。



b

リンク

2016/1/8(Fri) 15:25:09|NO.74054

これってHSP命令をC++で関数として使えるようにするライブラリ
極端に言うと
void func(){
screen(300,400);
mes("A");
}
見ないな感じということなのだろうか?



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