elective-stereophonic
elective-stereophonic
NXT client in C/C++ - any chances?
singapore
Please login or register.

Login with username, password and session length
Advanced search  

News:

Latest Nxt Client: Nxt 1.11.15

Pages: 1 2 3 [All]

Author Topic: NXT client in C/C++ - any chances?  (Read 12963 times)

d5000

  • Jr. Member
  • **
  • Karma: +2/-0
  • Offline Offline
  • Posts: 28
    • View Profile
NXT client in C/C++ - any chances?
« on: July 30, 2014, 02:21:00 pm »

Are there plans to develop a NXT client in a compiled language like C/C++? Or on another language/technology which not requires the end user to install Java?

I think that would be a great advance as many of the criticisms towards Nxt are related to its dependency on Java.

Personally, above all I would appreciate a minimal, lightweight command line client for use on remote machines.
Logged

Brangdon

  • Hero Member
  • *****
  • Karma: +229/-25
  • Offline Offline
  • Posts: 1389
  • Quality is addictive.
    • View Profile
Re: NXT client in C/C++ - any chances?
« Reply #1 on: August 10, 2014, 09:06:22 pm »

I imagine the problem is not so much developing it, as maintaining it in the face of rapid(*) development of the Java source. And the Java source is arguably the easiest way to support all the platforms Nxt is on, so is unlikely to be dropped. Having the code in two languages would mean a perpetual challenge keeping them in sync. It may be more practical in a year or two, if the pace of development slows. (It has to slow sometime, right?)


(*) - for some reason my fingers wanted to type "rabid".
Logged

Eadeqa

  • Hero Member
  • *****
  • Karma: +83/-68
  • Offline Offline
  • Posts: 1888
    • View Profile
Re: NXT client in C/C++ - any chances?
« Reply #2 on: August 10, 2014, 09:18:58 pm »

Are there plans to develop a NXT client in a compiled language like C/C++? Or on another language/technology which not requires the end user to install Java?

Nxt client is written in Javascript and does not require Java (for example trade.secureae.com works without Java). Yes, Nxt client can be written in C++ and use public nodes with local signing.

Nxt server is in Java. There is no need for C++ version anyway, as users with less than 100,000 Nxt have no chance to forge and should use lightweight client anyway, especially given most are behind NAT and don't even provide bandwidth support to the network, as nxt server doesn't use UPnP. 


« Last Edit: August 10, 2014, 09:21:23 pm by Eadeqa »
Logged
NXT-GZYP-FMRT-FQ9K-3YQGS

Brangdon

  • Hero Member
  • *****
  • Karma: +229/-25
  • Offline Offline
  • Posts: 1389
  • Quality is addictive.
    • View Profile
Re: NXT client in C/C++ - any chances?
« Reply #3 on: August 10, 2014, 11:03:05 pm »

I think I'd rather have the full block-chain stored locally, with full validation of transactions, even if I didn't have enough Nxt to forge.
Logged

Eadeqa

  • Hero Member
  • *****
  • Karma: +83/-68
  • Offline Offline
  • Posts: 1888
    • View Profile
Re: NXT client in C/C++ - any chances?
« Reply #4 on: August 11, 2014, 06:43:36 am »

I think I'd rather have the full block-chain stored locally, with full validation of transactions, even if I didn't have enough Nxt to forge.

Most users won't, especially not if the blockchain starts growing. I definitely don't want btc blockchain, for example.  Besides, I was talking about general  users with small amount of Nxt. They have no reason to download full blockchain.
Logged
NXT-GZYP-FMRT-FQ9K-3YQGS

lezin

  • Full Member
  • ***
  • Karma: +12/-2
  • Offline Offline
  • Posts: 116
    • View Profile
Re: NXT client in C/C++ - any chances?
« Reply #5 on: August 12, 2014, 10:32:47 am »

They have no reason to download full blockchain.

