As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
let's say that we ignore the target and source hardware for a moment. So, what's the better endian style to go with -- big or small?
I'm just trying to go with consensus / convention on this one. The best guidance I've received so far is "it depends" so always specify. That's fine. I'll do that.
However, in this situation there is no need to be one way or the other. There's no legacy, so I thought, "what would be the cleanest choice for current & emerging hardware."
Use whatever is predominant in your hardware. Or use "network byte order" (big endian) because the internet does. Or pick one at random. It's unimportant.
Don't choose. Just use whatever your compiler/platform uses. That gives no hassle and just works.
If you are doing raw network stuff, you may want to convert things to/from network endianness though, which is big endian. But don't mess up your whole code because of that. Just do the conversion when you get to the network writing part.
Actually the answer is it depends
If you just want a choice then Since in Big Endian high order byte comes first ,you can always check positive or negative from the first byte.
It doesn't matter. Just pick one.
This is a topic of endless debate. One does not hold a particular advantage over the other.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
A few months ago, we started developing an app to control an in-house developed test equipment and record a set of measurements. It should have a simple UI, and would likely require threads due to the continuous recording that must take place. This application will be used for a few years, and shall be maintained by a number of computer science students during this period.
Our boss graduated some 30 years ago (not to be taken as an offense; I have more than half that time on my back too) and has mandated that we develop this application in ANSI C. The rationale is that he is the only one that will be around the entire time, and therefore he must be able to understand what we are doing. He also ruled that we should use no abstract data types; he even gave us a list with the name of the global variables (sigh) he wants us to use.
I actually tried that approach for a while, but it was really slowing me down to make sure that all pointer operations were safe and all strings had the correct size. Additionally, the number of lines of code that actually related to the problem in hand was a only small fraction of our code base. After a few days, I scrapped the entire thing and started anew using C#. Our boss has already seen the program running and he likes the way it works, but he doesn't know that it's written in another language.
Next week the two of us will meet to go over the source code, so that he "will know how to maintain it". I am sort of scared, and I would like to hear from you guys what arguments I could use to support my decision.
Honestly it could blow up in your face, but if your boss isn't a complete twit he will see how much more productive you've been and be able to move forward. C# does use a different paradigm from ANSI C, with the OOP and all, but the syntax is similar enough he should be able to figure it out. If not leave lots of good comments in the code, and maybe be nice enough to produce some actual technical documentation he can read through.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Trying to decide between Dapper, Massive and PetaPoco. I do like simplicity of Dapper, flexibility of Massive and POCO support in PetaPoco but am currently procrastinating about which one to choose for my next project.
I do realise that, to a large extent, it's the matter of personal taste, but believe it will be valuable to hear some opinions on the subject, especially from people who tried more than one of these, err, libraries (what is the right term: library, file, framework?)
Try to decide which of the features you mention -- simplicity, flexibility, POCO support -- will be most useful to you and your project(s) one year from now. Which is most likely to make your work easier?
Then you'll have your answer. And if you still can't choose, pick Dapper (just a random selection I made :-) As the Cheshire Cat says, if you don't really know where you want to go, it doesn't matter which road you choose.
PetaPoco's documentation seems more mature than others. It seems like it is the safest route.
i havent triend any of those. by default i always base my decision on number of lines of resulting client code and type safety. of course there are number of other metrics you should take into account but if your project is not constrained by any special (exotic) requirements those two are generally appliable.
btw. i am aware about controversy my response may lead to ;)
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
We are about to implement a small automated securities trader. The trader will be build on top of the excellent quickfix FIX engine.
After due though, we narrowed our options down to implementing it in C# or in Python. Please specify the pros and cons of each language for this task, in term of:
Performance (The fact that Python uses a GIL troubles me in terms of thread concurrency)
Productivity
Scalability (We may need to scale this trader to a fully-sized platform)
EDIT
I've rephrased the question to make it less "C# vs. Python" (which I find irrelevant - both languages have their merits), but I'm simply trying to draw a comparison table before I make the decision.
I like both languages and a think both would be a good choice. The GIL might really be the most important difference. But I'm not sure if it's a problem in your case. The GIL only affects code running in pure Python. I assume that your tool depends more on I/O than on raw number crunching. If your I/O libraries handle the GIL correctly, they can execute concurrent code without problems. And even for number crunching you still have numpy.
My choice would depend on your existing knowledge. If you have experienced C# developers at hand I would go for C#. If you start absolutly from scratch and it's really 50:50, then I would go for Python. It's easier to learn, free and in many cases more productive.
And just to mention it: You might also have a look at IronPython. ;-)
For points "Performance" and "Scalability" I would suggest C# (although a large part of performance depends on your algorithms). Productivity is much of a subjective thing, but now C# has all cool features like lambda, anonymous method, classes etc which makes it much more productive.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
use net remoting or others ??
I want sample way, I think that no socket or other would be more easy to deploy ...
anyway ,help please , thanks.
You will want to begin with Namedpipes.
Since you are dealing with C#, have a look at:
http://msdn.microsoft.com/en-us/library/aa365590(v=vs.85).aspx
Essentially, this got me going instantly when I was looking into it:
http://msdn.microsoft.com/en-us/library/bb546085.aspx#Y1920
Good luck.
It depends on what you want to do. If you just want to send notifications between two processes running on the same computer, named events work just fine. If you want to send long messages, then there are named pipes, sockets, and WCF (which replaces .NET Remoting). You might also want to share memory with memory mapped files. There are several other possibilities.
The method you use depends in large part on how much data you want to communicate, how fast you need it to be, and how much time you want to spend futzing with it.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
i need to write an web crawler and i need need which is best language for performance like memory and performance ..
Edit: Original title was "which language is optimized for speed and perfomance c++ or C#"
i need to write an web crawler
In that case, the internet traffic is probably your bottleneck, so the language does not matter at all.
I'd say that, if you know what you're doing, C++ is more likely to be efficient than C#.
On the flip side, C# is probably easier to work with and to optimize your app in.
So, since you have to ask, I recommend C# in your case. ;)
C++ virtually always offers the best performance of any language that supports modern programming techniques like generic programming and OOP. You pay a price for this though - it's substantially harder to use than C#.
Of course C++. You can manage every byte of memory there, while C# is Managed Code, where you tell the framework what you want to do and the framework does the things you usually do in C++. But if that's the main motive - don't stop at C++ and get right to machine code, Assembly.
A Google search would give you an instant answer - C++ is (generally) a better performing language.