C / C++ / MFC

Richard MacCutchan7-Jan-20 22:14

Richard MacCutchan

7-Jan-20 22:14

Why are you including two definitions for the same structure? Either remove the duplicate or rename one of them to keep them unique.

phil.o7-Jan-20 22:33

phil.o

7-Jan-20 22:33

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."

_Flaviu7-Jan-20 22:43

7-Jan-20 22:43

Of course I tried with #ifndef, but I got error: error C2371: 'SID' : redefinition; different basic types

k50548-Jan-20 4:00

8-Jan-20 4:00

This doesn't do what you think it does:

C++

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

C++

int x;
 #ifdef x                    // only if preprocessor token 'x' exists
 #undef x                    // doesn't undefine int x 
 struct {                    // compiler error if branch taken, redifines type of x
   int i;
   double d;
 } x;
 #endif

 ...
    x myX;  //compiler error: typeof x unknown

_Flaviu8-Jan-20 7:18

8-Jan-20 7:18

I guess I know that. In WinNT.h I got:

C++

typedef struct _SID {
....
} SID, *PISID;

and in myheader.h I got:

C++

#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.

error C3861: 'major': identifier not found

Stefan_Lang8-Jan-20 21:44

Stefan_Lang

8-Jan-20 21:44

_Flaviu wrote:
C++
#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)

_Flaviu6-Jan-20 22:29

6-Jan-20 22:29

I have met another error while converting the project:

C++

error C3861: 'major': identifier not found
error C3861: 'minor': identifier not found

these are defined somewhere into gcc/linux. But can I use it in my win32/mfc project ? I have tried:

C++

#define major(dev) gnu_dev_major(dev)
#define minor(dev) gnu_dev_minor(dev)

but then gnu_dev_major is the problem. Of course, I have dig in on internet, and I haven't found something that solve the issue: gnu_dev_major(3): manage device number - Linux man page[^], or c++ - major and minor macros defined in sys/sysmacros.h pulled in by <iterator> - Stack Overflow[^]

How can I overcome this error ?

Victor Nijegorodov6-Jan-20 23:49

Victor Nijegorodov

6-Jan-20 23:49

Could the definitions from glibc/sysmacros.h at master · git-mirror/glibc · GitHub help you?

_Flaviu7-Jan-20 0:29

7-Jan-20 0:29

If I wrote:

C++

#define major(dev) gnu_dev_major(dev)
#define minor(dev) gnu_dev_minor(dev)

then I got following error:

C++

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 ...

Victor Nijegorodov7-Jan-20 0:40

Victor Nijegorodov

7-Jan-20 0:40

Didn't you read the link I have posted? There are some definition of the functions...

Just try something like

C++

unsigned int gnu_dev_major (unsigned long long int __dev)
{
  return ((__dev >> 8) & 0xfff) | ((unsigned int) (__dev >> 32) & ~0xfff);
}

_Flaviu7-Jan-20 1:07

7-Jan-20 1:07

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 !!!

Victor Nijegorodov7-Jan-20 1:13

Victor Nijegorodov

7-Jan-20 1:13

You are welcome!
But be sure that this function definition is correct! Wink | ;)

Stefan_Lang8-Jan-20 21:58

Stefan_Lang

8-Jan-20 21:58

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.

_Flaviu8-Jan-20 22:04

8-Jan-20 22:04

"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.

setw irrational behaviour

Stefan_Lang8-Jan-20 22:40

Stefan_Lang

8-Jan-20 22:40

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.

Vaclav_5-Jan-20 8:25

Vaclav_

5-Jan-20 8:25

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

C++

			else if (child > 0) { /* This is the parent. */

				//cout << setw(75) << left  << setw(75) << left  << "\033[1;31mINITIALIZE bold red text\033[0m\n";
				cout << setw(75) << left
						<< "\033[1;31mINITIALIZE bold red text\n" << flush;
				//cout << setw(75) << left  << setw(75) << left  << "\033[1;31mRESET  bold red text\033[0m\n";
				//	cout << setw(75) << left  << setw(75) << left  << "\033[1;32mbold green text\033[0m\n";
				cout << flush; // in << "" << endl;
				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
				// why closing the other socket (?)

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

k50545-Jan-20 10:27

5-Jan-20 10:27

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:

C++

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.

Vaclav_5-Jan-20 17:37

Vaclav_

5-Jan-20 17:37

PLEASE DISREGARD ALL OF THE FOLLOWING.
I AM USING SETW INCORRECTLY.

I need to check this more, but ...
with
cout << set(x) << left << "TEXT " << data << endl; ..
I expect TEXT to be output starting at column x and left justified.
As of now the data is output at unexpected column - as you pointed out.

Did I misinterpret setw - as it appears to set the width of the entire cout message , not just setting the starting column?

The "flush" ( clear cout buffer ) should have no effect on the actual output, it is there as an attempt to fix another issue.
However - endl at each cout line should also clear the cout buffer , hence each line should start independently - which it does.

The whole snippet is part of TWO processes output and I need to try this setw in single process FIRST! It appears that cout does not run in each process independently, so let me eliminate the child process.

I am also not sure if "\n" clears the cout buffer.

modified 6-Jan-20 0:49am.

Richard MacCutchan5-Jan-20 21:53

Richard MacCutchan

5-Jan-20 21:53

The setw() manipulator (<iomanip> functions | Microsoft Docs[^]) just sets the minimum width of the next field to be output. So whatever is in that field will be output (after converting to text if necessary) in a field that is at least that many characters wide. If the text is wider than the setw value then it will overflow the field.

As to your other comments above, setw has nothing to do with which column the output will start at.

Vaclav_ wrote:
It appears that cout does not run in each process independently

It sort of does, but ultimately they both feed into the same stream that is managed by the console handler.

Vaclav_ wrote:
I am also not sure if "\n" clears the cout buffer.

No, it is just a character sent to the stream, but I think the console handler converts it to CR LF. The end of output is sensed by the presence of the endl manipulator.

k50546-Jan-20 4:16

6-Jan-20 4:16

Vaclav_ wrote:
Did I misinterpret setw - as it appears to set the width of the entire cout message , not just setting the starting column?

Looks like you figured out where you went wrong with setw(), but I'd like to point out that setw sets the width of the next output field, but does not truncate, so cout << setw(5) << "Hello World"; will still print all of the string "Hello World".
If you really want to put output at a specific location on screen, maybe take a look at curses: http://tldp.org/HOWTO/NCURSES-Programming-HOWTO/

error C2065: '_S_IFDIR' : undeclared identifier

CPallini6-Jan-20 21:30

CPallini

6-Jan-20 21:30

Quote:
usual note that I am looking for a solution to an issue, not for commentaries on my code style

_Flaviu5-Jan-20 7:42

Re: error C2065: '_S_IFDIR' : undeclared identifier

5-Jan-20 7:42

Trying to convert a linux project to windows, I met an error (from the subject of the post). I have a chance to use something else in windows case ?

C++

if(S_ISDIR(type))
....

where type is defined as mode_t type ... and mode_t is another error:

C++

error C2061: syntax error : identifier 'mode_t'

how can I solve these errors ? I seek on internet and I found something like:

C++

#if defined __WIN32__ || defined _WIN32 || defined _Windows
      #if !defined S_ISDIR
            #define S_ISDIR(m) (((m) & _S_IFDIR) == _S_IFDIR)
      #endif
#endif

taken from here: c - Error: identifier "_S_IFDIR" is undefined - Stack Overflow[^]

k50545-Jan-20 10:31