Is there an equivalent to isatty() on windows CE? In other words, is there a way to detect in code if stdin/stdout/stderr has been redirected?
You could call GetStdIoPath (it's in coredll.dll - it's not documented in MSDN and I'm not sure if it's in any SDK headers, but you can always manually declare it as extern and the linker will find it).
Here's my C# version - you can easily port it back to C if necessary:
[DllImport("coredll.dll", SetLastError = true)]
public static extern int GetStdioPath(StdIoStream id, StringBuilder pwszBuf, int lpdwLength);
public enum StdIoStream
{
Input = 0,
Output = 1,
ErrorOutput = 2
}
Related
Im trying to get rid of a platform dependent code.
This code gets a string formated by a mask ("%Y-%m-%d %H:%M:%S") and convert it to std::tm struct and a std::time seconds.
I want to get rid of the need of preprocessor dependant blocks, as (imho) there must be a standard way of doing it in both platforms in the same way.
strptime does not exists in windows, std::get_time does not exists(?) on linux (g++ c++11).
Is there any way to make this code crossplatform (windows/linux) without using a factory pattern or preprocessor dependant blocks?
KDATETIME& KDATETIME::operator= (const char* k)
{
std::string smask;
smask = (std::string)this->mask;
std::string sk;
sk=k;
tm.tm_isdst=-1;
#ifdef WINDOWS <<---- THIS BLOCK
std::istringstream ss(sk);
ss >> std::get_time(&tm, smask.c_str());
#else
strptime(sk.c_str(), smask.c_str(), &tm);
#endif <<------
this->time = mktime(&tm); // t is now your desired time_t
[...]
}
I need a C# interface to call some native C++ code via the CLI dialect. The C# interface uses the out attribute specifier in front of the required parameters. That translates to a % tracking reference in C++/CLI.
The method I has the following signature and body (it is calling another native method to do the job):
virtual void __clrcall GetMetrics(unsigned int %width, unsigned int %height, unsigned int %colourDepth, int %left, int %top) sealed
{
mRenderWindow->getMetrics(width, height, colourDepth, left, top);
}
Now the code won't compile because of a few compile time errors (all being related to not being able to convert parameter 1 from 'unsigned int' to 'unsigned int &').
As a modest C++ programmer, to me CLI is looking like Dutch to a German speaker. What can be done to make this wrapper work properly in CLI?
Like it was also suggested in a deleted answer, I did the obvious and used local variables to pass the relevant values around:
virtual void __clrcall GetMetrics(unsigned int %width, unsigned int %height, unsigned int %colourDepth, int %left, int %top) sealed
{
unsigned int w = width, h = height, c = colourDepth;
int l = left, t = top;
mRenderWindow->getMetrics(w, h, c, l, t);
width = w; height = h; colourDepth = c; left = l; top = t;
}
It was a bit obvious since the rather intuitive mechanism of tracked references: they're affected by the garbage collector's work and are not really that static/constant as normal &references when they're prone to be put somewhere else in memory. Thus this is the only way reliable enough to overcome the issue. Thanks to the initial answer.
If your parameters use 'out' on the C# side, you need to define your C++/CLI parameters like this: [Out] unsigned int ^%width
Here's an example:
virtual void __clrcall GetMetrics([Out] unsigned int ^%width)
{
width = gcnew UInt32(42);
}
Then on your C# side, you'll get back 42:
ValueType vt;
var res = cppClass.GetMetrics(out vt);
//vt == 42
In order to use the [Out] parameter on the C++/CLI side you'll need to include:
using namespace System::Runtime::InteropServices;
Hope this helps!
You can use pin_ptr so that 'width' doesn't move when native code changes it. The managed side suffers from pin_ptr, but I don't think you can get around that if you want native code directly access it without 'w'.
virtual void __clrcall GetMetrics(unsigned int %width, unsigned int %height, unsigned int %colourDepth, int %left, int %top) sealed
{
pin_ptr<unsigned int> pw = &width; //do the same for height
mRenderWindow->getMetrics(*pw, h, c, l, t);
}
I am using CUDA 5.0. I noticed that the compiler will allow me to use host-declared int constants within kernels. However, it refuses to compile any kernels that use host-declared float constants. Does anyone know the reason for this seeming discrepancy?
For example, the following code runs just fine as is, but it will not compile if the final line in the kernel is uncommented.
#include <cstdio>
#include <cuda_runtime.h>
static int __constant__ DEV_INT_CONSTANT = 1;
static float __constant__ DEV_FLOAT_CONSTANT = 2.0f;
static int const HST_INT_CONSTANT = 3;
static float const HST_FLOAT_CONSTANT = 4.0f;
__global__ void uselessKernel(float * val)
{
*val = 0.0f;
// Use device int and float constants
*val += DEV_INT_CONSTANT;
*val += DEV_FLOAT_CONSTANT;
// Use host int and float constants
*val += HST_INT_CONSTANT;
//*val += HST_FLOAT_CONSTANT; // won't compile if uncommented
}
int main(void)
{
float * d_val;
cudaMalloc((void **)&d_val, sizeof(float));
uselessKernel<<<1, 1>>>(d_val);
cudaFree(d_val);
}
Adding a const number in the device code is OK, but adding a number stored on the host memory in the device code is NOT.
Every reference of the static const int in your code can be replaced with the value 3 by the compiler/optimizer when the addr of that variable is never referenced. In this case, it is like #define HST_INT_CONSTANT 3, and no host memory is allocated for this variable.
But for float var, the host memory is always allocated even it is of static const float. Since the kernel can not access the host memory directly, your code with static const float won't be compiled.
For C/C++, int can be optimized more aggressively than float.
You code runs when the comment is ON can be seen as a bug of CUDA C I think. The static const int is a host side thing, and should not be accessible to the device directly.
The operator's description on MSDN has a remark:
An exception is only thrown if the value of value requires more bits
than the current platform supports.
while ToInt32's description doesn't so I suppose the title is not entirely correct(for brevity),
a more correct question would be: "Why IntPtr.ToInt32 throws OverflowException in 64 bit mode for values that fit in Int32 and Explicit(IntPtr to Int32) doesn't"
In decompiled IntPtr ToInt32 and the operator look very similar:
public static explicit operator int(IntPtr value)
{
return (int) value.m_value;
}
[ReliabilityContract(Consistency.WillNotCorruptState, Cer.Success)]
public unsafe int ToInt32()
{
return (int) this.m_value;
}
I wonder what makes ToInt32 throw the exception, is it the unsafe keyword?
Your disassembler can't do a proper job here, mscorlib.dll is special. It is not an AnyCPU assembly, Microsoft builds and ships different versions of it, based on the processor architecture. I'd recommend you use the Reference Source, you'll get the original source code. Which looks like this:
[ReliabilityContract(Consistency.WillNotCorruptState, Cer.Success)]
public unsafe int ToInt32() {
#if WIN32
return (int)m_value;
#else
long l = (long)m_value;
return checked((int)l);
#endif
}
It is the checked keyword that provides the OverflowException.
Since coming from a pure C# background I am having a little bit of trouble with some of the Objective C syntax. I am playing around with the Audio Queue and I am trying to set the InputAudioQueue property EnableLevelMetering and get the CurrentLevelMeterDB property. I found a couple examples in Objective C.
Setting the property:
UInt32 enabledLevelMeter = true;
AudioQueueSetProperty(queue,kAudioQueueProperty_EnableLevelMetering,&enabledLevelMeter,sizeof(UInt32));
Getting the value:
AudioQueueLevelMeterState levelMeter;
UInt32 levelMeterSize = sizeof(AudioQueueLevelMeterState);
AudioQueueGetProperty(queue,kAudioQueueProperty_CurrentLevelMeterDB,&levelMeter,&levelMeterSize);
Float32 peakDB = levelMeter.mPeakPower;
Float32 averageDB = levelMeter.mAveragePower;
The API reference for AudioQueue is very minimal. I am not sure what to use for the following values in C#.
public bool SetProperty (AudioQueueProperty property, int dataSize, IntPtr propertyData)
public IntPtr GetProperty (AudioQueueProperty property, out int size)
Could somebody help a me out? Thanks.
Once you have your AudioQueue created (input or output), you can call:
int enabled = queue.GetProperty<int> (AudioQueueProperty.EnableLevelMetering);
Setting it is a little bit more annoying, you have to use:
queue.SetProperty (AudioQueueProperty.EnableLevelMetering, 4, (IntPtr) &enabled);