Warning C4350 says "A non-const reference may only be bound to an lvalue". I think since C4350 is off by default I haven't found much out there on it. I have read this post and it makes sense:
Non-const reference may only be bound to an lvalue
Anyway, I'm asking about it because I'm trying to update VS2008 VC++ projects to VS2012. When I do I get hundreds of C4350 warnings which I have turned on for some legacy reason (that admittedly may need to be reassessed). I have whittled it down to this simple bit of code that can reproduce the warning, but only if I have precompiled headers turned off:
#pragma warning(default:4350)
#include "stdafx.h"
#include <string>
int _tmain(int argc, char* argv[])
{
return 0;
}
If I turn precomiled headers on I get no warning. I also can't get it to happen in VS2008.
Is this a Visual Studio 2012 bug in std:string? Why does the precompiled header change the behavior? How do I fix the problem, as opposed to just ignoring the warning? Thanks!
The warning is (sorry for the poor formatting, it was the best I could figure):
c:\program files (x86)\microsoft visual studio 11.0\vc\include\xstring(689): warning C4350: behavior change: 'std::_Wrap_alloc<_Alloc>::_Wrap_alloc(const std::_Wrap_alloc<_Alloc> &) throw()' called instead of 'std::_Wrap_alloc<_Alloc>::_Wrap_alloc>(_Other &) throw()'
1> with
1> [
1> _Alloc=std::allocator
1> ]
1> c:\program files (x86)\microsoft visual studio 11.0\vc\include\xmemory0(838) : see declaration of 'std::_Wrap_alloc<_Alloc>::_Wrap_alloc'
1> with
1> [
1> _Alloc=std::allocator
1> ]
1> c:\program files (x86)\microsoft visual studio 11.0\vc\include\xmemory0(850) : see declaration of 'std::_Wrap_alloc<_Alloc>::_Wrap_alloc'
1> with
1> [
1> _Alloc=std::allocator
1> ]
1> A non-const reference may only be bound to an lvalue
1> c:\program files (x86)\microsoft visual studio 11.0\vc\include\xstring(688) : while compiling class template member function 'std::_Wrap_alloc<_Alloc> std::_String_alloc<_Al_has_storage,_Alloc_types>::_Getal(void) const'
1> with
1> [
1> _Alloc=std::allocator,
1> _Al_has_storage=false,
1> _Alloc_types=std::_String_base_types>
1> ]
1> c:\program files (x86)\microsoft visual studio 11.0\vc\include\xstring(898) : see reference to function template instantiation 'std::_Wrap_alloc<_Alloc> std::_String_alloc<_Al_has_storage,_Alloc_types>::_Getal(void) const' being compiled
1> with
1> [
1> _Alloc=std::allocator,
1> _Al_has_storage=false,
1> _Alloc_types=std::_String_base_types>
1> ]
1> c:\program files (x86)\microsoft visual studio 11.0\vc\include\xstring(700) : see reference to class template instantiation 'std::_String_alloc<_Al_has_storage,_Alloc_types>' being compiled
1> with
1> [
1> _Al_has_storage=false,
1> _Alloc_types=std::_String_base_types>
1> ]
1> c:\program files (x86)\microsoft visual studio 11.0\vc\include\stdexcept(31) : see reference to class template instantiation 'std::basic_string<_Elem,_Traits,_Alloc>' being compiled
1> with
1> [
1> _Elem=char,
1> _Traits=std::char_traits,
1> _Alloc=std::allocator
1> ]
1>c:\program files (x86)\microsoft visual studio 11.0\vc\include\xstring(689): warning C4350: behavior change: 'std::_Wrap_alloc<_Alloc>::_Wrap_alloc(const std::_Wrap_alloc<_Alloc> &) throw()' called instead of 'std::_Wrap_alloc<_Alloc>::_Wrap_alloc>(_Other &) throw()'
1> with
1> [
1> _Alloc=std::allocator
1> ]
1> c:\program files (x86)\microsoft visual studio 11.0\vc\include\xmemory0(838) : see declaration of 'std::_Wrap_alloc<_Alloc>::_Wrap_alloc'
1> with
1> [
1> _Alloc=std::allocator
1> ]
1> c:\program files (x86)\microsoft visual studio 11.0\vc\include\xmemory0(850) : see declaration of 'std::_Wrap_alloc<_Alloc>::_Wrap_alloc'
1> with
1> [
1> _Alloc=std::allocator
1> ]
1> A non-const reference may only be bound to an lvalue
1> c:\program files (x86)\microsoft visual studio 11.0\vc\include\xstring(688) : while compiling class template member function 'std::_Wrap_alloc<_Alloc> std::_String_alloc<_Al_has_storage,_Alloc_types>::_Getal(void) const'
1> with
1> [
1> _Alloc=std::allocator,
1> _Al_has_storage=false,
1> _Alloc_types=std::_String_base_types>
1> ]
1> c:\program files (x86)\microsoft visual studio 11.0\vc\include\xstring(898) : see reference to function template instantiation 'std::_Wrap_alloc<_Alloc> std::_String_alloc<_Al_has_storage,_Alloc_types>::_Getal(void) const' being compiled
1> with
1> [
1> _Alloc=std::allocator,
1> _Al_has_storage=false,
1> _Alloc_types=std::_String_base_types>
1> ]
1> c:\program files (x86)\microsoft visual studio 11.0\vc\include\xstring(700) : see reference to class template instantiation 'std::_String_alloc<_Al_has_storage,_Alloc_types>' being compiled
1> with
1> [
1> _Al_has_storage=false,
1> _Alloc_types=std::_String_base_types>
1> ]
1> c:\program files (x86)\microsoft visual studio 11.0\vc\include\string(689) : see reference to class template instantiation 'std::basic_string<_Elem,_Traits,_Alloc>' being compiled
1> with
1> [
1> _Elem=wchar_t,
1> _Traits=std::char_traits,
1> _Alloc=std::allocator
1> ]
Microsoft answered my question here:
http://connect.microsoft.com/VisualStudio/feedback/details/767960/warning-c4350-behavior-change-when-including-string-and-no-precompiled-header
Summary:
Is this a Visual Studio 2012 bug in std:string?
-They don't count it as a bug if if cleanly builds at warning level 4, which excludes this warning
Why does the precompiled header change the behavior?
-The compiler ignores everything that comes before a precompiled header, which in this case was my pragma statement that was enabling the warning. Enabling precompiled headers in the property settings caused the pragma to be ignored. Who knew?
How do I fix the problem, as opposed to just ignoring the warning?
-No fix it would seem, just ignore the warning
Related
I am using cython to convert py file to pyd file.
My test code is:
# funcA.py
class Window:
def exec(self):
pass
pass
And the setup.py file is:
#setup.py
from setuptools import setup
from distutils.extension import Extension
from Cython.Distutils import build_ext
ext_modules = [
Extension('funcA', ['funcA.py']),
]
setup(
name='App',
ext_modules=ext_modules,
include_dirs=["App"],
cmdclass={'build_ext': build_ext},
)
After python setup.py build_ext --inplace, a bug is reported:
Error compiling Cython file:
------------------------------------------------------------
...
class Window:
def exec(self):
^
------------------------------------------------------------
funcA.py:4:8: Expected an identifier
building 'funcA' extension
"C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\bin\HostX86\x64\cl.exe" /c /nologo /O2 /W3 /GL /DNDEBUG /MD -IApp -ID:\Anaconda3\envs\work\include -ID:\Anaconda3\envs\work\Includ
e "-IC:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\ATLMFC\include" "-IC:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include" "-IC:\Prog
ram Files (x86)\Windows Kits\10\include\10.0.19041.0\ucrt" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\shared" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\um" "-IC:\Program Files (x
86)\Windows Kits\10\include\10.0.19041.0\winrt" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\cppwinrt" /TcfuncA.c /Fobuild\temp.win-amd64-cpython-39\Release\funcA.obj
funcA.c
funcA.c(1): fatal error C1189: #error: Do not use this file, it is the result of a failed Cython compilation.
error: command 'C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\Community\\VC\\Tools\\MSVC\\14.29.30133\\bin\\HostX86\\x64\\cl.exe' failed with exit code 2
But, if I replace the funcA.py to:
#new funcA.py
class Window:
pass
Everything is OK.
Why exec function would couse this bug?
Any suggestion is appreciated~~~
------------- update --------------------------------
Thanks #DavidW's suggestion.
The solution is adding #cython: language_level=3 on the top of script.
Depending on what Cython version you're using (you don't say...) Cython defaults to Python 2 behaviour. In Python 2 exec was a keyword, so cannot be used as a function name.
Either:
pick a different function name,
put Cython in Python 3-like mode by setting language_level to 3. Bear in mind this may change some other things (e.g. print, the scope of list comprehensions, ...)
Use Cython 3 alpha version where it does default to Python 3 semantics by default.
I am trying to publish a website in VS2019 and it fails with
The command "dotnet bundle" exited with code -2147450730.
I haven't found much on this issue.
The build output window should have detailed information on the error:
Build started...
1>It was not possible to find any compatible framework version
1>The framework 'Microsoft.NETCore.App', version '2.0.0-preview1-002111-00' (x64) was not found.
1> - The following frameworks were found:
1> 6.0.2 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
1>
1>You can resolve the problem by installing the specified framework and/or SDK.
1>
1>The specified framework can be found at:
1> - https://aka.ms/dotnet-core-applaunch?framework=Microsoft.NETCore.App&framework_version=2.0.0-preview1-002111-00&arch=x64&rid=win10-x64
After I installed the missing framework it worked for me: https://aka.ms/dotnet-core-applaunch?framework=Microsoft.NETCore.App&framework_version=2.0.0-preview1-002111-00&arch=x64&rid=win10-x64
I try to cythonize a .py script. It is a PyQt5 gui with a large number of QToolButtons, and a working EventFilter. The c module is built successfully, however, the compilation fails with the following error:
d:\stuff\mapform2a.c(11338) : fatal error C1002: compiler is out of heap space in pass 2
LINK : fatal error LNK1257: code generation failed
error: command 'C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\x86_amd64\link.exe' failed with exit status 1257
The compiler comes from Visual Studio 2019. Python 3.5.5 (yes, old, I know, but I have reasons...).
Is there any way to increase the heap space when trying to "cythonize -i script.py" ?
Cython documentation is really not clear on this (for a non-C-expert at least...)
EDIT
The full log is as follows:
C:\temp\MapForm>python setup.py build_ext --inplace Compiling
MapForm2A.py because it changed. [1/1] Cythonizing MapForm2A.py
C:\Anaconda3\lib\site-packages\Cython\Compiler\Main.py:369:
FutureWarning: Cython directive 'language_level' not set, using 2 for
now (Py2). This will change in a later release! File:
C:\temp\MapForm\MapForm2A.py tree = Parsing.p_module(s, pxd,
full_module_name) running build_ext building 'MapForm2A' extension
creating build creating build\temp.win-amd64-3.5 creating
build\temp.win-amd64-3.5\Release C:\Program Files (x86)\Microsoft
Visual Studio 14.0\VC\BIN\x86_amd64\cl.exe /c /nologo /Ox /W3 /GL
/DNDEBUG /MD -IC:\Anaconda3\include -IC:\Anaconda3\include
"-IC:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE"
"-IC:\Program Files (x86)\Microsoft Visual Studio
14.0\VC\ATLMFC\INCLUDE" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\ucrt" "-IC:\Program Files (x86)\Windows
Kits\10\include\10.0.18362.0\shared" "-IC:\Program Files (x86)\Windows
Kits\10\include\10.0.18362.0\um" "-IC:\Program Files (x86)\Windows
Kits\10\include\10.0.18362.0\winrt" /TcMapForm2A.c
/Fobuild\temp.win-amd64-3.5\Release\MapForm2A.obj MapForm2A.c creating
C:\temp\MapForm\build\lib.win-amd64-3.5 C:\Program Files
(x86)\Microsoft Visual Studio 14.0\VC\BIN\x86_amd64\link.exe /nologo
/INCREMENTAL:NO /LTCG /DLL /MANIFEST:EMBED,ID=2 /MANIFESTUAC:NO
/LIBPATH:C:\Anaconda3\libs /LIBPATH:C:\Anaconda3\PCbuild\amd64
"/LIBPATH:C:\Program Files (x86)\Microsoft Visual Studio
14.0\VC\LIB\amd64" "/LIBPATH:C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\ATLMFC\LIB\amd64" "/LIBPATH:C:\Program Files
(x86)\Windows Kits\10\lib\10.0.18362.0\ucrt\x64" "/LIBPATH:C:\Program
Files (x86)\Windows Kits\10\lib\10.0.18362.0\um\x64"
/EXPORT:PyInit_MapForm2A
build\temp.win-amd64-3.5\Release\MapForm2A.obj
/OUT:build\lib.win-amd64-3.5\MapForm2A.cp35-win_amd64.pyd
/IMPLIB:build\temp.win-amd64-3.5\Release\MapForm2A.cp35-win_amd64.lib
MapForm2A.obj : warning LNK4197: export 'PyInit_MapForm2A' specified
multiple times; using first specification Creating library
build\temp.win-amd64-3.5\Release\MapForm2A.cp35-win_amd64.lib and
object build\temp.win-amd64-3.5\Release\MapForm2A.cp35-win_amd64.exp
Generating code c:\temp\mapform\mapform2a.c(7545) : fatal error C1002:
compiler is out of heap space in pass 2 LINK : fatal error LNK1257:
code generation failed error: command 'C:\Program Files
(x86)\Microsoft Visual Studio 14.0\VC\BIN\x86_amd64\link.exe'
failed with exit status 1257
I can only add that the process gets stuck on the "Generating code" message for about 90 seconds before raising the C1002 exception.
The setup file is rather standard:
from setuptools import setup
from Cython.Build import cythonize
setup(
ext_modules = cythonize("MapForm2A.py")
)
The module is pure PyQt5 (pyuic5 output) with no other dependencies and works fine if interpreted directly with no Cython.
EDIT: SOLUTION (Maybe someone will need it).
Thanks to #DavidW (discussion in the comments below).
Setup.py has to be modified in the following way:
from distutils import _msvccompiler
_msvccompiler.PLAT_TO_VCVARS['win-amd64'] = 'amd64'
from setuptools import setup
from Cython.Build import cythonize
setup(
ext_modules = cythonize("MapForm2A.py"),
)
The first two lines force 64-bit toolchain.
For the purposes of giving a little more explanation to something solved in the comments: the basic problem looks to be that you're compiling something large and complicated and MSVC has run out of memory at the linking step.
Microsoft has a page about this error which suggests a number of options, with the main one being to use a 64-bit compiler. (Note that this is independent of whether you're compiling a 32-bit or 64-bit module - it's merely the choice of compiler executable)
When compiling Python extension modules (especially with setup.py) the compiler setup is typically selected by distutils. Unfortunately, it looks like distutils chooses to force a 32-bit compiler (see https://github.com/python/cpython/blob/e488e300f5c01289c10906c2e53a8e43d6de32d8/Lib/distutils/_msvccompiler.py#L160).
My suggestion was to dig into the distutils internals at the top of setup.py (before any real setup takes place) to override this setting
from distutils import _msvccompiler
_msvccompiler.PLAT_TO_VCVARS['win-amd64'] = 'amd64'
Essentially all you're really doing is passing the option amd64 to the vcvarsall.bat script that microsoft supply to set up their compiler, thus getting a 64-bit compiler to build a 64-bit extension.
I have created a blank project using Visual Studio 2013 update 3 CTP 2 version for Multi Device Hybrid App template. When I run the project for Android platform using Ripple Nexus s and nexus Galaxy, it does not open the chrome . When I press f5 build and deployment gets succeed and after that a message dialog appears saying :
object reference not set to an instance of an object
The output window displays a message that Deployment succeeded. But does not really open the browser window.
I had reinstalled the template twice. Also I had turned my firewall off for public network but I couldn't Ensure Domain, Private, and Public are all checked for “Evented I/O for V8 JavaScript.” .Below is the o/p window.
1>------ Build started: Project: BlankCordovaApp3, Configuration: Debug Android ------
1>C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0 \ TypeScript\Microsoft.TypeScript.targets(95,5): warning :
The TypeScript Compiler was given no files for compilation, so it will skip compiling.
1> C:\BlankCordovaApp3\BlankCordovaApp3>call "C:\Program Files\nodejs\"\nodevars.bat
1> Your environment has been set up for using Node.js 0.10.31 (x64) and npm.
1> ------ Ensuring correct global installation of package from source package directory: C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\Extensions\tjdvfq0n.lk1\packages\vs-mda
1> ------ Build Settings:
1> ------ buildCommand: prepare
1> ------ platform: Android
1> ------ cordovaPlatform: android
1> ------ configuration: Debug
1> ------ cordovaConfiguration: Debug
1> ------ projectName: BlankCordovaApp3
1> ------ projectSourceDir: C:\BlankCordovaApp3\BlankCordovaApp3
1> ------ language: en-US
1> ------ App dir C:\BlankCordovaApp3\BlankCordovaApp3\bld\Debug already exists
1> ------ Platform android already exists
1> ------ Updating plugins
1> ------ Currently installed plugins:
1> ------ Currently installed dependent plugins:
1> ------ Currently configured plugins:
1> ------ Preparing platform: android
1> cordova library for "android" already exists. No need to download. Continuing.
1> Generating config.xml from defaults for platform "android"
1> Calling plugman.prepare for platform "android"
1> Wrote out Android application name to "BlankCordovaApp3"
1> no icon found matching Android typical densities
1> no icon found matching Android typical densities
1> no icon found matching Android typical densities
1> no icon found matching Android typical densities
1> Wrote out Android package name to "io.cordova.BlankCordovaApp3"
2>------ Deploy started: Project: BlankCordovaApp3, Configuration: Debug Android ------
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========
========== Deploy: 1 succeeded, 0 failed, 0 skipped ==========
When this issue occurs, what works is to exit Visual Studio, kill any Chrome processes from the task manager, and reboot the machine. Resuming your work in a new instance of VS should allow you to successfully deploy to Ripple. An earlier post covers the same issue.
Run Visual Studio as an administrator and try again.
I have been working on getting some of the simple Cuda 5.0 samples to work on Windows 7 with CMake. I'm running Windows 7 64-bit and Visual C++ Express 2010.
I had this working the other day and now it fails to compile, and I'm not quite sure why. I generally do my coding in *nix environments so windows development environments aren't a strong area for me.
If anyone can help save me from pulling out more hair it'd be greatly appreciated.
The example is just the simple vectorAdd.cu file that comes with Cuda and a CMakeLists.txt file. In the interest of keeping this posting short I'll hold off on putting the source file up since it's a little long.
Here's my CMakeLists.txt file:
CMAKE_MINIMUM_REQUIRED( VERSION 2.8 )
PROJECT( vectorAdd )
FIND_PACKAGE( CUDA REQUIRED )
CUDA_INCLUDE_DIRECTORIES(${CMAKE_CURRENT_SOURCE_DIR} )
CUDA_ADD_EXECUTABLE( ${CMAKE_PROJECT_NAME} vectorAdd.cu )
When I try to compile, I get this output:
1>------ Build started: Project: ZERO_CHECK, Configuration: Debug Win32 ------
1>Build started 2/10/2013 6:24:59 PM.
1>PrepareForBuild:
1> Creating directory "D:\Code\CPlusPlus\Cuda\example_1\Build\Debug\".
1>InitializeBuildStatus:
1> Creating "Win32\Debug\ZERO_CHECK\ZERO_CHECK.unsuccessfulbuild" because "AlwaysCreate" was specified.
1>CustomBuild:
1> Checking Build System
1> CMake does not need to re-run because D:/Code/CPlusPlus/Cuda/example_1/Build/CMakeFiles/generate.stamp is up-to-date.
1>FinalizeBuildStatus:
1> Deleting file "Win32\Debug\ZERO_CHECK\ZERO_CHECK.unsuccessfulbuild".
1> Touching "Win32\Debug\ZERO_CHECK\ZERO_CHECK.lastbuildstate".
1>
1>Build succeeded.
1>
1>Time Elapsed 00:00:00.07
2>------ Build started: Project: vectorAdd, Configuration: Debug Win32 ------
2>Build started 2/10/2013 6:24:59 PM.
2>InitializeBuildStatus:
2> Creating "vectorAdd.dir\Debug\vectorAdd.unsuccessfulbuild" because "AlwaysCreate" was specified.
2>ComputeCustomBuildOutput:
2> Creating directory "D:\Code\CPlusPlus\Cuda\example_1\Build\CMakeFiles\vectorAdd.dir\Debug\".
2>CustomBuild:
2> Building NVCC (Device) object CMakeFiles/vectorAdd.dir//Debug/vectorAdd_generated_vectorAdd.cu.obj
2>nvcc : fatal error : Could not set up the environment for Microsoft Visual Studio using 'C:/Program Files (x86)/Microsoft Visual Studio 10.0/VC/bin/../../common7/Tools/vsvars32.bat'
2> CMake Error at vectorAdd_generated_vectorAdd.cu.obj.cmake:206 (message):
2> Error generating
2> D:/Code/CPlusPlus/Cuda/example_1/Build/CMakeFiles/vectorAdd.dir//Debug/vectorAdd_generated_vectorAdd.cu.obj
2>
2>
2>
2>Build FAILED.
2>
2>Time Elapsed 00:00:00.29
3>------ Skipped Build: Project: ALL_BUILD, Configuration: Debug Win32 ------
3>Project not selected to build for this solution configuration
========== Build: 1 succeeded, 1 failed, 0 up-to-date, 1 skipped ==========
Anyone have a suggestion? I don't think I changed any settings from the time it worked to the time it stopped working. I've tried rebooting and all that stuff.