ab.com コミュニティ

以前下記で、「ActiveBasic V2」がダウンロードできました。
http://www.discover-soft.com/activebasic2.6/

いま、リンク先が見当たらないので、お教え下さい。

LineInput など、N88BASICの互換性は、V2が高いので、是非継続して使いたいのです。
[/url]

http://www.discoversoft.net/activebasic2.6/
でダウンロードできました。

有難うございました。

一応、そのまま残っていて安心しました。

山本さん、是非、オフィシャルにお願いいたします。

m(__)m

>> LineInput など、N88BASICの互換性は、V2が高いので、是非継続して使いたいのです。

LineInputは、せひとも採用（復活？）させて欲しいですね。
私の場合は、LineInputが使えない事で、VBからの移行が進みません。
ABへ移行したいと思いつつ、不定形のテキストファイルを扱うソフトを作るケースが多い事もあって、どうしてもLineInputのあるVBに落ち着いちゃいます。

公開されているLineInputを利用させてもらって対応する事もありますが、やっぱりできれば標準機能として欲しいです。

LineInputって、採用が見送られてしまうほど、需要が低いものなんしょうかね・・・？

> >> LineInput など、N88BASICの互換性は、V2が高いので、是非継続して使いたいのです。
私もいまだにVer.2.xを使わせてもらってますので、
公式サイトでの継続公開を、ぜひしてほしいですね。

> LineInputって、採用が見送られてしまうほど、需要が低いものなんしょうかね・・・？
たぶん、需要はあるんでしょうけども、ABの仕様の関係で採用が見送られたんじゃないかと思っています。

不定形のテキストファイルを扱うゆえに、どのくらいの量が読み込まれるか
わからないですよね。ところが、String型はVer2.xでは16KByte（4KBだったかも？）を
超えるとアプリケーションエラーで落ちたと思います、たしか。
Ver3.xではString型の上限はもっと小さくなっているように思いますので、
それゆえに、すでにライブラリが公開されている現状からは、
わざわざ標準機能として採用はないのではなかろうかと。

Line Input については，一応代替処理用ライブラリがあるのですが
AB2のLine Inputよりも遅くなってしまうようです。
http://www50.tok2.com/home/losedog2/download.htm#ABLIB （まけイヌさん作）

私も現在試しに，もっと速い方法がないか作ってみてるところですけどね。

_________________
' ============================================================
' Sinryow Game Home Page - http://www.sinryow.net/
' Sinryow ActiveBasic Center - http://ab.sinryow.net/
' ============================================================

互換を意識したLineInputを作ってみました。
Input #1, s
などと同様に、Open + Close と共に利用します。
LineInput 1, s
※LineInput (ファイルナンバー), (String型変数)
で使えます。「#1」ではなく「1」と書きます。
もちろん、Input #1, s などと混在しても問題ありません。

'内部関数。
'指定された文字（Byte型）が大文字なら小文字にして返す。
Function __WsByteLower( a As Byte ) As Byte
	If( TRUE=IsCharUpper(a) )Then
		__WsByteLower = a + 32
	Else
		__WsByteLower = a
	EndIf
EndFunction
'bBaseb文字列の中でSearch文字(Byte型でアスキーコード指定)が最初に現れるポインタを返す。
'無ければNULLを返す。C言語のstrchr()に相当。
'　※上記の__WsByteLower()を利用しています。
Function WsStrChr( pBase As BytePtr, bSearch As Byte ) As BytePtr
	dim nBaseSize As Long
	dim i As Long
	dim j As Long
	dim FinishTF As Long
	WsStrChr = NULL

	nBaseSize = lstrlen( pBase )

	i = 0
	While( i<nBaseSize-1 )
		If( __WsByteLower( GetByte(pBase + i) ) = __WsByteLower( bSearch ) )Then
			WsStrChr = pBase + i
			ExitWhile
		EndIf
		i = i + 1
	Wend

EndFunction