There is one, for safety. I think, we will need to shrink the blockchain after some times, there is no need to keep all the transactions. And NXT blockchain will grow very fast if NXT succeed !
Logged

Zahlen

  • Full Member
  • ***
  • Karma: +26/-4
  • Offline Offline
  • Posts: 228
    • View Profile
Re: NXT client in C/C++ - any chances?
« Reply #6 on: November 15, 2014, 10:26:07 pm »

Nxt server is in Java. There is no need for C++ version anyway, as users with less than 100,000 Nxt have no chance to forge and should use lightweight client anyway, especially given most are behind NAT and don't even provide bandwidth support to the network, as nxt server doesn't use UPnP.

Nonetheless forgers should have alternatives that don't depend on Java. I'm a poor shibe lessor, but what worries me most isn't Nothing@Stake or like attempts to game forging, it's Oracle, and compromised hardware.

Hopefully, when Nxt's value grows, there'll be enough economic incentive for an alternative server implementation. Simple one that just forges and sends NXT is enough for starters as a fallback.
Logged

Wolf0

  • Jr. Member
  • **
  • Karma: +7/-0
  • Offline Offline
  • Posts: 97
    • View Profile
Re: NXT client in C/C++ - any chances?
« Reply #7 on: February 04, 2015, 04:17:38 pm »

Nxt server is in Java. There is no need for C++ version anyway, as users with less than 100,000 Nxt have no chance to forge and should use lightweight client anyway, especially given most are behind NAT and don't even provide bandwidth support to the network, as nxt server doesn't use UPnP.

Nonetheless forgers should have alternatives that don't depend on Java. I'm a poor shibe lessor, but what worries me most isn't Nothing@Stake or like attempts to game forging, it's Oracle, and compromised hardware.

Hopefully, when Nxt's value grows, there'll be enough economic incentive for an alternative server implementation. Simple one that just forges and sends NXT is enough for starters as a fallback.

I agree, we need a NXT implementation in a language suitable for this. Java is meh for security - no matter how good your code is, a fuckup in the JVM can allow someone to exploit your app, and when your app handles money, this is bad - and for speed, it's pretty bad, too. Now, before I get a lot of grief for that last comment - Java is not nearly as slow as it used to be, and it's usably fast. But for things that need to be REALLY fast, such as validating a huge blockchain, Java is not the right tool.
Logged

Come-from-Beyond

  • Hero Member
  • *****
  • Karma: +794/-671
  • Offline Offline
  • Posts: 4013
    • View Profile
Re: NXT client in C/C++ - any chances?
« Reply #9 on: February 04, 2015, 06:25:08 pm »

Are there plans to develop a NXT client in a compiled language like C/C++? Or on another language/technology which not requires the end user to install Java?

I think that would be a great advance as many of the criticisms towards Nxt are related to its dependency on Java.

Personally, above all I would appreciate a minimal, lightweight command line client for use on remote machines.

https://www.varycode.com
Logged

Wolf0

  • Jr. Member
  • **
  • Karma: +7/-0
  • Offline Offline
  • Posts: 97
    • View Profile
Re: NXT client in C/C++ - any chances?
« Reply #10 on: February 04, 2015, 06:41:22 pm »

....

sems to me you need some education:


http://www.azulsystems.com/blog/cliff/2009-09-06-java-vs-c-performanceagain


Have a nice day!

"carefully hand-crafted C code, such that the author knows (and plans for) which exact machine instructions will be generated from the C compiler.  This is harder to do in Java because the translation layer is much more indirect" -- this here was my point, for best performance, you need to go low-level.
Logged

Come-from-Beyond

  • Hero Member
  • *****
  • Karma: +794/-671
  • Offline Offline
  • Posts: 4013
    • View Profile
Re: NXT client in C/C++ - any chances?
« Reply #11 on: February 04, 2015, 07:47:02 pm »

"carefully hand-crafted C code, such that the author knows (and plans for) which exact machine instructions will be generated from the C compiler.  This is harder to do in Java because the translation layer is much more indirect" -- this here was my point, for best performance, you need to go low-level.

http://en.wikipedia.org/wiki/Just-in-time_compilation
Logged

Wolf0

  • Jr. Member
  • **
  • Karma: +7/-0
  • Offline Offline
  • Posts: 97
    • View Profile
Re: NXT client in C/C++ - any chances?
« Reply #12 on: February 04, 2015, 07:54:47 pm »

"carefully hand-crafted C code, such that the author knows (and plans for) which exact machine instructions will be generated from the C compiler.  This is harder to do in Java because the translation layer is much more indirect" -- this here was my point, for best performance, you need to go low-level.

http://en.wikipedia.org/wiki/Just-in-time_compilation

Did you bother reading my post? JIT is done by a machine - the author isn't able to do many optimizations if they cannot actually interact with the native code.
Logged

Come-from-Beyond

  • Hero Member
  • *****
  • Karma: +794/-671
  • Offline Offline
  • Posts: 4013
    • View Profile
Re: NXT client in C/C++ - any chances?
« Reply #13 on: February 04, 2015, 07:58:23 pm »

Did you bother reading my post? JIT is done by a machine - the author isn't able to do many optimizations if they cannot actually interact with the native code.

A compiler does better optimizations than a human.
Logged

Wolf0

  • Jr. Member
  • **
  • Karma: +7/-0
  • Offline Offline
  • Posts: 97
    • View Profile
Re: NXT client in C/C++ - any chances?
« Reply #14 on: February 04, 2015, 08:04:03 pm »

Did you bother reading my post? JIT is done by a machine - the author isn't able to do many optimizations if they cannot actually interact with the native code.

A compiler does better optimizations than a human.

You haven't met very good programmers. That's ridiculous.

EDIT: Come to think of it, I was just thinking on the assembly level. If you think about the optimizations you can make to C code that help the compiler greatly, that statement sounds even more insane.
Logged

Come-from-Beyond

  • Hero Member
  • *****
  • Karma: +794/-671
  • Offline Offline
  • Posts: 4013
    • View Profile
Re: NXT client in C/C++ - any chances?
« Reply #15 on: February 04, 2015, 08:13:18 pm »

You haven't met very good programmers. That's ridiculous.

My Litecoin miner was faster than famous pooler's miner (the fastest of available CPU miners). I used all known tricks including loop unrolling, instruction prefetching, instruction reordering, data decoupling. I took into account instruction latency and throughput and even forced usage of multiple pipelines by using instruction from different groups.
Another guy just played with Intel C Compiler settings. And his executable code worked ~10% faster.

It's not ridiculous now, compilers do generate faster code than humans because take into account all the nuances of all families of the processors.

EDIT: His code was written in C, my code was written in Assembler.
Logged

Wolf0

  • Jr. Member
  • **
  • Karma: +7/-0
  • Offline Offline
  • Posts: 97
    • View Profile
Re: NXT client in C/C++ - any chances?
« Reply #16 on: February 04, 2015, 08:24:35 pm »

You haven't met very good programmers. That's ridiculous.

My Litecoin miner was faster than famous pooler's miner (the fastest of available CPU miners). I used all known tricks including loop unrolling, instruction prefetching, instruction reordering, data decoupling. I took into account instruction latency and throughput and even forced usage of multiple pipelines by using instruction from different groups.
Another guy just played with Intel C Compiler settings. And his executable code worked ~10% faster.

It's not ridiculous now, compilers do generate faster code than humans because take into account all the nuances of all families of the processors.

EDIT: His code was written in C, my code was written in Assembler.

It will be faster than MOST humans, but never always faster. Additionally - there are always optimizations the compiler can't figure out, because it doesn't know that certain code isn't necessary.

Take, for example, the TMTO I used on Pebblecoin's first PoW. Compiler couldn't figure that one out.
Logged

Come-from-Beyond

  • Hero Member
  • *****
  • Karma: +794/-671
  • Offline Offline
  • Posts: 4013
    • View Profile
