[an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] (none) [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] (none) [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive]
 
[an error occurred while processing this directive] [an error occurred while processing this directive]
Skåne Sjælland Linux User Group - http://www.sslug.dk Home   Subscribe   Mail Archive   Forum   Calendar   Search
MhonArc Date: [Date Prev] [Date Index] [Date Next]   Thread: [Date Prev] [Thread Index] [Date Next]   MhonArc
 

Re: [PROGRAMMERING] malloc ter sig underligt



Peter Makholm <sslug@sslug> wrote:

> Anders Melchiorsen <sslug@sslug> writes:
>
>> Garantien for at et int*-array er mere nul-afsluttet end et
>> int-array er da vist til at overskue. Så vi skal i begge tilfælde
>> vide noget om hvad funktionen returnerer.

Ovenstående påstand fastholder jeg.


> Hvis vi returnerer en int* ser det således ud:
>
>    pointer 
>      |       +----+----+----+----+----+----+----
>      +-----> | 42 | 17 |  9 |  0 | -6 | -2 | ...  
>              +----+----+----+----+----+----+----

Ovenfor har du tegnet en int*. Så kan en int** ikke se anderledes ud
end nedenfor, nemlig som et array af int* (her hver roteret 90 grader) :


    pointer
      |        +-----+-----+-----+-----+-----+-----+------+----
      +----->  |  *  |  *  |  *  | NULL|  *  |  *  | NULL | ...
               +--+--+--+--+--+--+-----+--+--+--+--+------+----
                  |     |     |           |     |  
                +-+-+ +-+-+ +-+-+       +-+-+ +-+-+
                | 42| | -3| |142|       |  8| | 77|
                +---+ +---+ +---+       +---+ +---+
                | 17| | 12|             |  2|
                +---+ +---+             +---+
                |  9| | 97|             | -2|
                +---+ +---+             +---+
                      |  0|
                      +---+
                      |  3|
                      +---+

> Her kan vi tydelig se at når *pointer er NULL så er der ikke flere
> værdier.

Det er en betydning du har læst ind i din specielle funktion. Som det
ses af tegningen ovenfor (det kunne jo være en hashtabel) kan man
ingenlunde udlede at ** betyder "nulafsluttet".

Den ekstra stjerne har sjovt nok heller ikke løst problemet med, at vi
ikke ved, hvornår indholdet af en int* slutter. Vi har bare fået mange
flere af dem (hvor mange flere, det ved vi ikke).


[...]

> Men den generelle konvention er altså at bruge dobbelt-pointere,
> undtagen ved tekststrenge hvor char netop kan indeholde et
> stopelement (tegn 0).

Det vil jeg altså tillade mig at tvivle på. Ikke kun fordi jeg aldrig
har hørt om denne konvention, men også fordi det unødigt kræver cirka
en faktor fem ekstra i lagerplads at håndtere en liste tal på den
måde, du foreslår.

Alternativerne er ligetil: udvælg et element som "specielt" eller gem
længden i sin egen variabel. Begge dele at foretrække i forhold til
denne påståede konvention.



Anders.


 
Home   Subscribe   Mail Archive   Index   Calendar   Search

 
 
Questions about the web-pages to <www_admin>. Last modified 2005-08-10, 22:44 CEST [an error occurred while processing this directive]
This page is maintained by [an error occurred while processing this directive]MHonArc [an error occurred while processing this directive] # [an error occurred while processing this directive] *