Posts by thelamb

Do you know exactly what virtual memory means?

You asked if reading physical memory would 'be like calling ZwReadVirtualMemory'. It is not.

If you driver reads directly from the physical memory, it does not use any functions that have to do with virtual memory. Your teacher has hooks on these Virual memory functions... so you will bypass his hooks.

This is/was a technique used by malware to bypass anti-virus's hooks on certain function.

You will have to do research on how to read the physical memory yourself though.. if you are stuck somewhere I can help but there are enough resources out there explaining it

It goes wrong in free.
sizeof( mem ) will be the size of a void*, not the size that was previously requested in Alloc.

Also.. be careful with pointer arithmetic:

char* pChar = 0;
pChar++; // pChar will be 1
int* pInt = 0;
pInt++;  // pInt will be 4!

So increasing a pointer, increases it by the size of the type it points to.

In your case it goes wrong, but if you ever decide to change the type of m_pData... be careful.

I think the burden of multiple IDE's is (hardly) ever worth it. It already annoying to keep build settings synchronized between Debug and Release build (I always forget to set important options in the 'All configurations' tab).

And with the current state of IDE's(don't forget about plugins/extensions for those IDE's!) I think it is hardly necessary

Hmm, malloc/free are C functions, if you can avoid it you shouldn't really use them in C++. Look at new/delete instead.

You have the right mindset to become a good C/C++ coder. It is always a must to check the return value of functions. _beginthreadex can definitely fail and when it does, you must delete the memory you just created.

Even if you didn't have this dynamic memory you'd still want to check the return value of beginthreadex though, to break out of this while loop and inform the user that something went wrong.

Interesting...
Haven't thought about this much, but I guess a relatively straight forward method is to store the sClient on the heap, hand a pointer to it over to the thread.. and then copy it to the thread's local storage, finally free the memory you allocated on the heap in the thread.

Another scenario would involve locks, where this snippet would attempt to acquire a lock before changing sClient... you'd also have to hand over this lock to the thread, that will unlock it when it is done reading the sClient.

You can test it, by printing what the string points to:

printf( "0x%x\n", _str );

If they point to the same.. the compiler 'optimized' it, but it may very well be that it added both strings.

Here on Daniweb you won't get much help without showing some effort of yourself. What have you done yourself? Have you ever programmed in C++ before? If not, start doing (hands-on) tutorials.

Unless I miss something that is your best shot... but if you've never developed a driver it will be a long shot.

I must say that I doubt this is the teacher's intention though...
Is all that he provides for you some binary that contains 'something' and that something you need to read in real-time ?

The front/rear is a little confusing.

If I push two items, rear will increase by 2. front remains unchanged, but in holds() you output front.

So, that explains why holds() gives the wrong size?

I have use Code::Blocks for a long time (code completion was close to absent in the old version, but improved greatly in the latest. If you stick to nightly builds it's even better).

I still use C::B if I have to develop on Linux, but for Windows I switched to VS. I get it for free from my uni so cost was not a consideration.

I develop drivers for Windows as well, it was easier to get the WDK build environment to work with VS than it was with C::B. Also, together with the Visual Assist X plugin all the code completion and colouring is great.
Beside that, there is a nice VS plugin that allows you to debug a VM from within the IDE, it even deploys the driver for me automatically.

I used KDevelop on Linux a long time ago, and did not like it but that is probably because I put no effort in trying to understand it, so ignore that opinion.

In any case... if you're starting out just try some IDE's and see which one _you_ like, in the end that is all that matters.

(Edit: okok not if you work at a company, so they force the environment on you... judged by your question that is not the case ;))

All of those strings will be in the strings section, not on the stack.

In assembly it would look like
MOV EAX, DWORD PTR[some-fixed-address]

Not all of the strings have to be loaded in memory though, they can reside on disk until necessary.

Try to compile your code and open it in a debugger, like the free OllyDbg and look at the 'strings' tab, you will see all the hard coded strings(and more) that you've used. Or you can use 'strings' on Linux - there must be a Windows variant of that as well but I don't know where from the top off my head, probably in the Visual studio tools somewhere.

Don't think that is entirely correct. The bar is pretty much equivalent to foo, the pointer to the string is just not directly returned as in foo, but through a variable that holds the same pointer.
So the value of s is returned, not a reference to s itself.

This would be incorrect:

const char** bar()
{
    const char* s = "Hello";
    return &s;
}

This could still work if you're lucky... but the return value will point to the local variable s which at some point will be gone.

This will work, because the hard coded strings are stored in the strings section of your executable, and s just points to that. After the function returns the string will still be there.

static storage is if you declare a variable like this:

void myFunction() {
    static int myStatic = 1;
    myStatic++;
}

The first time you call myFunction, it will initialize myStatic to 1, and increase it. The next time you call the function, myStatic will still be 2.

So static variables declared in a function body are 'persistent' over function calls

Look up the 'new' operator.

Your addAll function is declared 'const', but inside the function you call 'addLast' which is not declared const.

That is where it tries to convert the 'this' pointer(itself) from a const ...&(because addAll is const) to a ...&.

