|
It could be something as shown below -
bool GetSecond(const string& first, string& second)
{
for (int i = 0; i < ARR_SIZE; ++i)
{
if (first == arr[i].first)
{
second = arr[i].second;
return true;
}
}
return false;
}
void GetDest(const string& src, string& dest)
{
string src2 = src;
while (GetSecond(src2, dest))
{
if (src == dest)
break;
src2 = dest;
}
}
For each element in the pair call GetDest with first as the first parameter and second as the second parameter.
You may need to add other conditions to satisfy your algorithm.
|
|
|
|
|
Thank you for your reply.
Your algorithm is great!
I made some modifications, so that it's perfect now!
typedef vector<pair<char, char> > _OWN_TYPE;
_OWN_TYPE vecKey2Name;
bool GetSecond(const char& first, char& second)
{
for (int i = 0; i < vecKey2Name.size(); ++i)
{
if(vecKey2Name[i].first == vecKey2Name[i].second)
continue;
if (first == (vecKey2Name[i].first))
{
second = vecKey2Name[i].second;
return true;
}
}
return false;
}
void GetDest(const char& src, char& dest)
{
char src2 = src;
while (GetSecond(src2, dest))
{
if (src == (dest))
break;
src2 = dest;
}
}
int main()
{
vecKey2Name.push_back(make_pair('X', 'Y'));
vecKey2Name.push_back(make_pair('A', 'B'));
vecKey2Name.push_back(make_pair('C', 'D'));
vecKey2Name.push_back(make_pair('B', 'C'));
vecKey2Name.push_back(make_pair('T', 'X'));
vecKey2Name.push_back(make_pair('Y', 'T'));
for(_OWN_TYPE::iterator itr = vecKey2Name.begin(); itr != vecKey2Name.end(); ++itr)
cout << (itr->first) << " --> " << (itr->second) << endl;
for(_OWN_TYPE::iterator itr = vecKey2Name.begin(); itr != vecKey2Name.end(); ++itr)
GetDest(itr->first, itr->second);
cout << "=============================================================" << endl;
for(_OWN_TYPE::iterator itr = vecKey2Name.begin(); itr != vecKey2Name.end(); ++itr)
cout << itr->first << " --> " << itr->second << endl;
}
modified 6-May-12 6:25am.
|
|
|
|
|
Why not have a simple look-up table? Specially if the number of cases is this small...
|
|
|
|
|
Can you explain a little deeper?
The size of the arry is under 5000 in most case.
|
|
|
|
|
In my opinion
Falconapollo wrote: T → X (X is the final target in circuit)
Y → X (X is the final target in circuit)
Should be instead
T → Y
Y → Y
Am I missing something?
Veni, vidi, vici.
|
|
|
|
|
Yes. You miss something,
X → Y
A → B
C → D
B → C
T → X
Y → T
includes
X → Y
Y → T
T → X
so, it shoule be:
X → X
Y → X
T → X
|
|
|
|
|
1) X → Y
2) A → B
3) C → D
4) B → C
5) T → X
6) Y → T
Let's start from Y :
from rule (6) Y → T we reach T , then
from rule (5) T → X we reach X .
Now, I ask to you: Why we should stop here?
Why cannot we use rule (1) X → Y to reach again X and then stop (because there are no suitable rules but the consumed ones)?
Veni, vidi, vici.
|
|
|
|
|
I'm sorry for my late reply!
You are right, I made a mistake.
When X->Y Y->T T->X, it makes a cyclic reference. So, each element in the circel CAN be the terminate element.
I'm sorry for my mistake!
|
|
|
|
|
There are multiple possibilities. How do you select which one to use? Does the final targets are known beforehand. If not, how do you decide which one to use?
In your case, we can see that D is a final target because D is never on the left side of the pair. But for the other sequence, one could start with Y and end with Y (since it is a loop).
If the target are knows, then you would be able to build the result by search which item lead to the target and then repeat using the source as the new target (and the final target would be the original target).
Philippe Mori
|
|
|
|
|
If the target are knows, then you would be able to build the result by search which item lead to the target and then repeat using the source as the new target (and the final target would be the original target).
Yes, you are right.
Then, how to implent your idea into algorithm in C++?
|
|
|
|
|
- For each possible target, find immediate source. Add them (each pair) to a result list.
- For each immediate source not equal to the original target, find its own source. Add each pair to the result list.
- Recursively repeat the second step until you don't find any source distinct from the initial target.
You can remove recursivity if you like if you keep track of which pair were processed.
By the way, I assume that none of the source have multiples (immediate) targets.
Philippe Mori
|
|
|
|
|
I have no clue how this happened and how to fix it.
I am getting this error message from the compiler ( VC6.)
<b>“The source files ...cpp and ..cpp are ...both configured to produce ...pch
Project cannot be build.”</b>
I started getting this error on a file I really did not put into my project, so I deleted it.
Than this error “moved” onto a real file and I would like to fix it.
I would be most grateful if some VC 6.0 expert helps me to understand this and/ or how to fix it.
Thanks
Vaclav
-- modified 3-May-12 15:04pm.
|
|
|
|
|
Check the properties on your source files to ensure that only one is configure to create the PCH information.
Binding 100,000 items to a list box can be just silly regardless of what pattern you are following. Jeremy Likness
|
|
|
|
|
Richard,
that is exactly what the error message is saying.
I got that far.
I would not be asking here if I knew how and where to check that.
Vaclav
|
|
|
|
|
Right click on each files and select Properties.
Binding 100,000 items to a list box can be just silly regardless of what pattern you are following. Jeremy Likness
|
|
|
|
|
OK,
we are getting somewhere.
Indeed the ..pch file is in Properties of the offending source.
Now, how to get rid of it.
I suppose deleting it ( from the debug directory) won't work since it is obviously being generated by ...??
|
|
|
|
|
I think I found it.
Somehow all files were set to build precompiled header.
Thanks Richard for getting me started, I really appreciate your help.
Vaclav
|
|
|
|
|
Happy to help. I wonder how they all got set like that?
Binding 100,000 items to a list box can be just silly regardless of what pattern you are following. Jeremy Likness
|
|
|
|
|
i have this code:
FILE* file;
file=_wfopen(L"fisier.txt",L"w,ccs=UNICODE");
fwrite(text.c_str(),sizeof(wchar_t),wcslen(text.c_str()),file);
fclose(file);
the problem I'm having is that the file "fisier.txt" is saved on desktop and not where my app is.
How can I change the location from VS 2005 so that the file is created in my app's directory?
I don't want to change the path in the code.
|
|
|
|
|
Use the Common Item Dialog[^] to allow the user to specify the path to the file. Or use one of the Shell functions[^] that provide the user's application data path.
Binding 100,000 items to a list box can be just silly regardless of what pattern you are following. Jeremy Likness
|
|
|
|
|
I'm thinking is some setting is Visual Studio but I cannot find it.
And how come it saves the file on desktop?
I cannot see any logic in that.
|
|
|
|
|
dliviu wrote: I'm thinking is some setting is Visual Studio
Why are you thinking that?
dliviu wrote: And how come it saves the file on desktop?
The desktop is just a folder like everywhere else.
dliviu wrote: I cannot see any logic in that.
The logic is missing from your code. If you do not tell Windows where to store your files then it is going to have to make a decision based on 'best guess'.
Binding 100,000 items to a list box can be just silly regardless of what pattern you are following. Jeremy Likness
|
|
|
|
|
There must be a setting because i downloaded a vs c++ project which saves the files created with fopen in the app's directory and not on desktop!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
|
|
|
|
|
It's nothing to do with Visual Studio, it depends on the environment of the executable program (which does not necessarily run inside Visual Studio). And a single exclamation mark is enough to make your point!
Binding 100,000 items to a list box can be just silly regardless of what pattern you are following. Jeremy Likness
|
|
|
|
|
and how can I tell windows where to store my c++ created files??
|
|
|
|