|
Big thanks for your answer.
I did it in the same way.
The Main-Thread and 2 threads for the input (one for keyboard and a second one for the barcode-scanner)
Greetings
|
|
|
|
|
As already stated, you cannot write to the read-only stdin stream. (Check the return code of fscanf.) You could try the following:
std::stringbuf buffer;
std::iostream stream(&buffer);
You can both read and write to that stream. You can have one thread collecting data from stdin, and one thread to collect data from elsewhere.
This stream will not be threadsafe however, so you have to add locks to read and write access. I suppose you can do something similar in C if C++ is not your choice.
|
|
|
|
|
Thanks for your answer
I resolve it with multiple threads, like your idea
Greetings
|
|
|
|
|
When should I use (*objectName).memberNameOrFunction and when to use objectName->memberNameOrFunction
I can access the member variables and functions by both the ways. So I am just curious when should I use which one.
|
|
|
|
|
For built in pointer types, there is no difference. I'd say using -> will make you code look more like users are used to, so I would recommend that. Your compiler would also not make any difference. Dereference and pointer operators can however be overloaded, but only someone insane would make an implementation that broke the intuitive functionality.
|
|
|
|
|
Thanks Niklas I will use ->
What do u mean by built-in pointers? what are others?
|
|
|
|
|
I was talking about pointer types.
You can mimic pointer behavior by overloading the pointer operator:
class A
{
public:
int intValue;
};
class B
{
A myA;
public:
A* operator->() { return &myA; }
};
B b;
cout << b->intValue << endl;
Here, b is not a pointer, but can be used as such.
But of course, then all bets are off since it will yield a function call, which may contain whatever.
|
|
|
|
|
|
Since objectName is a pointer, you must use -> .
There is no advantage in first dereferencing it with * and then using the . operator.
|
|
|
|
|
|
HI Guys,
I am using visual studio 2010 and I need to change the Mainframe icon at runtime based on my requirement so I have defined a macro _CHANGEICO. If this macro is defined I need to use some different icon and so I modified the .rc file accordingly and saved. Now If add any string or any new item to the resource all my macro declaration is deleted from the .rc file.
For example I have tried the following i.e. modified the resource file like this
#if defined(_CHANGEICO)
IDR_MAINFRAME ICON "res\\Orbit.ico"
#else
IDR_MAINFRAME ICON "res\\Sun.ico"
#endif
(OR)
#ifdef _CHANGEICO
IDR_MAINFRAME ICON "res\\Orbit.ico"
#else
IDR_MAINFRAME ICON "res\\Sun.ico"
#endif
After the above changes,I have added string to resource from visual studio, the .rc file is getting modified automatically like this
IDR_MAINFRAME ICON "res\\Sun.ico"
Can any one please help me in solving this issue, My changes should not be altered by the visual studio.
|
|
|
|
|
You should not modify the .rc file by hand, since it's content will be overwritten whenever you edit a resource in the resource editor. You should have a file named *.rc2 which the environment will not touch. Make your edits there. (I think this file is included as the last statement in your .rc file.)
Also, this will not change the icon at runtime, but at compile time.
|
|
|
|
|
|
I understood what you have said, I tried the same way the compiler is throwing errors like "res\IMAPP.rc2(75): fatal error RC1004: unexpected end of file found". Could you please give me a sample so that I can use it or instructions need to be followed for achieving this. Thanking u a lot...
|
|
|
|
|
#ifdef _CHANGEICO
IDR_MAINFRAME ICON "res\\Orbit.ico"
#else
IDR_MAINFRAME ICON "res\\Sun.ico"
#endif
works just fine here. Make sure your #ifdef is properly closed by an #endif, which is the only reason I can think of creating your problem.
|
|
|
|
|
Thanks a lot ..it is working perfectly fine now..
|
|
|
|
|
I'm not sure how your "I need to change the Mainframe icon at runtime" requirement is being met.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Some people are making such thorough preparation for rainy days that they aren't enjoying today's sunshine." - William Feather
|
|
|
|
|
I am sorry for mentioning as changing the icon at runtime in the question posted earlier, actually I need to change Icon at compile time. For changing it at compile time everyone has helped me to achieve it and it's been achieved.
|
|
|
|
|
Syntax:
#if defined _CHANGEICO
IDR_MAINFRAME ICON "res\\icon1.ico"
#else
IDR_MAINFRAME ICON "res\\icon2.ico"
#endif
And You have to remove IDR_MAINFRAME From the .rc file
|
|
|
|
|
How to show only unique elements from this double linked list using UniqueList function? I made something, but it removes only the first...
<pre>
#include "iostream"
using namespace std;
void Add(int n);
void UniqueList();
struct Elem
{
int key;
Elem *prev;
Elem *next;
} *start;
int main()
{
int num;
while(cin >> num)
{
Add(num);
}
cout << endl;
UniqueList();
return 0;
}
void Add(int n)
{
Elem *p = start;
start = new Elem;
start->key = n;
start->next = p;
start->prev = NULL;
}
void UniqueList()
{
Elem *p = start;
if(NULL != start) cout << "The list is:" << endl;
else cout << "Empty list.";
while(NULL != p)
{ if(p->prev != p->next)
cout << p->key << endl;
p = p->next;
}
}
</pre>
|
|
|
|
|
one problem is that you're never setting the 'prev' members of the added items to anything but NULL. if you have a double-linked list, you need to do something like this:
void Add(int n)
{
Elem *p = start;
start = new Elem;
start->key = n;
start->next = p;
start->prev = NULL;
p->prev=start;
}
but that will probably blow up the first time through, since start itself hasn't been initialized, and *start is never allocated.
|
|
|
|
|
and what about the other main problem with the duplicates?
|
|
|
|
|
i'm going to guess that that's probably a side effect of:
a) not setting prev to anything but NULL and
b) not initializing 'start' the first time around.
and, maybe i don't understand the task, but why are you doing this:
if(p->prev != p->next)
why compare prev and next pointers ? and why compare prev and next and not p itself:
if(p->key != p->next->key)
|
|
|
|
|
I fixed the prev problem. "if(p->prev != p->next)" is a shot in the dark. Any ideas how to show only uniques
|
|
|
|
|
you're on the right track. but the key thing that's missing is that the list needs to be sorted before you can be guaranteed that duplicates will show up in p and p->next.
duplicates, but p, p->next will never be the same: 1,4,3,5,3
this will work: 1,3,3,4,5
|
|
|
|