From my understanding reading this thread from several years ago, somebody once got Protocol Buffers working with Codegear C++ Builder 2007
https://groups.google.com/forum/?fromgroups=#!topic/protobuf/YapO_DqFVvc
The author of the above Builder 2007 version of protobuf uploaded it to a 3rd party URL, however the link to it seems to be long dead, and judging by the discussion and the current state of Protocol Buffers 2.5.0 the fix/change has never been forked from protobuf or merged into the trunk.
Updated:
When using generated code from protoc.exe (2.5.0) for either of the example .proto files, C++ Builder 2007 complains about a multitude of problems, including "duplicate entries" for names in the google::internal namespace (such as google::internal::kEmptyString - it also complains about the std::hash based containers and that memset is an unrecognised symbol.
It took me several days to arrive at a solution, but here's how I managed to get it working in Codegear 2007:
Obtain the C++ Builder version of protobuf https://github.com/saadware/protobuf-cppbuilder - this is based on 2.4.1, so it is a little outdated, but I would guess that it's possible to merge the C++ builder changes into 2.5.0 (or whatever the latest version is). The C++ Builder version of protobuf is for Builder 2009, but it fixes various problems with std::hash, so it's a better starting point than Google's release.
Take a copy of the following .cc files in the ./src/google/protobuf folder and change them to a .cpp extension. There seems to be an issue with the .cbproj format which doesn't like .cc (You will need to add all of these files into your Codegear 2007 .cbproj - these are the files required for libprotobuf-lite).
extension_set.cpp
generated_message_util.cpp
message_lite.cpp
repeated_field.cpp
wire_format_lite.cpp
stubs\common.cpp
stubs\once.cpp
io\coded_stream.cpp
io\zero_copy_stream.cpp
io\zero_copy_stream_impl_lite.cpp
As per the thread by 'Dazza' use find-and-replace-in-files (e.g. Notepad++) to rename the google::internal namespace. Note that a case-sensitive find/replace is required because there are occurrences where the name 'Internal' is used for other things. For this step I followed Dazza's suggestion of changing it to google::internals. (Note - this is both for the libprotobuf-lite and for the strings used to make the generated code)
In the generated code strings, search for all occurrences of memset and change them to std::memset (This is primarily for the code generator lib; libprotoc. If you don't do this, every time you re-generate your .proto bindings, C++ builder will be unable to identify memset.
Build protoc.exe using Visual Studio (I couldn't get Protoc.exe to build in Builder, but that shouldn't matter anyway, the code generator only needs to be built once)
Modify the example .proto files use the lite runtime;
option optimise_for = LITE_RUNTIME. Note - reflection capabilities are not available with this option switched on.
Run protoc.exe on your .proto file with --cpp_out. The output file will have a .cc extension - you will need to rename this to .cpp
Add your generated files to your project and build.
(Note- there are still a few warnings outstanding - one complaining about a superfluous & taking the address of a function, and a few others complaining about signed/unsigned comparisons - but at least it builds and seems to work)
Related
Now I am going to connect to device using bluetooth, so I have got some source code.
It uses namespace Windows::Devices, but my visual studio gives me compile error.
using namespace Windows::Devices;
I guess I have to install some packages additionally, but I am not sure what I have to install.
If anyone knows, please help me.
Since the question is tagged c++ I'm going to assume that that's the programming language you are using. The most convenient way to consume Windows Runtime types from C++ is through C++/WinRT. It consists of both a base library as well as a code generator. The code generator is responsible for providing the "projected types" (see Consume APIs with C++/WinRT), generated into namespaces such as Windows::Devices.
It's common for a project to generate the headers containing the projected types on the fly, that can then be included like any other header. A project created using the C++/WinRT VSIX extension does that. Those projects have a reference to the Microsoft.Windows.CppWinRT NuGet package that contains the code generator, as well as project properties to drive it during a build.
Previously, the header files containing the projected C++/WinRT types had been delivered through the Windows SDK. They are still part of the SDK, and can be used by client code, even though it's preferable to use the NuGet package instead. You'll find the Windows.Devices.h header file under %WindowsSdkDir%Include<WindowsTargetPlatformVersion>\cppwinrt\winrt, so to use this namespace, that's the file you'll need to include.
I have a embedded controller code handed over, it has a bunch on .c files and some headers and a lot of associated files for the embedded processor, its a motorola MC9S12DT256 and it uses a not-so-good compiler - Cosmic. i used Visual studio(just a txt editor) for modifying the code and it changes the hex file being burned to the processor.
I got it earlier this week and spent most of my time on it and it worked ok for minor changes (where changin a value in the code and compiling again made the necessary changes) Now i have to make some major changes. The code calls certain functions which are not to be found any where in the all of the .hpp/.h/.cpp i got. there are no associated dlls as well. I tried to find some basic link and put it in a .sln and still most data is not recognized (as in i cant go to declaration of defn).
So my question is - how to get to the function definiton to where it is called when VS blanks out. Find all references also does no help
Thanks
PM
They may be compiler intrinsics (functions provided by the compiler rather then in a library). But it is not clear how you have determined that they do not exist in a static library or why you think you should be able to see a definition (as opposed to a declaration).
When using Visual Studio as an embedded project IDE, you should create the project as a "makefile project" (even if you don't actually have a makefile), and you need to add all the necessary header paths for your embedded code and the Cosmic compiler standard header folder as include files to the project - VS scans the header files for declarations for Intellisense code completion and browser navigation.
I have a C++ project that builds on several platforms.
On Mac OSX and Linux, I use SConstruct, which allows me to have some "smartness" regarding the different compilation steps. Namely, I could put the program version in a file named VERSION at the root of the repository, whose content is simply:
2.0
In the build SConscript, I just have to open, read and parse that file and I can create dynamic defines based on it. For instance:
env.Append(CXXFLAGS=['-DVERSION_MAJOR=%s' % open('VERSION').read().split('.')[0]])
This is, for obvious reasons, very convenient. It also allows me to put today's date in an environment variable for instance.
Now for Windows, I have a .sln file with different .vcxproj files into which I'd like to do something similar, except I have no idea how.
To summarize, my question is: how can I have "smart" defines like that (reading, parsing a file and putting its content into several environment variables) without having to change the .sln/.vcxproj files manually on every version shift ?
I know I could use SCons on Windows too, but I'd like not to (mainly because it seems less popular on the platform, and I don't want to scare potential contributors that only know Windows-specific tools).
A common way to do this is to define your constants in an include file:
e.g.
// Version.h - Autogenerated, don't edit
#define VERSION_MAJOR 1
Next you write a script or a program (in your favourite language) to obtain version from somewhere and dynamically write Version.h. Possibly parse the old Version.h and increment or get it from some external source.
In visual studio, create a custom build step for Version.h and make it dependent on something that forces it to update on every build.
You could maintain the current solution, and for Windows, integrate it with Visual Studio solution and project files generated by SCons using the MSVSProject() builder or the MSVSSolution() builder.
You can find more info about these SCons builders here.
I've added a custom build step to my Visual Studio project files which generates the google protobuf .h/.cc files from the .proto input files. But I've been wondering if it's possible to start a compile only if the content of the proto files has changed?
Is there a way to tell VisualStudio from a custom build step exactly that? What is the optimal way to integrate proto files into a visual studio build solution?
At the moment, at every build the .proto file is updated which then also updates the time stamp of the output .h/.cc files ...which then issues a recompile of everything dependent from that. Is there a better way around it, while still building them directly from visual studio?
Follow these detailed instructions to specify Custom Build Tool.
Considering your proto file resides together with .h/.cpp files in standard project configuration, here are values to be inserted in Custom Build Tool:
Command Line:
path\to\protoc --proto_path=$(ProjectDir) --cpp_out=$(ProjectDir) %(FullPath)
Outputs:
$(ProjectDir)%(Filename).pb.h;$(ProjectDir)%(Filename).pb.cc
Please note usage of item metadata macros, which replaced some of deprecated macros (like $(InputDir) and $(InputName)).
Now Protocol Buffers compiler will be run only when Input file (i.e. %(FullPath)) is newer than "Outputs".
Maybe this helps. Especially look at the post of Igor Zavoychinskiy:
Solution of this nasty problem is actually simple: in outputs sections
you should specify full path(s). This isn't explicitly stated anywhere
but without this checker just fails to find the files and, hence,
assumes they don't exist. For example for protobuffers compiling
outputs section will be like this:
$(InputDir)\$(InputName).pb.cc;$(InputDir)\$(InputName).pb.h
and (maybe?) kmote00:
...
Bottom line: I just had to make sure my "Outputs" entry exactly
matched the Default Value in the (user-defined) "OutputFile" property.
(Thankfully this also obviated the need for a two-pass build, which
was another annoyance I had previously put up with.)
Is anyone using Boost for regular expressions in BCB6, or can recommend anything else? I've downloaded the latest boost ZIP file a few times, but I can't get it to unzip yet (my PC is probably not in the best state right now). It is a pretty huge library, so if there is anything else smaller that is just regular expressions, that works well with BCB6, I'd like to try that first. I tried http://www.regular-expressions.info/delphi.html also, but it doesn't have any info about BCB support (just Delphi) and it looks like some of the supplied OBJ files have issues with BCB (and no source code to rebuild those).
Edit: After searching the source code and include folders under CBuilder6\ I found out Builder does have built-in support for regex. So another question is, do they work well, and which set of functions/objects should I use for a VCL-based app? I found TRegexp (but no docs for it) and also some PCRE functions under the CRTL help file (but I'd rather use higher level or C++ if all about the same).
The TPerlRegex classes (available at the link you posted above) work fine in C++ Builder. See the section about halfway down the page that refers to older Delphi versions. Best of all, they're free with full Delphi source that will compile in Builder as well.
The components/classes are based on PCRE, and in fact include C source for the .obj files that are used when you compile not to need the DLL, but you can also use it without the .obj files by compiling to require the DLL and distributing the DLL with your app.
The related application to that site, RegexBuddy, can generate strict C-based code for the regexes, or can generate Delphi code (or C++ Builder XE, which can pretty easily be made to work with Builder 6 if you remember that Builder XE is Unicode-based and Builder 6 isn't). (I'm not affiliated with RegexBuddy; I've just been a user since version 1 was released.)
Here's a sample of RegexBuddy 3's C (PCRE) support: