Hallo Java fans, I have to learn Java quick and need a book! Java for C++ veterans or something like that. ~~~~~~~ <;,>< ~~~~~~~~~~~

(UK) Johnson's 1755 dictionary used the -our spelling for all words still so spelt in Britain (US) Webster's 1828 dictionary featured only -or //en.wikipedia.org/wiki/American_and_British_English_spelling_differences#Historical_origins Neither are wrong.

~~~~~~~~~~~~~~~~ <;,>< ~~~~~~~~~~~~~~~~~~~~~~~

where do live? I never saw an awerty keyboard. German ones have qwertz, damn nuisance.

------------------<;,><-------------------

To irritate them I ask what they mean by carbon, and whether they know what carbon dioxide is. Then I can go onto the ban-sodium-chloride-because-chlorine-is-bad campaign. If I meet a real fundy greenie I can try and get them excited about banning H2O. You can drown in H2O.

------------------<;,><-------------------

Well, boo to you, you misogynists. I drove in in driving snow behind some old guy in a hat - they're the worst - crawling along and braking at every corner. Before that I cleared the 15 cm of climate change off the garden path. Quite normal for November, what are they all whingeing about? Just glad I got the menfolk to carry in plenty of logs at the weekend. But I confess I came in the car and not on the scooter, what a chicken...

------------------<;,><-------------------

Have you thought about asking the Huffington Post if you could blog with them? You would fit right in...

------------------<;,><-------------------

I know it was along time ago, but in 1962, when men were men and snow was several feet deep, my Mum went into labour with my youngest sister while ill with pneumonia. The ambulance came as far as it could, and the combined forces of family and neighbours dug a path free for half a mile so the men could carry my Mum out tied on a stretcher held over their heads.

------------------<;,><-------------------

I think your determination to be amusing at my expense just exceeded my determination to find help here. Perhaps among the other readers there are some who understand what my problem is and have dealt with it themselves in the recent past. The problem is not the code, or the size of integers. The problem is handling the code auditors.

------------------<;,><-------------------

I am aware that different machines have different sizes for integer. I was hoping to hear something like - compilers are so clever nowadays they can handle this. It seems there is no way out and I will have to make a header file with standard types in it. I might have one left from 10 years ago. I was just hoping this kind of stuff was no longer necessary. (I just surprised the new graduate, who wanted to know what an unsigned character is good for. Apart from using it as an unsigned character, in the old days when size mattered we used to use unsigned char to get an 8-bit integer. That was in image processing, with one integer for each pixel, etc.)

------------------<;,><-------------------

The project style guidelines say this: "Unless portability and reusability is not a concern, the use of standard integral types is forbidden (exception: enum) and the types from a standard project header must be used." I can remember the days when we used to do this, but it has fallen into disuse. Are integers more portable now? I remember it being a problem with DEC machines, but we don't use them anymore. It seems I am not following the guidelines right now, I need a good reason in case the code inspectors ask. In help all it says is that integer size is machine dependent.

------------------<;,><-------------------

So that's where all the money went... ------------------<;,><-------------------

Found it! Some external dll (G) I was using in B had an interface using CString. Since I am not allowed to use MFC, I redefined these to be string. I don't actually use these parts. Anyway, string is not the same as CString and this was causing an access violation, even though it compiled and linked, the rat. I solved this by taking a local copy of the G.h file of the external dll. In it I put includes so it could see CStrings. This actually makes the exclusion of MFC in my own code redundant, but I can't help that. The G people are not willing to work without MFC (neither was I actually). G also had some problems in its export functions, which are being repaired. We are pleased to find these bugs now and not after delivery.

------------- Ave computer! Hackitura te salutat! (I just made this up. Just to show you can hack Latin as well as C++.)

Sorry, I was not very clear: I hop into B by calling a function B declares as DllExport, and A sees as DllImport. B has a dll and a lib and A can see them. This has always worked OK when I called it "fresh" every time. B's internal objects - static instances of B's classes - seem to be null when I go into B using the void* - I get the buffer overrun when I call functions of an internal object. (I am not allowed to use dynamic allocation "because the code is safety critical". This makes things very hard.) When I call B I import the stuff like this: DllExport int BDoWork( struct BigDataBlock1 *pBigDataBlock1, struct BigDataBlock2 *pBigDataBlock2, void* pB) I turn the void* back into a proper pointer like this: BWrapper* pmyB = (BWrapper*)pB; and it works OK, I can import data along with the pointer, and it seems to be alright, I can copy the data into B's internal structures. I use ASSERT when copying. B was written by myself. Respectable code always has a few bugs. I am sure there are still a few in there. What should I be looking for? It imports and handles very large amounts of data; I already had to cut the data into slices to avoid overflowing buffers on the dll call. I made it a dll so I could go into B with the debugger when debugging A. (Visual Studio is cool; it can even hop into Ada dlls, can you imagine?) You helped me a lot by saying void* should work the way I use it. Now I suppose the bug is inside B so I can concentrate there.

------------- Ave computer! Hackitura te salutat! (I just made this up. Just to show you can hack Latin as well as C++.)

