Are there big working (commercial programs) ?

[marc_256]

Are there big working (commercial programs) written and developed in PB ?

I just like to know it, for my project.
I started it in PB 4.31 and lost a lot of time with upgrading my software to the next version of PB. (last one PB5.11)
and this is a lot of work, for the ogre3D-Engine commands.

Now I have the problem that my pb-ogre program is not thread-safe.

I am thinking of converting all to C++.

Is this a good idea ?
Are there working projects out there ?

Thanks in advance,
Marc

[Shield]

There are some, but usually it's not made public that they are written in PB.
A good example is the PB IDE itself.

What I can think of right now is a reporting tool made by srod (IIRC):
http://www.arctic-reports.com/

I don't know how 'big' it is though, it's a pretty vague term.
Other users claim to have written software in PB with several (ten)thousand lines.

Regarding 3D applications with OGRE...never heard of a single one...


However, I think the majority uses PB for smaller to medium sized applications.

[Zach]

If upgrading your PB version is such a problem for your codebase.. why not just stick with the older PB version?

Unless you need fixes to serious bugs or something? That being said, converting it to C/C++ or whatnot is going to be a whole load of work too..

I understand things change, and perhaps critical bugs you have to work around finally get fixed or w/e, but if I were writing a large program I would write it with a couple things in mind..

1) Try to organize it and set it up so that changes to the language won't involve huge rewrites. Not always possible but I imagine it is to some degree by using some sort of wrapping layer (macros maybe?), where you would only have to change the "top" layer of code that actually builds the functions/data structures you are using?

2) Couldn't you break the program up and organize it through DLL files? I would hope that a DLL compiled on one version of PB should be able to be used with code written in another version? If that is the case, then you have the added benefit of not having to rewrite/recompile those DLLs which don't need it.

It seems to me code management is just as important an issue as anything else.


But that being said.. If the issue is that your program is not thread-safe (and it needs to be?) then wouldn't you have to solve the exact same problem when rewriting it to another language? Sometimes PB is not the best tool for the job / programmer. But if you really want to stay with PB for other reasons, I would try refactoring first and perhaps coming up with a system of organization that makes it easier for you to adapt to language changes.

Either way, it seems that no matter what you choose the answer will involve a lot of work rewriting things. So if you prefer to stay with PB then try and figure out a new way to make your codebase easier to manage. Otherwise, rewrite it in the language you want. The important thing is to re-write your code so you can avoid having to do a major rewrite again no matter which solution you choose.

[Tenaja]

I am thinking of converting all to C++.

Is this a good idea ?
Are there working projects out there ?

PB vs. C++...
PB has a very large library with great help built in. ...But PB's library is microscopic compared to those available for C/C++. However, those C libraries are as scattered as the web can possibly be, and come with questionable help.
PB has an update every few years that requires a few minor edits. C hasn't really changed much since the early 90's (late 80's?) when it moved argument parameter types into the header.
You may spend a few hours updating very old (pre-4.4) PB code to current versions, but C will require 10x more work.

The hardest part about updating your PB is likely the move to 4.4 or 4.5; start with that. Everything after that can easily be done in one shot, and is a list of minor changes. I have never coded in pre-4.4 PB, but I have updated a few snippets here and there, and it is not too bad.

On the other hand, in the end, you will most likely never regret an update to C. However, it will be a LOT more work. Think of the strings... that's what directed me to PB.

[Shield]

Well, he is talking about C++, not only C. C++ actually evolved a lot during the years and the newly established standard
brought a lot of new features while still maintaining compatibility (which is not necessarily a good thing as the language is plain ugly ).

And as a side note, C++ comes with std::string, there isn't really a difference to PB's string functions.
It's not like you still have to juggle around character arrays...

[BorisTheOld]

I am thinking of converting all to C++.

I'd recommend that you stick with PB and rework your code to bring it up to date.

Over the years I've worked on many large projects that involved converting from one language to another. Such projects are not for the fainthearted. The more different the languages, the longer and more complex will be the conversion.

[IdeasVacuum]

There is in fact one in your area of interest Marc - deepMesh
http://www.purebasic.fr/english/viewtop ... 14&t=46115
http://www.deepmesh3d.com/

[PMV]

Now I have the problem that my pb-ogre program is not thread-safe.

I am thinking of converting all to C++.

OGRE itself is not threadsafe! Regardless if you use C++
or PB, you have the same problem. But, as PB will
always be behind the current OGRE-Version, maybe
if thats important for you ... especially when the
newest version uses DX10/11 with multithreading.

Aren't you the one with this 100k lines of code, that
is living near the bankrup? It is not important if someone
else is using PB for big projects (what do you define as big?)
It is more important, how far is your current dev state?
How long will a translation take to C++ for you?
What benefit do you expect from C++?
Do you have that time and enough experience with C++
to get that benefit early enough?

When Fred implements the "modul"-design, PB will be ready
for big teams+projects ... but as a single developer, PB
has everything that is needed ... and when you already use
PB for many years, you know the pros and contras from PB.

Are there big working (commercial programs) written and developed in PB ?

Count old ones like the Game "Restricted Area"?
I'm working on a game since a few years now, so for me
it is called "big" ... and will take longer ...
At the end, there are a few ones, even so not all
are public like already mentioned and who knows what
will come in the future.

I just like to know it, for my project.
I started it in PB 4.31 and lost a lot of time with upgrading my software to the next version of PB. (last one PB5.11)
and this is a lot of work, for the ogre3D-Engine commands.

Hm, it shouldn't be that time consuming. I think the heavily evolve of
the OGRE part could be the reason, that shouldn't occur that often.

And to be save: everything wirtten is just my opinion

MFG PMV

[Comtois]

GeoControl is written with PB.

[Didelphodon]

ProcDOT and Minibis are written in PB.

Cheers,
Didel

[marc_256]

First at all, thanks to you all for the answers,

I was a little down, so I needed a little push here to continue.
Well, I stay with PB, I will work out some work arounds.
Maybe it was the good (best) choice, when I made the choice to start with PB a few years ago.

Marc,
Hoop one day, I can bring out a demo version
* sorry for my english.

[Kukulkan]

Most client software of regify.com is written in PureBasic:

For example this software for business end users to send invoices (Win only, more complicated than it looks like...):
http://www.regify.com/index.php?PageID=apps&language=EN


And the regify Client SDK for Windows, Linux and MacOS is also written in PB and used by our customers:
http://www.regify.com/index.php?PageID=SDK&language=EN

And, of course, the regify client software for Windows and Mac itself (first and second entry):
https://www.regify-on.net/downloads.php


The only additional libs we are using are libcurl and crypto++. For regibill we also use iSed QuickPDF lib. Everything else is PureBasic.

We are working with GIT as CVS and we are using Cygwin on Windows to run the same makefiles (with OS conditions) on all target plattforms.

Trust me, PB is a good choice even for bigger programs

[edit]Forgot to mention that we are using PureBasic since 2007 for these products. If big is a matter of continuity over time, it is also possible with PureBasic[/edit]

Kukulkan

[Fred]

Hoop one day, I can bring out a demo version
* sorry for my english.

It's a common mistake to always push back the release to add a "killer thing without which the software worth nothing". Your priority when you do a new software is to actually ship it, even if it's not as feature complete as you wanted first. The reason is simple: you need user feedback to get you in the right path, as your first version won't probably be perfect.

[Fred]

We are working with GIT as CVS and we are using Cygwin on Windows to run the same makefiles (with OS conditions) on all target plattforms.

Almost the same here, using standard makefile to manage crossplateform compiling is a must.

[marc_256]

Well thanks to all, I am motivated again,

Thanks Fred, you are right ...
the problem was, that the program was almost working on WinXP x32, the CAD GUI was almost done.
But when I tested it in Win8 x64, the CAD GUI was really ugly.

So, ... re-developing my GUI now.

Marc