I'm trying to write some code that uses git_diff_perfdata from the Libgit2 library.
git_diff_perfdata s;
However, when compiling on my Mac I get the error:
use of undeclared identifier 'git_diff_perfdata'
My understanding is that Libgit2 is meant to be used exclusively through the inclusion of git2.h. Is that correct?
git_diff_perfdata is defined in sys/diff.h and used in status.h
Should I be including sys/diff.h directly. If so, why? Alternatively, what errors might I be making? Looking at the header code I'm unable to see how sys/diff.h is included through anything that is included by git2.h.
Additionally, from what I can tell git_diff_perfdata isn't meant to be an opaque data type (i.e. only the pointer is defined).
I'm using the code downloaded from:
https://github.com/libgit2/libgit2/archive/v0.26.0.zip
The headers in sys are part of the public API, but they're a bit lower level. You can think of them as internal implementation details that have been made public because they might be useful to application developers. If you want to use them, include them directly.
Related
I prefer working with files that are less than 1000 lines long, so am thinking of breaking up some Erlang modules into more bite-sized pieces.
Is there a way of doing this without expanding the public API of my library?
What I mean is, any time there is a module, any user can do module:func_exported_from_the_module. The only way to really have something be private that I know of is to not export it from any module (and even then holes can be poked).
So if there is technically no way to accomplish what I'm looking for, is there a convention?
For example, there are no private methods in Python classes, but the convention is to use a leading _ in _my_private_method to mark it as private.
I accept that the answer may be, "no, you must have 4K LOC files."
The closest thing to a convention is to use edoc tags, like #private and #hidden.
From the docs:
#hidden
Marks the function so that it will not appear in the
documentation (even if "private" documentation is generated). Useful
for debug/test functions, etc. The content can be used as a comment;
it is ignored by EDoc.
#private
Marks the function as private (i.e., not part of the public
interface), so that it will not appear in the normal documentation.
(If "private" documentation is generated, the function will be
included.) Only useful for exported functions, e.g. entry points for
spawn. (Non-exported functions are always "private".) The content can
be used as a comment; it is ignored by EDoc.
Please note that this answer started as a comment to #legoscia's answer
Different visibilities for different methods is not currently supported.
The current convention, if you want to call it that way, is to have one (or several) 'facade' my_lib.erl module(s) that export the public API of your library/application. Calling any internal module of the library is playing with fire and should be avoided (call them at your own risk).
There are some very nice features in the BEAM VM that rely on being able to call exported functions from any module, such as
Callbacks (funs/anonymous funs), MFA, erlang:apply/3: The calling code does not need to know anything about the library, just that it's something that needs to be called
Behaviours such as gen_server need the previous point to work
Hot reloading: You can upgrade the bytecode of any module without stopping the VM. The code server inside the VM maintains at most two versions of the bytecode for any module, redirecting external calls (those with the Module:) to the most recent version and the internal calls to the current version. That's why you may see some ?MODULE: calls in long-running servers, to be able to upgrade the code
You'd be able to argue that these points'd be available with more fine-grained BEAM-oriented visibility levels, true. But I don't think it would solve anything that's not solved with the facade modules, and it'd complicate other parts of the VM/code a great deal.
Bonus
Something similar applies to records and opaque types, records only exist at compile time, and opaque types only at dialyzer time. Nothing stops you from accessing their internals anywhere, but you'll only find problems if you go that way:
You insert a new field in the record, suddenly, all your {record_name,...} = break
You use a library that returns an opaque_adt(), you know that it's a list and use like so. The library is upgraded to include the size of the list, so now opaque_adt() is a tuple() and chaos ensues
Only those functions that are specified in the -export attribute are visible to other modules i.e "public" functions. All other functions are private. If you have specified -compile(export_all) only then all functions in module are visible outside. It is not recommended to use -compile(export_all).
I don't know of any existing convention for Erlang, but why not adopt the Python convention? Let's say that "library-private" functions are prefixed with an underscore. You'll need to quote function names with single quotes for that to work:
-module(bar).
-export(['_my_private_function'/0]).
'_my_private_function'() ->
foo.
Then you can call it as:
> bar:'_my_private_function'().
foo
To me, that communicates clearly that I shouldn't be calling that function unless I know what I'm doing. (and probably not even then)
I am creating a C++/CLI wrapper for native C code that has it's own Object typedef and am receiving the C2872 'Object': ambiguous symbol error when linking. The compiler output is:
1>C:\src\OS_kernel.h(27): error C2872: 'Object': ambiguous symbol
1>C:\src\OS_types.h(261): note: could be 'ObjectStruct *Object'
1>C:\src\OS_kernel.h(27): note: or 'System::Object'
It may be worth mentioning that I am mocking this native C code for the purposes of the C++/CLI wrapper; not sure if that opens up a potential solution that would otherwise not be available if no source code was available. I'm guessing there is a way to specify which definition I want the code to use, but I don't know how to specify that. Is that possible? I want to specify it to use the ObjectStruct *Object.
It would be great if I didn't have to modify the mock code since it could potentially be hundreds or thousands of individual places.
As an aside, I am also receiving this error for other types the native library is using, such as Buffer and Boolean.
OK, since you're getting the error in OS_kernel.h, I'm guessing that's part of the C code you're wrapping.
Obviously, one possible solution is to treat the name Object as a reserved word, and edit your C code to not use it. One could argue that this is the most correct solution, but it may not be possible to do that.
Depending on how you're referencing the C code, it may be reasonable to compile it as C++, and stick it entirely within a namespace. That way, when the C code (now C++ code) uses Object it will see the typedef within its namespace, and you'll have the option to reference either namespace in your code.
The fact that you're getting this error from your library's header file indicates to me that you've got a using namespace System; directive, and that the #include of your library's header files comes after that using directive. Consider removing the using namespace System;, or at least moving it after the #include. This way, you won't get that error in the library's headers, you'll just have to deal with it in your code.
I'm running through the libgit2 sample code for getting the content of blobs, and I've hit a problem with the line:
git_buf filtered_content = GIT_BUF_INIT;
I get error C2065: 'GIT_BUF_INIT': undeclared identifier, which makes sense, because I can't find this defined in any of the included header files. As nobody seems to have asked this question before I get the strong feeling I'm missing something obvious. Any ideas on what I need to do to use GIT_BUF_INIT?
That's declared inside the library because it references an internal buffer. You should zero the structure as usual for C.
If the examples contain GIT_BUF_INIT they were probably extracted from the tests and we missed that it's not available outside.
I realize that doing this can lead to compile errors. But is an import always safe if no (new) compile errors or warnings arise? If I use an import statement (e.g. to remove duplicate protocol definition warning), could doing so, on it's own, ever change the run-time behavior? What checks (if any) are necessary to ensure invariability of operation after a new header import?
Yes, importing a header can lead to run-time issues.
For example, you may get a warning that a selector is unknown so the compiler is making assumptions about its signature. If you fix that warning by importing the relevant header, then that changes the code the compiler is emitting. Generally, it would change the code from broken to correct, but that nevertheless results in a run-time change.
If you use #import, then the header could define preprocessor macros that radically alter the subsequent code. For example, it could #define setNeedsDisplay setHidden or something.
The only way I can think of to verify that importing the header didn't alter the generated code is to examine the generated code and compare before and after. You can ask Xcode or clang to produce assembly from the compilation. You could also use otool -tV to disassemble the binaries (although that wouldn't show changes in, say, static data like strings).
This is kind of a strange question. Basically there’s a const struct defined in a framework that I may or may not be able to load. Let’s say the struct is called “ExternalStruct”. I can tell whether or not I can load the framework but I can’t use the variable by name because if I can’t load the framework it will crash. How can I do what I’m trying to do (reference ExternalStruct but only if I can load this framework)?
Thanks
EDIT:
My other thought was to use an ifdef but I’m not sure how those work with respect to compile time vs link time.
If you can get the CFBundle/NSBundle for the library in question, once it's loaded you can use CFBundleGetDataPointerForName.