Here is a void* problem to challenge you. I have a very large application A. Sometimes it needs to use a little application B. B instantiates an external dll I didn't write, we can call it G. B uses DllExport to export some functions I can call with DllImport. Whenever I call B it makes a new G and deletes it again. Fine. Now they changed the rules. I can only have one G. Easy, I think. Add an Init function to B's external interface, call it to instantiate my single instance of G. Return a void* to B, so whenever I want to call it it reuses the instance of B and thus of G. A is not allowed to know what happens in B, so the void* is perfect. I keep void* mPointerToB as a member of A. B has some internal classes, we can call one ClassM. So B contains a member ClassM mM. When I hop into B it runs for a while until it tries to call mM.function. Then I get a buffer overrun. So I googled and found this statement. "A void pointer cannot point to a class member in C++." Is my void pointer to B losing its internal objects along the way? Where can I find out more? Am I doing this in the wrong way? This is C++ in Visual Studio 2008. I use void* in other places to access pointers to things in Ada functions in the same way, so it should work, I think.

------------- Ave computer! Hackitura te salutat! (I just made this up. Just to show you can hack Latin as well as C++.)

Sorry if I landed in the wrong place, I could not see an Ada section... I get all the strange jobs. So here we have a very large amount of Ada code, as dll, which I call from C++. When my C++ is running in debug mode, no problem. In release mode (yes, I have written here before about this) it finds a memory leak when doing new, gives me an access violation and crashes. I followed this carefully as advised by yourselves. There are no memory leaks whatsoever in my C++ - DevPartner says so and I think so too. However, my ada.dll has a leak. Aonix dlls always have leaks, in my experience, but little ones you can live with. This one is different. So I got a new Aonix compiler, 8.4 (yes, I would prefer Gnu but they won't give me it, so there) and rebuilt it. I got patch U2 for it, which is intended to stop it making memory leaks when calling external dlls. Well, this Ada calls some very old external Fortran dlls (don't I get the FUN jobs). I have the very uncomfortable feeling I should get those Fortran dlls recompiled, but they are GFE. Our wise and intelligent buying department did not get me a maintenance contract, so Aonix are not being very helpful. Has anyone else seen this? Is there a memory leak finder for Ada similar to DevPartner? Is patch U2 no good?

------------- Ave computer! Hackitura te salutat! (I just made this up. Just to show you can hack Latin as well as C++.)

Thank you. I do know where it crashes, it enters my little dll through an exported function, then instantiates the class in there, and dies in the constructor, right on the {. I can tell that its problem is a null or corrupted pointer, because the debugger lets me look at the assembly code, and it tries to jump to places it's not allowed to, an access violation, as it says. I am trying to get DevPartner to run again. (The newest version seems to be a bit buggy.) When it was running before, it complained about "Calling Virtual Functions from Constructors and Destructors" and stuff like that, which I have stopped doing (this is what I meant by improvements). Hence my question. Is it OK to put code - I mean, real code that does things - in the constructor and destructor, when the compiler allows it and DevPartner whinges about it? If I can't get it running this week I shall just have to deliver the debug version, which is not so tragic right now, but it bothers me.

------------- Ave computer! Hackitura te salutat! (I just made this up. Just to show you can hack Latin as well as C++.)

No I didn't. That is one of the best ones so far. (I even bookmarked it.)

------------- Ave computer! Hackitura te salutat! (I just made this up. Just to show you can hack Latin as well as C++.)

I get an access violation in release mode but not in debug. Yes, I know it's been talked about in many threads and I think I have read all of them. I can even debug release mode now, to impress my colleagues. It dies when I hop into a dll I wrote, but not always quite in the same place. I have a feeling I have a NULL pointer. Anyway, I have been looking at ways I might be making a null pointer, and have made many improvements, but it still crashes. HERE is the question... One of the threads here asked if the poster had code in his constructor. Now I often have code in my constructors, I even call other constructors, with new (and I delete every single one, I promise), and as far as I am concerned this is quite normal and acceptable. Am I wrong? Could this be it? I also put code in destructors, deleting stuff and ending other processes.

------------- Ave computer! Hackitura te salutat! (I just made this up. Just to show you can hack Latin as well as C++.)

modified on Monday, May 18, 2009 9:26 AM

Ah, the helpful website cut out most of the messages because of strange characters. There are several ways to remove things from the list, and I have tried all of them, quite successfully, with all my included dlls and exes, with the exception of these std libs. Maybe there is a way to remove these results from the end result. It is very irritating, because my code is safety critical and I am supposed to be over 95% coverage, and this glitch pushes me down to 60% of code and 40% of methods. Here is just one of those messages: std:: (underline) DebugHeapAllocator (pointed bracket open) char (pointed bracket close) deallocate::deallocate(unsigned int)

------------- Bibo ergo sum

modified on Thursday, March 26, 2009 3:26 AM

The Compuware website isn't helping me so I'll try here before I go home. I have a lot of C++, and I prove how nicely I have tested it by running DevPartner Coverage. Easy. Now it has decided to analyse the Microsoft standard libs too. I turned off all the other Microsoft stuff, in fact in was turned off by default anyway. I tried all the obvious things in Help. And still I get hundreds of lines of this (as code not tested; of course I didn't test it!): std::::allocate... std::... Looks like the standard lib to me. Has anybody here had this problem? Has anyone a suggestion not mentioned in Help?

------------- Bibo ergo sum