Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
What is the current state of serialisation-to-binary in Rust?
I have some large (1-10MB) data structure to be sent across a network, and don't want to encode them as JSON or hex (the two serialisers I have found).
I have found #[repr(packed)]. Is this what I should use, or is there something more portable?
#[repr(packed)] only makes your data small. It does not offer any format guarantees or serialization help.
You have a few choices here (ordered by my opinion from best to worst solution):
You can use the Cap'n proto implementation for Rust
https://github.com/dwrensha/capnproto-rust
It's not really serialization, more of a forced format for structs that are then sent over the network without any conversion
fast
You could write your own Serializer and Deserializer.
you have full control over the format
runtime overhead for every single datum
you need to implement lots of stuff
You can transmute your structs to a [u8] and send that
probably the fastest solution
you need to make sure that the compiler for the program on both sides is exactly the same, otherwise the formats don't match up.
Someone evil may send you bad data. When you transmute that back, you get buffer overflows and stuff
references in your data-structure will cause wild pointers and undefined behaviour
Don't use references
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I'm almost new to programming and I came to this question that:
why should object carry code along with data? isn't packing data enough?
For example:
Instead of having 5 employee objects that each has a getDataOfBirth() method (consuming more memory), have a single method in global space and have 5 object with only attributes(smaller objects).
Am I getting something wrong? Is my question even considered general and possible to be occurred in every newbie's mind?
The linguistic aspect of it:
This is an idea that OOP skeptics have been talking about for a long time, but it's more of a matter of preference I would say. If you are new to programming and already are thinking about these things, then maybe functional programming would make a lot of sense to you.
The memory aspect of it:
The functions are typically not stored inside the objects, so OO objects that have a lot of functions do typically not carry those functions around. This is however an implementation detail but most OOP languages should be thought of like that.
Especially in the case of natively compiled languages like C++, the code and the data will be separated into different memory areas altogether and will not really mix. That is also a bit of an implementation detail but all mainstream operating systems, as far as I know, will allocate memory with code separated from data. The functions of a class will be allocated in one area and the data of the objects in another, and normally all objects of the same class will use the same functions.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I am documenting a small itcl project. Due to shortcomings in itcl support in doxygen, and the fact that Ruff! does not support itcl, I am left with NaturalDocs and RoboDoc as the leading candidates. However, I don't want to pick an unsupported system, and was wondering which is going to be there in the long term?
What will be there in the long term? Who knows! It depends on how much people use it, really, as with all open source code systems. It should be noted that both the tools you refer to are really slow developing at this point: they do what they do and need little significant change to keep on doing it.
As far as I can see, ROBODoc requires that you do pretty much all the annotation work yourself, whereas NaturalDocs will derive a bit more for you. Not very much though; in particular, you will have to write plenty of annotations on things whichever route you use. (I've no particular experience with either though; I tend to prefer to maintain documentation in a separate file with something like doctools but that's a very different approach. I've also done nasty custom things in the past; you really don't want to use them.)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I always hear that we need to encapsulate whenever we write object-oriented code. If I'm the only developer on a project, do I still need to use encapsulation?
One way to put an answer: Encapsulation, conceptually, exists for writing better, safer, less error-prone code. It doesn't exist, primarily, to facilitate teams working together on code (that might be a side effect, but that's not the purpose).
So the goods that encapsulation seeks to foster scale from one coder to many coders, and they are goods that do not really have to do with the number of coders, although those goods may find stronger expression the larger the project and teams are.
Encapsulation is there for a reason.
Someone has to maintain and manage your code after you are done, right? What if the project gets bigger and you get team members?
So, the answer is "yes", it is always best to use encapsulation whenever possible.
The fact you are asking this question makes me wonder you actually did not get the actual value of encapsulation as a means to reduce and thus deal with complexity.
My theoretical computer science professor used to tell me that in the end, if you think at the whole binary representation of a program, any program is just a number. Very big indeed but, only a number. And that is true, any other construct we use but 0 and 1 (i.e. C++, Java, Python, functional programming, object oriented programming, aspect oriented programming, etc..) is just because of the fact we need more abstract means to get the one number we need.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
After reading the definition of procedural design (http://en.wikipedia.org/wiki/Design_document) and searching for a few example diagrams, I have been having trouble on finding out more on what procedural design means other than finding this diagram (http://www.kelso.scotborders.sch.uk/departments/computing/resources/mindmaps/Procedural%20program%20design.gif). Typically, when is this type of documentation necessary? Is it when there's a specific algorithm used in the application?
This is most often used when you have a few very similar constructs that are used really often. In a way SQL is a "procedural design" since it limits you to tables and column and a handful of operations which can be applied to the "data model" (= the database).
Code generators thrive in this area since they have a large but simple input and generate a lot of code that would be extremely tedious and error prone to write by hand. In a similar way, you can generate "documentation" for this which is usually a big waste of time since it will be enormous in volume and contain very little information about how the system works.
[EDIT] In computer science the amount of information in a message is the amount of "surprise" you get per bit. So one page of "1'000 feet view" which is tight packed with information, which gives you a compressed introduction how the system is designed and how you can find your way around, is worth more than 1'000 pages of documentation generated from a data model.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Suppose that you are writing or maintaining a piece of code that uses some API that you are not 100% familiar with.
How do you decide whether to read the documentation of a certain call target, and how much time to spend reading it? How do you decide not to read it?
(Let's assume you can read it by opening the HTML documentation, inspecting the source code, or using the hover mechanism in the IDE).
Ideally you should read all of it, but we know that's a pain in the... you know. What I normally do on those cases (and I did that a lot while I worked as a freelancer) is weight some factors and depending on the result, I read the docs.
Factors that tell me I shouldn't read the docs:
What the function does is easy to guess from the name.
It isn't relevant to the code I'm maintaining: for example, you are checking how some code deletes files, and you have some function that obviously does some UI update. You don't care about that for now.
If debugging: the function didn't change the program state in a way meaningful to the task at hand. As before, you don't want to learn what SetOverlayIcon does, if you are debugging the deletion code because it's dying with a file system error.
The API is just a special case of an API you already know and you can guess what the special case is, and what the special arguments (if any) do. For example, let's say you have WriteToFile(string filename) and WriteToFile(string filename, boolean overwrite).
Of course, everything depends on the context, so even those rules have exceptions.