Semantic issue: 'mutable' cannot be applied to references
The above is only the latest in a series of errors I've received attempting to get the fuego-iphone project to compile. I'm not certain, but it could be related to the way I compiled boost. The project's README recommends using these instructions for compiling boost into a framework, but I had already done so with the more recent instructions here. Could this CLANG error be related to a boost version somehow?
I admit relative ignorance when it comes to C++.
If anyone has any brilliant suggestions for using the fuego library in general with xcode, I have tried quite a few different things, and am pretty much at wit's end. Thanks!
EDIT: Apologies for any ambiguity here, but I'm not asking about mutable references, so much as showing the latest symptom of this issue. The fuego mailing list has a relevant question about using boost 1.48, and checking now, it's clear that I've compiled 1.49, so I'll recompile an earlier version of boost and see if that fixes it somehow.
The mutable modifier means that a field can be changed from within a const method. But for reference fields, that doesn't make any sense, because references can never be changed in C++.
Related
I starting to look into porting my application from Gtkmm 3.24 to Gtkmm 4.x (not sure which version yet). For now, I am only trying to understand what exactly is deprecated and how much work is needed for planning. One way to ease porting is to look into all deprecated usages in the Gtkmm 3.24 version and update them to the newer flavor before porting. I have found several macros that can help with that:
GTKMM_DISABLE_DEPRECATED
GDKMM_DISABLE_DEPRECATED
GLIBMM_DISABLE_DEPRECATED
GIOMM_DISABLE_DEPRECATED
When I #define these, the compiler throws error when meeting deprecated stuff because they have been disabled. This is nice, once the code is leveled up, to make sure the code stays free of deprecated usages.
In my case, however, the code is still full of deprecations and the compiler stops compilation on the first deprecation it meets. This does not help me much in understanding where the deprecations lie and how much work is needed. I could go about and solve every error, one by one, until there is no more (this is ultimately what I will do) but I can't know ahead how much time this will take.
What I would really like are macros that throw warnings when meeting deprecation, but let the compiler go on about building. This way I could get a list of everything that is deprecated in my codebase and plan work appropriately. I have browsed the Gtkmm documentation and codebase but found nothing.
Do such macros exist and if so, what are they?
The solution was to use
GTKMM_DISABLE_DEPRECATED
GDKMM_DISABLE_DEPRECATED
GLIBMM_DISABLE_DEPRECATED
GIOMM_DISABLE_DEPRECATED
like I did but to use the -k flag with make. From man make:
-k, --keep-going
Continue as much as possible after an error. While the target
that failed, and those that depend on it, cannot be remade, the
other dependencies of these targets can be processed all the same.
Source: Inkscape GTK+ 3 migration wiki page.
So I am converting a project from Unity 4.x to 5.x and there are a number of functions that the Unity compiler is warning me that are no longer supported or are obsolete.
My question is do these functions still work? (even though they are marked as obsolete)
I know at some point they need to be updated to the newer API but for the moment I just need to fix the bugs so that the game works. Are these functions still usable? or are they potentially the source of runtime bugs?
Thanks
All obsolete functions has been replaced with new functions. So should take a backup and update your project. Go to Assets->Run API Updater, if your project in not getting updated automatically. Dont worry unity will take care of most of the things.
Yes, it's still work ! They just only warning it.
But i suggest you should change for better result, Unity 5 will update you code from old project, then you should change it following warning, just replace
using "xxxx" instead.
to the current context.
I would like to generate LLVM IR for a toy language whose compiler is written in Scala.
SLEM seems to be exactly what I need but I can't figure out if it's usable in its current
state. I tried to download the sources but I am unable to compile it.
Anyone used it successfully or knows whether it's usable?
I haven't used SLEM, but checking its commits it seems that the last one was from early 2011, so it's updated to LLVM version 2.9 at the latest. The IR has significantly changed since then, so it would probably not be usable if you try to use it with a newer LLVM.
You can update it, of course, but perhaps a better option would be LLVM-J - Java bindings to LLVM. It's updated to LLVM 3.1, in which the IR is far closer to what it is right now, plus it's basically just a wrapper around LLVM's C API, so updating it yourself should be relatively simple.
While doing some analysis on the usage details for the SquishIt framework, I came across a link as mentioned below:
https://danielsaidi.wordpress.com/tag/squishit/
which describes that SquishIt is having some problems with getting to work with JavaScript closures.
I am currently using the latest version :0.9.3.0 of SquishIt.Mvc. Can anyone help me to know whether this version has still the issues while working with JavaScript closures.
I am not aware of any issues at this time (was not aware of any in 2010 either however). It seems like any issues with closures are probably really issues with the minification library used, or files incorrectly terminated. At some point in the last couple years I think we did start adding semicolons between concatenated files if not present to deal with the latter. If you do find any I would love to hear about them.
I am on Linux(Ubuntu) with OpenCV 2.4 installed. I am try to use Eclipse to create an opencv project. When I build the project, I got collect2: ld returned 1 exit status error which I guess is caused by missing libs. Then I put libraries in this project, but I find every lib has three very similar brothers, like:
libopencv_highgui.so
libopencv_highgui.so.2.4
libopencv_highgui.so.2.4.0
So, which one should I add to project libraries? And what's the different between them?
Best Regards.
libopencv_highgui.so and libopencv_highgui.so.2.4 are probably symbolic links to libopencv_highgui.so.2.4.0.
Libraries frequently do this so that software that needs to link against specific versions can while keeping the generic library also exposed.
This is mainly useful when a program to be linked against a major or minor version of a library. Consider if a legacy application needed to link against version 1.2 of libopencv_highgui. The program couldn't link against libopencv_highgui.so because that's not guaranteed to be the correct version. However, the program could link against libopencv_highgui.so.1.2. libopencv_highgui.so.1.2 may be a symbolic link to libopencv_highgui.so.1.2.3, but that would be ok since the third number usually means a minor bug fix that won't break compatibility.
So this brings up which file you should link against. This really depends. Unless you need to depend on some bug or quirk of a specific minor revision, I would definitely avoid linking against the 2.4.0 one. That ties your program specifically to version 2.4.0. When 2.4.1 gets released (or trickles down your distro's package manager), it probably won't break your program.
If you link against libopencv_highgui.so and then 2.5 is installed as the main lib (and then libopencv_highgui.so links to libopencv_highgui.so.2.5.0), there is a chance that your program will not link correctly since the second number does sometimes mean compatibility changes.
So in short, if it's a personal project, just link to whatever you want. libopencv_highgui.so is probably safe if it's personal. If it's going to be distributed, figure out what versions of the library your code will link properly against and then use the vaguest one possible. For example, if your code works with 2.2, 2.3 and 2.4, you should go ahead and link to libopencv_highgui.so. If it only works specifically with 2.4.0, you should link with libopencv_highgui.so.2.4.0. If it will work with any sub revision of 2.4, you should go with libopencv_highgui.so.2.4.
Basically you have to make a choice about what you think will link properly on the most people's setups.
I think I make some mistake here. What I need is these libraries, But when I add them into project libraries. YOU SHOULD USE THESE NAMES, for the library I mentioned in the question, we should add opencv_highgui in to eclipse libraries dependency but libopencv_highgui.so.2.4. For the future use, I write these stuff here.