Topic: Bitcoin source code is a giant mess - page 4. (Read 10724 times)
Switching to another codebase is certainly one possibility, but refactoring the existing code is also a realistic option. Starting with a good test harness around bitcoind would be a good start for both options. And the existence of an API makes this a lot easier.
Linux kernel use goto quite extensively
Am pretty sure that it is C not C++ (and yes they are two very different languages).
We're far beyond that point. The code needs very thorough restructuring. That can be done incrementally, even while others are adding functionality, but I think it is going to be very hard to get a consensus on the needed changes.
The consesus about the needed changes could conceivably be that the official Bitcoin client switches from the "Satoshi legacy C++" to one of the newer candidate codebases, e.g. the Java code from Hungary.For me it is good to read more and more comments about the need to stop treating Satoshi (and his legacy code base and protocol) as an inviolate revelation and more as an ingenious sketch of the future.
Time for me to repost my favourite picture of an amber:
We're far beyond that point. The code needs very thorough restructuring. That can be done incrementally, even while others are adding functionality, but I think it is going to be very hard to get a consensus on the needed changes.
I would suggest that if you see problems with the bitcoin codebase, you submit a patch (and appropriate tests for your patch) via the bitcoin github, and make the codebase better! The code is open source!
Will
Will
Let's not turn this into a C++ coding standards discussion.
Linux kernel use goto quite extensively
2. Excessive use of C++ subclasses and operators makes it hard to read code. You see a << b, but it actually goes to a very specific place which is not entirely obvious where.
Streaming operators << and >> have always been the standard way of doing I/O in C++ so are you saying these operators are being used for something *other than streaming*?
I have nothing against using << as a streaming operator. The problem is that it's much harder to search for any operators in use (be it "<<" or "+"). Especially when you pointer-dereference operator overload. Or implicit copy constructors. Yes, code may look elegant for a mathematician, but inside an app where you have tons of multi-word symbols, operator density or implicitness is painful.
When you have "[a add:b]" instead of "a + b" it's much clearer what is going on and you can quickly find all occurrences of -add: method call.
I also hate these symbols, because of the same reason.
You just cannot find a function that implements it. And worse; it can either be in a header, or in a cpp file... and it can be overridden/inherited, so: good luck looking for it!
2. Excessive use of C++ subclasses and operators makes it hard to read code. You see a << b, but it actually goes to a very specific place which is not entirely obvious where.
Streaming operators << and >> have always been the standard way of doing I/O in C++ so are you saying these operators are being used for something *other than streaming*?
I have nothing against using << as a streaming operator. The problem is that it's much harder to search for any operators in use (be it "<<" or "+"). Especially when you pointer-dereference operator overload. Or implicit copy constructors. Yes, code may look elegant for a mathematician, but inside an app where you have tons of multi-word symbols, operator density or implicitness is painful.
When you have "[a add:b]" instead of "a + b" it's much clearer what is going on and you can quickly find all occurrences of -add: method call.
Donald Knuth and Linus Torvalds both agree with this sentiment. 
Just like any other tool, you have to know when to use it, and when not to use it.
Just like any other tool, you have to know when to use it, and when not to use it.Bitcoin source is by no means even remotely close to being a model of C++ exposition. Expedience always takes priority over tidiness.
If you're working on a native Mac wallet, you might want to contact Colin Tulloch. He's also exploring this. I've been trying to convince him to use bitcoinj compiled down to native code with GCJ/CNI. I prototyped this last year and got an Objective-C++ app that could load bitcoinj wallets up and running, the end result was a native .app without any Java dependencies. Unfortunately for various reasons I stopped rebasing that branch and the support wasn't fully documented or integrated into bitcoinj. But writing a real SPV wallet app is a lot of work, so reusing the work we've done in the Java world makes a ton of sense. From the code perspective it looks like writing C++ except you don't need to delete objects and the API uses jstrings instead of std::string or NSString.
The fact that goto has been used badly doesn't make it a bad instrument: it's a great instrument if you know exactly when to use or not use it.
Donald Knuth and Linus Torvalds both agree with this sentiment.
Just like any other tool, you have to know when to use it, and when not to use it.
it ties into the topic, What are the problems that the code creates? What problems will it cause?
Hard to read, harder to change without breaking something.
it ties into the topic,
What are the problems that the code creates? What problems will it cause?
What are the problems that the code creates? What problems will it cause?
...
Completely off-topic. This post is only about the form of the code and not its content (which is equally important, but not the subject of this thread).
I don't know how to program C++, but I can tell from what I do know that the Bitcoin system feels intentionally limited.
the block chain limit of 1mb... creates fee scarcity fluctuations; The limit will be hit sooner and economic effects from the fees will be visible once we get close to it.
the size of the coin limit of 21 million, if it had been 210 million with 500 coin initial block release, the price would more easily be able to handle large fluctuations a far smoother accent to it's final value.Having the limit that small to me feels like it was done intentionally for experimental observations, more scarcity econonomics.
also the number of zeros past the period also feels like a mistake with large disparities in value between two currencies it becomes very difficult to transfer financial information when large chunks of an economy are absorbed, Think along the lines of 100 trillion yen cap value to bitcoin with someone trying to exchange a small amount to a country like zimbabwe with a 1million/1USD value... there are not enough digits to transfer the value accurately in that situation, you'd be limited to doing 100 thousand zimbabwe dollar transaction... what if you can buy a cup of coffee in zimbabwe with 100 Z dollars? you wouldn't be able to do the micro-transaction.
10 minute confirms? when transactions can go around the globe in under a second. with a 1mb limit every 1 minute it could more effectively use the network overall power and increase security on a timed basis.
It would not surprise me that the code was written intentionally for big problems to occur much sooner, for expermentation... Bitcoin really is an experiment, the limits it has are made to cause instability intentionally or to observe data fluctuations more easily. The code itself could be flawed and vague on purpose.
So what is everyone doing to improve these possibly intentional limitations?
the block chain limit of 1mb... creates fee scarcity fluctuations; The limit will be hit sooner and economic effects from the fees will be visible once we get close to it.
the size of the coin limit of 21 million, if it had been 210 million with 500 coin initial block release, the price would more easily be able to handle large fluctuations a far smoother accent to it's final value.Having the limit that small to me feels like it was done intentionally for experimental observations, more scarcity econonomics.
also the number of zeros past the period also feels like a mistake with large disparities in value between two currencies it becomes very difficult to transfer financial information when large chunks of an economy are absorbed, Think along the lines of 100 trillion yen cap value to bitcoin with someone trying to exchange a small amount to a country like zimbabwe with a 1million/1USD value... there are not enough digits to transfer the value accurately in that situation, you'd be limited to doing 100 thousand zimbabwe dollar transaction... what if you can buy a cup of coffee in zimbabwe with 100 Z dollars? you wouldn't be able to do the micro-transaction.
10 minute confirms? when transactions can go around the globe in under a second. with a 1mb limit every 1 minute it could more effectively use the network overall power and increase security on a timed basis.
It would not surprise me that the code was written intentionally for big problems to occur much sooner, for expermentation... Bitcoin really is an experiment, the limits it has are made to cause instability intentionally or to observe data fluctuations more easily. The code itself could be flawed and vague on purpose.
So what is everyone doing to improve these possibly intentional limitations?
Close enough to have a working goto...
Hmm... am not really sure about that (and no C++ guru would ever recommend using it) - the problem is that the compiler needs to handle all the object dtors correctly (the reason why it is *not easier for the compiler*).
I am not sure that g++ (or other major compilers) give such a guarantee.
It's a bit like using *void* pointers (another common C idiom that is *bad* in C++).
Really? Well, then I was wrong all my life, believing that C++ was backward compatible with C...
You are wrong - C++ is *not* backwards compatible with C only as *close as possible*.
Really? Well, then I was wrong all my life, believing that C++ was backward compatible with C...
You are wrong - C++ is *not* backwards compatible with C only as *close as possible*.
The fact that goto has been used badly doesn't make it a bad instrument: it's a great instrument if you know exactly when to use or not use it.
Opposing it just because someone isn't trained or smart enough to use it properly is a dumbing down which does much much much more harm than good.
Opposing it just because someone isn't trained or smart enough to use it properly is a dumbing down which does much much much more harm than good.
Jump to: