CIYAM
Legendary
Offline
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 04, 2013, 03:11:14 PM |
|
Close enough to have a working goto... ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) 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++).
|
|
|
|
jdbtracker
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 04, 2013, 03:24:01 PM Last edit: June 04, 2013, 09:24:41 PM by jdbtracker |
|
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?
|
If you think my efforts are worth something; I'll keep on keeping on. I don't believe in IQ, only in Determination.
|
|
|
misterbigg (OP)
Legendary
Offline
Activity: 1064
Merit: 1001
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 04, 2013, 03:34:56 PM |
|
... 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).
|
|
|
|
jdbtracker
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 04, 2013, 03:45:16 PM |
|
it ties into the topic,
What are the problems that the code creates? What problems will it cause?
|
If you think my efforts are worth something; I'll keep on keeping on. I don't believe in IQ, only in Determination.
|
|
|
misterbigg (OP)
Legendary
Offline
Activity: 1064
Merit: 1001
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 04, 2013, 03:46:40 PM |
|
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.
|
|
|
|
jgarzik
Legendary
Offline
Activity: 1596
Merit: 1099
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 04, 2013, 03:47:42 PM |
|
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. ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) Just like any other tool, you have to know when to use it, and when not to use it.
|
Jeff Garzik, Bloq CEO, former bitcoin core dev team; opinions are my own. Visit bloq.com / metronome.io Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
|
|
|
Mike Hearn
Legendary
Offline
Activity: 1526
Merit: 1129
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 04, 2013, 03:47:53 PM |
|
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.
|
|
|
|
misterbigg (OP)
Legendary
Offline
Activity: 1064
Merit: 1001
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 04, 2013, 04:06:11 PM |
|
Donald Knuth and Linus Torvalds both agree with this sentiment. ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) 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.
|
|
|
|
oleganza
Full Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 200
Merit: 104
Software design and user experience.
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 04, 2013, 04:42:08 PM |
|
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.
|
Bitcoin analytics: blog.oleganza.com / 1TipsuQ7CSqfQsjA9KU5jarSB1AnrVLLo
|
|
|
piotr_n
Legendary
Offline
Activity: 2053
Merit: 1356
aka tonikt
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 04, 2013, 04:43:39 PM |
|
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. +1 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!
|
Check out gocoin - my original project of full bitcoin node & cold wallet written in Go.PGP fingerprint: AB9E A551 E262 A87A 13BB 9059 1BE7 B545 CDF3 FD0E
|
|
|
sickpig
Legendary
Offline
Activity: 1260
Merit: 1008
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 04, 2013, 04:57:27 PM |
|
Presented without comment: link (github.com)Linux kernel use goto quite extensively
|
Bitcoin is a participatory system which ought to respect the right of self determinism of all of its users - Gregory Maxwell.
|
|
|
mmeijeri
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 04, 2013, 05:05:45 PM |
|
Let's not turn this into a C++ coding standards discussion.
|
ROI is not a verb, the term you're looking for is 'to break even'.
|
|
|
willphase
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 04, 2013, 10:57:49 PM |
|
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
|
|
|
|
mmeijeri
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 04, 2013, 11:00:08 PM |
|
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.
|
ROI is not a verb, the term you're looking for is 'to break even'.
|
|
|
2112
Legendary
Offline
Activity: 2128
Merit: 1073
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 05, 2013, 01:45:44 AM |
|
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: It is an ambodiment of both the mess and the beauty.
|
|
|
|
CIYAM
Legendary
Offline
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 05, 2013, 03:24:20 AM |
|
Linux kernel use goto quite extensively
Am pretty sure that it is C not C++ (and yes they are two very different languages).
|
|
|
|
mmeijeri
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 05, 2013, 06:37:59 AM |
|
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.
|
ROI is not a verb, the term you're looking for is 'to break even'.
|
|
|
LvM
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 09, 2013, 05:45:38 PM |
|
Worst problem of BTC is not the code but the basic "cash/change" logic ignoring all fundamentals of GAAP. Ripple -though in this respect much better structured- cannot be trusted due to many other reasons.
|
|
|
|
oleganza
Full Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 200
Merit: 104
Software design and user experience.
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 09, 2013, 06:47:19 PM |
|
Worst problem of BTC is not the code but the basic "cash/change" logic ignoring all fundamentals of GAAP. Ripple -though in this respect much better structured- cannot be trusted due to many other reasons.
Can you expand on cash/change problem? What's wrong with it?
|
Bitcoin analytics: blog.oleganza.com / 1TipsuQ7CSqfQsjA9KU5jarSB1AnrVLLo
|
|
|
mmeijeri
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 09, 2013, 06:48:05 PM |
|
Not again, he already has his own thread.
|
ROI is not a verb, the term you're looking for is 'to break even'.
|
|
|
|