Topic: Looking for someone to create/modify software for this forum [5500+ BTC] - page 18. (Read 165632 times)

+1. I suggest you contact Paul Taulborg. He created D2Jsp forums which is easily the most feature packed forum I've encountered.

Not anymore, orig devs split to make Xenforo I believe, now they are suing each other out of existence.
Vbulletin 4 is total garbage

Of all the available forum software phpbb has the least amount of bugs reported (only 5 since 2003-2012) but that really doesn't mean anything. Maybe somebody is hording all their phpbb bugs for future exploits

Just drop $200 on the vbulletin software, Its the best and most feature filled of all the BB software.

Vbulletin is exspensive but its worth it.

Who ever ends up winning this thing should go with a facebook messaging system, where your PMs are always in conversation format i dunno how many times ive replied to people or recieved replies from people not knowing wtf we are talk ing about all becuase they didnt quote my last message im sure im not the only with this problem.

The package that I have implemented for the open source project I will be launching later this year handles the issues of subscribing/unsubscribing very simply and already handles much of the required functionality (child boards, topic locking and moving).

I am working on the project every day and hope to be ready for launch in a couple of months (the delay being due to my having to now start documenting a project that has taken me over 10 years to build).

Whether or not a suitable platform for the actual forum I am quite certain it would be a very suitable platform for at least prototyping it.

I don't know SMF nor much about this project, but even if work on this new system were to be started today, it is many months (or years ?) before this live, production forum would be migrated over to it, right?

Couldn't there be developments to improve (fork) SMF to fix the worst problems in the meantime.   For instance, the ability to stop showing certain threads in the "show new replies"?  Right now there is data destruction occurring as users delete their posts in hopes that they will no longer keep seeing those old threads reappear.

Even if the SMF fork is an all-volunteer effort, at least it is something so that progress forward can start occurring sooner rather than later, no?


Considering how much larger this community is than it was back in November when the first post was made, perhaps there is someone capable and willing to take your design ideas and with the help of this forum's community, launch development as an open source project right off the bat and start building?  Let the bounty go towards building community for the project or whatever.

The entirety of it...  Does myBb have all of those features?

Need much handholding? Pretty much the whole post is what you need to read, but pay attention to the "Required Features" section. Hint: no "stock" installation of any existing BB software will work because it is insufficient.

Point me to a piece of the OP that is relevant

Have you read the first post?

Why doesn't the admin of this site use myBb or Php

Will be busy doing some "real" work next week but managed to spend a couple of days this week adding to my Forum package.

Here are a few more snapshots of what I've whipped up in the last couple of days (will be leaving it at this as far as posting snapshots goes in case they are too annoying):



This list is similar to the "unread posts" list (currently shows both read and unread but will be adding a checkbox to control this later). The "read" posts appear as light grey.



For a post to marked as "read" you need to click the "Mark As Read" button (will take you back to the list so not really such an inconvenience). In order to reduce (IMHO) unnecessary I/O my system does not work with a "view count" and so will not automatically mark topics as read.

The more interesting button here however is the "Subscribe" - no more silly posts needed to do that job here. Also an "Unsubscribe" button will appear for Topics you have posted in or subscribed to which lead us to the last snapshot:



This is equivalent to the "show new replies" list (currently shows read and unread but will also be adding a checkbox to control this).

You'll notice the "Introduce Yourself" topic does not appear here (as I used the "Unsubscribe" to get rid of it).

Once again all the server software is 100% C++ and is 100% generated.

Nice set of links.

I really do understand the problems one can encounter programming in C++ (and much more so in C or doing C-ish stuff in C++) and have been programming in C++ since the mid 90's (started using C in the mid to late 80's).

My opinion is that if you do things the "right way" then the most "feared" problems really don't come up (such as buffer overruns, corrupted heaps, memory leaks, etc.) but I think now we are really just trading opinions and of course have gone a fair bit off topic.

The software system that I have built (and am still in the process of turning into an open source project) *generates* 100% of the "application" source code in any case so the usual sorts of problems associated with "coding mistakes" are pretty much irrelevant.

The "forum" package that I've been working on (although it's not a priority amongst many other tasks I'm currently busy with) is getting close to completion (as far the functionality excluding the PMs) so if anyone has any interest when completed I will provide information where they could take a look at it.