Re: NXT client in C/C++ - any chances?
« Reply #17 on: February 04, 2015, 08:28:56 pm »

It will be faster than MOST humans, but never always faster. Additionally - there are always optimizations the compiler can't figure out, because it doesn't know that certain code isn't necessary.

Take, for example, the TMTO I used on Pebblecoin's first PoW. Compiler couldn't figure that one out.

I assumed that algorithmic optimizations were already done.
Logged

Wolf0

  • Jr. Member
  • **
  • Karma: +7/-0
  • Offline Offline
  • Posts: 97
    • View Profile
Re: NXT client in C/C++ - any chances?
« Reply #18 on: February 04, 2015, 08:32:24 pm »

It will be faster than MOST humans, but never always faster. Additionally - there are always optimizations the compiler can't figure out, because it doesn't know that certain code isn't necessary.

Take, for example, the TMTO I used on Pebblecoin's first PoW. Compiler couldn't figure that one out.

I assumed that algorithmic optimizations were already done.

And this is why humans will always be better than compilers. Humans write compilers - even on a low-level basis, certain things may be rearranged, for example, to take advantage of the CPU cache better. It's very possible the compiler misses things. Also, my argument about the security hasn't been addressed.
Logged

Come-from-Beyond

  • Hero Member
  • *****
  • Karma: +794/-671
  • Offline Offline
  • Posts: 4013
    • View Profile
Re: NXT client in C/C++ - any chances?
« Reply #19 on: February 04, 2015, 08:51:57 pm »

Also, my argument about the security hasn't been addressed.

Majority of financial software is run on JVM. Bad security is a myth that was busted a decade ago. Or all these bankers are stupid.
Logged

Wolf0

  • Jr. Member
  • **
  • Karma: +7/-0
  • Offline Offline
  • Posts: 97
    • View Profile
Re: NXT client in C/C++ - any chances?
« Reply #20 on: February 04, 2015, 09:00:48 pm »

Also, my argument about the security hasn't been addressed.

Majority of financial software is run on JVM. Bad security is a myth that was busted a decade ago. Or all these bankers are stupid.

Does it? Any sources? Because while I don't think the JVM is necessarily bad, I think it's an extra layer of complexity for exploitable bugs to hide in.
Logged

Come-from-Beyond

  • Hero Member
  • *****
  • Karma: +794/-671
  • Offline Offline
  • Posts: 4013
    • View Profile
Re: NXT client in C/C++ - any chances?
« Reply #21 on: February 04, 2015, 09:04:58 pm »

Does it? Any sources? Because while I don't think the JVM is necessarily bad, I think it's an extra layer of complexity for exploitable bugs to hide in.

Some exploits (e.g. stack buffer overflow) are not even possible.

http://news.efinancialcareers.com/uk-en/137065/the-six-hottest-programming-languages-to-know-in-banking-technology/:

Quote
Java ranks first due to the volume of jobs on offer rather than the scarcity of the skill-set. Java remains core to the vast majority of investment banking technology projects, from low latency trading systems to market data pricing systems and order booking management platforms, says Paul Elworthy, senior manager at recruiters Ikas International.
Logged

Wolf0

  • Jr. Member
  • **
  • Karma: +7/-0
  • Offline Offline
  • Posts: 97
    • View Profile
Re: NXT client in C/C++ - any chances?
« Reply #22 on: February 04, 2015, 09:15:45 pm »

Does it? Any sources? Because while I don't think the JVM is necessarily bad, I think it's an extra layer of complexity for exploitable bugs to hide in.

Some exploits (e.g. stack buffer overflow) are not even possible.

http://news.efinancialcareers.com/uk-en/137065/the-six-hottest-programming-languages-to-know-in-banking-technology/:

Quote
Java ranks first due to the volume of jobs on offer rather than the scarcity of the skill-set. Java remains core to the vast majority of investment banking technology projects, from low latency trading systems to market data pricing systems and order booking management platforms, says Paul Elworthy, senior manager at recruiters Ikas International.