'LineInputのエミュレート案
Macro LINEINPUT( FileNumber As Long, ByRef strBuffer As String )
	Dim poTemp As BytePtr
	Dim nReadSize As Long
	Dim nFileSize As Long
	Dim hFp As Long
	Dim nLeftSize As Long
	Dim nFpUnitMove As Long
	Dim pMark As BytePtr
	Dim b As Byte
	Dim nShouldGetLength As Long

	'パラメータのセット
	FileNumber = FileNumber - 1
	nFileSize = GetFileSize( _System_hFile[FileNumber], 0 )
	hFp = SetFilePointer( _System_hFile[FileNumber], 0, 0, FILE_CURRENT )
	nLeftSize = nFileSize - hFp

	'一端全て読み込むためのバッファー確保
	poTemp = calloc( nLeftSize+1 )
	ZeroMemory( poTemp, nLeftSize+1 )

	'読み込み
	ReadFile( _System_hFile[FileNumber], _
				poTemp, _
				nLeftSize, _
				VarPtr(nReadSize), _
				ByVal NULL )

	'LFで分割。
	pMark = WsStrChr( poTemp, 10 )
	If( pMark=NULL )Then
		nShouldGetLength = lstrlen( poTemp )
		strBuffer = ZeroString( nShouldGetLength + 1 )
		strBuffer = lstrcpy( strBuffer, poTemp )
		Exit Macro
	Else
		'引数に代入すべき文字列の長さを得る。
		b = GetByte( pMark-1 )
		If( b=13 )Then
			nShouldGetLength = pMark - poTemp - 1
		Else
			nShouldGetLength = pMark - poTemp
		EndIf
		'ファイルポインタの移動先（代入文字列の分だけ進める）を計算。
		nFpUnitMove = hFp + ( pMark - poTemp ) + 1
	EndIf

	'LFの手前までを引数に代入
	SetByte( poTemp + nShouldGetLength, 0 )
	strBuffer = ZeroString( nShouldGetLength + 1 )
	strBuffer = lstrcpy( strBuffer, poTemp )

	'ファイルポインタの調整
	hFp = SetFilePointer( _System_hFile[FileNumber], nFpUnitMove, 0, FILE_BEGIN )

	'バッファー開放
	free( poTemp )

End Macro

Ver3.13 + Win2000 で動作確認。
わざわざWsStrChr()とか定義しているのは、私の好みのせいです（^^;）

行の終端は LF or CR+LF で判断しています。
問題は、
LineInput #1, s
でなく
LineInput 1, s
と＃を外して書かなきゃいけないため、Ver2.xのABファイルをそのまま移せないこと。
Inputの定義ファイルを見ると
Macro INPUT_FromFile(FileNumber As Long)
で＃が使えているのですが･･･Macroの仕様はよく分かりません。
BackSearchABで「NoWestさんのページに以前書いてあった話で
Macroに関するものが」との記述を見つけましたが、辿れず。
もう消えているのか、見つけられなかっただけか。
ご存知の方いますか？


>> Line Input については，一応代替処理用ライブラリがあるのですが
>> AB2のLine Inputよりも遅くなってしまうようです。
>> http://www50.tok2.com/home/losedog2/download.htm#ABLIB （まけイヌさん作）
まけイヌさんのライブラリは私も以前に使わせてもらいましたが、
ある条件下で、同じ文を二度読み込んで来たり、ファイルの最後まで読み込んでしまったり、
というバグが合ったように思います。
･･･と、言うだけ言っておいて『発生条件不明』なので大変恐縮ですが。
やー、その後String型の文字数上限などの問題から、
BytePtr型+ReadFileで一括読み込みするようになったもので、
エラーの原因究明を放置しちゃってるんですよ。
今となっては、そのエラーが出たファイル自体、何処に行ったか分かりません･･･。
もうバグ修正版がアップされていましたら、ごめんなさい。

>> 私も現在試しに，もっと速い方法がないか作ってみてるところですけどね。
他のスレでも「Ver2.xに比べて遅い」との記述を見かけた気がしますが、
方法次第でもっと速度が上がるものなのですか？
それは考えもしませんでした。
バッファーに読み込んで1Byteずつ順に走査してLFを探していく方法しか、
思いつきませんでした。
上のコードでは、将来的に最初にファイル終端まで読み込んでおいて、
LineInputが呼び出されたら、その読み込んでおいたバッファーから値を
返せば早くなるかな～と、考えて組んでますが、そうすると
Open + Close 文の定義も書き換える必要が出てくるので、
今回はそこまではやっていません。

> >> 私も現在試しに，もっと速い方法がないか作ってみてるところですけどね。
> 他のスレでも「Ver2.xに比べて遅い」との記述を見かけた気がしますが、
> 方法次第でもっと速度が上がるものなのですか？
> それは考えもしませんでした。
> バッファーに読み込んで1Byteずつ順に走査してLFを探していく方法しか、
> 思いつきませんでした。
> 上のコードでは、将来的に最初にファイル終端まで読み込んでおいて、
> LineInputが呼び出されたら、その読み込んでおいたバッファーから値を
> 返せば早くなるかな～と、考えて組んでますが、そうすると
> Open + Close 文の定義も書き換える必要が出てくるので、
> 今回はそこまではやっていません。

まけイヌさんの方法が，「一度バッファにすべて読み込んでしまう」方法ですよ。
それで私も速くなると思ったのですが，それで遅くなるとは・・・。

AB4で以下のコードを試して見ました。
snrmain.phpは9600行・421kbです。
これで52秒かかりました。
※実際はプロジェクトとしており，まけイヌさんのライブラリを入れています

#N88BASIC
' ↓ ここからプログラムが実行されます

Dim fd As Long, buf As String
fd=liOpen("snrmain.php")
Print Time$()

While liGet(fd, buf)>0
Wend

Print Time$()
liClose(fd)

しかし，AB2の以下のコードはわずか3秒（！）で終了します。

Dim buf As String
Open "snrmain.php" For Input As #1
Print Time$

While Eof(1)=0
	Line Input #1, buf
Wend

Print Time$
Close #1

仮設としては，バッファから「\r\n」を取り出すための処理が（ABのコンパイラ性能ゆえに）遅いのでは・・・と考えています。

_________________
' ============================================================
' Sinryow Game Home Page - http://www.sinryow.net/
' Sinryow ActiveBasic Center - http://ab.sinryow.net/
' ============================================================

>> まけイヌさんの方法が，「一度バッファにすべて読み込んでしまう」方法ですよ。
そうですね。
さきほど、最新バージョンのまけ犬さんライブラリをDLして、
以前にエラーを出しただろうファイルでテストしてみたところ、
今回はエラー無く通ったので、問題は修正済みみたいですね。


こちらでも速度計測してみました。
AB3.13で以下のコードで試してみました。
test2.txtは112KB・3177行です。

'まけイヌさん's ライブラリ 利用

#N88BASIC
#include "linput.sbp"

'■変数宣言
Dim	hID		As Long		'<< ファイルＩＤを受け取るための変数
Dim	s		As String	'<< 取得した文字列を受け取るための変数

'■■サンプルファイル１
'■ファイルの終端が改行されていないケース。
hID	= liOpen("test2.txt")	'<< ファイルＩＤを取得
While liGet( hID, s)		'<< FALSEが返るまで１行ずつ文字列を取得
	'内容表示
	'Print s
Wend
liClose(hID)				'<< ファイルＩＤを解放

Input s
End

こちらは9秒かかりました。一方で、

' 上記案の自前LineInput

#N88BASIC
#include <WSLib6_LikeStringC.sbp>

Dim s As String

Open "test2.txt" For Input As #1
	While (Eof(1)=0)
		LineInput 1, s
		'Print s
	Wend
Close 1

Input s
End

こちらは2秒で済みました。

ちなみにVer2.59の場合は、

#strict

Dim s As String

Open "test2.txt" For Input As #1
	While (Eof(1)=0)
		Line Input #1, s
'		Print s
	Wend
Close 1

Input s
End

1秒で済みました。
確かに速いですが、上記の2秒との差はおそらく、一度バッファーに全て
読み込んでしまうことで、無くせると思います。

ここからは予想なのですが、Ver2.xに比べてVer3.x（or Ver4.x）での
まけイヌさんのLineInputライブラリが遅くなってしまう理由は、
関数内部でMid$を使っているためじゃないか･･･と思ったんですが、

Function Mid$(buf As String, StartPos As Long)(ReadLength As Long) As String
	Dim length As Long

	StartPos=StartPos-1
	If StartPos<0 Then
		'error
		'Debug
		Exit Function
	End If

	length=Len(buf)
	If length<=StartPos Then Exit Function

	If ReadLength=0 Then
		ReadLength=length-StartPos
	End If

	If ReadLength>length-StartPos Then
		ReadLength=length-StartPos
	End If

	Mid$=ZeroString(ReadLength)
	memcpy(Mid$,StrPtr(buf)+StartPos,ReadLength)
End Function

を見てみても、特に遅くなりそうな理由は見つからないですね･･･あれ？
とすると、内部でのIf文の個数でしょうか？
私の場合はLFしか検索してないので、その差かな、と思えなくはないか･･･と。

ちょっと調べてみました。
Mid$の第一引数はString型です。そこにBytePtr型を渡しているので、BytePtr->Stringの型変換が起こって時間が掛かってるようです。(String型を渡してもByRefではないのでコピーするのに時間が掛かりますけど...)
Mid$の第一引数をBytePtr型にしてmemcpyのところを

memcpy(Mid$,buf+StartPos,ReadLength)

とすれば速くなります。

>>BytePtr->Stringの型変換が起こって時間が掛かってるようです。
なるほど。それは盲点でした。
そういえば以前に、String型で書いていたコードを全てBytePtr型に書き換えたら劇的に早くなったことが在りましたが、あれはコードのアルゴリズムが書き換えに伴って少々変更された故だけでなく、String型のコピーや変換が無くなった故も、やっぱりあったのですね。･･･と、これは私事ですか。失礼。
（早くなった原因がはっきりしてうれしかったもので、つい。）

淡幻星さんのコードを改造してみました。
改行コードはCR, LF, CR+LFに対応しています。
実機では処理速度を半分程度に抑えることが出来ました。

Macro LINEINPUT(FileNumber As Long, ByRef strBuffer As String)
  Dim Buf As BytePtr
  Dim Size As Long
  Dim Length As Long

  FileNumber = FileNumber - 1
  Size = GetFileSize(_System_hFile[FileNumber], 0) - _
    SetFilePointer(_System_hFile[FileNumber], 0, NULL, FILE_CURRENT)

  Buf = calloc(Size + 1)
  ReadFile(_System_hFile[FileNumber], Buf, Size, VarPtr(Size), ByVal NULL)

  Length = 0
  While TRUE
    Select Case Buf[Length]
      Case NULL
        Exit While
      Case 10  'LF
        SetFilePointer(_System_hFile[FileNumber], Length + 1 - Size, NULL, FILE_END)
        Exit While
      Case 13  'CR or CRLF
        SetFilePointer(_System_hFile[FileNumber],
          Length + 1 - (Buf[Length + 1] = 10) - Size, NULL, FILE_END)
        Exit While
      Case Else
        Length = Length + 1
    End Select
  Wend
  strBuffer = ZeroString(Length)
  memcpy(StrPtr(strBuffer), Buf, Length)

  free(Buf)
End Macro

ただ、ExcelVBAと処理速度を比べるととても遅いので、
一旦バッファに読み込む方法を取らないと
劇的な速度向上は望めないと思います。

私の名前が出たのと、淡幻星様と久々にお会い(？)できたのとで
書き込んでみました。

