I saw the two projects are quite related, but what are the differences between them? The official webpage doesn't tell much about it.
I know that ABI (Application Binary Interface) is used to provide low-level binary interface among different platforms. So is libc++abi used to provide different implementations for different platforms, and general interface for libc++?
Would be better go give some specific example, e.g. what are included in libc++abi and what in libc++.
Thanks.
The Application Binary Interface, or ABI for short, is intended to provide certain low level functions from which to build the C++ standard library. It is a supporting library that is a separate component from the actual standard library. Along with libcxxabi, you may also come across Pathscale's libcxxrt or GCC's libsupcxx.
On the other hand, libc++ is an implementation of the C++ standard library that can be built using either of the 3 mentioned ABIs.
Related
I'm trying to find the values of several C++ constants which are useful for coding the V1 microbit's ADC, such as ADC_ENABLE_ENABLE_Enabled (in this article).
I believe the #include "MicroBit.h" refers to this repo https://github.com/lancaster-university/microbit/tree/master/inc but I can't find the ADC definitions!
The definitions for these macros come from deep in the low-level libraries for the microprocessor used on the BBC microbit, the nrf51822. Higher level libraries typically include these files (or the build system might) to implement more intuitive and easier-to-use APIs. While I am not sure where these files are on your system as it depends on your build environment, the source is on GitHub:
https://github.com/NordicSemiconductor/nrfx/blob/7eca6c2dc02b24cbdaa3ba0e63a7195e34ebe07c/mdk/nrf51_bitfields.h#L163
I am currently developing a method for symbolically executing and testing IEC 61131-3 applications.
For evaluating my approach, I require non-trivial programs written in any of the languages defined in the standard.
Are there any openly accessible code bases I could use for this?
The OSCAT libraries is the biggest open code base written in IEC61131-3 afaik. They provide different libraries for different use cases and for different plc vendors
Furthermore there are some example programs available on Beckhoff Infosys. For almost every library they provide a sample section. One of the biggest samples is the OOP extension sample (OOP extensions are included in the new version of IEC61131-3, not sure if you are interested in it).
Another source of examples is the Codesys Store. They have some free and some paid examples.
And one more I like (but its only in german). M. Seitz the author of a good plc programming book provides some accompanying samples, one of them a bit bigger (coffee machine). There is also a simulation and control library available.
A very good source for examples is Beckhoff's information system which is also available for download.
You can find good examples of different methods for example under different libraries.
Some links:
Programming Reference (Good source)
OOP Sample
Standard library (Library containing IEC standard functions)
We'd like to offer a compiled library that implement a protocol layer to be imported into C/C++ source code project for microcontrollers. And eventually expose a sort of compiled function to the source code project. let's say a sort of "dll". Is there any know technique to realize something of similar?
While it is possible to provide functions via a library, generally in the microcontroller/embedded realm it quickly becomes impractical.
Each microcontroller core will have a unique instruction set. Further, micros from the same family may have a variety of extensions which are either supported or not... So you're left with providing a library file for each individual microcontroller (from each vendor) that you'd like to support.
But...
In my experience, calling conventions between compilers are not the same. So a library compiled by one toolchain will not be able to be linked to object files created by another toolchain.
That leads you to then provide a library for each individual micro from each vendor for each toolchain someone might use. Ick. Oh, and don't rely on an OS calls either, as you don't know what you'll be linked with...
A more conventional approach is to use the same approach RTOS vendors tend to use: provide the source, and protect your IP with licensing terms. The reality is that if your end users want to, they can step through the assembly and figure out exactly what is happening, so you're not hiding your implementation that carefully anyway.
There are lots of oop languages, but I couldn't find any that has conveniences like garbage collection, but compiles natively to machine code. Sort of like between C and java/c#. One interesting language I found was Vala, but that's limited to the GNOME platform and is not that well-known
Go is probably closest.
But why on earth do you want it natively compiled anyway?
JIT compilation of portable bytecode has proved to be an extremely effective strategy. It compiles down to native code at runtime (so you get up to the performance of native code after the first few iterations) and it avoids the issues of having to build and manage platform-specific compiled binaries.
Are you thinking about C++? That is in high usage and can be compiled on nearly any (major) platform.
In the case you want to use an oo language that compiles down to native code you will "always" have to use header files and stuff as the elf format doesn't support oo (There is no class information in elf).In case you want to use classes from external libs you need to make the compiler aware somehow about the fact that there are classes, functions, etc. that are declared outside of your project. In C++ this is solved by the use of header files. So that's, I think, a major drawback in native object oriented languages. To resolve that issue a few tweaks would need to be made to elf/loader/linker in order to support the kind of features (like "linking" against "classes") you might expect. Even though mechanism for garbage collection could be implemented even in native languages. But that seems no good for os implementation.
There are C++ libs to do that for userspace apps like:
Boehm collector
Smart pointers
For me, a library is a collection of classes that do useful things. Typically something, that can be useful in a lot of projects. Is that also the case in terms of objective-c? What exactly is a library there? Only classes that have methods? Or also collections of functions? And do they have to be compiled to be called a "library"? Where is the segregation between an "Framework"? Aren't bove the same thing?
According to Wikipedia: "Frameworks are functionally similar to shared libraries, a compiled object that can be dynamically loaded into a program's address space at runtime, but frameworks add associated resources, header files, and documentation."
A framework is essentially a shared library (binary, similar to a DLL) in a bundle that also includes all of the information needed to use that library (like header files, documentation, internationalization resources, etc). A framework without all of the extras is just a library.
There is no requirement that a framework be object-oriented in nature, though I assume that's the norm with Cocoa.
For Cocoa, the concept of a framework generally replaces (enhances) the concept of a library. However, the Objective-C toolchain imposes no such requirement. You can use source-only "libraries" or unix-style binary libraries (e.g. an .so file). I think of a "library" in these generic terms... it's just a collection of useful code, in source or binary form. A framework, on the other hand, is a specific thing with a specific meaning for OS X.
Assuming you are talking about a library that uses the Cocoa frameworks and not just one written in the plain old Objective-C language, a library (or framework) is a collection of classes that work together to perform a specific task. I would not organize an ObjC framework as a collection of functions since that totally goes against the paradigm of the language.
As for the difference between a library and framework, that's probably a bit subjective. To me, a library (in the context of your question) is something written in C that probably more closely resembles a non-OO collection of functions. A framework would be a full package of classes as I described above. So the Messaging framework on CocoaDev would be a framework, whereas the sqlite3 APIs you can access on the iPhone would be a library. Again, that's just me. Other people may interpret the terms differently.