Interesting - I see. Still seems overcomplex, but I suppose mitigating common exploits makes it useful enough to security.
Logged

Riker

  • Core Dev
  • Hero Member
  • *****
  • Karma: +439/-42
  • Offline Offline
  • Posts: 1795
    • View Profile
Re: NXT client in C/C++ - any chances?
« Reply #23 on: February 04, 2015, 09:19:50 pm »

Interesting comparison between Java and C security http://java.dzone.com/articles/java-riskier-cc
Logged
NXT Core Dev
Account: NXT-HBFW-X8TE-WXPW-DZFAG
Public Key: D8311651 Key fingerprint: 0560 443B 035C EE08 0EC0  D2DD 275E 94A7 D831 1651

Eadeqa

  • Hero Member
  • *****
  • Karma: +83/-68
  • Offline Offline
  • Posts: 1888
    • View Profile
Re: NXT client in C/C++ - any chances?
« Reply #24 on: February 05, 2015, 08:01:00 pm »

You haven't met very good programmers. That's ridiculous.

My Litecoin miner was faster than famous pooler's miner (the fastest of available CPU miners). I used all known tricks including loop unrolling, instruction prefetching, instruction reordering, data decoupling. I took into account instruction latency and throughput and even forced usage of multiple pipelines by using instruction from different groups.
Another guy just played with Intel C Compiler settings. And his executable code worked ~10% faster.

It's not ridiculous now, compilers do generate faster code than humans because take into account all the nuances of all families of the processors.

EDIT: His code was written in C, my code was written in Assembler.

It will be faster than MOST humans, but never always faster. Additionally - there are always optimizations the compiler can't figure out, because it doesn't know that certain code isn't necessary.

Take, for example, the TMTO I used on Pebblecoin's first PoW. Compiler couldn't figure that one out.

Speed is not everything. It's much easier to write secure software in Java than it's in C, C++ and Assembly (No pointers to arbitrarily access memory, no buffer overruns, bound checking,).  Plus Java is platform independent, which makes it even safer.  You don't have to worry about compiling for Linux, Mac, and Windows versions separably.
That would be pain in the ass.  The java security related problems you mentioned are mostly applet related, which is a browser plugin. Nxt is not an applet. It's a standalone application.

99%  of banks, ebay, Amazon and GMail are running Java on server side. If it's so easy to hack a server running Java, try hacking Amazon. Start up speed is not relevant in server application as it starts only once and keeps running for weeks. Don't confuse client side application with server side applications. Nxt core is server side application. Nxt client is written in Javascript (not Java) and anyone is free to write a client in C.

« Last Edit: February 05, 2015, 08:06:16 pm by Eadeqa »
Logged
NXT-GZYP-FMRT-FQ9K-3YQGS

Eadeqa

  • Hero Member
  • *****
  • Karma: +83/-68
  • Offline Offline
  • Posts: 1888
    • View Profile
Re: NXT client in C/C++ - any chances?
« Reply #25 on: February 05, 2015, 08:27:22 pm »

Also, my argument about the security hasn't been addressed.

Majority of financial software is run on JVM. Bad security is a myth that was busted a decade ago. Or all these bankers are stupid.

Does it? Any sources? Because while I don't think the JVM is necessarily bad, I think it's an extra layer of complexity for exploitable bugs to hide in.

Really you shouldn't be posting nonsense about things you know nothing about. A VM adds extra layer of security to software (i.e. array bounds checking, buffer overflows, incorrect memory branching -- all these things can be exploited in bad C++ software)

Yes, there have been bugs and security flaws in Java's security manager and sanboxing, but as I said they are mostly related to browser plugin where you run  untrusted bytecode  in a browser.

Nxt is a standalone application, and you download it and run it (as you trust Nxt developers). It's not  untrusted bytecode  on a random website you ran in your browser while you were surfing porn. See the difference? The second one is dangerous as there could be bugs in Java sandboxing and security manager (as has been shown many times by hackers),  The first is trusted software that you downloaded from a source you trust.





« Last Edit: February 05, 2015, 08:30:09 pm by Eadeqa »
Logged
NXT-GZYP-FMRT-FQ9K-3YQGS

DesertWind

  • Full Member
  • ***
  • Karma: +70/-16
  • Offline Offline
  • Posts: 172
    • View Profile
Re: NXT client in C/C++ - any chances?
« Reply #26 on: February 06, 2015, 04:14:12 pm »

Also, my argument about the security hasn't been addressed.

Majority of financial software is run on JVM. Bad security is a myth that was busted a decade ago. Or all these bankers are stupid.

The closest thing I run to Nxt... is the Interactive Brokers TWS trading platform...
Which has a Java code base roughly 10 times larger... and more complex and real-time.

It's suitable for 100,000 serious and Pro traders who trade stocks, options, futures, and forex...
Who can live with the 100 ms ping latency... otherwise speed is not an issue.

Using C/C++ for crypto with 60,000 ms latency is pointless... and dead ends you to a small group of elite C devs.

As for security, no amount of cryptological elegance can compete with hardware security devices...
Like this one that is MANDATORY for my Interactive Brokers account.

https://www.interactivebrokers.com/en/?f=%2Fen%2Fgeneral%2FgoldHelp.php%3Fib_entity%3Dllc

Hey, those 100,000 IB traders is the REAL target market for Nxt... not picking off random cryptogeeks.  :)
Logged

Brangdon

  • Hero Member
  • *****
  • Karma: +229/-25
  • Offline Offline
  • Posts: 1389
  • Quality is addictive.
    • View Profile
Re: NXT client in C/C++ - any chances?
« Reply #27 on: February 06, 2015, 09:45:41 pm »

Speed is not everything. It's much easier to write secure software in Java than it's in C, C++ and Assembly (No pointers to arbitrarily access memory, no buffer overruns, bound checking,).
I'd say it's easier to write to a mediocre level with Java, but harder to write to a high level, compared to C++. And by C++ I mean a modern version, C++11 or later. You would not be using raw pointers or other dangerous idioms, and you would use libraries that checked for buffer overruns, bounds etc.

If I didn't have a full-time job, I'd seriously consider writing a C++ version of Nxt. As I think has already been mentioned, the main problem would be keeping it up to date. Once the NRS version has had a hard fork, the C++ would be unusable until it updated. At the moment we're having hard forks roughly every other month, and it would be a major commitment to track that. I don't think it is worth it now, and won't be until Nxt settles down and becomes stable. Which will probably take another year or two at least.
Logged

Wolf0

  • Jr. Member
  • **
  • Karma: +7/-0
  • Offline Offline
  • Posts: 97
    • View Profile
Re: NXT client in C/C++ - any chances?
« Reply #28 on: February 07, 2015, 06:48:45 pm »

Also, my argument about the security hasn't been addressed.

Majority of financial software is run on JVM. Bad security is a myth that was busted a decade ago. Or all these bankers are stupid.

Does it? Any sources? Because while I don't think the JVM is necessarily bad, I think it's an extra layer of complexity for exploitable bugs to hide in.

Really you shouldn't be posting nonsense about things you know nothing about. A VM adds extra layer of security to software (i.e. array bounds checking, buffer overflows, incorrect memory branching -- all these things can be exploited in bad C++ software)

Yes, there have been bugs and security flaws in Java's security manager and sanboxing, but as I said they are mostly related to browser plugin where you run  untrusted bytecode  in a browser.

Nxt is a standalone application, and you download it and run it (as you trust Nxt developers). It's not  untrusted bytecode  on a random website you ran in your browser while you were surfing porn. See the difference? The second one is dangerous as there could be bugs in Java sandboxing and security manager (as has been shown many times by hackers),  The first is trusted software that you downloaded from a source you trust.

