Can v8 (Google's open source JavaScript engine) be used with C++11?
https://developers.google.com/v8/embed
The V8 API provides functions for compiling and executing scripts,
accessing C++ methods and data structures, handling errors, and
enabling security checks. Your application can use V8 just like any
other C++ library. Your C++ code accesses V8 through the V8 API by
including the header include/v8.h.
It´s a sublink of the one you commented, i hope it helps.
Yes, as of today it can be used effectively with C++11, and even C++14 semantics. I had this same question while writing a v8 project, which uses a multitude of C++11 (and later) threading features.
Related
I am trying to evaluate Djinni, for generating Java and Obj-C wrappers from our C++ code.
We currently use SWIG and are evaluating other tools for wrapper generation.
Due to some restriction at my work place our C++ code is in C++-98.
We cannot migrate to C++-11 due to some customer needs.
As such I wanted to know if I can use Djinni, with C++-98.
Djinni github readme states:
Interfaces are objects with defined methods to call (in C++, passed by shared_ptr). Djinni produces code allowing an interface implemented in C++ to be transparently used from ObjC or Java, and vice versa.
I saw couple of sample's using Djinni over the internet and they all seem to use shared_ptrs with their interfaces.
Is C++-11 mandatory for using Djinni?
No, Djinni can not be used with C++98. It uses C++11 pretty extensively, both in the generated code and in the support library, so it can't support C++98.
I recently added lua support in one of my c++ applications. The goal is that my application is the core and the users can access functions from my core using lua.
I have seen that it is possible to have syntax correction and auto completion like visual studio has. And that is exactly what I want to have, too.
How to I implement this feature? The lua file can be written inside a window of my application. Can I connect my c++ function pool with this lua scripting?
Any help on this would be greatly appreciated.
Fabian
Use Scintilla. It's crossplatform and is available as a library for different platforms and frameworks.
As an example, here are few links:
QScintilla for Qt4 and Qt5.
ScintillaNet for Windows Forms applications.
wxWindows has it already, and it's called wxStyledTextCtrl.
Sure, it is possible to use Scintilla even if you are not using any GUI editors and your application is pure code. It's just an external library, and can be either static (part of your binary after compilation) or dynamic (should be bundled with your application).
With native c++, I mean, not managed c++, not cli, not any special things from microsoft, I can:
1) get high performance
2) use existing c++ code library and engine
3) write cross platform code (for example, for ios and android)
it needn't be fully native c++, I can use managed code to do the ui things, like object-c in ios and java in android, but beside interface, can I use native c++ code?
I suggest you have a look at the presentation here: Using the Windows Runtime from C++ and especially at the comments from Herb Sutter. I quote:
Please answer this question: If I decide to write C++ GUI application
in Metro style am I forced to use all these proprietary ref, sealed,
^, Platform::String^ extensions for GUI components or not?
#Tomas: No, you are not forced to use them. We are providing two
supported ways:
1) These language extensions (C++/CX).
2) A C++ template library (WRL), see
Windows Kits\8.0\Include\winrt\wrl as Yannick mentioned. WRL is a C++
library-based solution sort of along the lines of ATL, which offers
what I think you're looking for -- template wrapper/convenience
classes and explicit smart pointers and such.
Yes you absolutely can, real native C++ is fully supported.
You do however mostly have to use the new WinRT libraries to do an user interface or system calls and although they are native code and fully callable from C++ directly the interface to them makes it very painful indeed to do so, as everything is a reference counted COM object and in addition it's not so easy to create instances of them as just calling "new" so you have to write a lot of ugly code to do so.
As the earlier answer said, microsoft provide two ways to help with this. One is via language extensions to c++ and the other is a c++ template library. Personally I consider both to be rather ugly for doing something as simple as calling an API but that's just me :)
But to answer your question, it's completely possible to write your application in real native c++. You won't need to use managed code at all for anything. But you'll probably want to use either the language extensions or the template library to make calling the API more easy.
Personally I'm hoping someone writes a wrapper for WinRT that exposes the most necessary functionality as a more usable c++ native library and then everyone can just use that from c++ instead...
My purpose is to reuse some C++ STL implementation for iOS development with static library.
As we know, iOS devices are based on ARM6/7 family,which is different with *86 family for some compiler options.
For mobile development, we prefer to reuse some C++ codes across different platforms,such as iOS, Android, and even for the PC back end.
So question here to know some issues or limitations for this purpose.
Thanks
C++ STL just refer some popular version,I do not want to cover all STL libs, I just want to know some popular issues for this case. Thanks for pointing any out.
The main purpose of using standardized tools is to achieve portability. As long as you use the library as intended, without relying on behavior outside the standard, there should not be any issues moving it to any platform with a good C++ implementation.
The Standard Library implementation on iOS is the same as the one on Mac OS. There should be no difference.
ARM vs x86 should make no difference whatsoever. The part of the C++ Standard Library called the STL consists entirely of templates, hence "Standard Template Library." Templating over high-level data structures all but precludes assembly-language tricks.
No - when working for my previous employer, we used a whole protocol stack (with some STL) written in C++ for our desktop client to bootstrap development of our iPhone client. Worked great.
This question already has answers here:
What is the difference between ANSI/ISO C++ and C++/CLI?
(2 answers)
Closed 7 years ago.
I'm learning C++ (CLI apparently), and every time I post a question saying that I am using C++, someone jumps down my throat saying that I'm not using C++, but C++/CLI. I'm not really sure of a difference, as I am extreamely new to this, but it seems to make everyone upset. Can anyone shine some light on the differences?
As a second note, the reason I am asking this is because it was suggested that I use CLI to be able to make a method accessible to my C# project. I have everything running fine in my C++ project, through my constructor, but now I would like to be able to call those same methods from my C# project.
C++ CLI runs on the "Common Language Interface". This basically means that when it's compiled, the compiled code will end up being allot like the byte code produced via C#.
C++ CLI has a ton of extensions added to it such as Garbage Collection that do not exist in C++. C++ CLI also allows for "safe" C++ code. In this mode you're not allowed to use pointers. There's no such thing as "safe" code in C++ it's all "unsafe". C++ CLI can be nice for interfacing .NET code and C++ libraries, but besides that, I haven't found a use for it.
The Wikipedia page has a good overview: http://en.wikipedia.org/wiki/C%2B%2B/CLI
And yes, they are right to jump on you for being able to program in C++ CLI will not allow you to program in C++....they are different enough that you cant just mix them.
AFAIK, C++ CLI allows you to have access to the .net framework.
It offers some garbage collection and few other specific features not on C++
C++ runs directly as binary complied for your hardware. C++ cli is a c++ extension that is used to interface with the MS common language runtime. It complies to IL normally and is executed inside the .net runtime. There are numerous differences between the two some of the major ones being garbage collection and how inheritance and interfaces work.
The reason to use c++Cli is gain the advantages of using the hundreds of classes provided to you by the framework. These are all accessible from any CLR compliant language so some have been left to wonder why one would use c++ to access the framework, unless you are linking into some legacy code.