|
Inside myheader.h there is a lot for other structs and defines that is in conflict with those from Windows. SID_IDENTIFIER_AUTHORITY for example ... So, removing or renaming is not an option (I guess). But I am not figure out how to solve this conflict with namespacing ...
|
|
|
|
|
This is just going to lead to more and more problems for you. You need to isolate your definitions from the ones in Windows. You can do it with the use of namespaces, or changing the names in your local definitions. But either way, until you fix this issue you are wasting your time trying to build any of the code.
|
|
|
|
|
Thank you Richard.
"You can do it with the use of namespaces"
Can you give me a little pseudocode that show me how to do it ?
|
|
|
|
|
Namespaces are a C++ feature, and not available if you are using C only. Basically a namespace wraps a set of definitions so that they can be uniquely identified within a source listing. eg:
namespace MyLib {
class A {
int x;
...
};
}
namespace MyProj {
class A {
int y;
...
};
}
...
int main() {
MyProj::A a1; MyLib::A a2;
a1.y = a2.y; }
update:The last line of the sample code, above should be a1.y = a2.x, apologies for any confusion 
If, however, you are using C, you've got two choices.
1) refactor you project so that your SID and the system SID never appear in the same source code file (otherwise known as a translation unit). That's not always possible, and even when it is, it's usually requires a lot of thought, care, and effort.
2) refactor you project and rename your SID to something else, eg MyProg_SID. That's still a lot of work, but its' probably a lot less work than option 1, above. Additionally, your IDE might provide a renaming tool that will do the grunt work for you. If not, you might be able to use the find and replace feature of your favorite text editor.
modified 8-Jan-20 10:07am.
|
|
|
|
|
That C code I modified as C++ code, so I could use namespaces 
|
|
|
|
|
It is not that straightforward unfortunately. A namespace is a qualifier that allows you to have objects with the same name in a single compilation unit. As a simple example:
namespace foo
{
typedef struct
{
int bar;
} FOOBAR;
};
namespace gaa
{
typedef struct
{
char bar;
} FOOBAR;
};
int main
{
foo::FOOBAR foobar; foobar.bar = 10;
gaa::FOOBAR gaabar; gaabar.bar = 'X';
}
|
|
|
|
|
The field names are not an issue you just need the struct, typedef and pointer to have different names
As Richard said it's going to bite you find a different name.
If you want to try a different name with minimal typing go to your file myheader.h and at the top after the guard put these
#define _SID _mySID
#define SID mySID
#define PISID myPISID
now go to the very bottom and put these
#undef _SID
#undef SID
#undef PISID
Now your SID is called mySID to all other units because it just does a text substitute
If you are happy it is all well the make the change permanently using Edit->find & replace on the file using Visual Studio.
In vino veritas
|
|
|
|
|
Interesting idea, and it works for this case, but inside that myheader.h, I have several structs with names as windows have ... so, I guess is not productive renaming structs ... that is why I am thinking seriously at namespaces ... but I don't know how to use it yet.
modified 9-Jan-20 1:33am.
|
|
|
|
|
Why are you including two definitions for the same structure? Either remove the duplicate or rename one of them to keep them unique.
|
|
|
|
|
Maybe it's a typo?
You could try to change #ifdef to #ifndef; which would make much more sense anyway since there is not point in defining something which has already been defined elsewhere.
"Five fruits and vegetables a day? What a joke!
Personally, after the third watermelon, I'm full."
|
|
|
|
|
Of course I tried with #ifndef, but I got error: error C2371: 'SID' : redefinition; different basic types
|
|
|
|
|
This doesn't do what you think it does:
typedef struct_SID {
...
} SID, *PISID
#ifdef SID
typedef struct {
...
}SID;
#endif
#ifdef,#undef etc only refers to preprocessor tokens. In C/C++, you can not undefine (or redefine) a previously defined item. e.g. the following is not valid
int x;
#ifdef x // only if preprocessor token 'x' exists
#undef x // doesn't undefine int x
struct { int i;
double d;
} x;
#endif
...
x myX;
|
|
|
|
|
I guess I know that. In WinNT.h I got:
typedef struct _SID {
....
} SID, *PISID;
and in myheader.h I got:
#ifdef SID
typedef struct {
...
}SID;
#endif
and my project take SID from WinNT.h, and I want to take it from myheader.h. Even if I get out #ifdef SID and #endif from myheader.h, the situation is the same. And moreover, inside myheader.h I have several struct with the same naming as windows has.
|
|
|
|
|
_Flaviu wrote:
#ifdef SID
typedef ... SID;
Sorry to be rude, but that's bullsh1t! If there really is a #define for the symbol SID anywhere in your code or your precompiler options, then your ccode will most likely never compile, because any attempt to use, declare or otherwise reference a struct SID will be turned into garbage by the precompiler which replaces the symbol with something else!
So, unless and until you make sure that nobody does such a #define, there is no point looking further! And then, of course, the #ifdef makes no sense - not that it did before.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
|
|
If I wrote:
#define major(dev) gnu_dev_major(dev)
#define minor(dev) gnu_dev_minor(dev)
then I got following error:
error C3861: 'gnu_dev_major': identifier not found
error C3861: 'gnu_dev_minor': identifier not found
I have arrived in a kind of same error ...
|
|
|
|
|
Didn't you read the link I have posted? There are some definition of the functions...
Just try something like
unsigned int gnu_dev_major (unsigned long long int __dev)
{
return ((__dev >> 8) & 0xfff) | ((unsigned int) (__dev >> 32) & ~0xfff);
}
|
|
|
|
|
Ahh, I didn't read whole source code. I am struggle to solve another errors. But I implemented what you said and I get rid of that error. Thank you Victor !!!
|
|
|
|
|
You are welcome!
But be sure that this function definition is correct! 
|
|
|
|
|
It looks like you're trying to use a GCC/linux function under Windows. Does that even make any sense? I mean, I've seen that you got it to compile now, but that doesn't mean your program will do what you expect it to!
I'm not familiar with gcc/linux and these functions, but if what Victor posted corresponds to the original implementation, it looks like dev is some version identifier composed of a major and minor version number. The way such versions are composed in Windows may be entirely different! There's no common scheme for it between different applications, compilers, or the OS itself. So don't expect any correct results from a Linux implementation!
To properly solve this issue you should find out who uses these functions and what are they expected to return. Only then will you be able to implement a proper replacement. Or, better, find the corresponding functions provided in Windows.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
"find the corresponding functions provided in Windows" I am perfectly agree with you. This is another part of work. And I am not sure that I'll find such replacement.
modified 9-Jan-20 4:56am.
|
|
|
|
|
Yes, it's entirely possible you won't find a match. That is the problem with language extensions, and the reason why many projects insist on staying compatible to the C++ standard instead.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
This is a corollary on an old issue of cout and perror (cerr) output not following expected sequence.
I understand that is caused by cout and perror(cerr) outputting to DIFFERENT streams. End of story for now.
Now I am having issues with inserting setw and left into cout NOT doing what I expect.
See attached IDE output. (Align cout text left starting on column set in setw.)
setw(30) without left is also being totally ignored, until width is set to 75 (?).
What gives?
PS in Linux if it should make a difference.
To avoid any unnecessary replies - usual note that I am looking for a solution to an issue, not for commentaries on my code style.
Cheers
else if (child > 0) {
cout << setw(75) << left
<< "\033[1;31mINITIALIZE bold red text\n" << flush;
cout << flush; cout << setw(75) << left << "(offset 30 ) START PARENT PROCESS "
<< endl;
#ifdef DEBUG
cout << setw(75) << left
<< "parent has / knows child process ID " << dec
<< child << endl;
cout << setw(75) << left
<< "TRACE This is the parent, orignal process "
<< endl;
cout << setw(75) << left << "TASK @line " << dec << __LINE__
<< dec << endl;
cout << setw(75) << left << "function " << __FUNCTION__ << endl;
cout << setw(75) << left << "STOP @line " << __LINE__ << endl;
cout << setw(75) << left
<< "child > 0 File descriptor socket[0] " << dec
<< sockets[0] << endl;
cout << setw(75) << left
<< "child > 0 File descriptor socket[1] " << dec
<< sockets[1] << endl;
#endif
Actual output on IDE console
START test area 370
main
TASK create a pair of connected sockets
TRACE @line 403
SUCCESS opening stream socket pair
result 0
socketpair File descriptor socket[0] 11
socketpair File descriptor socket[1] 12
TRACE @line 420
TASK fork Create another process child default -1
TASK @line 427
function main
TRACE @line 429
INITIALIZE bold red text
(offset 30 ) START PARENT PROCESS
parent has / knows child process ID 11713
TRACE This is the parent, orignal process
TASK @line 451
function main
STOP @line 453
child > 0 File descriptor socket[0] 11
child > 0 File descriptor socket[1] 12
child process , not ID ! 0
TRACE This is the child. process
TASK @line 513
function main
|
|
|
|
|
You do know that left applies to the output stream until its changed with either right or internal, don't you?
Anyway, the only odd thing I can see is this bit
INITIALIZE bold red text
(offset 30 ) START PARENT PROCESS
Your code is:
cout << setw(75) << left
<< "\033[1;31mINITIALIZE bold red text\n" << flush;
cout << flush;
cout << setw(75) << left << "(offset 30 ) START PARENT PROCESS "
<< endl;
In that first line, you have a terminating \n, so the output stream sends your text, including the line terminator, then fills the output so that 75 chars are actually written, since the cout string is 32 chars long, you get an additional 43 spaces to make up the output width before the next cout. Remove the terminating \n and add a << endl.
Otherwise, it all looks good to me. Changing the width to 35 seems to do the right thing, and removing the left right-justifies the output, which I think is correct, so I'm not sure what you're seeing that's wrong. Maybe give us an example of what output you get when it seems incorrect to you, please.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