I may not know much about Java, but I know plenty about security in coding in general. I am a C/C++/x86 ASM coder, and yeah, you can introduce bugs - does that mean we need to add training wheels for devs?
Logged

Eadeqa

  • Hero Member
  • *****
  • Karma: +83/-68
  • Offline Offline
  • Posts: 1888
    • View Profile
Re: NXT client in C/C++ - any chances?
« Reply #29 on: February 07, 2015, 07:43:28 pm »

I may not know much about Java, but I know plenty about security in coding in general. I am a C/C++/x86 ASM coder, and yeah, you can introduce bugs - does that mean we need to add training wheels for devs?

I wouldn't call it "training wheel." JVM provides security checks. Nxt development speed would have been a lot slower with C.  Plus being cross platform JL only compiles one version,  instead of three  separate versions ( windows, mac, Linux).   

Having said that, crypto is just set of protocols and standards, so it's perfectly possible to write your nxt server in C (or any language for that matter) and it will still work.
Logged
NXT-GZYP-FMRT-FQ9K-3YQGS

Wolf0

  • Jr. Member
  • **
  • Karma: +7/-0
  • Offline Offline
  • Posts: 97
    • View Profile
Re: NXT client in C/C++ - any chances?
« Reply #30 on: February 07, 2015, 08:14:41 pm »

I may not know much about Java, but I know plenty about security in coding in general. I am a C/C++/x86 ASM coder, and yeah, you can introduce bugs - does that mean we need to add training wheels for devs?

I wouldn't call it "training wheel." JVM provides security checks. Nxt development speed would have been a lot slower with C.  Plus being cross platform JL only compiles one version,  instead of three  separate versions ( windows, mac, Linux).   

Having said that, crypto is just set of protocols and standards, so it's perfectly possible to write your nxt server in C (or any language for that matter) and it will still work.

Very true, but one thing really irks me about Java, ESPECIALLY when coding any kind of crypto: What idiot decided ALL numbers should be signed?
Logged

Come-from-Beyond

  • Hero Member
  • *****
  • Karma: +794/-671
  • Offline Offline
  • Posts: 4013
    • View Profile
Re: NXT client in C/C++ - any chances?
« Reply #31 on: February 07, 2015, 08:31:26 pm »

What idiot decided ALL numbers should be signed?

Whoever it was, that was a smart choice.
Logged

Wolf0

  • Jr. Member
  • **
  • Karma: +7/-0
  • Offline Offline
  • Posts: 97
    • View Profile
Re: NXT client in C/C++ - any chances?
« Reply #32 on: February 07, 2015, 08:37:03 pm »

What idiot decided ALL numbers should be signed?

Whoever it was, that was a smart choice.

Explain. I can see no scenario where restricting the programmer from using all bits in a datatype the way they want/need to being a good idea.
Logged

Come-from-Beyond

  • Hero Member
  • *****
  • Karma: +794/-671
  • Offline Offline
  • Posts: 4013
    • View Profile
Re: NXT client in C/C++ - any chances?
« Reply #33 on: February 07, 2015, 09:13:55 pm »

Explain. I can see no scenario where restricting the programmer from using all bits in a datatype the way they want/need to being a good idea.

It reduces number of possible bugs.
Logged

Wolf0

  • Jr. Member
  • **
  • Karma: +7/-0
  • Offline Offline
  • Posts: 97
    • View Profile
Re: NXT client in C/C++ - any chances?
« Reply #34 on: February 07, 2015, 09:18:56 pm »

Explain. I can see no scenario where restricting the programmer from using all bits in a datatype the way they want/need to being a good idea.

It reduces number of possible bugs.

You're joking. You realize it also causes ridiculous code, because full unsigned longs can't be used? Such as the implementation of the Java minter - it has some weird stuff in it to work around this crippling "feature."

How on earth does it even reduce the number of possible bugs? It'd be better to make all numbers unsigned, and let the programmer deal with it (also a shit idea!) rather than effectively cut off a bit from the datatypes.
Logged

