volatile CString -- how do i convert to CString??

A simple question:

I have a volatile Csting and I want to convert it into a CSting like this (or any other way)

volatile CString aString;
CString anotherString;

aString=anotherString;

I want the value Cstring to be that of the volatile string
but I cant obviously do it. I've tried strcpy and a whole lotta other stuff, but I cant seem to be able to convert the sucker.
Please help me before I swallow my computer whole.
SeverinAsked:
Who is Participating?
 
trestanCommented:
CString volatile * aString;
CString anotherString = "test";

aString=&anotherString;
0
 
SeverinAuthor Commented:
Edited text of question
0
 
SeverinAuthor Commented:
Adjusted points to 53
0
Cloud Class® Course: Microsoft Office 2010

This course will introduce you to the interfaces and features of Microsoft Office 2010 Word, Excel, PowerPoint, Outlook, and Access. You will learn about the features that are shared between all products in the Office suite, as well as the new features that are product specific.

 
NorbertCommented:
what happens?
0
 
SeverinAuthor Commented:
error C2678: binary '=' : no operator defined which takes a right-hand operand of type 'volatile class CString' (or there is no acceptable conversion)
0
 
SeverinAuthor Commented:
error C2678: binary '=' : no operator defined which takes a right-hand operand of type 'volatile class CString' (or there is no acceptable conversion)
0
 
SeverinAuthor Commented:
Is there no way to do it without using pointers?
0
 
nietodCommented:
Why are you declaring the CString as volatile?  If it is trully volatile, then you are likely to have problems even if you get it to compile.  What is your goal?
0
 
SeverinAuthor Commented:
I'm using it to transfer information between two different threads. My books said that such variables must be volatile or else the compiler would optimize too much?
0
 
nietodCommented:
No.  Not volatile.  You must use a mutex or other syncronization device to control access to the threads.  The volatile attribute then isn't necessary.  That is fine since it is insufficient to protect you anyways.  Are you familar with mutexes and that sort of thing?
0
 
SeverinAuthor Commented:
No, I'm just reading bout it, but if you could help me out I'll surely raise the points :-)
0
 
nietodCommented:
Why don't you finish reading about them first and then ask if you have any questions (I'm suspect you will).  Just as a synopsis, though.  The idea behind mutex;s them is they act like a sort of like a switch.  When one thread locks the mutex, no other thread can lock it until the first thread releases the mutex.  The way it is used is you come up with some sort of rule that is applicable to your program, like "not thread may access XXXX unless that currently have mutex YYYY locked"  Thus no two threads can access XXXX at the same time.  The way it would be used in this case is you would create a mutex for controlling the CString.  Not one could access the CString unless the locked the mutex first (and then they must unlock it when done.)  Note that ALL accesses must lock the mutex.  Many people believe  you must lockt he mutex only before changing the CString.  you must lock it even if you are just using the CString, like printing its contents.  Depending on  your actual design, you may want to use the same mutex to control access to several objects.

Read up about it and then let me know if you have questions.
0
 
NorbertCommented:
Volatile tells the compiler that the contens of a variable can changed from anywhere
and for little things I think it is nice and better than semapores:
endless Thread:
Global Scope:
volatile BOOL RunForEver=TRUE;
volatile BOOL ThreadEnded=FALSE
.ThreadFunc...
{
    while(RunForEver)
    {
      DoSomething
    }
    ThreadEnded=TRUE;
}
other thread
{
.
RunForEver=FALSE;
while(!ThreadEnded);
.
}

this works fine and needs no mutex
but I think for strings it is very dangerous because what happens
if one thread changes the contens while the other thread is reading it? the result may be very confuse.
using unary Data types is no problem because the task change is never done within a single instruction it is only done between two instructions
}
0
 
nietodCommented:
Nordbert, has the right idea, that volatile won't work for objects and complex interactions.  It will work in simple cases with simple types like he has shown above.  But it can fail in more complex interactions involving simple types.

Volatile was developed for interrupt processing, not for multithreading, and should really be used just for that.  In general volatile is not sufficient by itself even for interrupt processing.  A synchronization mechanism is necessary in addition to volatile when processing interrupts.  However, the synchoinzation mechanism is the processor's own interrupt enable status, not a mutex or other OS device.
0
 
