PureBasic Forums - English

Very useful new commands and functions, thanks a lot!

Probably a RegisterFontFromMemory() or CatchFont() could be a nice complement, since most of it now it's already here.

Forgotten in changes list

Added: #PB_Entity_PlaneBody, #PB_Entity_ConeBody and #PB_Entity_CompoundBody body type
Added; AddSubEntity() ; see CompoundBody.pb example

Thank you.

How does the function ResetStructure? This is similar toOr function smarter work, free memory but not allocating if that is not necessary?

Thank you --- will begin testing soon...

Thanks for the new beta. Did not expect it and found it to be a good surprise.

User_Russian wrote:How does the function ResetStructure? This is similar to

Code: Select all

Macro ResetStructure(Pointer, Struct)
  ClearStructure(Pointer, Struct)
  InitializeStructure(Pointer, Struct)
EndMacro

Or function smarter work, free memory but not allocating if that is not necessary?

It does exactly that.

thanks!

Fred wrote:...
- Removed: ASCII mode for internal PureBasic string representation, PureBasic is now unicode only.
...

PureBasic: Rest in peace. You are not BASIC anymore.
Maybe you should be renamed to PureSomething or so...

PB programs are getting bigger and bigger, but they are
only inflated by zeros. Maybe you think bigger is better?

i doubt that would be due to ascii/unicode. at least i can't see a big difference in size compiled with or without unicode.
maybe you have your code full of hardcoded strings?

Thanks guys!!!!

I know why you chose to do it but I always felt that ASCII support was a great convenience and an important feature.

I still think it's a mistake.

yes i thought adding support for more datatypes was the way to go !? (life is still extremely dicey and difficult without unsigned dword!), not dropping support for existing datatypes, especially one as common as Ascii strings (they don't get much more common than that!) simply because it's "too hard" for PB to maintain. Now the "too hard" part becomes the programmers problem, so I have to disagree with this approach! just my 2c, but thankyou very much for the new features. Hopefully I can figure out how to use Tailbite so I can make .libs with PB 5.50 that I can import back into 5.42, but yes I (like many or at least several it seems) certainly won't be able to drop support for 5.42 (just as i cant drop support for Quad datatype), it will remain a constant alongside the new 5.50... (now the programmer will have to maintain two builds). Thankyou for listening to my concerns and sorry if it sounds like im whinging because i'm not, i'm just nervous about having to make a forced and unwanted change to my development style. Maybe a newer version could add support for ".s" and ".su" strings? (Why can't we have both in 2016? Why cant we have unsigned dword?) anyway I promise I'll shut up now, thankyou for hearing my 2c, i get back to work now

The decision to remove Ascii compilation was not made lightly by the PB-Team. The reasons why were giving, and all makes perfect sense. The heads-up was giving way back in 2014, so I don't get how this change makes it “programmers problem.” That's just my 2c


Quick re-cap for newcomers;

Advantages
“- Faster building time, less code in our source tree, makefiles much shorter
- Less bugs because of code reduction
- No more Unicode switch, so it's easier when sharing code source on the forum, or when developing an user lib (everybody is Unicode)
- Makes PB definitely more modern.”

Fred: “before freaking out, we are just talking about removing the "Unicode switch", not all ASCII related operations !”

Fred: “We plan to provide 2 new functions, to ease things a bit:”