That's not possible.

Do you understand the concept of declaring a function 'const'?

No, Physical memory has nothing to do with Virtual memory ;)

Does the solution need to work for newer versions than XP?

You can add an instance of a class just like any other variable:

class B
{
   int m_one;
   string m_two;
};
class A
{
   B instB;
};

Or if you just want a pointer to B:

class A
{
   B* instB;
public:
   A( const B& b )
   {
        instB = &b;
   }
};

Hope that is what you meant.

It could be me, but I really don't understand what you're asking - could you be more specific please?

It makes absolutely sense that this doesn't make sense at first sight ;).

void Reallocate(char* Source)

Here, Source is a _copy_ of char* Buffer. So modifying what Source points to will leave Buffer completely untouched.

Only if you modify the thing-that-Source-points-to you will also modify the thing-that-Buffer-points-to .. because they point to the same thing.

So essentially you have 2 pointers pointing to the same thing, and you modify what one of those pointers points to.

Change realloc to take a char** as argument, and hand over &Buffer, then you can modify what Buffer points to.

What isn't working? What is the result, and how does it differ from what you expect?

The assignment makes very little sense if you're not allowed to do all the above.

The only other thing I can think of is using a driver to read directly from Physical memory, but this will only work on XP and earlier windows versions. Not to mention the hell you'll go through trying to implement it correctly.

Did the teacher not give any clues as to how you should approach this?

No, toupper only takes one parameter.

char upChar = toupper( 'c' ); // upChar = 'C'

Did you google what the toupper function does? What parameters does it take etc.

Think about what those loops are doing.

Do you think it is correct?

The board is small, so you don't need any fancy search strategy...
Take this as example:

int row1[9] = { 0, 0, 0, 0, 0, 0, 0, 0, 2 };

bool isInRow = false;
for( int i = 0; i < 9; ++i )
    if( row1[i] == NewNumber )
        isInRow = true; // it is in the row

if( isInRow )
    ; // show an error

So this is just checking one row.. It shouldn't be too hard to change this to check in a 2d array, depending on where the NewNumber is added.

B2 would be the second column and the second row.
Assume your board is defined as int[9][9] you want to check int[1] and int[1].

Why do you create the _clock in main? You can also just hand over *c to the j constructor.

Other than that we still need more precise info... Why don't you create a compilable example that has the same problem.

Right now you are giving us code that isn't the same as what you're running, so we have to guess what you are _really_ doing.

It's impossible to say with this example.

Where do you call waiting(), and where do you call getID()?
How do you make sure that the clock* is valid? Maybe the Clock object that you passed by ref. to the constructor has already 'died' when you call getID().

So better show us some more code (e.g. the shortest code necessary to reproduce the problem).

... is not an operator, are you sure he did not mean . ?

Check: http://en.wikipedia.org/wiki/Operators_in_C_and_C%2B%2B

I guess the most common use of ... is in try/catch blocks:

try {
} catch( ... ) {

}

This will catch all C++ exceptions

Ok, it goes wrong in your assumption that list[mid] is a string, it is in fact a char.

The difference with food is that food is defined as an array of strings, and list is merely a string.

So I am going to guess that you want list to be an array of strings as well (I didn't look much at your code, this is just a guess based on the name 'list').

You may want to look at 'vector' classes in C++, they are much easier to handle than bare arrays usually.

The errors can be very cryptic, but trust me... after a while you will see at a glance what this means.

You are defining key as string, and list as string.
Then you compare key with list[mid], do you see how that could go wrong?

What is the type of list[mid]?

In short, the compiler doesn't have a comparison function in the string class that can compare a string with the type of `list[mid]`.

Edit: When posting code, please use 'CPP' syntax colouring.. it makes things easier to read:
code=cpp <-- put that between the [] braces, instead of just code.

Parameters in a function are separated by ',' not by ';'

Look carefully at what it says: it says a 'const char*' was the reason of the termination, and you are catching 'char*'.

I guess the Microsoft compiler doesn't see that as a difference, and g++ does. So just change it to catch( const char* ).

Sorry I didn't spot this before... it is more correct to catch a const char*

Some comments:

strlen already returns the correct length, you don't need to decrease the length to account for the null-char.

I don't think the revString is necessary.

You can define a pointer to the start of string, and one to the end.. compare them and increase the first pointer, decrease the second pointer.

e.g.

char szInput[SIZE];
 ...
char* p1 = szInput;
char* p2 = &szInput[strLength-1]; // -1 not because of '\0', but because string's index starts at 0

while( <something, for you to think about ;) ) {
    if( *p1 != *p2 )
        ; // it's not a palindrome
    p1++;
    p2--;
}

so all you need to hand over to your function is a char* and the size(which is not strictly necessary... but nicer)

Come on that is trivial to find out.

First: understand why strcmp is deprecated, do you know why?

A lot is wrong...

Compile with -Wall (enable all warnings) and it will tell you which functions are deprecated.

As a first sweep: don't use anything from conio.h

When you throw, the current function that's currently executing will end abruptly (it will not return though).