trestanCommented:
It is up to you to try every methods and choose the one you prepered. There are always various ways to achieve one purpose.
To the question you posted, I want to mention that the declaration of "CString* volatile pCstr" and "volatile CString* pCstr" are different(sorry for the confusive expression in answer). The former declares a volatile pointer to a CString, while the later is a pointer to a volatile CString. I think the first one can satisfy your need.
As you have tried, operators are not defined for a volatile class. It is strange. But a pointer can serve the purpose. It can be used as usual CString.

0
 
nietodCommented:
>> It is up to you to try every methods and choose the one you prepered. There are always various ways to achieve one purpose.

Agreed.  But in this case volatile is undeniably not one of them.  You cannot safely use volatile in this way.  You can probably make it compile, but it is a dangerious design that will have erratic behavior and best and more likely will cause crashes.  If you are not going to use snychrozation methods for this you might as well not use volatile and just pray the code doesn't go bezerk to often.  
0
 
trestanCommented:
It depends on how you use the CString. I am more agree with Mr. Norbert's opinion. It is not the problem of volatile, but may be the problem of multi-use of one memory block. Even you can try more methods, it does not mean that you discard a specific one. It will be good to try and know its behaviour.
0
 
nietodCommented:
I think nordbert would agree completely with me.  There was nothing in his statement that would  contradict what I said.  

Look at it this way.  mutex's and their like are a pain.  They are an extra step that can easily be missed or missused.  They are slow and make code longer.  If you could get by just by using volatile no one would use mutexes.  But people do use mutexes because you can't use volatile safely except in some VERY limited cases.

Why can't you use volatile?  lots of reasons, but one is enough.  For example, say thread one changes the string by making it longer.   To do so it needs to reallocate the memory buffer to store the longer string.  That is, it is going to change the pointer in the string object to a new location.  What if, as it is changing this pointer, thread 2 tries to access the string object.  It might access the string when it has a longer length, but still points to the shorter string buffer.  It could see it points to the new string buffer, but that string buffer might not have the new string value copied into it yet.  These sort of things will cause eratic behavior.  the worse case is that it could access the string object when thread one is writing the new pointer out to memory.  In that case it could obtain a value for the pointer that is several bytes from the old pointer and several bytes from the new pointer.  This pointer does not point to either the old string buffer or the new one.  When thread 2 dereferences the pointer you get an exception.    This are just some possiblities there are plenty more.

Volatile will not work safely in this case.  It wasn't meant to and it can't.
0
 
trestanCommented:
I do not object to using the mutexes. Mr. nietod gives a detail description of the case violation may happens. Honestely, the C++ creater do not have much favor to the volatile type. I mean that it will do no harm to try both and get feeling to both. And to use it when it can work well since it is simple.
0
 
nietodCommented:
But this is not a case where it will work--right????
0
 
SeverinAuthor Commented:
Thanx guys, I think I have it all worked out now. All except one thing, who shall have the points?
0
 
nietodCommented:
What is the mechanism you are using?  
0
 
NorbertCommented:
Because the only sure working mechanism is using mutex and nietod was the first ho said to use it I think nietod should earn the points

BTW nietod : my name is Norbert not Nordbert
0
 
trestanCommented:
I think there are two questions he asked in this section. First he asked how to convert a volatile CString to CString, I answered it. Then he asked how to transfer information between two threads, nietod first gave the answer.
0
 
nietodCommented:
Norbert, sorry.  I type at a rapid 60 words a minute--59 of which are wrong.

trestan,  your solution with pointers probably doesn't compile.  I never tried it, but if you have a pointer to a volatile CString you will still have the same problem.  If you have a volatile pointer to the CString then it will, but that is not what the question asked for.
0
 
alexoCommented:
Let me jump in and add some comments.

First, "volatile" tells the compiler "this variable may be changed outside your control, so do not put it in a register, cache its value or do any other fancy optimizations on it".

Protecting the object is, of course, mandatory (although, for mutithreaded protection you should use critical sections which are faster than mutexes by a factor of ~20) *but* a volatile attribute is also necessary.

Consider the following case:

    int sharedVariable = 1;

    // Some code...
    for (i = 0; i < MAX; ++i)
    {
        EnterCriticalSection(&lock);
        sharedVariable *= 2;
        LeaveCriticalSection(&lock);
        Sleep(100);
    }

The shared variable is supposed to be changed by another thread but, since the "volatile" qualifier was not supplied, an aggressive optimization can put it in a register so the effects of the other threads will not propagate.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.