So I'm doing this DirectX 11 project and had to use ...array<T>^ arr from the System header and I had to switch my Common Language RunTime Support settings to /clr. After fiddling with the other setting to get the project to compile I seem to have messed something up ,because now I cant use breakpoints and all the objects I have seem to not exist I dont know how else to put it. Please help.
Unless you need to work with .NET types, I'd recommend not using /CLR. Instead of using array<T>^, you can just use std::vector<T> and eliminate the dependency on the common language runtime.
Related
Since upgrading to Gradle 3.3 I'm having trouble building my code due to missing-translation errors:
Error: xxx is not translated in "af" (Afrikaans), "am" (Amharic), "ar" (Arabic), "az" (Azerbaijani), "az-AZ" (Azerbaijani: Azerbaijan), "be" (Belarusian), "bg" (Bulgarian), "ca" (Catalan), [...], "zh-TW" (Chinese: Taiwan), "zu" (Zulu) [MissingTranslation]
The majority of the reported languages are those supported by a 3rd-party module included in my project, and it now seems to define the supported languages for the entire project, giving me this kind of error for all strings that are not translated into above languages. Before upgrading to Gradle 3.3 this was not causing any problems.
I considered the following solutions:
Remove surplus translations from other modules. I want to avoid that because those modules are external and needlessly altering them would really hurt maintainability of my project.
Disable the "incomplete translation" Lint inspection - the most common suggestion for similar questions on SO. This is sub-optimal because I want to be made aware of translations that are missing in my code (working so far). Besides that, disabling the check does not get rid of the error.
Define the supported configurations in build.gradle as described in this answer. I like this option (specifying languages instead of relying on translations available in the modules), but it also does something strange: I'm getting missing-translation errors for strings that are marked translatable = false.
For now, I'm downgrading again to the previous Gradle version. But what is the best apporach for fixing these build errors?
Hoping that there might have been corrections since I posted this question a few months ago, I checked the situation.
It seems that the issues were introduced with the Gradle plugin 2.3.0 and not Gradle 3.3 itself as I suggested in the question. Downgrading the plugin avoids the errors but can hardly be a long-term solution.
I found that option 3 in the question is the best way to handle it: add this to the app's build.gradle:
android {
defaultConfig {
...
resConfigs "en", "fr"
}
}
This is described in Googles documentation and, as mentioned, also in this answer. It removes all unnecessary resources - and the warnings/errors along with them.
Quoting the documentation:
The Gradle resource shrinker removes only resources that are not referenced by your app code, which means it will not remove alternative resources for different device configurations. If necessary, you can use the Android Gradle plugin's resConfigs property to remove alternative resource files that your app does not need.
For example, if you are using a library that includes language
resources (such as AppCompat or Google Play Services), then your APK
includes all translated language strings for the messages in those
libraries whether the rest of your app is translated to the same
languages or not. If you'd like to keep only the languages that your
app officially supports, you can specify those languages using the
resConfig property. Any resources for languages not specified are
removed.
The "false positives" (missing translation error for a non-translatable string) I got were for strings that were defined in more than one module. Renaming the strings or providing translations for them solved the problem. This, too, seems to be introduced with Gradle plugin 2.3.0.
In build.gradle add below code
lintOptions {
disable 'MissingTranslation'
}
I have a new project where I cannot use boost::format. I get a compiler error complaining that boost's override of a virtual function, ~basic_altstringbuf, lacks a "throw()". Even the most trivial attempt to use boost::format does that.
I have other projects where it works fine. I have verified that the new project uses the same include-paths for boost, and for the VC++ includes. All the projects have "Enable C++ Exceptions" set to Yes. The only explanation I can come up with is that the projects that work have some #DEFINE or some setting that disables those vile exception specs in the std:: include-files. But I have no idea what or where it might be. Any ideas?
Error 1 error C2694: 'boost::io::basic_altstringbuf::~basic_altstringbuf(void)': overriding virtual function has less restrictive exception specification than base class virtual member function 'std::basic_streambuf<_Elem,_Traits>::~basic_streambuf(void) throw()
EDIT: Corollary question: Is there a Properties-item in VS++ 2012 that will cause the std:: header files to be included without exception-specs? - short of turning off exceptions, that is?
At the request of the original owner of the green check-mark, I am submitting this summary.
The bugs are on the Microsoft side, in header-files for C++ standard library interfaces, and in the VC++ compiler when "Disable Language Extensions" is NOT set. The header files contain exception-specifications that the standard does not call for. When "language extensions" are not enabled, the compiler accepts invalid code. I have filed a bug report.
Boost could work around the problem in this specific case by adding seven characters to a nested include-file, i.e. "throw()" at line 65 in alt_sstream_impl.hpp. I filed a report with boost also, although I made it clear that the bug is not in their code. I am just suggesting a workaround.
All the tedious details are in the two reports linked above.
Check the preprocessor defines.
You might turn on and inspect verbose logging to see the exact flags that are passed to cl.exe
You could keep the preprocessed source and compare the version from the old (working) project with the new (failing) project.
My gut says, something else is being #defined/passed using -D in the old project that is not being defined in the new project, of differently (think of WINVER type macros)
See new answer posted: VC++ 2012 and Boost incompatibility - `throw()` specifications in library headers
EDIT by OP, Jive Dadson - It turned out to be /Za, which enables/disables "Microsoft language extensions." It is the contention of Visual Studio that the C++ standard requires that a program shall not compile if it has a virtual function override that is less restrictive in the "throw()" category than the function it overrides. Boost has a class that derives from basic_streambuf, and has a virtual destructor that lacks "throw()". The original destructor has that evil festoon. My new project will compile boost::format if I turn MS language extensions ON.
So the question becomes, who is wrong, and how? Is it standard-complying to put throw() on that destructor or not? Is the desired behavior (desired by me, that is) actually an "extension"? I seem to recall that MS considered some standard C++11 features to be "extensions," but I am not sure I remember correctly. Anyway, I will leave it to the boosters to decide, if they are interested. https://svn.boost.org/trac/boost/ticket/7477
I have a game which uses std::wstring as its basic string type in thousand of places as well as doing operations with wchar_t and its functions: wcsicmp() wcslen() vsprintf(), etc.
The problem is wstring is not supported in R5c (latest ndk at the time of this writting).
I can't change the code to use std::string because of internationalization and I would be breaking the game engine which is used by many games ...
Which options do I have?
1 - Replace string and wstring with my own string classes
This would give me better platform independency, but it is ridiculous to reimplement the wheel.
I've already started with a COW implementation of strings. I need it to be COW because I use them as keys in hash_maps.
This is of course lots of work and error prone ... but it seems it is something I can do.
2 - Try to fix the NDK recompiling the STLPort with my own implementations of the wide char string functions of the C standart library (wcslen, mbstowcs ... )
This would be the preferable way ... but I have no idea how to do it :(
How do I replace a function (lets say wcslen) in the libstdc++.a or libstlport_static.a? (not sure where they are :()
And as well I'm not sure which functions I need to reimplement, I know wcslen is not working so I guess they should be all ...
3 - Do you have any other idea?
I can't wait for an official fix for this and I will have to go with option #1 if I can't realize how to do #2.
I've read somewhere that if you target 2.3 you can use wstrings, but I ought to target Android 2.1.
PS: Forgot to say I need to use STL of course, but no RTTI and I can live without exceptions.
Thanks in advance!
Try out CrystaX's NDK. It has had stl support long before the official google one. The current version (r5), which is based off the of the official ndk r5, is still beta 3, but it does have wchar_t support.
http://www.crystax.net/android/ndk-r5.php
I'm suffering from the same problem as you, but my only other thought is to load the strings via the JNI (as jstring* in native land), then convert them to UTF characters as necessary. Take a look at the available JNI string functions here:
http://download.oracle.com/javase/1.5.0/docs/guide/jni/spec/functions.html#string_operations
Qt provides an excellent copy-on-write, international-friendly string implementation, QString, that is LGPLed.
You could, in theory extract it from the Qt source and use it in your own project. You will find the QString implementation in src/corelib/tools/qstring.h and .cpp in a Qt source download. You would also need the QChar, QByteArray, QAtomic, and QNamespace includes/classes (all under the corelib folder,) and you should define QT_NO_STL_WCHAR when compiling. (For this I would compile by hand or using my own script/Makefile.) Not simple, but once you get it up and running your life will be a lot simpler. It's better than reinventing the wheel, because it comes with loads of convenience functions and features.
Rather than stripping out just QString, you could also just use the QtCore module as a whole. See the android-lighthouse project for a Qt port to Android. (Also, it might be better to get your sources from there than from the above "vanilla" link, regardless of what you do.)
I am trying to build an old version of an application which consists of VC++ projects that were written in Visual Studio 2003.
My OS is Windows 7 Enterprise (64-bit).
When I try and build the solution I get the following errors:
error C4772: #import referenced a type from a missing type library; '__missing_type__' used as a placeholder
fatal error C1084: Cannot read type library file: 'Smegui.tlb': Error loading type library/DLL.
They both complain about the following import statement:
#import "Smegui.tlb" no_implementation
This is not a case of the file path being incorrect as renaming the Smegui.tlb file causes the compiler to throw another error saying it cannot find the library.
Smegui is from another application that this one depends on. I thought perhaps I was missing a dll but there is no such thing as Smegui.dll.
All I know about .tlb files is that they are a type library and you can create them from an assembly using tlbexp.exe or regasm.exe (the later also registers the assembly with COM)
There is also an Apache Ant build script which uses a custom task to invoke devenv.com to build the projects. This is the same script that the build server originally used to build the application. It gives me the same errors when I try and run it.
The strangest thing about this is that I knew it ought to work seeing as it is all freshly checked out from subversion. I tried many different combinations of admin vs user elevation, VS vs Ant build, cleaning, release.
I have got it to build successfully about 5 times but the build seems to be non-deterministic.
If anyone can shed some light on how this tlb stuff even works or what this error might mean I would greatly appreciate it.
I found a far more reliable solution: open the tlb with oleview.exe and then close it.
Not sure what this actually does but it works every time.
I think oleview is actually one of the samples included with Visual Studio but I haven't had the time to debug it and see what it is doing.
I ran into this error because one type library was trying to load a dependent type library, which it could not find. Even though the dependent type library was in the same directory, and even though that directory was in the searchable path, the compiler would error loading the first type library, but not mention the dependent type library in the error.
To find the pseudo-missing type library, I ran Process Monitor (procman64.exe) during the compile. This showed that after the reported type library had successfully loaded, a dependent type library could not be found. It even showed all of the places that it was looking for the dependent type library, none of which were where it should have been looking (e.g.: ).
The fix was to add a <PreBuildEvent> to the project to copy the dependent .tlb file to one of the directories that was actually being searched.
<PreBuildEvent>
<Command>copy /Y ..\Lib\Interop\CWSpeechRecLib.tlb .\</Command>
</PreBuildEvent>
http://msdn.microsoft.com/en-us/library/sce74ah7%28VS.71%29.aspx
smegui.tlb is referencing some other tlb that the compiler can't find. If you have the .idl for smegui you might be able to figure out what the other is. I suspect the missing tlb is something that original build machine had registered but that your machine doesn't have registered.
A type library is a binary description of a set of interfaces, coclasses and enums. They're usually generated for COM components, in the case of tlbexp and regasm the tlb is created from the assembly metadata. For native COM components they are usually generated from an idl (Interface Description Language) file by the midl tool.
Edit:
I just noticed you're on x64 Windows. Are you building the project with a new version of Visual Studio? If so, are you targeting x86 or x64? If the latter, it may simply be a 32bit component that the compiler can't find (or less likely, a x64 component the x86 compiler can't find if you are targeting x86), for WOW64 the registry is virtualized for x86 vs. x64 applications.
Well I finally found out why I managed to get it to build sometimes and not others... sort of.
So long as I ran the build script with elevated administrator permissions and let that get as far as it could until that error occurred, then run the build script again as a protected administrator succeeded. Those steps must be done in that exact order with no other steps in between. If I try build in Visual Studio it does not work (although I did get it to succeed once). Probably some kind of virtualisation issue although it still doesn't quite make sense.
Well I don't need help on this any more and I know it's probably impossible to fully answer this question without knowing exactly what the build is doing. However if anyone does have any more thoughts I would happily receive them.
Cheers,
Steiny
When including "sqlite3.c" into my project, I get lots of compiler errors:
error C2027: use of undefined type "_ht" d:\...\sqlite3.c line 19556
...
fatal error C1003: Errors in the program are too numerous to allow recovery. The compiler must terminate.
When inlcuding "sqlite3.c" into an empty test project, I have no problems. I compared project settings and there are no big differences between the two projects.
How can I troubleshoot this problem? Is there anyone who had the same issue?
It looks like you're not including all its header files (or maybe you're trying to build C as C++). Don't Do That. Better yet, build it into a library (or use someone else's build) and just include the built version in your project.
Right click the sqlite3.c file in your project and select Properties. Go to
C/C++ -> Advanced -> Compile As => "Compile as C Code (/TC)"
This solves the issue. Make sure to set that under all of your Configurations and Platforms.
I ran into the same issue. I'm creating a plugin and so compiling in sqlite rather than having to distribute an additional DLL is beneficial, and this is less work than creating an additional project to build a static lib.