Then the exception will 'travel' back though the call stack, until it finds a catch block that catches it, when it finds one that catch block will be executed.
After the catch block is done, execution will continue normally starting from after the catch block.

void throwFunction() {
    throw( 5 );
    cout << "This will never be executed\n"; 
}

void callingFunction() {
    throwFunction();
    cout << "This will never be executed\n"; 
}

int main( ) {

    try {
        callingFunction();
            cout << "This will never be executed\n"; 
    } catch( char* str ) {
        cout << "Exception, str: " << str << "\n";
    } catch( int e ) {
        cout << "Exception, number: " << e << "\n";
    }catch( ... ) {
        cout << "Exception that's not an int or char*\n";
    }
}

throwFunction throws an int, so it stops executing. The exception travels back to callingFunction but there are no try/catch blocks around the call to throwFunction. So it travels back to main, where there are try/catch blocks.
It looks at the first block, which catches a char*... it skips this because the exception is an int. The next block catches an int, so that will be executed. After it prints "Exception, number 5" the execution will continue after the full try/catch blocks.

So the code you pasted works? Since card_list is in the class.
+ are you sure the _compiler_ is crashing?

Please give us the smallest source that reproduces the problem.. including all files that we need (e.g. the card class etc.) - then we can give better suggestions.

#1 : Your vector 'quantity' is uninitialized, which means you are trying to print garbage.

#2 : Your loop is suppose to _fill_ the vector, now you are just printing it out like in #1.
Also, the loop counter must be named x, not the vector itself.

So if I ask you to make the first element of

vector <double> vDouble (100);

0, how would you do it?

Edit:
- In the second for loop, the index stays an integer. The type of the index never depends on what type you store in the vector.

Also, I don't know if the teacher mentioned this... but there are 'iterators' for vectors... maybe he wants you to use them.

Why do you catch in this function, immediately after you throw? If you remove the try catch in this function, you will have to catch it at the caller's side (and this function will not return). For example:

try {
 myHeap.top()
} catch( const char* e )
{
 cout << "Error: " << e << "\n";
}

I find it personally 'dirty' to throw a bare char*, I always create an Exception class which inherits from std::exception. And when I catch I catch a const std::exception&.

Edit:
if you want to catch in the top function AND make the caller catch as well, you can change the catch block in top to:

catch( const char* str )
{
   cout << ...;
   throw str;
}

There is a macro 'RAND_MAX' which gives you the maximum, but it is not defined in _all_ systems.

Is that worse than friend or static functions in each class? I guess I'm missing something about your problem

The max of rand() is system-dependent.

Show us what you are doing, there may be a different reason for your program crash.

Why not public (or protected, if the classes are related) getter/setter functions? If that doesn't make sense then I'm not entirely sure what your problem is, in that case... could you elaborate with an example?

Don't include 'as soon as possible' in your topic and post... it is rude and even made me consider not replying to you at all.

You are defining the function SumN inside the body of main()... that is wrong. Each function must have its own scope.

Besides that, you say:
double* array;

*array;

that is also wrong... the type of array is double, not double*... Look up exactly how arrays work in C/C++.

General note:
'array' is a pretty bad name for a variable

You sent me a PM, please don't do that.. post here:

so in other words...c++ exception handling should only be used when a program will/can crash because of an error? in this case i should just return an error code if the program is unable to perform the requested operations?

No: I said 'if you don't catch an exception the program will crash'. If you catch it, it will not crash.
What I was trying to say with this is that you basically force yourself to do error checking if you use exceptions - you don't _want_ your program to crash if something small goes wrong.

The downside of excessively using exceptions is readability of code... because you will need try{ } catch ( ... ) { } blocks everywhere.. on the other hand, a lot of if( something == false ) can also be cluttering.

You can start by writing an empty main function, and other functions that the question states (ReadDials) etc. put the 8 char variables in main, and call ReadDials with those 8 variables.

I don't really understand your question...

The decision between throwing in error-cases or returning a status code is a design decision... advantage of trowing exceptions is that if you don't catch them, the program will crash, where if you just return a status code (e.g. FALSE) the caller can ignore this status code, producing undefined results. If you are a consist programmer this should not happen though (and there are code annotations that can spot cases where you forgot to check a return value.. google if you want to know more ;))

In your case I would just alter this function to return a boolean, especially if you're not very fluent in C++ yet. In any case, you should stick to a consistent approach, don't in one case throw exceptions and in a similar function return an error value.

I don't understand your comment "the called function ... never knows it had an error". Even if it knew, what would it do about it? It really doesn't have to care.

The caller requested something to be performed... if there was an unrecoverable failure, the caller should deal with that.

Why is it when I try to get an OP to think about the problem himself that other people just tend to give away the answer - he's just going to do what you say now without actually understanding what's happening.

What are the types of one, two and three in this example?

char myString[20];

??? one   = myString;
??? two   = myString[2];
??? three = &myString[2];

strcpy takes a char* as first and second argument.

You're bumping after 2 hours... that's not going to get you any help. In fact, you've lost me.