I am using C++ Builder XE4 on Windows7 Professional (32bit).
I found the difference in the following code.
String lbl = L"";
String msg1 = String().sprintf(L"[%s]", lbl);
ShowMessage(msg1); // [(null)]
String msg2 = String().sprintf(L"[%s]", lbl.c_str());
ShowMessage(msg2); // []
I expected both of msg1 and msg2 were "[]". But actually, msg1 is "[(null)]".
Is the msg1 correct in terms of language specification? Or is this "undefined" behavior?
Another question is how I should take care of this kind of mistake (letting "lbl" not "lbl.c_str()"). Because both of them shows no error in compiling, I will not notice this kind of error in the compling time.
I hope to know some prevention tips for this kind of mistake if there is any.
C++ Builder 32 bit compiler doesn't warn you about this mistake. All compilers based on LLVM (like bcc64 and gcc) show below error in this case:
cannot pass object of non-trivial type 'String' (aka 'System::UnicodeString') through variadic method; call will abort at runtime
If you compile the source by C++ Builder 64bit (based on LLVM) you will see this error.
Related
When I tried to migrate my project based on apache beam pipelines from python 3.7 to 3.8 the type hint check started to fail at this place:
pcoll = (
wrong_pcoll,
some_pcoll_1,
some_pcoll_2,
some_pcoll_3,
) | beam.Flatten(pipeline=pipeline)
pcoll | beam.CombinePerKey(MyCombineFn()) # << here
with this error:
apache_beam.typehints.decorators.TypeCheckError: Input type hint violation at GroupByKey: expected Tuple[TypeVariable[K], TypeVariable[V]], got Union[TaggedOutput, Tuple[Any, Any], Tuple[Any, _MyType1], Tuple[Any, _MyType2]]
The wrong_pcoll is actually a TaggedOutput because it's received as a tagged output from one on previous ptransforms.
Type hint check fails when the type of wrong_pcoll which is a TaggedOutput as a part of the type of pcoll (which type in correspondence with the exception is Union[TaggedOutput, Tuple[Any, Any], Tuple[Any, _MyType1], Tuple[Any, _MyType2]]) passed to GrouByKey that is used inside of CombinePerKey.
So I have two questions:
Why does it work in python 3.7 and doesn't on 3.8?
How to specify type for a tagged output? I tried to specify the type for the process() method of PTransform that produced that as a union of all output types that it yields, but for some reason for the type hint check has been chose the wrong one. Then I specified strictly the type I need: Tuple[Any, Any] and it has worked. But it's not a way since process() also yields other types, like simple str.
As a workaround, I can pass this wrong_pcoll through a simple beam.Map with lambda x: x and .with_output_types(Tuple[Any, Any]), but it does not seem to be a clear way to fix it.
I investigated similar failures recently.
Beam has some type-inferencing capabilities which rely on opcode analysis of pipeline code. Inferencing is somewhat limited and conservative. For example, when Beam attempts to infer a function's return type and encounters an opcode that it does not know, Beam infers the return type as Any. It is also sensitive to Python minor version.
Python 3.8 removed some opcodes, such as SETUP_LOOP, that Beam didn't handle previously. Therefore, type inference behavior kicked in for some portions of the code where it didn't work before. I've seen pipelines where an increased type inference on Python 3.8 exposed incorrectly-specified hints.
You are running into a bug/limitation in Beam's type inference for multi-output DoFns tracked in https://issues.apache.org/jira/browse/BEAM-4132. There was some progress, but it's not completely addressed. As a workaround you could manually specify the hints. I think beam.Flatten().with_output_types(Tuple[str, Union[_MyType1, _MyType2]]) should work for your case.
In Intellij IDEA, I have a Scala case class expecting Longs as arguments. The arguments passed in are numbers, which intellij interprets as Ints and reports an error on it. The code compiles without errors or warnings, so he compiler (and I) don't care. It's pretty easy to fix by putting a l after the number, but that is cumbersome and does not increase readability. Is there a setting somewhere in Intellij Idea to fix this behavior?
There is an open bug (see also the linked issues):
SCL-7729 Highlight error with implicit conversion of covariant type
Im following a youtube tutorial by Bucky in C programming. Every time i use scanf and enter the input i get an error pop up. i typed these exact same codes from the video tutorial but mine does not work.
HERE'S THE CODE:
int main()
{
int age;
printf("How old are you?\n");
scanf("%d, &age");
if (age>= 18){
printf("You may enter this website!");
}
if(age<18){
printf("nothing to see here!");
}
return 0;
}
It only works after compiling and running. But after i input the age, an error window pops up and says "A problem caused the program to stop working correctly. Windows will close the program and notify you if a solution is available."
I'm sure the codes are correct but What is causing this? Help me please so i can move forward.
You placed quote in incorrect place in scanf:
scanf("%d, &age");
should be:
scanf("%d", &age);
C language is limited in a ways to implement functions with variable numbers of arguments (which scanf is, since it's can read variable number of variables from terminal), so this is why such errors are possible.
Modern compilers will warn you about incorrect scanf usage, e.g. GCC will give a warning:
1.c: In function ‘main’:
1.c:8:1: warning: format ‘%d’ expects a matching ‘int *’ argument [-Wformat=]
scanf("%d, &age");
^
By the way, your example misses
#include <stdio.h>
I'm trying to write an ABL binding for the ØMQ C library, but am crashing the Procedure Editor for my zmq_init function binding. I wrote a binding for zmq_version without issue, so I assume it's not a .dll file problem. Anyway, the C function prototype looks like this:
void *zmq_init (int io_threads);
The ABL code I've written is as follows:
PROCEDURE zmq_init EXTERNAL "libzmq.dll" CDECL:
DEFINE INPUT PARAMETER num_threads AS LONG.
DEFINE RETURN PARAMETER context_ptr AS MEMPTR.
END PROCEDURE.
DEF VAR mContext AS MEMPTR NO-UNDO.
RUN zmq_init(INPUT 0, OUTPUT mContext).
This particular function initializes a "0mq context" (potential problem: it's a thread pool) and returns a pointer to it. Could the error be related to OpenEdge's non-threaded nature, even though I'm calling an external library and requesting 0 threads be allocated in the pool?
Running the code in Procedure Editor makes it crash with a Windows "Progress Client has stopped working" error with Exception code: C0000005 ACCESS_VIOLATION (full stack trace here, although I don't always get a stack trace with info in it).
I've never done Windows C programming, but it looks like what I'd call a Segmentation Fault if I were on Unix using gcc (accessing protected memory). Speaking of which, I'd in fact rather run this code on a Unix machine but apparently Progress only provides evaluation developer OE environments for Windows :(.
I've disabled DEP without success. Is ABL trying to dereference the pointer when it returns from the library or something? Surely there has to be a way to handle signatures with a return value of void* that get malloc'ed in the library call.
I've paged through OpenEdge Development: Programming Interfaces, Tom Bascom's UNIX Shared Libraries PowerPoint, and some other PowerPoint called OpenEdge in an LDAP World that has some code samples but don't see anything obvious that I'm missing.
I'm on OpenEdge 10.2B, Windows 7 64-bit, however using the 32-bit version of OpenEdge as that's my only option for evaluation software. Anyone got a license I could borrow for compiling/running this code on CentOS? :-)
You are missing PERSISTENT keyword when you are declaring your procedures.
Please try the following code:
zmq.p
&SCOPED DLLNAME 'libzmq.so'
PROCEDURE zmq_init EXTERNAL {&DLLNAME} CDECL PERSISTENT:
DEF INPUT PARAMETER NumThreads AS LONG.
DEF RETURN PARAMETER Context AS MEMPTR.
END PROCEDURE.
PROCEDURE zmq_term EXTERNAL {&DLLNAME} CDECL PERSISTENT:
DEF INPUT PARAMETER Context AS MEMPTR.
DEF RETURN PARAMETER ResultStatus AS LONG.
END PROCEDURE.
PROCEDURE zmq_version EXTERNAL {&DLLNAME} CDECL PERSISTENT:
DEF OUTPUT PARAMETER major AS LONG.
DEF OUTPUT PARAMETER minor AS LONG.
DEF OUTPUT PARAMETER patch AS LONG.
END PROCEDURE.
check_zmq.p
DEF VAR Zmq AS HANDLE NO-UNDO.
DEF VAR MajorVersion AS INT NO-UNDO.
DEF VAR MinorVersion AS INT NO-UNDO.
DEF VAR PatchVersion AS INT NO-UNDO.
DEF VAR CallStatus AS INT NO-UNDO.
DEF VAR ZmqContext AS MEMPTR NO-UNDO.
RUN zmq.p PERSISTENT SET Zmq.
RUN zmq_version IN Zmq ( OUTPUT MajorVersion, OUTPUT MinorVersion, OUTPUT PatchVersion ).
MESSAGE MajorVersion MinorVersion PatchVersion.
RUN zmq_init IN Zmq ( 1, OUTPUT ZmqContext ).
RUN zmq_term IN Zmq ( ZmqContext, OUTPUT CallStatus ).
MESSAGE CallStatus.
FINALLY:
IF VALID-HANDLE(Zmq) THEN
DELETE PROCEDURE Zmq.
END FINALLY.
Could the error be related to OpenEdge's non-threaded nature, even though I'm calling an >external library and requesting 0 threads be allocated in the pool?
I ran into the same problem several times (Progress Client has stopped working) while i was working on some c# methods (called via clr bridge) in which I used threads.
Hiding the threads from progress by using some c# library classes(AsyncOperation,AsyncCallback) solved the problem, but most attempts caused the progress runtime to stop.
Related to .net the progress help states "You cannot use System.Threading.Thread, or any derived class — ABL is single-threaded."
I know that calling c# methods via clr bridge is completely different from invoking c libraries but maybe our problems are caused by the single threaded nature of OpenEdge.
I grabbed your code from github and changed the MEMPTR variables to INT64. This allowed it to run without crashing (10.2b05 32-bit on 64-bit Windows 7). Since the memory is being handled by zeromq, I think this is a safe way to handle the issue.
What's the difference between these two?
MsiInstallProduct and Installer.InstallProduct. From what I've read, the only difference is that the first returns an int that will dictate if the installation succeeded or not.
I am currently using DTF (WiX) to call Installer.InstallProduct. The problem is, this function has a return type of void.
Question:
How can I determine if the installation succeeded or not when calling Installer.InstallProduct via DTF?
As you noticed, MsiInstallProduct simply returns error or success with no further information. Installer.InstallProduct returns nothing. DTF returns nothing.
Why the difference? MsiInstallProduct is old school C/C++ where you return error codes. The others are new school where instead you raise exceptions. Your code then catches the exception to know that there was a problem.