Topic: Bitcoin source code is a giant mess (Read 10793 times)
And also, for fun : https://en.wikipedia.org/wiki/Considered_harmful
$ grep -R goto ~/linux-3.10-rc5/* | wc -l
108095
Also Dijkstra was wrong: -
http://pplab.snu.ac.kr/courses/adv_pl05/papers/p261-knuth.pdf
If you want to argue with Knuth, you're a braver soul than me.
And for entertainment value: -
http://harmful.cat-v.org/software/c++/linus
108095
Also Dijkstra was wrong: -
http://pplab.snu.ac.kr/courses/adv_pl05/papers/p261-knuth.pdf
If you want to argue with Knuth, you're a braver soul than me.
And for entertainment value: -
http://harmful.cat-v.org/software/c++/linus
well, this thread has degenerated, so I'll throw a couple wrenches of my own.
I've read the comments and looked at the information that I can find... I think Satoshi was a programmer, just that they were a C programmer trying to write in C++ code.
If we approach the source code from the perspective of a C programmer it could start making sense.
I've read the comments and looked at the information that I can find... I think Satoshi was a programmer, just that they were a C programmer trying to write in C++ code.
If we approach the source code from the perspective of a C programmer it could start making sense.
More likely he was a Mathematician or EE who knew how to program. Comp. Sci. types tend to understand the need for a disciplined approach to programming..
well, this thread has degenerated, so I'll throw a couple wrenches of my own.
I've read the comments and looked at the information that I can find... I think Satoshi was a programmer, just that they were a C programmer trying to write in C++ code.
If we approach the source code from the perspective of a C programmer it could start making sense.
I've read the comments and looked at the information that I can find... I think Satoshi was a programmer, just that they were a C programmer trying to write in C++ code.
If we approach the source code from the perspective of a C programmer it could start making sense.
because C++ sucks.
and with that I'm out of here - enjoy the trolling guys - hopefully at least a point or two managed to get through.
If code is less readable, you're wrong.
It's as simple as that.
i.e. for the very same reason you oppose goto, goto is good in some situations.It's as simple as that.
If code is less readable, you're wrong.
It's as simple as that.
It's as simple as that.
i.e. for the very same reason you oppose goto, goto is good in some situations.
I'm sorry but you're wrong and being a child at the same time - read my initial post about undefined behaviour and *landmines* then you can join in with the adults.
Sheesh!
I think any useful discussion has left this topic already so I will probably unwatch about now.
If code is less readable, you're wrong.
It's as simple as that.
i.e. for the very same reason you oppose goto, goto is good in some situations.It's as simple as that.
Code:
bool done = false;
bool some_cond = false;
for( size_t i = 0; i < 10 && !done; i++ )
{
for( size_t j = 0; j < 10 && !done; j++ )
{
for( size_t k = 0; k < 10 && !done; k++ )
{
if( some_cond )
{
done = true;
break;
}
}
}
}
This is horrible and *MUCH* less clear than a simple goto.
Code:
bool some_cond = false;
for( size_t i = 0; i < 10; i++ )
{
for( size_t j = 0; j < 10; j++ )
{
for( size_t k = 0; k < 10; k++ )
{
if( some_cond )
{
goto end;
}
}
}
}
end:
If code is less readable, you're wrong.
It's as simple as that.
This is a case of bad goto use.
Really - understand that there is "no good goto use" in C++ (see below).
As long as you don't jump outside of trys, or inside loops, that's fine.
I.e. it is mostly used to jump out of nested loops.
And yes, there are plenty of situations were nested loops make sense. And doing that with an exception is violating the KISS principle.
I.e. it is mostly used to jump out of nested loops.
And yes, there are plenty of situations were nested loops make sense. And doing that with an exception is violating the KISS principle.
By placing a goto *anywhere* in code you have placed the coding equivalent of a *landmine*.
Why? Because if anyone in the future working on a large loop with a goto hiding in it uses some normally perfectly acceptable OO or exception handling code then *boom* you end up with undefined behavior even though you didn't even *write* the stupid goto.
So if you think it is a good idea to hide gotos in large loops then I'd suggest you might want to put a comment on every 3rd line or so like this:
// Warning, warning! Danger Will Robertson! This loop contains a *goto* landmine. You are best to only write C code in here.
In no C++ project that I have worked on was *goto* ever used (or would have been accepted) and even in a very large C project I worked on it was used very sparingly.
The only people I've found to still write "goto" are C programmers who never managed to accept the idea of exception handling.
BTW - for your nested loop situation use this approach:
Code:
bool done = false;
bool some_cond = false;
for( size_t i = 0; i < 10 && !done; i++ )
{
for( size_t j = 0; j < 10 && !done; j++ )
{
for( size_t k = 0; k < 10 && !done; k++ )
{
if( some_cond )
{
done = true;
break;
}
}
}
}
to explain the problem with pseudo c++ code(pseudo code with c syntax, gotos and exceptions. as i can't code C++, but hate it on principal):
Code:
try {
goto out;
} catch exception {
print("am im getting printed or not?");
} finally {
print("okay, does i get printed too then?")
}
out:
throw exception;
This is a case of bad goto use.
As long as you don't jump outside of trys, or inside loops, that's fine.
I.e. it is mostly used to jump out of nested loops.
And yes, there are plenty of situations were nested loops make sense. And doing that with an exception is violating the KISS principle.
And a Jump table is what?
It is not part of the C++ language (so not relevant to this discussion).
Understand that the main evil in coding goto is the possibility of it leading to undefined behavior which does not have to be reported by the compiler (same as something like a[ i ] = i++; which compilers are not likely to give you any warning about).
I don't think this problem is specific to C++ complier.
Code:
try {
goto out;
} catch exception {
print("am im getting printed or not?");
} finally {
print("okay, does i get printed too then?")
}
out:
throw exception;
And a Jump table is what?
It is not part of the C++ language (so not relevant to this discussion).
Understand that the main evil in coding goto is the possibility of it leading to undefined behavior which does not have to be reported by the compiler (same as something like a[ i ] = i++; which compilers are not likely to give you any warning about).
I don't think this problem is specific to C++ complier.
I'm a novice at C++
Why use goto instead of a throw for error handling?
to take *advantage* of undefined behavior. Why use goto instead of a throw for error handling?
I'm a novice at C++
Why use goto instead of a throw for error handling?
Why use goto instead of a throw for error handling?
And a Jump table is what?
It is not part of the C++ language (so not relevant to this discussion).
Understand that the main evil in coding goto is the possibility of it leading to undefined behavior which does not have to be reported by the compiler (same as something like a[ i ] = i++; which compilers are not likely to give you any warning about).
Ok, this is getting nuts. there is nothing inheritantly wrong wrong with goto. the problem is that not everyone uses them responsibly. there once was a time in history when poor use of goto created what was called "spaghetti code" where people used goto's to jump into the middle of functions and such all over the place. this made the code hard to read and costly to return. This caused the stigma on goto. Structured Programming using accepted constructs becae the norm.
For any company paying to have code developed, Maintainability became the mandate. Arguing about goto accomplishes nothing. if you are coding for free, do what ya want, go ahead, develop bad habits. Somebody will make you confrom sooner or later. the US Gov. spent hugh sums getting ADA developed and used to encourage a common structured, readable language. Today, ADA isn't so popular, i suspect because the rebels couldn't do what ever they wanted.
The thing to do if you are coding for public consumption is to write and document your code as if the next person isn't as smart as you and what is clear to you may not be clear to them. Do this and you'll be a successful Professional Programmer/Software Engineer.
For any company paying to have code developed, Maintainability became the mandate. Arguing about goto accomplishes nothing. if you are coding for free, do what ya want, go ahead, develop bad habits. Somebody will make you confrom sooner or later. the US Gov. spent hugh sums getting ADA developed and used to encourage a common structured, readable language. Today, ADA isn't so popular, i suspect because the rebels couldn't do what ever they wanted.
The thing to do if you are coding for public consumption is to write and document your code as if the next person isn't as smart as you and what is clear to you may not be clear to them. Do this and you'll be a successful Professional Programmer/Software Engineer.
+1 CIYAM. To add to your good and explanative post, we could add that the main *good* usage of goto in C is for error handling, or to rephrase : to compensate for the lack of ... exceptions. Exception handling being provided by C++, there's no good reason to use gotos in C++ anymore.
gotoes are directly dangerous in C++.And a Jump table is what?
Isn't this open source? anybody can rewrite the code in any language that they want.
It definitely *is* open source but not just *anybody* can rewrite the code - to do that you would need to understand not just the C++ language (which I don't think anyone here is arguing is easy itself) but also boost (a big library which I actually don't use) as well as the other libraries that are being used in the project.
Even the devs themselves missed the subtleties of BerkleyDB that led to the temporary "hard-fork".
In short - no-one is going to come up with a 100% compatible Bitcoin equivalent in another language without a *lot* of work (a point that has been argued in various other threads - the problem was that Satoshi wrote the spec *after* he wrote the code).
so, anyone with the time, the knowledge, and the desire can rewrite it in any language. as for it being used. I don't see that being an issue. It doesn't mean that it can't be done.
Isn't this open source? anybody can rewrite the code in any language that they want.
It definitely *is* open source but not just *anybody* can rewrite the code - to do that you would need to understand not just the C++ language (which I don't think anyone here is arguing is easy itself) but also boost (a big library which I actually don't use) as well as the other libraries that are being used in the project.
Even the devs themselves missed the subtleties of BerkleyDB that led to the temporary "hard-fork".
In short - no-one is going to come up with a 100% compatible Bitcoin equivalent in another language without a *lot* of work (a point that has been argued in various other threads - the problem was that Satoshi wrote the spec *after* he wrote the code).
Isn't this open source? anybody can rewrite the code in any language that they want.
... but the satoshi client is still official community approved and most well tested client, so nobody gonna use it unless rewrite is very good, or suits there specific needs.
Isn't this open source? anybody can rewrite the code in any language that they want.
+1 CIYAM. To add to your good and explanative post, we could add that the main *good* usage of goto in C is for error handling, or to rephrase : to compensate for the lack of ... exceptions. Exception handling being provided by C++, there's no good reason to use gotos in C++ anymore.
gotoes are directly dangerous in C++.
+1 CIYAM. To add to your good and explanative post, we could add that the main *good* usage of goto in C is for error handling, or to rephrase : to compensate for the lack of ... exceptions. Exception handling being provided by C++, there's no good reason to use gotos in C++ anymore.
I think goto's are fine, they are just unfashionable
but fast and handy.
but fast and handy.
In C they can indeed make sense - but in C++ they present problems that the language itself does *not* provide guarantees for (in regards to safe exception handling).
So in C++ "goto" really is a "no no" (for error handling as the "goto" in this topic was originally referring to you should just use a "throw").
The *only* reason that *goto* was not *dropped* as a keyword from C++ was to keep backwards compatibility as much as possible with C.
So "fast and handy" they maybe - but in C++ they are 100% *wrong* (as any exception handling would get *screwed* by the *goto* as the language does not cater for this situation).
It goes the same for "setjmp" and "longjmp" (guess most don't remember those) - they can also *not* be used safely in C++ apps.
heretical as it is
I think goto's are fine, they are just unfashionable
but fast and handy.
I think goto's are fine, they are just unfashionable
but fast and handy.
In case of bitcoin quality and performance is high because of high effort of highly capable people committed to it. It however does not have the right patterns and is not well readable.
So then I think that *fundamentally* what we are really looking at identifying is which are the *wrong* patterns and how they should be reworked and also how any *unreadable* code should be changed to make it more readable.
This would be a much more productive direction than just having a "language war" (which never gets anywhere that I've seen in following such things since using Usenet back in the early 90's).
(I also don't think that Bitcoin should be *exclusively* C++ as I do support the idea of eventually there being a Bitcoin protocol RFC type document that *could* be implemented in any decent language).
Whilst I am an advocate of C++ (and don't see any reason to change the language at all) I think in any case the importance is the choice of algorithms and design patterns not the language itself.
Any language that provides the correct semantics with reasonable enough performance and is readable should be acceptable.
+1Any language that provides the correct semantics with reasonable enough performance and is readable should be acceptable.
I do not hate C++.
I think that there are languages that better support good design patterns, readability, code quality and have a performance that is acceptable. That does not mean there would not be any C++ code that has the right patterns, readability and quality.
In case of bitcoin quality and performance is high because of high effort of highly capable people committed to it. It however does not have the right patterns and is not well readable.
I'm just asking, I wanted to try to learn a new language and build a Bitcoin clone with extra features that the language can provide, just extra features or flexibility.
Whilst I am an advocate of C++ (and don't see any reason to change the language at all) I think in any case the importance is the choice of algorithms and design patterns not the language itself.
Any language that provides the correct semantics with reasonable enough performance and is readable should be acceptable.
BTW - all the C++ haters should have a list of bugs that *crash* the bitcoin-qt client (and lose people BTC) - could we have a list please just so we have an idea of how *broken* it actually is?
(and if it is not broken then why are people arguing it *needs* to rewritten in another language?)
Any language that provides the correct semantics with reasonable enough performance and is readable should be acceptable.
BTW - all the C++ haters should have a list of bugs that *crash* the bitcoin-qt client (and lose people BTC) - could we have a list please just so we have an idea of how *broken* it actually is?
(and if it is not broken then why are people arguing it *needs* to rewritten in another language?)
Java was already a step forward.
SBROFL.Java is a terrible step backward, it's a total mess, manages to overcomplicates everything both over modern+higher level languages, AND over C/C++ themselves.
Java was already a step forward.
The next time I would consider Scala as it runs on JVM is OOP and is functional.
The next time I would consider Scala as it runs on JVM is OOP and is functional.
Go.
So what would be the ideal programming language to build Bitcoins succesor?
and of course functional programming is the way forward, not OOP.
so, you like functional programming, hence functional programming is the way to go, and everyone else is doing it wrong.well thought...
C++ sucks.
People who repeatedly type C++ sucks *suck*.
Guys, how many extra hashes you will get programming oo? None notices the irony of things? Indeed, BTC was designed for PC, but "surprise", FPGAs and ASIC too control over it, hashes are today produced with very low level hardware, quite the oposite of "OO"..
lolwut.we're not talking about miners here.
Dude, no patronizing intention, but you always are under scrutinize of miners here., They move the thing around..
Guys, how many extra hashes you will get programming oo? None notices the irony of things? Indeed, BTC was designed for PC, but "surprise", FPGAs and ASIC too control over it, hashes are today produced with very low level hardware, quite the oposite of "OO"..
lolwut.we're not talking about miners here.
Guys, how many extra hashes you will get programming oo? None notices the irony of things? Indeed, BTC was designed for PC, but "surprise", FPGAs and ASIC too control over it, hashes are today produced with very low level hardware, quite the oposite of "OO"..
no, C++ generally sucks.
I can code OO, but it sucks big time when you don't have a interpreter or duck typing. (python ftw!)
and of course functional programming is the way forward, not OOP.
you want duck typing? cast everything to void* I can code OO, but it sucks big time when you don't have a interpreter or duck typing. (python ftw!)
and of course functional programming is the way forward, not OOP.
A lot of the more recent changes to C++ have been to make things *easier* (such as the new use of "auto") as well as to improve its *functional programming* limitations and other general improvements (such as no longer requiring a space between two '>' characters in order to avoid being confused with the '>>' operator).
The major *problem* it has was that unlike more modern languages it wasn't designed to do some of the things that it was later found to be able to do (some admittedly much worse than can be done in other languages) and so has had to *evolve* (and this evolution has been slow).
That evolution is still ongoing but I certainly understand that it is not appealing to many - if "beauty" is in the eye of the beholder then I can appreciate that C++ is the kind of language you would have had to have had quite a few beers before thinking of it as anything more than comely.
You assume evolution makes 'good' choices. Your assumption is wrong.The major *problem* it has was that unlike more modern languages it wasn't designed to do some of the things that it was later found to be able to do (some admittedly much worse than can be done in other languages) and so has had to *evolve* (and this evolution has been slow).
That evolution is still ongoing but I certainly understand that it is not appealing to many - if "beauty" is in the eye of the beholder then I can appreciate that C++ is the kind of language you would have had to have had quite a few beers before thinking of it as anything more than comely.
C++ sucks.
A lot of the more recent changes to C++ have been to make things *easier* (such as the new use of "auto") as well as to improve its *functional programming* limitations and other general improvements (such as no longer requiring a space between two '>' characters in order to avoid being confused with the '>>' operator).
The major *problem* it has was that unlike more modern languages it wasn't designed to do some of the things that it was later found to be able to do (some admittedly much worse than can be done in other languages) and so has had to *evolve* (and this evolution has been slow).
That evolution is still ongoing but I certainly understand that it is not appealing to many - if "beauty" is in the eye of the beholder then I can appreciate that C++ is the kind of language you would have had to have had quite a few beers before thinking of it as anything more than comely.
The major *problem* it has was that unlike more modern languages it wasn't designed to do some of the things that it was later found to be able to do (some admittedly much worse than can be done in other languages) and so has had to *evolve* (and this evolution has been slow).
That evolution is still ongoing but I certainly understand that it is not appealing to many - if "beauty" is in the eye of the beholder then I can appreciate that C++ is the kind of language you would have had to have had quite a few beers before thinking of it as anything more than comely.
I will simply say that I did manage to build CIYAM which is a web application generating platform using C++ and using *no other framework* nor back-end scripting language.
Okay, you managed to use C++ to make a application. Good for you.So even if it does suck - it has enough going right with it to be able to do that much at least.
Did you know that brainfuck can print the mandlebrot factal in ascii art?Just because you *can* code in it, does not make it good.
Languages are tools and as such are really only as bad as the hands of those who lack the skill to use them correctly (yes - most people do not have the patience to learn a language as difficult as C++ and I would probably not advise anyone to do so if they don't want to spend many years learning).
Languages does not need to be complicated to be efficient, C++ is way to complicated(and yet i understand it!). Bjarne Stroustrup did it wrong, by taking a good and uncomplicated language(C), and fucked it up(C++). if he had designed it from the bottom, it would have been much better. C and classes does not mix well. but you can still do OOP in C, the whole linux vfs is OO C code.
I will simply say that I did manage to build CIYAM which is a web application generating platform using C++ and using *no other framework* nor back-end scripting language.
So even if it does suck - it has enough going right with it to be able to do that much at least.
Languages are tools and as such are really only as bad as the hands of those who lack the skill to use them correctly (yes - most people do not have the patience to learn a language as difficult as C++ and I would probably not advise anyone to do so if they don't want to spend many years learning).
So even if it does suck - it has enough going right with it to be able to do that much at least.
Languages are tools and as such are really only as bad as the hands of those who lack the skill to use them correctly (yes - most people do not have the patience to learn a language as difficult as C++ and I would probably not advise anyone to do so if they don't want to spend many years learning).
Of course you are aware that C++ *does* functional programming,
nope, it does not. can C++ generate complex functions at runtime, with only a little programming(compiling code/assembly/implementing brainfuck and then use it is cheating).
you cannot easily compose one function from another 2 functions in C++.
along with procedural, object oriented, generic
Well thats one is true, but which language doesn't?
Quote
and let's not forget template meta programming (and actually the *last* one of these is the big *way forward* which basically *no other* language can do).
nope that sucks too, because C++ generally sucks. Haskell does some of the same at compile time, because of its lazy evaluation and referential transparency. C++ sucks big time at this. and of course functional programming is the way forward, not OOP.
Of course you are aware that C++ *does* functional programming, along with procedural, object oriented, generic and let's not forget template meta programming (and actually the *last* one of these is the big *way forward* which basically *no other* language can do).
a) C++ generally sucks.
c) C++ generally sucks.
anti c++ circlejerk thread?c) C++ generally sucks.
I can code OO, but it sucks big time when you don't have a interpreter or duck typing. (python ftw!)
and of course functional programming is the way forward, not OOP.
a) C++ generally sucks.
c) C++ generally sucks.
anti c++ circlejerk thread?c) C++ generally sucks.
C++ generally sucks if you never had the time or intelligence to learn OOP.
LOL. Global Variables: the wave of the future.
Just rewrite the whole thing in ADA. End of problem.
RELEASE TEH DIJKSTRA!..
Actually I ate enough Dijkstra during uni to hate "goto" forever even if I started writing BASIC when I was 10 years old..
a) C++ generally sucks.
c) C++ generally sucks.
anti c++ circlejerk thread? c) C++ generally sucks.
a) C++ generally sucks.
b) goto err, the best way to handle errors in C, they are better than nested if/else and breaks.
c) C++ generally sucks.
b) goto err, the best way to handle errors in C, they are better than nested if/else and breaks.
c) C++ generally sucks.
Interesting that people still use COBOL, FORTRAN and C++. Rather than try to fix that C++ code, would be easier to switch completely to some modern language, and have a small library of functions coded in C/ASM where efficiency is critical.
Not again, he already has his own thread.
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.
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?
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.
Ripple -though in this respect much better structured- cannot be trusted due to many other reasons.
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.
Coding in C and never using goto, is like driving a car and never using its last gear. Safe for poor drivers... 
Bitcoin is written in C++ (which is not even close to C as any C++ programmer knows).
Coding in C and never using goto, is like driving a car and never using its last gear. Safe for poor drivers...
Bitcoin is written in C++ (which is not even close to C as any C++ programmer knows).
Coding in C and never using goto, is like driving a car and never using its last gear. Safe for poor drivers...
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*?
"goto err" is not a big deal in my view.
Bitcoin-QT is a mess for entirely different reasons.
1. Endianness is not well documented. libbitcoin flips some bytes where BitcoinQT does not, but also does not document why they are doing that.
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.
3. Some utility class names look like variable names.
4. Some funny design patterns are not documented even with a single line of text. E.g. CBigNum is smartly done (BN_CTX and BIGNUM are wrapped in classes differently), but you have to be really proficient in C++ or spend half a day deciphering the code to understand why it is done that way. For someone coming from C/Objective-C it's not easy.
I'm working on Mac wallet app and reimplement many things that BitcoinQT does in C and ObjC and learn how that whole thing works. It is smart, but it's messy.
Bitcoin-QT is a mess for entirely different reasons.
1. Endianness is not well documented. libbitcoin flips some bytes where BitcoinQT does not, but also does not document why they are doing that.
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.
3. Some utility class names look like variable names.
4. Some funny design patterns are not documented even with a single line of text. E.g. CBigNum is smartly done (BN_CTX and BIGNUM are wrapped in classes differently), but you have to be really proficient in C++ or spend half a day deciphering the code to understand why it is done that way. For someone coming from C/Objective-C it's not easy.
I'm working on Mac wallet app and reimplement many things that BitcoinQT does in C and ObjC and learn how that whole thing works. It is smart, but it's messy.
You're a OpenCoin employee / currently hired by OpenCoin?
No
It's doable but it needs to be a design criteria from the beginning.
Indeed - I did it with an Object Database I created (the error string buffers are pre-allocated before the ODB instance is even created) - it is a little tricky though as you end up using "non-standard" exceptions (although you can make it enough like a std::exception to be useful).
You're a OpenCoin employee / currently hired by OpenCoin?
...I doubt there is much code out there at all that can really handle out of memory conditions well (for a start you can't throw a std::runtime_error as that needs a std::string to be allocated).
It's doable but it needs to be a design criteria from the beginning.
I seriously doubt that Bitcoin is written robustly throughout to handle out of memory conditions.
Actually I doubt there is much C++ code out there at all (apart from perhaps OS level code) that can really handle out of memory conditions well (for a start you can't throw a std::runtime_error as that needs a std::string to be allocated).
Well in my code you would have seen something like this:
Code:
if (!pkey || !group || !pub_key || !priv_key)
throw runtime_error( "no keys or group found" );
Yeah I agree, I don't see how it is useful to return an error in this case. You want the program to halt. I seriously doubt that Bitcoin is written robustly throughout to handle out of memory conditions.
Yup - just checked the source link - error handling.
Well in my code you would have seen something like this:
BTW - I hate the term RAII (although it stuck) - I argued years ago on comp.lang.c++.moderated to call the idiom "scoped objects".
Well in my code you would have seen something like this:
Code:
if (!pkey || !group || !pub_key || !priv_key)
throw runtime_error( "no keys or group found" );
BTW - I hate the term RAII (although it stuck) - I argued years ago on comp.lang.c++.moderated to call the idiom "scoped objects".
Can we have some context on how it was used?
Yep I updated the original post to include a link.
...These situations include: multi-level breaks, resource allocation/deallocation, error handling in C language, computed goto in Perl language.
In this case its error handling in the C language (although Bitcoin is written in C++).
Everybody is afraid of breaking it since it appears to work, and that is reasonable to an extent, but on the other hand this code base is utterly unsuitable for serious work.
Yep. A year ago I came in here and I wanted to work on Bitcoin. Clean it up a bit, reduce external dependencies, etc... but I was pooh-poohed. Now I'm doing the same work in Ripple, and it is welcomed. For Bitcoin code to improve first the people working on it need to acknowledge that there's a growing problem and then commit to addressing it. Even if it is just a little bit at a time, or for example making sure that new code is clean (adding RAII utilities where needed, for example), it can help to reverse the spaghettification.
Can we have some context on how it was used?
Also:
Also:
Quote
While overall usage of gotos has been declining, there are still situations in some languages where a goto provides the shortest and most straightforward way to express program's logic (while it's possible to express the same logic without gotos, the equivalent code will be longer and often more difficult to understand).
These situations include: multi-level breaks, resource allocation/deallocation, error handling in C language, computed goto in Perl language.[15][16]
These situations include: multi-level breaks, resource allocation/deallocation, error handling in C language, computed goto in Perl language.[15][16]
Gavin has said that the genius doesn't lie in the code base, but in the algorithms and that the code is crap. I agree with that assessment. There's a somewhat refactored version available that can also be used for alt coins, but I don't have a link handy right now. I've been thinking about refactoring the code myself. Everybody is afraid of breaking it since it appears to work, and that is reasonable to an extent, but on the other hand this code base is utterly unsuitable for serious work.
I think this would very much depend upon the specific context - although I haven't coded a "goto" myself since the 1980's I did work on some C code with huge *case* statements in the 90's where it can actually make some sense (in general it is not a good idea with C++ due to the problems of exception handling).
Typically the only reason to use such a construct would be to "skip" to the *end* of a large block of code (and of course you could always use *break* inside a loop to do the same thing).
In no way is a *goto* more "efficient for the compiler" though (nor is it very good for human eyes as no-one would *expect* to even *see* a goto these days) so in regards to your quote I'd have to agree it doesn't inspire a lot of confidence.
Typically the only reason to use such a construct would be to "skip" to the *end* of a large block of code (and of course you could always use *break* inside a loop to do the same thing).
In no way is a *goto* more "efficient for the compiler" though (nor is it very good for human eyes as no-one would *expect* to even *see* a goto these days) so in regards to your quote I'd have to agree it doesn't inspire a lot of confidence.
Jump to: