Official Bin$ function as complement to the &B notation

[RhoSigma]

Hey, how come you were able to edit an existing entry?  Has Fellippe relaxed that rule back to normal?

Yes he did, so let's use it carefully without abuse. It's a perfect feature to do code updates like I did here. Also placing additional thoughs as PS, PPS etc. into a post, but I totally understand his annoyance, if it is used to totally turn the point of a post in an actively ongoing discussion or to wipe out the post entirely. And I guess if it happens again, then he will lock the feature again, and then forever, doesn't matter how much we complain and argue.

[luke]

Can we add this to QB64? It seems desirable to have built in _BIN$ function, but I'm not sure what capability we have for adding things not written in C.

[SMcNeill]

Can we add this to QB64? It seems desirable to have built in _BIN$ function, but I'm not sure what capability we have for adding things not written in C.

You can always add the translated code into libqb.cpp.  It's not pretty, but it's functional.

[RhoSigma]

Can we add this to QB64? It seems desirable to have built in _BIN$ function, but I'm not sure what capability we have for adding things not written in C.

You can always add the translated code into libqb.cpp.  It's not pretty, but it's functional.

I was looking for the possibility to build a native _BIN$ already when adding the &B stuff and part of the work is already done, it's a simple derivate of either the func_oct/func_oct_float or func_hex/func_hex_float in libqb.cpp, maybe it's time to finally finish it, just give me a day or two.

[FellippeHeitor]

I was looking for the possibility to build a native _BIN$ already when adding the &B stuff and part of the work is already done, it's a simple derivate of either the func_oct/func_oct_float or func_hex/func_hex_float in libqb.cpp, maybe it's time to finally finish it, just give me a day or two.

🤩

[RhoSigma]

While looking into the routines something bothers me, OCT$ and HEX$ both have a minimum output size worth of 16 bits for negative numbers. In my BIN$ I'll go down to 8 bits, if it's sufficent for the negative number.

So how to interpret this 16 bits minimum in regard to QuickBASIC compatiblity:
1.) Was it originally done that way by Galleon, because QuickBASIC did it the same way? -- Then it should stay that way and I should also take it over into BIN$.
2.) Was it simply because QuickBASIC did not have smaller variable types than INTEGER (16bit) anyways? -- Then I could use this opportunity to adapt OCT$/HEX$ to 8 bits minimum too, as QB64 has it's _BYTE variable type now.

I don't have QuickBASIC ready here, if somebody could just check what OCT$(-1) and HEX$(-1) spit out there in.

[FellippeHeitor]

QuickBASIC 4.5:
 

[RhoSigma]

Thank you @FellippeHeitor,

so that's indeed 16 bits even for the smallest negative integer, then I'll do it the same way in the coming _BIN$.

[RhoSigma]

@Qwerkey

Thanks Richard for updating BIN$ in the Library. As you can see in the previous posts, I move forward now to make _BIN$ a built-in function in QB64. Until that is done, the library function will certainly serve for many people.

[RhoSigma]

@FellippeHeitor @luke,

Couldn't resist, finished it right up today.
Implementation of the new _Bin$ function is done, Pull request #198 is ready for review and merge.

Note that I used the opportunity also to clarify some details in the OCT$ and HEX$ functions too (comments only) and removed a couple of empty lines.

I've tested the new _Bin$ locally here and compared the results with my function from the initial post, everything works as expected and the results do match each other.

[FellippeHeitor]

Thank you for that, @RhoSigma! Changes merged and already available in the latest dev build. ✨
Keep 'em coming! ❤️

[RhoSigma]

Yep, have seen it, thank you Fellippe and Luke.

[Qwerkey]

@Qwerkey

Thanks Richard for updating BIN$ in the Library. As you can see in the previous posts, I move forward now to make _BIN$ a built-in function in QB64. Until that is done, the library function will certainly serve for many people.

Will keep BIN$ in the Library until next full release (v2.1?) and then will remove.
@RhoSigma @bplus

[RhoSigma]

Will keep BIN$ in the Library until next full release (v2.1?) and then will remove.
@RhoSigma @bplus

@Qwerkey
Would have been my suggestion too, after v2.1 Stable the Library entry and this entire forum thread can go.

@FellippeHeitor
Oh, thanks again, just saw your invitation into the Team and accepted, glad to be part of it now.
So I guess I can commit to the QB64Team\qb64 repository now directly without the need to fork and pull request. It's time to clone/sync the Repo into GitHub Desktop then.

[FellippeHeitor]

Oh, thanks again, just saw your invitation into the Team and accepted, glad to be part of it now.
So I guess I can commit to the QB64Team\qb64 repository now directly without the need to fork and pull request. It's time to clone/sync the Repo into GitHub Desktop then.

That's it, exactly. We currently keep development and master tied to continuous integration, so we commit to master only for stable release, and commit to development when there's a new feature ready, since that'll trigger the dev build generation.

I tend to work locally on a "patches" branch, so that I can keep it in sync with the repo without triggering the CI with every push, then I eventually merge it with Development when it's ready for public testing.

Welcome aboard (again) 😉.