I am trying to port a project from Google Protocol Buffers 3.0.0-beta-2 to 3.1.0. After recompiling my .proto file I noticed that I had a number of compilation errors with the project due to protoc enforcing a coding standard that I did not choose and renaming fields accordingly. I do not want to rename e.g. MDData to Mddata or XYServer to Xyserver inside the project since the intended meanings of the abbreviations are now lost and possibly subject to change in further Protocol Buffer releases to come.
I have seen this behaviour on the C# part so far and am not sure if this is also the case for generated code for C++.
TL;DR:
Is there a way to disable automatic code style changes inside Google Protocol Buffer's Proto Compiler (and keep my own formatting) of fields?
There is no way to enforce this short of writing your own code generator. Only the public API of the stubs is considered stable.
Under the hood, the protoc compiler regenerates the code from scratch each time, so there is no way for it to know the original style of the file. It would need to be passed in the original generated file along with the proto in order to do this.
That said, if you want to modify the code generator, it is certainly possible.
Related
What's a smart way to generate and validate a protocol buffer spec? Is there any library (binding?) for the protoc file format, maybe java or python?
Just to be clear, I know that after my code generates a protocol buffer specification it will be fed to protoc for generating language-specific binding code. It's straightforward for me to invoke protoc to validate a generated spec (just check exit code etc.), but I thought maybe there's a better way.
The only vaguely related thing I could find is Cannot parse a protocol buffers file in python when using the correct .proto file
Thanks in advance.
I would probably just invoke the protoc binary and check the exit code, because that command line interface is likely to be more stable across versions than a library interface.
However, all the relevant functionality is available in libprotoc.so. As a starting point, you can see the protoc main program here, which is beautifully short: https://github.com/google/protobuf/blob/master/src/google/protobuf/compiler/main.cc
I expect you could pretty much copy that to your own project and link against libprotoc.so.
I want to make some changes to the Go crypto/tls standard library.
Is making a copy of crypto/tls in the vendor folder a good way to do this?
It almost works, it seems the vendored is copy used when I compile the application (Caddy webserver). Apart from one error I get:
go/src/github.com/user/caddy/caddytls/httphandler.go:40: cannot use "vendor/crypto/tls".Config literal (type *"vendor/crypto/tls".Config) as type *"crypto/tls".Config in field value
Is there a way of casting to get around this one error? Doesn't sound like good practice to me though.
I would have thought that the vendored copy would always be used, but it seems something is still using the standard crypto/tls library? (I think "net/http" is. Do I have to vendor this too?)
I actually had to do that. The most practical way is to copy and modify the package (as well as its internal dependencies) - this includes some import paths. And it is not really vendored (vendoring is basically using unmodified packages, otherwise vendoring tools will not work), it is a fork, under a different name. I would guess that caddy does not need the modified version - if it does, you need to fork and modify caddy as well.
It goes without saying, but be extremely careful when modifying crypto/tls package - I for example has to make a minimal change that does not really modify TLS operation (I needed to be able to derive key material from the session master secret and randoms).
Also, you have to fully realize that this has significant cost - when a new version of go is out, one that potentially has updates for the crypto/tls package or its dependencies, you will have to apply your changes once again, manually. Committing a diff between the vanilla version and your version helps. I don't think this is at all practical for non-trivial changes (mine were quite limited - a new public field in Config, few lines of code in handshakes, a new interface).
I need the same functionality. It seems like the crypto/tls package does not allow the reading of custom TLS extensions added from the client side in the ClientHello payload. It would be great to be able to check for any custom extensions and then marshal them out accordingly.
It is a pity that this is not a separate package as we could then in our go.mod file be able to use replace to specify a custom TLS package.
e.g
replace golang.org/x/crypto/tls => ./tls
Then running go mod vendor.
Where the ./tls is my local version with the changes applied.
Are there official rules/guidelines for including boost headers? I'm wondering as up until recently I almost always used the format #include <boost/library.hpp>. Then I came across Boost.Timer, whose documentation states that there are 2 versions of the library, a deprecated and a new one.
The deprecated version resides in <boost/timer.hpp> whereas the new one resides in <boost/timer/timer.hpp>. The two version seemingly exist without any interaction...
So I thought: "well obviously one should prefer the 'internal' headers". So I looked at some of my more regularly used headers and noticed that for example <boost/format.hpp> simply includes the headers of boost/format plus several external dependencies. So including the specific headers doesn't seem like the best idea.
So I thought: "well maybe that's a transitional artifact and they're working towards the boost/library/header'scheme".
The I noticed the new Boost.Atomics library - only just recently added - and was stunned: there's a header boost/atomics.hpp and a folder with headers of the same name.
Now I'm somewhat confused: Is there an official guideline on which headers are to be considered public (similar to the standard headers) and where the internal aspects of the api starts? Or is it completely up to the library to decide the structure of it's headers?
As far as I know, the Boost Library Requirements and Guidelines does not define the scoping and separation of header files. The Boost Header Policy defines guidelines to allow headers to co-exist with other headers. Nevertheless, many of the libraries provide a distinction by:
Providing separate files for logical divisions of types/functionality users may want.
Placing header files internal to the library within a detail directory.
Declaring internal types, functions, etc. in a detail namespace.
Some even make another level of distinction by separating a function declaration from its definition within header files by placing the definition in an impl directory.
It is suppose to be safe to include the highest-level header file. Additionally, it should generally be safe to include more specific files. For example:
If I want boost::thread, boost::mutex, and boost::lock, or do not mind the additional includes, then I may include boost/thread.hpp.
If I only want boost::thread, then I would include boost/thread/thread_only.hpp. I would not directly include boost/thread/detail/thread.hpp.
In Java when you compile a .java file which defines a class, it creates a .class file. If you provide these class files to your coworkers then they cannot modify your source. You can also bundle all of these class files into a jar file to package it up more neatly and distribute it as a single library.
Does Ruby have any features like these when you want to share your functionality with your coworkers but you don't want them to be able to modify the source (unless they ask you for the actual .rb source file and tell you that they want to change it)?
I believe the feature you are looking for is called "trust" (and a source code control repository). Ruby isn't compiled in the same way that Java is, so no you can't do this.
I have to say your are in a rough position, not wanting to share code with a coworker. However, given that this is an unassailable constraint perhaps you could change the nature of the problem.
If you have a coworker that needs access to some service provided by a library of yours, perhaps you could expose it by providing a web/rest service instead of as a .rb file.
This way you can hide your code behind a web server, and if there is a network architecture that allows for low latency making these service calls, you can effectively achive the same goal.
Trust is a lot easier though.
edit:
Just saw this on HN: http://blog.astrails.com/2009/5/12/ruby-http-require, allows a ruby file to include another file through http instead of the filesystem.
Ruby is
A dynamic, interpreted, open source programming language with a focus on simplicity and productivity.
So like all interpreted languages, you need to give the source code to anyone who want's to execute your program/script.
By the way searching "compiled ruby" on google returned quiet a few results.
I don't think there is one. Ruby is purely an interpreted language, which means ruby interprets your source code directly in order to run it. Java is compiled, so there's an intermediate bytecode (the .class). You can obfuscate your ruby if you really wish, but it's probably more trouble than it's worth.
Just to make sure you realize, however, upwards of 95% of Java can be decompiled back into source using various free utilities, so in reality, Java's compilation isn't much better than distributing Ruby source.
This is not a language specific problem and one that can be managed more effectively through source control software.
There is a library called ruby2c that compiles a subset of Ruby into C code (which you can then compile into native code, if you want).
It was actually originally written as a Ruby code obfuscator (but has since been used for lots of other stuff, including Ruby Arduino development).
Visual Studio seems to want to put class contructor code and event handling code in the .h file. I have only been involved in small 1 man projects and was wondering what the general industry standard was.
For Visual C++ Application projects what code would one put in the .h file? I am used to the mode classical C++ way of declaring your class in the .h file and coding in the .cpp file. Does this still apply to Visual Studio applications?
I have a strong C background which would explain my preference for this. The VSC++ compiler doesn't seem to mind.
In short: What is one supposed to put in which type of file?
TIA
Ends
There is no widely accepted industry standard. By putting (short) function definitions in the header, you give the compiler a better chance to inline the code. The benefit is that it can make the code run faster (keep those functions short, though). However, this comes at the cost of exposing more code to the clients who include that header, making you (or your colleagues) recompile more files when you change the implementation.
You also have to take into account the cost of going against your tools. Since VC++'s wizards insist on putting the functions in the headers, you have to move them everytime if you disagree.
It's really project-specific, I would say.
If you're using MFC and you're talking about the generated code, it's best to leave it alone.
If you're trying to do 'normal' C++ development, put as little as you can get away with in the header, as it means client code doesn't depend on too many implementation details. What you can get away with depends a little on use of templates, and how much indirection your performance budget can support.
For Visual C++ Application projects
what code would one put in the .h
file? I am used to the mode classical
C++ way of declaring your class in the
.h file and coding in the .cpp file.
Does this still apply to Visual Studio
applications?
Short: Yes
Long: Depends on the person or language. In c++ the header is for declaring and cpp for the coding. For C# you have one file (or if you use interfaces, 2)
This might seem minor, but just remember: headers are #included in several places. (And headers including headers complicates things further.) Any time you change a header, a lot of files are gonna be compiled again. Keeping as little of frequently changing code in the header reduces recompilation of dependant files.
Another thing: an uncluttered header file gives you a quick overview of what a class/form has to offer.