I am working on a Java binding for the excellent libvips
Using this function all is fine:
VipsImage *in;
in = vips_image_new_from_file( test.jpg, NULL )
vips_image_write_to_file( in, "out.jpg", NULL )
So mapped in Java:
Pointer vips_image_new_from_file(String filename,String params);
But I have a problem when the parameter like this:
VipsImage *in;
VipsImage *out;
vips_invert( in, &out, NULL )
vips_image_write_to_file( out, "out.jpg", NULL )
I have tried:
int vips_resize(Pointer in, PointerByReference out, Double scale, String params);
Pointer in = vips_image_new_from_file("file.png",null);
PointerByReference ptr1 = new PointerByReference();
vips_invert(in, ptr1, null);
vips_image_write_to_file( ptr1.getValue(), "fileout.png", null);
But doesn't work. The ptr1.getValue() does not contains the expected result.
How can I do it?
Thanks
I'm the libvips maintainer, a Java binding would be great!
But I think you might be taking the wrong approach. I think you are trying a straight wrap of the C API, but that's going to be tricky to do well, since it makes use of a lot of C-isms that don't map well to Java. For example, in C you can write:
VipsImage *image;
if (!(image = vips_image_new_from_file("somefile.jpg",
"shrink", 2,
"autorotate", TRUE,
NULL)))
error ...;
ie. the final NULL marks the end of a varargs name / value list. Here I'm asking the jpeg loader to do a x2 shrink during load, and to apply any Orientation tags it finds in the EXIF.
libvips has a lower-level API based on GObject which is much easier to bind to. There's some discussion and example code in this issue, where someone is making a C# binding using p/invoke.
https://github.com/jcupitt/libvips/issues/558
The code for the C++ and PHP bindings might be a useful reference:
https://github.com/jcupitt/libvips/tree/master/cplusplus
https://github.com/jcupitt/php-vips-ext
That's a PHP binding for the entire library in 1800 lines of C.
I'd be very happy to help if I can. Open an issue on the libvips tracker:
https://github.com/jcupitt/libvips/issues
Related
In c++ we have iterators that act as reference to some element in list. Assigning to the iterator it is possible to change elements inside the list.
for example:
std::map<std::pair<int,int> ,Ship> playgroundMap;
playgroundMap.insert(std::make_pair(std::make_pair(2,2),Ship(100,Cannon(50))));
playgroundMap.insert(std::make_pair(std::make_pair(3,3),Ship(200,Cannon(60))));
std::cout<<"Iterators : "<<std::endl;
auto shipPtr = playgroundMap.find(std::make_pair(2,2));
std::cout<<" address of ship Before : "<<&shipPtr->second<<std::endl;
shipPtr->second.cannon.firepower = 1000;
auto tmp = Ship(200,Cannon(90));
shipPtr->second = tmp;
std::cout<<" address of ship After newly Assigned : "<<&shipPtr->second<<std::endl;
std::cout<<"finalList : "<<std::endl;
for(auto a : playgroundMap)
{
std::cout<<a.second.durability<<std::endl<<a.second.cannon.firepower<<std::endl;
}
Let alone the fact that reference in c++ are enough to achieve this. References in c++ do not rebound on assignment like they do in dart.
for example in c++:
std::map<std::pair<int,int> ,Ship> playgroundMap;
playgroundMap.insert(std::make_pair(std::make_pair(2,2),Ship(100,Cannon(50))));
playgroundMap.insert(std::make_pair(std::make_pair(3,3),Ship(200,Cannon(60))));
std::cout<<"Reference : "<<std::endl;
auto &shipRef = playgroundMap[std::make_pair(2,2)];
std::cout<<" address of ship Before : "<<&shipRef<<std::endl;
shipRef.cannon.firepower = 1000;
auto tmp = Ship(200,Cannon(90));
auto &tmpRef = tmp;
std::cout<<" address of tmpref (newly created ship) : "<<&tmpRef<<std::endl;
shipRef = tmpRef;
std::cout<<" address of ship After newly Assigned : "<<&shipRef<<std::endl;
std::cout<<" address of finalList : "<<std::endl;
for(auto a : playgroundMap)
{
std::cout<<a.second.durability<<std::endl<<a.second.cannon.firepower<<std::endl;
}
This would modify the list element in c++ while in dart the reference would rebind and element in list would not change.That is whole another thing i understand that both these concepts are different in both languages.
My question is, Is there some kind of c++ iterator like way in dart that allows me to do these kind of operations. I know i can just store the index but i don't want to do that.
There is nothing like that in the platform libraries.
In general, Dart iterators give access to the values of a collection, not to changing the collection itself.
One of the reasons for this restriction could be that Dart doesn't have reference variables to begin with, but nothing inherently prevents Dart from having an iterator that allows you to change the value of the current element. At least for a list, it could work. A hash set probably wouldn't work, because the changed value wouldn't be in the same place of the iteration.
All in all, it's not something the platform libraries support, or have wanted to support. The Dart platform libraries are, in most places, slightly more functional programming like than C++.
Use case: I am converting data from a very old program of mine to a database friendly format. There are parts where I have to do multiple passes over the old data, because in particular the keys have to first exist before I can reference them in relationships. So I thought why not put the incomplete parts in a vector of references during the first pass and return it from the working function, so I can easily use that vector to make the second pass over whatever is still incomplete. I like to avoid pointers when possible so I looked into std::reference_wrapper<T> which seemes like exactly what I need .. except I don't understand it's behavior at all.
I have both vector<OldData> old_data and vector<NewData> new_data as member of my conversion class. The converting member function essentially does:
//...
vector<reference_wrapper<NewData>> incomplete;
for(const auto& old_elem : old_data) {
auto& new_ref = *new_data.insert(new_data.end(), convert(old_elem));
if(is_incomplete(new_ref)) incomplete.push_back(ref(new_ref));
}
return incomplete;
However, incomplete is already broken immediately after the for loop. The program compiles, but crashes and produces gibberish. Now I don't know if I placed ref correctly, but this is only one of many tries where I tried to put it somewhere else, use push_back or emplace_back instead, etc. ..
Something seems to be going out of scope, but what? both new_data and old_data are class members, incomplete also lives outside the loop, and according to the documentation, reference_wrapper is copyable.
Here's a simplified MWE that compiles, crashes, and produces gibberish:
// includes ..
using namespace std;
int main() {
int N = 2; // works correctly for N = 1 without any other changes ... ???
vector<string> strs;
vector<reference_wrapper<string>> refs;
for(int i = 0; i < N; ++i) {
string& sref = ref(strs.emplace_back("a"));
refs.push_back(sref);
}
for (const auto& r : refs) cout << r.get(); // crash & gibberish
}
This is g++ 10.2.0 with -std=c++17 if it means anything. Now I will probably just use pointers and be done, but I would like to understand what is going on here, documentation / search does not seem to help..
The problem here is that you are using vector data structure which might re-allocate memory for the entire vector any time that you add an element, so all previous references on that vector most probably get invalidated, you can resolve your problem by using list instead of vector.
I am working with Embedded C language and recently run the MathWorks Polyspace Code Prover (Dynamic analysis) for the whole project to check for critical runtime errors. It found one bug (Red warning) at While loop where I am copying some ROM data into RAM via memory registers.
The code is working fine and as expected but I would like to ask if there is any solution to safely remove this warning. Please find the code example below:
register int32 const *source;
uint32 i=0;
uint32 *dest;
source= (int32*)&ADDR_SWR4_BEGIN;
dest = (uint32*)&ADDR_ARAM_BEGIN;
if ( source != NULL )
{
while ( i < 2048 )
{
dest[i] = (uint32)source[i];
i++;
}
}
My guess is that ADDR_SWR4_BEGIN and ADDR_ARAM_BEGIN is defined in linker script and polyspace didn't compile and link the project that is why it is complaining about the possible run time error or infinite loop.
ADDR_SWR4_BEGIN and ADDR_ARAM_BEGIN are defined as extern in the respective header file.
extern uint32_t ADDR_SWR4_BEGIN;
extern uint32_t ADDR_ARAM_BEGIN;
The warning is red and exact warning is as follow:
Check: Non-terminating Loop
Detail: The Loop is infinite or contains a run-time error
Severity: Unset
Any suggestions would be appreciated.
The code is overall quite fishy.
Bugs
if ( source != NULL ). You just set this pointer to point at an address, so it will obviously not point at NULL. This line is superfluous.
You aren't using volatile when accessing registers/memory, so if this code is executed multiple times, the compiler might make all kinds of strange assumptions. This might be the cause of the diagnostic message.
Bad style/code smell (should be fixed)
Using the register keyword is fishy. This was once a thing in the 1980s when compilers were horrible and couldn't optimize code properly. Nowadays they can do this, and far better than the programmer, so any presence of register in new source code is fishy.
Accessing a register or memory location as int32 and then casting this to unsigned type doesn't make any sense at all. If the data isn't signed, then why are you using a signed type in the first place.
Using home-brewed uint32 types instead of stdint.h is poor style.
Nit-picks (minor remarks)
The (int32*) cast should be const qualified.
The loop is needlessly ugly, could be replaced with a for loop:
for(uint32_t i=0; i<2048; i++)
{
dest[i] = source[i];
}
If PolySpace does not know the value ADDR_ARAM_BEGIN it will assume it could be NULL (or any other value value for its type). While you explicitly test for source being NULL, you do not do the same for dest.
Since both source and dest are assigned from linker constants and in normal circumstances neither should be NULL it is unnecessary to explicitly test for NULL in the control flow and an assert() would be preferable - PolySPace recognises assertions, and will apply the constraint in subsequent analysis, but assert() resolves to nothing when NDEBUG is defined (normally in release builds), so does not impose unnecessary overhead:
const uint32_t* source = (const uint32_t*)&ADDR_SWR4_BEGIN ;
uint32_t* dest = (uint32_t*)&ADDR_ARAM_BEGIN;
// PolySpace constraints asserted
assert( source != NULL ) ;
assert( dest != NULL ) ;
for( int i = 0; i < 2048; i++ )
{
dest[i] = source[i] ;
}
An alternative is to provide PolySpace with a "forced-include" (-include option) to provide explicit definitions so that PolySpace will not consider all possible values to be valid in its analysis. That will probably have the effect of speeding analysis also.
the reason why Polyspace is giving a red error here is that source and dest are pointers to a uint32. Indeed, when you write:
source= (int32*)&ADDR_SWR4_BEGIN
you take the address of the variable ADDR_SWR4_BEGIN and assign it to source.
Hence both pointers are pointing to a buffer of 4 bytes only.
It is then not possible to use these pointers like arrays of 2048 elements.
You should also see an orange check on source[i] giving you information on what's happening with the pointer source.
It seems that ADDR_SWR4_BEGIN and ADDR_SWR4_BEGIN are actually containing addresses.
And in this case, the code should be:
source = (uint32*)ADDR_SWR4_BEGIN;
dest = (uint32*)ADDR_ARAM_BEGIN;
If you do this change in the code, the red error disappears.
I am trying to use the C/C++ API of Z3 to parse fixed point constraints in the SMTLib2 format (specifically files produced by SeaHorn). However, my application crashes when parsing the string (I am using the Z3_fixedpoint_from_string method). The Z3 version I'm working with is version 4.5.1 64 bit.
The SMTLib file I try to parse works find with the Z3 binary, which I have compiled from the sources, but it runs into a segmentation fault when calling Z3_fixedpoint_from_string. I narrowed the problem down to the point that I think the issue is related to adding relations to the fixed point context. A simple example that produces a seg fault on my machine is the following:
#include "z3.h"
int main()
{
Z3_context c = Z3_mk_context(Z3_mk_config());
Z3_fixedpoint f = Z3_mk_fixedpoint(c);
Z3_fixedpoint_from_string (c, f, "(declare-rel R ())");
Z3_del_context(c);
}
Running this code with valgrind reports a lot of invalid reads and writes. So, either this is not how the API is supposed to be used, or there is a problem somewhere. Unfortunately, I could not find any examples on how to use the fixed point engine programmatically. However, calling Z3_fixedpoint_from_string (c, f, "(declare-var x Int)"); for instance works just fine.
BTW, where is Z3_del_fixedpoint()?
The fixedpoint object "f" is reference counted. the caller is responsible for taking a reference count immediately after it is created. It is easier to use C++ smart pointers to control this, similar to how we control it for other objects. The C++ API does not have a wrapper for fixedpoint objects so you would have to create your own in the style of other wrappers.
Instead of del_fixedpoint one uses reference counters.
class fixedpoint : public object {
Z3_fixedpoint m_fp;
public:
fixedpoint(context& c):object(c) { mfp = Z3_mk_fixedpoint(c); Z3_fixedpoint_inc_ref(c, m_fp); }
~fixedpoint() { Z3_fixedpoint_dec_ref(ctx(), m_fp); }
operator Z3_fixedpoint() const { return m_fp; }
void from_string(char const* s) {
Z3_fixedpoint_from_string (ctx(), m_fp, s);
}
};
int main()
{
context c;
fixedpoint f(c);
f.from_string("....");
}
Lets say I have an IDL function:
void foo(out Data d);
When I inherit from the generated code the signature will look sth like this:
void foo(IDL::Data_out d);
My first question is, what do I have to pass on the client side? I tried:
IDL::Data_out d;
_servantRef->foo(d);
but this doesn't work because Data_out doesn't have a default constructor. I then tried:
IDL::Data* d;
_servantRef->foo(d);
but now the compiler can't cast from IDL::Data* to IDL::Data_out. The following works but looks overcomplicated and thus not correct:
IDL::Data* d(NULL);
IDL::Data_out do(d);
_servantRef->foo(do);
How do I have to proceed from there? During its execution of foo() the servant will at some point allocate a data object like this:
void Servant::foo(IDL::Data_out d)
{
d = new Data();
}
I will then delete the object after having used it on the client side like this:
IDL::Data* d(NULL);
IDL::Data_out do(d);
_servantRef->foo(do);
delete d;
Is this at least correct by its idea or does this work differently? Would appreciate a little help or pointers to documentation where this is described in a understandable way.
You have to use the _var classes correctly, they are like an auto_ptr and make sure the memory is freed when the _var goes out of scope. The client code should be
IDL::Data_var d;
_servantRef->foo (d.out ());
The servant code should be
void Servant::foo(IDL::Data_out d)
{
d = new Data();
}
The new IDL to C++11 language mapping makes this way easier, there the client code is
IDL::Data d;
_servantRef->foo (d);
The servant code is
void Servant::foo(IDL::Data& d)
{
// modify d
}
See TAOX11 for more details about IDL to C++11.
Johnny Willemsen's answer is good. But you also asked:
Would appreciate a little help or pointers to documentation where this is described in a understandable way.
See the book Advanced CORBA Programming with C++ by Henning & Vinoski.
You can also download a copy of the official IDL to C++ language mapping document here. The IDL to C++11 language mapping is available here.