Thread: compiler differences

Originally Posted by BEN10

are definitions of pow different in c and c++?please explain it.and yes i was compiling this as C++ in visual studio.

C does not have function overloading, while C++ has

Originally Posted by BEN10

i typecasted pow and then it works fine but i still didn't get it why it didn't work without typecasting.if typecasting was needed it should have been needed with turbo c++ also.are definitions of pow different in c and c++?please explain it.and yes i was compiling this as C++ in visual studio.

save the file as .c not .cpp

and seriously do you need to do so much to find the decimal equivalent of a hexadecimal number?

Originally Posted by BEN10

i typecasted pow and then it works fine but i still didn't get it why it didn't work without typecasting.if typecasting was needed it should have been needed with turbo c++ also.are definitions of pow different in c and c++?please explain it.and yes i was compiling this as C++ in visual studio.

It might work in Turbo C++ because it's old and not very standards compliant today.
It works differently in C++ because C++ have the ability to have a number of functions with the same name. The compiler chooses which one to call depending on what types you are passing to the function. But there's no overload that takes two integers, so the compiler simply couldn't decide which function to call, since an integer can be promoted to a number of types.

Originally Posted by MK27

Keep in mind each process has it's own stdin and stdout. If you had a forked process connected to a parent with a pipe, you write into the stdin of the pipe and it comes out of the stdout of the pipe, right? But if the child wrote into it's own stdin (usually you would close that) the same thing will happen.

Code:

fwrite("this",4,1,stdin);

Does the same thing you just observed.

i tried this...

Code:

#include<stdio.h>

int main()
{
    fwrite("this",4,1,stdin);
    perror("fwrite status");
}

output:

Code:

[c_d@localhost C scratchpad]$ gcc temp.c
[c_d@localhost C scratchpad]$ ./a.out
fwrite status: Bad file descriptor
[c_d@localhost C scratchpad]$

no it did not mimic the system-call.

Code:

#include<unistd.h>
#include<fcntl.h>

int main()
{
    close(STDOUT_FILENO);
    if((write(STDIN_FILENO,"arrgh!",6))==-1)
    {
        perror("stdin");
    }
    if((write(STDOUT_FILENO,"arrgh!",6))==-1)
    {
        perror("stdout");
    }
}

output:

Code:

[c_d@localhost C scratchpad]$ gcc temp.c
[c_d@localhost C scratchpad]$ ./a.out 
arrgh!stdout: Bad file descriptor
[c_d@localhost C scratchpad]$ ./a.out <temp.c
stdin: Bad file descriptor
stdout: Bad file descriptor
[c_d@localhost C scratchpad]$

so process stdin stdout fd points /dev/tty under "normal circumstances"

this is what i found about stdin...

Code:

#include <sys/types.h>
#include <sys/stat.h>
#include <unistd.h>
#include <stdio.h>


int main(void) 
{
    struct stat st;
    char *whichtty;

    if ( !isatty(STDIN_FILENO) ) 
    {
	    (void) fprintf(stderr, "%s\n", "stdin is not connected to a tty device.");
    } 
    else 
    {
	    if ( (whichtty = ttyname(STDIN_FILENO)) == NULL ) 
	    {
	        perror("ttyname");
            return 1;
	    } 
	    else 
	    {
	        (void) fprintf(stderr, "stdin is connected to tty device %s.\n", whichtty);
	    }
    }

    if ( fstat(STDIN_FILENO, &st) == -1 ) 
    {
	    perror("file status");
	    return 1;
    } 
    else 
    {
	    if ( st.st_mode & S_IWUSR ) 
	    {
	        (void) fprintf(stderr, "%s\n", "stdin appears to be writeable by the user.");
	    } 
	    else 
	    {
	        (void) fprintf(stderr, "%s\n", "stdin does not appear to be writeable by the user.");
	    }
    }
    return 0;
}

output:

Code:

[c_d@localhost C scratchpad]$ gcc temp.c
[c_d@localhost C scratchpad]$ ./a.out
stdin is connected to tty device /dev/pts/3.
stdin appears to be writeable by the user.
[c_d@localhost C scratchpad]$

now, when i do this

Code:

[c_d@localhost C scratchpad]$ ./a.out <temp.c
stdin is not connected to a tty device.
stdin appears to be writeable by the user.
[c_d@localhost C scratchpad]$ chmod -w temp.c  #remove write perm
[c_d@localhost C scratchpad]$ ./a.out <temp.c
stdin is not connected to a tty device.
stdin does not appear to be writeable by the user.
[c_d@localhost C scratchpad]$ chmod +w temp.c

fwrite() may invoke write() eventually, but there's lots of stuff going on inbetween...

why so much difference FILE *stdin(stream) and STDIN_FILENO(descriptor of the same stdin stream)?

anyone?...guys?...

can you answer my questions? or do you think its best that i not dig into these things...

What does it matter?
The C Library does everything necessary to make the code work.
We don't need to understand its implementation details. Plus these details are implementation-defined. They can change (and probably will) between different compilers.

I think the answer is that FILE * and the stdio.h functions are standard. They work in DOS, Windows, OS/2, Linux, Unix, VAX/VMS, RT-11, RSTS/E, CP/M, many differnet RTOS's, and most other environments there is a C compiler for.

The correspondence between the lower level implementation (e.g. open, write, read, etc) may be close or quite far apart, depending on the actual low-level implementation. Modern OS's tend to work similar to what stdio.h implements, which makes it easier to use the OS. Older OS's such as CP/M or RT-11 are not quite so straight forward to translate from FILE * operations into native form.

--
Mats

yes, i guess its because its standard and because they have been implemented in that way...

i just will stop trying to write into stdin then. i dont want confuse and to set my poor keyboard on fire

i ll leave you all in peace. thanks again for your patience.