recently we planned to upgrade glib library to latest version : 2.64
We have built the library and try to use the same in our build infrastructure. While running build we are getting errors :-
error: 'g_mem_chunk_alloc0' is deprecated
error: 'g_mem_chunk_free' is deprecated
error: 'g_mem_chunk_alloc' is deprecated
error: 'g_atexit' is deprecated
How could we find the replacement of those deprecated functions in newer glib version?
error: 'g_mem_chunk_alloc0' is deprecated
error: 'g_mem_chunk_free' is deprecated
error: 'g_mem_chunk_alloc' is deprecated
The g_mem_chunk_*() APIs were deprecated in 2005 (15 years ago), and all mention of them was removed from the documentation in 2011 (9 years ago).
I don’t think it’s reasonable to keep documentation for deprecated functions around for 15 years (it would cause more confusion than it would solve).
The GSlice API is the replacement for GMemChunk. In particular:
* g_mem_chunk_alloc0() → g_slice_alloc0()
* g_mem_chunk_free() → g_slice_free()
* g_mem_chunk_alloc() → g_slice_alloc()
These won’t be 1:1 replacements for the deprecated APIs, as otherwise the developers at the time could have avoided deprecating those APIs. You will likely have to rework your code.
error: 'g_atexit' is deprecated
The documentation for g_atexit() explains that there is no replacement for it:
The behaviour of atexit() in the context of dynamically loaded modules is not formally specified and varies wildly.
Related
I am working on a project with some of use on Xcode 7.2 and some on 7.3 (including myself). We don't want to force everyone to upgrade to 7.3 (most would also have to update their OS and we are closing in on release date).
If I use #selector() as advised by Xcode for the new syntax anyone running 7.2 is unable to compile the project as they get an error. Using Selector("…") allows the project to compile on all versions but it creates a warning that I would love to suppress (with a TODO next to it for removal once everyone has upgraded).
Is there any way to suppress this warning, or should I just live with it for now as a price of being fast to upgrade?
Update: By adding #objc before the function in question the original warning changes to Use '#selector' instead of explicitly constructing a 'Selector', and it is willing to make the change for me making the code un-compilable on Xcode 7.2 or earlier.
As the issue isn't a deprecated method neither of the two existing answers work in this case (I would use the #avaliable option to continue getting warnings about any other deprecated methods and make case-by-case decisions on each though).
There is a workaround:
#available(iOS, deprecated=10.0)
func _Selector(str: String) -> Selector {
return Selector(str)
}
But you have to use _Selector instead of Selector in your code, And I'm not sure if Apple approves of this, so before submitting to AppStore, I Suggest remove #available(iOS, deprecated=10.0).
Credit of using #available goes to Daniel Thorpe for his answer here
Isn't this working?
On your target Build settings: All
Apple LLVM Warnings - Deprecated fonctions -> NO
Using gcc with -std=c++11
pkg-config libxml++-2.6 --modversion
2.40.1
get lots of warnings like this:
/usr/include/libxml++-2.6/libxml++/parsers/saxparser.h:224:8: warning: 'template class std::auto_ptr' is deprecated [-Wdeprecated-declarations]
I may follow the recommendation and disable this warning but I may miss other warnings in future.
I may try latest libxml++ version 2.91; despite huge minor(lol) version difference it's at most one month younger; I'll build this on older machines where libxml++ will probably be older.
I'll ignore this warning. Would anybody do otherwise ?
You should be safe ignoring the std::auto_ptr warning. Prior to C++11, auto_ptr was a common way to manage memory, because it takes ownership of a pointer. Post C++11 it's recommended to use the new smart pointers that are part of STL (ie std::unique_ptr, std::shared_ptr).
This question has a good discussion on std::auto_ptr and issues that led to it being deprecated. I wouldn't write new code using it, but existing code using auto_ptr should be safe (assuming there aren't bugs to begin with which may or may not be valid).
Well, there is a better-than-average chance that auto_ptr will be removed from C++17. So I would be at least somewhat concerned about relying on software that made use of it.
You could replace your libxml++ version by a version higher or equal than 2.9.1 They fixed the auto_ptr thing and replaced it by unique_ptr. Although you have to install libxml++-2.9.1 by hand by downloading it from:
http://ftp.gnome.org/pub/GNOME/sources/libxml++/
hope it helps.
I've read about Boost.Reflect at http://bytemaster.github.io/boost_reflect/index.html and it seems like exactly what I need. I've downloaded it from https://github.com/bytemaster/boost_reflect and found several incompatibilities with boost 1.55.0 and MSVC2013. (E.g. Boost.Reflect uses the deprecated Boost.Signals, and it uses the "template" qualifier in ways that MSVC2013 treats as errors.)
I could go into details but my initial question is: is this supposed to work? Github says that Boost.Reflect's last upgrade was two years ago. Is it still being maintained? Has it turned into something else?
I'm attempting to use the phpDocumentor web interface to generate documentation for a CodeIgniter project. When I attempt to parse the directory, I get a long list of "Strict standards" errors that all look like this
"Strict standards: Declaration of parserTag::getString() should be compatible with parserStringWithInlineTags::getString($trim = true) in D:\wamp\www\phpdoc\phpDocumentor\DocBlockTags.inc on line 185"
"Strict standards: Declaration of phpDocumentorTParser::packageTagHandler() should be compatible with Parser::packageTagHandler($word) in D:\wamp\www\phpdoc\phpDocumentor\phpDocumentorTParser.inc on line 2945"
"Strict standards: Declaration of phpDocumentor_TutorialHighlightParser::setupStates() should be compatible with Parser::setupStates() in D:\wamp\www\phpdoc\phpDocumentor\TutorialHighlightParser.inc on line 527"
Can anyone tell me what would cause this, or whether it's related to the phpdoc installation or something else?
phpDocumentor 1.x is php4 code, and so running it on newer versions (especially 5.3+) triggers many such notices and warnings. You can lower your error reporting threshold to hide them, but a better option for newer PHP code is to try phpDocumentor 2.x, which is in beta right now.
As for these notices having a negative effect on the docs you generate using 1.x, your docs should be fine. Those particular notices are not failures of any kind.
I'm upgrading a project to use the 10.5 SDK. I'm getting warnings of this form:
warning: 'getAttributeNS::' is
deprecated (declared at
/Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/WebKit.framework/Headers/DOMElement.h:74)
...for getAttributeNS, hasAttributeNS, removeAttributeNS, replaceChild, and getElementsByTagNameNS.
I've looked at the header referenced, and I see that they are indeed marked deprecated via some Macro Magic. I also found some "documentation" on Apple's developer site, but it just lists the interfaces. It doesn't give any guidance on how to use them or what to use instead.
So, any advice on (a) how to figure out what to use instead, and (b) what I should actually use instead, would be very much appreciated.
According to the 10.5 WebKit changes, there are now methods called getAttributeNS:localName: and so on, and a replaceChild:oldChild: method of DOMNode.