I have actually done a fair bit of programming in C++, and that's why I think it's dangerous.

I'm not saying it's too dangerous to use, I'm just saying it's a poor choice for some applications. Higher level languages are a lot more forgiving when it comes to simple mistakes.

For the record my favourite language is Python and I wouldn't advise using that for such a high transaction website either.

If you are using C++ in a way that you are always shooting your feet then you first ought to learn how to shoot.


Sorry if I'm coming across as patronizing it just seems to me that your comments don't show a great understanding of modern C++ as std::auto_ptr (what I can only guess you are referring to with the above quote) is on only one type of smart pointer (and if you look into boost there are various others - http://www.boost.org/doc/libs/1_49_0/libs/smart_ptr/smart_ptr.htm). The point is not to just prevent "dangling" pointers (which if you choose to use plain pointers anywhere in between you can't stop anyway) but to carefully control lifetime scope and to safely share pointers amongst owners, observers and (if required to) do so with thread safety.

Really guys - this whole "C++ is too dangerous to use" mantra sounds a little like the '90's Java hyperbole that came out from Sun (now try implementing the very useful RAII or as I prefer to call it "scoped object" pattern in that particular language and enjoy all that added mess of try/finally spaghetti you'll need to release your resource at the right time).

You can use C++ in the same way as your more "beginner friendly" languages and it will do the job - only faster. Even a lot of the old parsing ugliness (such as the old auto_ptr > vs auto_ptr> which you can now use) has been addressed.

No one is forcing you to use plain pointers or char arrays (I am guessing your bugbears). Pretty much all areas of real risk are API's (especially OS ones) and underneath all your shiny other languages must be the same API calls (which being C are going to have the same risks - just you are insulated one level from them unless of course your OS is written in a higher level language).

BTW I presume you guys did read that the bitcoin-qt *bug* was actually a missing compiler flag and not due to C++ coding.

Haha. I like this.

Basic probability says that the more lines of code there are, the greater the chance of it having a bug. As you add lines the chance of software having a bug approaches 100% and this applies to all code. Not badly written code, not code without unit tests, not code written by beginners. All code. For shipped code without unit tests and a dedicated QA team it's about 20 lines, for the best team it's about 100, for the best practices in the industry it's about 300. Does your codebase contain more than 300 lines? I don't care how good you are, even if you're Donald Knuth your code contains bugs.

Some languages are more powerful than others and the bugs are more dangerous. C++ is a powerful language where bugs have a high chance of being loose cannons.


No need to patronise me. Smart pointers prevent dangling pointers, which is only one class of security problem with direct memory access. If you aren't using C++ in a way that is potentially dangerous then C++ isn't the right tool for the job.

you did notice this didn't you?

Of course you can write some terrible stuff in C++ but typically the only problems I tend to find these days are dealing with C style interfaces which are the ones most likely to need to deal with pointers to buffers (and even worse void pointers).

I am not sure exactly what the bitcoin-qt problem is *but* there is no such problem in the older client (so why not blame Qt rather than C++ itself?).

To offer a parallel criticism I remember years ago when Adaptive Server Anywhere first decided to rewrite their C++ SQL query tool in Java (the reason why I could never actually work out as the C++ worked extremely well). The resulting program was such an embarrassment (queries that used to take seconds taking minutes, exceptions being thrown all the time and memory usage ridiculously high) that they had to include the old C++ program anyway (and I don't think anyone would have seriously tried using the Java app more than once or twice).

So can we agree that "crap can be written in any language" and stop with the language bashing?

I won't dispute that C++ has a large (maybe the largest) learning curve but if you learn it properly then I don't see it being more likely to result in poorer quality code.

In modern C++ one rarely uses plain pointers excepting the case of using them for the purpose of adding extra "optional" function arguments. If you don't know about them please read up on "smart pointers".

Right now there's a critical vulnerability in the Bitcoin client, which just goes to show how easy it is to make an exploitable mistake in C++.

Also from a philosophical stance, if you knew your code had a buffer overflow then you would have fixed it. Malicious developers aside, security vulnerabilities are always unknowns. All code has bugs and some bugs are critical. You can only reduce your areas of risk, and in a language like C++ every pointer is a potential risk.