Apologies if I'm missing something really obvious, but I'm trying to understand how to write a custom front end and back end with Pantheios. (I'm using it from C++, not C.)
I can follow the purposes of the initialisation functions (I think) but I'm unsure about the others: pantheios_be_logEntry, pantheios_fe_getProcessIdentity and pantheios_fe_isSeverityLogged.
In particular, I'm confused about the relationship between a front end and a back end. How do I make them communicate with each other?
Not sure I understand exactly what you don't understand, but maybe that's part of the problem. ;-) So I'll try my best and you let me know whether it's near or not.
pantheios_fe_getProcessIdentity() is called once, when Pantheios is initializing. You need to return a string that identifies the process. (Actually, it identifies the link-unit; a term defined in Imperfect C++, written by Pantheios' creator, Matthew Wilson, which means the scope of link names, i.e. an executable program module or a dynamic library module.)
pantheios_fe_isSeverityLogged() is called whenever a log statement is executed in application code. It returns non-zero to indicate that the statement should be processed and sent to the output (via the back-end). If it returns zero, no processing occurs. FWIU, this is the main reason why Pantheios is so fast.
pantheios_be_logEntry() is called whenever a log statement is to be sent for output, when pantheios_fe_isSeverityLogged() has returned non-zero and the Pantheios core has processed the statement (forming all the arguments in your code into a single string). It sends the statement string to wherever it should go. For example, the be.fprintf back-end prints it to the console using fprint().
Once you grok these aspects, the second part of your question is where it gets interesting. When your front-end and back-end are initialized they get to create some context (e.g. a C++ object) that the Pantheios core holds for them, and gives them back each time it calls a front/back end API function. When you're customizing both, you can have them communicate via some shared context that they both know about, but which the Pantheios core does not (and should not) know about, beyond having an opaque handle (void*) to it.
HTH
Related
There's an app that uses TLS callbacks to remap its memory using (NtCreateSection/NtUnmapViewOfSection/NtMapViewOfSection) using the SEC_NO_CHANGE flag.
Is there any way to hook NtCreateSection before the target app use it on its TLS callback?
You could use API Monitor to check if it is really that function call and if I understand you correctly you want to modify its invocation. API Monitor allows you to modify the parameters on the fly. If just "patching" the value when the application accesses the api is enough you could than use x64dbg to craft a persistent binary patch for your application. But this requires you to at least know or get familiar with basic x64/x86 assembler.
I have no idea what you're trying to achieve exactly but if you're trying to execute setup code before the main() function is called (to setup hooks), you could use the constructor on a static object. You would basically construct an object before your main program starts.
// In a .cpp file (do not put in a header as that would create multiple static objects!)
class StaticIntitializer {
StaticIntitializer(){
std::cout << "This will run before your main function...\n";
/* This is where you would setup all your hooks */
}
};
static StaticInitializer staticInitializer;
Beware though, as any object constructed this way might get constructed in any order depending on compilers, files order, etc. Also, some things might not be initialized yet and you might not be able to achieve what you want to setup.
That might be a good starting point, but as I said, I'm not sure exactly what you're trying to achieve here, so good luck and I hope it helps a little.
I've just started programming and I've come to hear the standard beginner's definition of "the use of the return value in main" a lot, but it does not get to the point I am trying to understand. So, yes a return value 0 for 'int main' for example signifies that the programme running was successful and since main is of int datatype, 0 reflects this.
BUT what is the point of this? Won't the computer already know that the code was successful or not? Surely, we could write a flawed code and then return 0, and by that logic, we (the programmers) are saying this code is correct but the compiler actually executes the programme and if it's wrong/flawed it simply cannot operate on it.
Please use explanations that a beginner could understand.
The return code of your program ain't about crashing, its about a functional kind of failure.
For example, the program grep defines exit/failure code 0 as successfully found and 1 as not found. While value 2 gets used for invalid input.
Within scripting, this can be used for some automated logic without the user needing a user to interpret the results.
As you are a beginner, I would recommend to always return zero as you are focusing on how to learn the language. Looking into how applications can connect to each other via exit codes is adding unneeded distraction/complexity.
A program can fail, because some expectations are not met.
For example, a program which count the number of lines in files passed as arguments to main would fail when one of the arguments is not a valid file name, or if, for some reasons, that file could not be opened. And if you code such a program, you'll need to explicitly add some program logic (that is, several or many source code lines) for that. A good programmer don't allow his program to crash (even with wrong or missing input or arguments).
A simple program which copies a source file into a destination requires two arguments. If main is not given two arguments, it should fail. If the first argument does not name a valid and accessible file, the program should also fail. If the copy could not be achieved because some disk is full, that program should also fail.
The return from main is, in practice, not some arbitrary integer. On Linux and many POSIX systems, it should be some integer between 0 and 255 (with 0 meaning "successful execution", and other exit values are for failures). See exit(3) & waitpid(2) for more.
By some convention (which you need to document) the failure codes (in practice there are few of them, usually less than a dozen and quite often 0 -named EXIT_SUCCESS- on success and 1 -named EXIT_FAILURE- on failure) could tell about the failure reason. See for examples the documentation of tar(1), coreutils programs, grep(1), etc.
BSD unixes define some conventions in sysexits (but Linux programs generally don't use that).
Shell scripts can easily test and handle the exit code.
Read also about the Unix philosophy. Successful command-line programs (e.g. cp(1)) could often be silent. Error messages would go (by convention) to stderr.
As you would learn more about C programming, you'll understand that conventions matter a big lot (and it is important to document them). Study also the source code of some existing free software programs, e.g. on github.
Remember that you don't write code mostly for the computer, but also -and mostly- for the person (perhaps you in a few months, perhaps some future developer working at your company, when you'll be a professional developer) which would have to improve your code....
The return value from main indicates if something worked in a "business" sense, not in a "technical" sense. If the program has a technical flaw, main probably won't return at all, as the program will probably have crashed, or the return value will be meaningless, due to undefined behaviour.
The return value is used in things like search programs to indicate if something the program was interested in was found or not. The computer can't know what to return in these sorts of cases, as it has no understanding of the semantics of the program.
The return value of main, which becomes the exit code of the process once it's done running, is not related to whether the code is correct C++, but whether it has executed correctly from the point of view of its semantics (its business logic, let's say).
While the program exists as C++ source code, returning from main is an instruction like any other. Having return 0; in main will not affect whether your program is a valid C++ program, and will not fix e.g. syntax errors. While being compiled, it's totally irrelevant w.r.t. correctness.
The return value of main comes into play when the compiled program actually runs (already in binary form).
That is, when you're executing e.g. gcc ... -o myapp, the return value of main does not come into play (indeed, it doesn't even exist). But when you're then executing ./myapp, its process exit code (which is used by e.g. shell) is what gets set by the return value of main.
For example, the unix if command tests whether its argument returned 0 or non-0:
if ./myapp; then
echo "Success"
fi
Whether the above shell script echoes Success or not depends on whether the process exit code of myapp was 0 or not, in other words, whether its main function returned 0 or not.
The Windows-world equivalent of such a check would be:
myapp.exe
if errorlevel 1 goto bad
echo "Success"
bad:
One common convention is to have a process exit code of 0 on success, 1 when the program couldn't complete its task (e.g. it was asked to remove a file which doesn't exist), and 2 when it was invoked incorrectly (e.g. it was given a command-line option it doesn't understand). These are the values main returns.
I would really appreciate your inputs on moving from a YieldTermStructure pointer to that of adding a spread as below::
boost::shared_ptr<YieldTermStructure> depoFutSwapTermStructure(new PiecewiseYieldCurve<Discount,
LogLinear>(settlementDate, depoFutSwapInstruments_New, termStructureDayCounter, 1.0e-15));
I tried adding a spread of 50 bps as below...
double OC_Spread(0.50 / 100);
Rate OCSQuote = OC_Spread;
boost::shared_ptr<Quote> OCS_Handler(new SimpleQuote(OCSQuote));
I then proceed to create a zerospreaded object as below:
ZeroSpreadedTermStructure Z_Spread(Handle<YieldTermStructure>(*depoFutSwapTermStructure), Handle<Quote>(OCS_Handler));
But now I am stuck as the code repeatedly breaks down if I go on ahead to do anything like
Z_Spread.zeroYieldImpl;
What is the issue with above code. I have tried several flavors of above approach and failed on all the fronts.
Also is there a native way of calling directly the discount function just like as I do now with the TermStructure object prior to adding the spread currently as below???
depoFutSwapTermStructure->discount(*it)
I'm afraid you got your interfaces a bit mixed up. The zeroYieldImpl method you're trying to call on your ZeroSpreadedTermStructure is protected, so you can't use it from your code (at least, that's how I'm guessing your code breaks, since you're not reporting the error you get).
The way you interact with the curve you created is through the public YieldTermStructure interface that it inherits; that includes the discount method that you want to call, as well as methods such as zeroRate or forwardRate.
Again, it's hard to say why your call to discount fails precisely, since you're not quoting the error and you're not saying what *it is in the call. From the initialization you do report, and from the call you wrote, I'm guessing that you might have instantiated a ZeroSpreadedTermStructure object but you're trying to use it with the -> syntax as if it were a pointer. If that's the case, calling Z_Spread.discount(*it) should work instead (assuming *it resolves to a number).
If that's not the problem, I'm afraid you'll have to add a few more details to your question.
Finally, for a more general treatment of term structures in QuantLib, you can read here and here.
I seem to have an odd problem that every time i try to increment an integer that tracks the outgoing networking requests(the response requests will match that int so we can pair up response data). Well every time I try to increment the console will "block" and freeze at the incremntation? Is there any reason why it might do this? Its just a normal tracker_id += 1 code shouldn't be blocking and im usually am never noobish at these things.
Sometimes you may get the impression that the debugger is on one line while indeed the code is stopped at the istruction before or after.
If tracker_id is a simple variable (e.g. int, long) and not a class instance then there is no way that tracker_id += 1 is blocking. It's just impossible.
Note also that the compilers are becoming more and more liberal on how they translate source code to machine code, so be sure to compile with all optimizations disabled if you want to be able to track source code and variables correctly.
I had to classes in my main class, the first class is a simple networking class i created to easily call from an API (the Bitcoin JSON-RPC api so i could call just coin_server->getbalance()) the issue was that both classes were located in the main class and apparently the bitcoin class would be destroyed before it was set inside the game server class. There for it would explain why when i tried to call coin apis functions it would crash.
I'm writing a C shared library for internal use (I'll be dlopen()'ing it to a c++ application, if that matters). The shared library loads (amongst other things) some java code through a JNI module, which means all manners of nightmare error modes can come out of the JVM that I need to handle intelligently in the application. Additionally, this library needs to be re-entrant. Is there in idiom for passing error strings back in this case, or am I stuck mapping errors to integers and using printfs to debug things?
Thanks!
My approach to the problem would be a little different from everyone else's. They're not wrong, it's just that I've had to wrestle with a different aspect of this problem.
A C API needs to provide numeric error codes, so that the code using the API can take sensible measures to recover from errors when appropriate, and pass them along when not. The errno.h codes demonstrate a good categorization of errors; in fact, if you can reuse those codes (or just pass them along, e.g. if all your errors come ultimately from system calls), do so.
Do not copy errno itself. If possible, return error codes directly from functions that can fail. If that is not possible, have a GetLastError() method on your state object. You have a state object, yes?
If you have to invent your own codes (the errno.h codes don't cut it), provide a function analogous to strerror, that converts these codes to human-readable strings.
It may or may not be appropriate to translate these strings. If they're meant to be read only by developers, don't bother. But if you need to show them to the end user, then yeah, you need to translate them.
The untranslated version of these strings should indeed be just string constants, so you have no allocation headaches. However, do not waste time and effort coding your own translation infrastructure. Use GNU gettext.
If your code is layered on top of another piece of code, it is vital that you provide direct access to all the error information and relevant context information that that code produces, and you make it easy for developers against your code to wrap up all that information in an error message for the end user.
For instance, if your library produces error codes of its own devising as a direct consequence of failing system calls, your state object needs methods that return the errno value observed immediately after the system call that failed, the name of the file involved (if any), and ideally also the name of the system call itself. People get this wrong waaay too often -- for instance, SQLite, otherwise a well designed API, does not expose the errno value or the name of the file, which makes it infuriatingly hard to distinguish "the file permissions on the database are wrong" from "you have a bug in your code".
EDIT: Addendum: common mistakes in this area include:
Contorting your API (e.g. with use of out-parameters) so that functions that would naturally return some other value can return an error code.
Not exposing enough detail for callers to be able to produce an error message that allows a knowledgeable human to fix the problem. (This knowledgeable human may not be the end user. It may be that your error messages wind up in server log files or crash reports for developers' eyes only.)
Exposing too many different fine distinctions among errors. If your callers will never plausibly do different things in response to two different error codes, they should be the same code.
Providing more than one success code. This is asking for subtle bugs.
Also, think very carefully about which APIs ought to be allowed to fail. Here are some things that should never fail:
Read-only data accessors, especially those that return scalar quantities, most especially those that return Booleans.
Destructors, in the most general sense. (This is a classic mistake in the UNIX kernel API: close and munmap should not be able to fail. Thankfully, at least _exit can't.)
There is a strong case that you should immediately call abort if malloc fails rather than trying to propagate it to your caller. (This is not true in C++ thanks to exceptions and RAII -- if you are so lucky as to be working on a C++ project that uses both of those properly.)
In closing: for an example of how to do just about everything wrong, look no further than XPCOM.
You return pointers to static const char [] objects. This is always the correct way to handle error strings. If you need them localized, you return pointers to read-only memory-mapped localization strings.
In C, if you don't have internationalization (I18N) or localization (L10N) to worry about, then pointers to constant data is a good way to supply error message strings. However, you often find that the error messages need some supporting information (such as the name of the file that could not be opened), which cannot really be handled by constant data.
With I18N/L10N to worry about, I'd recommend storing the fixed message strings for each language in an appropriately formatted file, and then using mmap() to 'read' the file into memory before you fork any threads. The area so mapped should then be treated as read-only (use PROT_READ in the call to mmap()).
This avoids complicated issues of memory management and avoids memory leaks.
Consider whether to provide a function that can be called to get the latest error. It can have a prototype such as:
int get_error(int errnum, char *buffer, size_t buflen);
I'm assuming that the error number is returned by some other function call; the library function then consults any threadsafe memory it has about the current thread and the last error condition returned to that thread, and formats an appropriate error message (possibly truncated) into the given buffer.
With C++, you can return (a reference to) a standard String from the error reporting mechanism; this means you can format the string to include the file name or other dynamic attributes. The code that collects the information will be responsible for releasing the string, which isn't (shouldn't be) a problem because of the destructors that C++ has. You might still want to use mmap() to load the format strings for the messags.
You do need to be careful about the files you load and, in particular, any strings used as format strings. (Also, if you are dealing with I18N/L10N, you need to worry about whether to use the 'n$ notation to allow for argument reordering; and you have to worry about different rules for different cultures/languages about the order in which the words of a sentence are presented.)
I guess you could use PWideChars, as Windows does. Its thread safe. What you need is that the calling app creates a PwideChar that the Dll will use to set an error. Then, the callling app needs to read that PWideChar and free its memory.
R. has a good answer (use static const char []), but if you are going to have various spoken languages, I like to use an Enum to define the error codes. That is better than some #define of a bunch of names to an int value.
return integers, don't set some global variable (like errno— even if it is potentially TLSed by an implementation); aking to Linux kernel's style of return -ENOENT;.
have a function similar to strerror that takes such an integer and returns a pointer to a const string. This function can transparently do I18N if needed, too, as gettext-returnable strings also remain constant over the lifetime of the translation database.
If you need to provide non-static error messages, then I recommend returning strings like this: error_code_t function(, char** err_msg). Then provide a function to free the error message: void free_error_message(char* err_msg). This way you hide how the error strings are allocated and freed. This is of course only worth implementing of your error strings are dynamic in nature, meaning that they convey more than just a translation of error codes.
Please havy oversight with mu formatting. I'm writing this on a cell phone...