Sinryow様のおっしゃるとおりLine Inputもどきライブラリ「linput.sbp」は
一度ファイル全体をバッファに取り込み、その後順次シークしています。
この方法は素直ではなく、またLine Input命令の動作とも違います。
※コンセプトの中に「あまり考えずに楽に使える」というのもあったので、
　この仕様になっているというのもあります
※弱点は２ＧＢ以上のファイルではliOpen関数が失敗する点です

正確に再現するなら、やはりファイルをロックした状態のまま、
１バイトずつ評価していく地道な方法になります。
..が、これをActiveBasic側でやっていては、
どう頑張ってもLine Inputの処理速度を越える事は出来なさそうです。

一応、現在LDGDI自体をクラスライブラリ化していますが、
実はこの中でLine Inputみたいな機能を実現しています。
コードはほぼ同じなのですが、何故かクラス化する事で多少速くなるみたいです。
※メンバ変数へのアクセス速度が優位に出来ているのかな？？


P.S.
しかし、プログラムの速度アップの話題は心なしかウキウキしますね♪
早く上記ライブラリのバグを潰してしまおう..(苦笑)

_________________
# まけイヌ (losedog2)
# Home : http://www50.tok2.com/home/losedog2/
# Mail : losedog2@yahoo.co.jp

久しぶりに覗きに来たら、なにやらLINE INPUTの話題が上がっていますね。

コードの掲載や、それに対する修正案などもあり、このまま掲示板の中に埋もれてしまうとすごく勿体無いような気が・・・

こういのって、「実践コードモジュール」の格好のネタになるのでは？
#・・ていうか、掲載希望（笑）

えー、しばらく空けてのレスなので、ご覧になられるか分かりませんが、主に上記の御三方へ。では、順に。


≫高信期さん
ここへの投稿の後、Ver2.xのエミュレート関数ライブラリとして、
調子に乗って自分のサイトでLineInputを公開し始めたのですが、
そちらの次回更新版に、高信期さんのコードを利用させて頂いて
よろしいでしょうか？
いえ、随分とすっきりとスマートに書かれているな～と思いまして。
それから、「BytePtr型＋ReadFileで一括読み込みしたほうが操作早い＆楽～」
などと宣いましたが、それはあくまでしっかりソフトを作りこむときであって、
ちょっとコードを組む、一回使ったら破棄、程度に軽く作るときは、
String型＋Openを利用した方が随分と楽だと、さきほど思い直したのも理由です。
そんなわけで利用させていただきたいのですが、よろしいでしょうか？
もしよろしければ、その後「実践コードモジュール」へも
転載させていただこうかと思います。
私を含め、Ver2.x好みにとってはOpen命令と共にVer3.xで使えることは、
有用なポイントだと思いますので。


≫まけイヌさん
一時期ちょっと顔を出しただけで、しばらく音沙汰の無かった私を
覚えていてくださいましたか。びっくりしました。光栄です。
この後の話題は、ここの掲示板の趣旨から外れますので、まけイヌさんの
サイトにお邪魔させていただこうかと思います。続きはそちらで。


≫KAMATYさん
そんなわけで（上記参照）、しばらく経ちましたけれども、
「実践コードモジュール」への転載も無いようですので、
もし高信期さんの許可が下りましたら、差し出がましいですが、
私が高信期さんのコードを転載させていただこうかと思います。
私のよりも高信期さんのコードの方がよっぽど綺麗ですので。
ついでにClipStr、SetClipStrのエミュレート案も載せようかと思ってます。
クラス化されたそれが既にあるようですが、Ver3.xではまだ使えませんし。


うーむ。Ver4.xはまだバグや仕様変更の危険性があるので、
クラスが魅力的にしろ未だにVer3.xを利用している私や、
N88Basicとの互換性がより優れている（≒命令簡単）Ver2.xを好む私などは、
少数派なんでしょうかねぇ？
Ver2.xのリンクが復活しないところを見ると、山本様としては、
早くユーザーにVer4.xに移行して欲しく思っているように感じます。
逆行してスイマセン。＞山本様