Come-from-Beyond

  • Hero Member
  • *****
  • Karma: +794/-671
  • Offline Offline
  • Posts: 4013
    • View Profile
Re: NXT client in C/C++ - any chances?
« Reply #35 on: February 07, 2015, 10:36:15 pm »

You're joking. You realize it also causes ridiculous code, because full unsigned longs can't be used? Such as the implementation of the Java minter - it has some weird stuff in it to work around this crippling "feature."

How on earth does it even reduce the number of possible bugs? It'd be better to make all numbers unsigned, and let the programmer deal with it (also a shit idea!) rather than effectively cut off a bit from the datatypes.

I'm talking about bugs caused by signed/unsigned mismatch. If you want to add 1 billion to 2 billion and get 3 billion you indeed need a work-around. But at least you always know that all numbers are signed.
Logged

Wolf0

  • Jr. Member
  • **
  • Karma: +7/-0
  • Offline Offline
  • Posts: 97
    • View Profile
Re: NXT client in C/C++ - any chances?
« Reply #36 on: February 07, 2015, 10:41:00 pm »

You're joking. You realize it also causes ridiculous code, because full unsigned longs can't be used? Such as the implementation of the Java minter - it has some weird stuff in it to work around this crippling "feature."

How on earth does it even reduce the number of possible bugs? It'd be better to make all numbers unsigned, and let the programmer deal with it (also a shit idea!) rather than effectively cut off a bit from the datatypes.

I'm talking about bugs caused by signed/unsigned mismatch. If you want to add 1 billion to 2 billion and get 3 billion you indeed need a work-around. But at least you always know that all numbers are signed.

That's not the only use of unsigned variables - you need unsigned variables when doing crypto, because they aren't treated as numbers, they're treated as raw data.
Logged

Come-from-Beyond

  • Hero Member
  • *****
  • Karma: +794/-671
  • Offline Offline
  • Posts: 4013
    • View Profile
Re: NXT client in C/C++ - any chances?
« Reply #37 on: February 07, 2015, 10:49:06 pm »

That's not the only use of unsigned variables - you need unsigned variables when doing crypto, because they aren't treated as numbers, they're treated as raw data.

Majority of cryptoalgos is sign agnostic.
Logged

Wolf0

  • Jr. Member
  • **
  • Karma: +7/-0
  • Offline Offline
  • Posts: 97
    • View Profile
Re: NXT client in C/C++ - any chances?
« Reply #38 on: February 07, 2015, 10:59:14 pm »

That's not the only use of unsigned variables - you need unsigned variables when doing crypto, because they aren't treated as numbers, they're treated as raw data.

Majority of cryptoalgos is sign agnostic.

Depends on how the operations are treated - I know there's a >>> operator for shifting, but what about the rest of the operations? Do they ignore the sign bit?
Logged

Come-from-Beyond

  • Hero Member
  • *****
  • Karma: +794/-671
  • Offline Offline
  • Posts: 4013
    • View Profile
Re: NXT client in C/C++ - any chances?
« Reply #39 on: February 08, 2015, 08:49:20 am »

Depends on how the operations are treated - I know there's a >>> operator for shifting, but what about the rest of the operations? Do they ignore the sign bit?

Other bit operations do.
Logged

Wolf0

  • Jr. Member
  • **
  • Karma: +7/-0
  • Offline Offline
  • Posts: 97
    • View Profile
Re: NXT client in C/C++ - any chances?
« Reply #40 on: February 08, 2015, 10:03:04 am »

Depends on how the operations are treated - I know there's a >>> operator for shifting, but what about the rest of the operations? Do they ignore the sign bit?

Other bit operations do.

Well, that's good - addition is still an issue (used in several algos), but at least the bit operations work as expected.
Logged
Pages: 1 2 3 [All]
 

elective-stereophonic
elective-stereophonic
assembly
assembly