Thread: Incompatible types in assignment.

  1. #16
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Quote Originally Posted by itCbitC View Post
    There is no copy made of the list object as it is defined inside insertnumber() only.
    No copy?
    What do you actually think returning the pointee does?
    Not to mention that (currently), returning the pointee will cause a memory leak.

    The pointer to the list of nodes is contained within the structure itself so there is no deviation from the norm of linked lists.
    Yes, but if you go p->next->previous, you won't arrive at the same struct!
    That just means that if you walk the struct, you will not find the same node as the copy you have made!
    This can cause problems.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  2. #17
    Registered User
    Join Date
    Oct 2008
    Location
    TX
    Posts
    2,059
    Quote Originally Posted by Elysia View Post
    No copy?
    What do you actually think returning the pointee does?
    Not to mention that (currently), returning the pointee will cause a memory leak.
    You're correct; for some absurd reason I had it in me that list *n was malloced in main() even though IINM I said that it was defined in insertnumber()
    Quote Originally Posted by Elysia View Post
    Yes, but if you go p->next->previous, you won't arrive at the same struct!
    That just means that if you walk the struct, you will not find the same node as the copy you have made!
    This can cause problems.
    Now that's a doubly linked list you are talking about...there's no *prev pointer here.
    Last edited by itCbitC; 12-21-2008 at 03:27 PM.

  3. #18
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Quote Originally Posted by itCbitC View Post
    Now that's a doubly linked list you are talking about... There's no *prev pointer here.
    Yes, I know there is not, but I was merely pointing out the fact that it would not be the same node, and the easiest way to get back to a node is next, then previous. Of course, it can be walked from the beginning, as well. It was the principle I was after.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  4. #19
    Registered User
    Join Date
    Oct 2008
    Location
    TX
    Posts
    2,059
    Quote Originally Posted by Elysia View Post
    Yes, I know there is not, but I was merely pointing out the fact that it would not be the same node, and the easiest way to get back to a node is next, then previous. Of course, it can be walked from the beginning, as well. It was the principle I was after.
    Gotcha!

  5. #20
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Quote Originally Posted by itCbitC View Post
    You're correct; for some absurd reason I had it in me that list *n was malloced in main() even though IINM I said that it was defined in insertnumber()
    Btw, this would still cause a copy to be made, but it would avoid a runtime error.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  6. #21
    Registered User
    Join Date
    Oct 2008
    Location
    TX
    Posts
    2,059
    Quote Originally Posted by Elysia View Post
    Btw, this would still cause a copy to be made, but it would avoid a runtime error.
    Not if the malloc() happens only in main(); this way you're not dereferencing a NULL pointer and no copy is made.

  7. #22
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    No, dereferencing a NULL pointer is undefined behavior, and does not create a copy.
    Returning the pointee does, however, because the function returns a struct, and thus the struct itself (the pointee) is copied, and returned to main, where it is once again copied.
    If a pointer were to be returned, the pointer is copied, but the pointee is not.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  8. #23
    Registered User
    Join Date
    Oct 2008
    Location
    TX
    Posts
    2,059
    Quote Originally Posted by Elysia View Post
    No, dereferencing a NULL pointer is undefined behavior, and does not create a copy.
    I was referring not to the copy but to the runtime error when I talked about dereferencing the NULL pointer.

  9. #24
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    So are we discussing runtime errors or copies now? I do agree - mallocing will not cause a runtime error, but a copy is still made, so...
    I don't know if you still have/held some belief that mallocing would solve the copy problem - which it will not, but it will, of course, solve the runtime error. In a wrong way, though, perhaps.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  10. #25
    Registered User
    Join Date
    Oct 2008
    Location
    TX
    Posts
    2,059
    Quote Originally Posted by Elysia View Post
    So are we discussing runtime errors or copies now? I do agree - mallocing will not cause a runtime error, but a copy is still made, so...
    I don't know if you still have/held some belief that mallocing would solve the copy problem - which it will not, but it will, of course, solve the runtime error. In a wrong way, though, perhaps.
    I didn't mean to leave this thread abruptly, however if you see my post #21 the implication is that there's no insertnumber() function and all the malloc'ing happens ONLY in main(). Figure only is the operative keyword here. Doing it this way gets rid of the twin problem of runtime error and the copies.

  11. #26
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Ah yes, of course. If you get rid of the function entirely.
    But you want the function there, do you not? Yes, it's a good thing, so we must take care not to create copies then.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  12. #27
    Registered User
    Join Date
    Oct 2008
    Location
    TX
    Posts
    2,059
    Quote Originally Posted by Elysia View Post
    Ah yes, of course. If you get rid of the function entirely.
    Cool beans! we are on the same page then
    Quote Originally Posted by Elysia View Post
    But you want the function there, do you not? Yes, it's a good thing, so we must take care not to create copies then.
    Modularization is always good but for 3, 4 lines of code I wouldn't have gone for a separate function but again it's a matter of personal style.

  13. #28
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Makes sense to me since it's clearer what the code does if you put it inside a function.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  14. #29
    Registered User
    Join Date
    Nov 2008
    Posts
    44
    I've made some changes which seem to make more sense. Changes have been highlighted. Another question. About my input. I want to input numbers until the input reads in a full stop. But i'm missing something to put in my first while loop. Just kind of want it run ( e.g. while( there is input to be read in) if you get me ) only reason i have the while in there is so i can use the break statement.

    So yeah here is my code.

    Code:
    #include<stdio.h>
    #include<stdlib.h>
    
    typedef struct L
    {
    	char number[15] ;
    	struct L *next ;
    } list ;
    
    list *insertnumber( char NUMBER, list *n1 )
    {
    	list *n ; 
    	n = malloc( sizeof( list ) ) ;
    	n -> number[15] = NUMBER ;
    	n -> next = n1 ;
    	return n ;
    }
    
    void printl( list *n )
    {
    	while( n != NULL )
    	{
    		printf( "%s\n", n -> number ) ;
    		free( n ) ;
    		n = n -> next ;
    	}
    }
    
    int main( void )
    {
    	char *num ;
    	char check ;
    	int i ;
    	list *q = NULL ;
    	
    	num = calloc( 15, sizeof( char ) ) ;
    	
    	while(  )
    	{
    		check = getchar() ;
    		
    		if( check != '.' )
    		{	
    			num[0] = check ;
    			for( i = 1 ; i < 15 ; i++ )
    				num[i] = getchar() ;
    		}
    		else
    			break ;
    		
    		q = insertnumber( *num, q ) ;
    	}
    	
    	printl( q ) ;
    	
    	return 0 ;
    }
    The print function and stuff still isn't done, just wanted to make sure the pointers are now ok?

  15. #30
    Registered User
    Join Date
    Oct 2008
    Location
    TX
    Posts
    2,059
    IMO you don't need the while loop. There are 2 terminal conditions: a full stop and num array bounds. Modify the for loop for these 2 cases as in
    Code:
    for(i = 0 ; i < 15 && (num[i] = getchar()) != '.'; i++)

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. assignment from incompatible pointer types
    By iunah in forum C Programming
    Replies: 13
    Last Post: 10-12-2008, 03:32 AM
  2. incompatible types in assignment
    By vapanchamukhi in forum C Programming
    Replies: 6
    Last Post: 09-19-2008, 07:45 AM
  3. incompatible types in assignment
    By vapanchamukhi in forum C Programming
    Replies: 1
    Last Post: 09-18-2008, 11:35 PM
  4. The Interactive Animation - my first released C program
    By ulillillia in forum A Brief History of Cprogramming.com
    Replies: 48
    Last Post: 05-10-2007, 02:25 AM
  5. Incompatible types in assignment error
    By Zildjian in forum C Programming
    Replies: 12
    Last Post: 10-03-2003, 01:15 PM