On 23 Apr 99 at 6:07,  wrote:

> Kedves Istvan!

Szia!

> > > Remelem nem irtam nagy marhasagot...
> >
> > Csak egy picit :))
> > Az abc ugyanis nem pointer.
> 
> Szerintem meg igen.

Pedig bizony nem... :))

De az a gyanum, hogy nem az ellen bizonygatjatok ezt, ami ellen en 
irom. Az termeszetesen igaz, hogy amikor a tomb nevet onmagaban 
hasznalod, az az expression a tomb elso elemere valo mutatora fog 
kiertekelodni. Ugyanugy, mint egy szubrutin neve is, annak a 
kifejezesnek is a szubrutin kezdocime lesz az erteke. Ettol azert meg 
nem mondja senki, hogy a szubrutin az egy pointer. :)

> > > char def[29];
> > > def = abc;
> > Ez nem jo, nem kap meg def semmit!
> 
> Szerintem sem. A def egy const char *pointer (bizonyitast lasd alabb). Azaz a

Jujj, az teljesen mas dolog!!!

const char *poi; egy olyan pointer, ami const char-ra mutat, tehat
*poi = 'a'; helytelen, viszont poi++; mar lehetseges.

> leforditott ertek lesz a def-ben es utanna nem irhatod at. Ugyanis
> forditaskor 29 byte le lesz foglalval valahol es az erre mutato POINTER
> betoltodik a def pointer-be.

Nincs def pointer sehol a memoriaban, ahova betoltodhetne barmi is!

> > Legegyszerubb ugy megnezni ezt, hogy kiprobalod ezt a kettot:
> >
> >   extern char abc[5];
> >   char *p = abc;
> >
> > illetve
> >
> >   extern char *abc;
> >   char *p = abc;
> 
> Mivel az elso esetben abc erteke az offset "tomb valahol a memoriaban", ezert
> a ket dolog ugyan az (SZERINTEM).

Forditsd le, nezd meg, milyen kod lesz belole, es latod, hogy nem 
ugyanaz.

> Igyexem alatamasztani az allitasomat
[...]
> Ha az abc nem a "valahol elhelyezkedo tomb"-re mutato pointer lenne, hanem
> maga a tomb, akkor valami zagyvasagot kellene kiirnia. De nem azt irja ki.
> Tehat abc egy pointer.

Szoval a szohasznalatban van kulonbseg koztunk: Te ugy hasznalod a 
tomb nevet, mint a kifejezes erteket (ami egy pointer), en meg 
szemantikailag (ami egy tomb, ami kifejezesekben az elso elemere 
mutato pointerkent ertekelodik ki).

> Az a kulonlegessege, hogy const. Bizonygatas:
...
> char abc[]="ABC";
> char *p=abc;
> abc=p;
...
> >cc x.c
> "x.c", line 4: left operand must be modifiable lvalue: op "="

Ez a hibajelzes nem azt jelenti, hogy konstans!! Hanem azt, hogy nem 
lvalue.

> Szoval levonhato az a kovetkeztetes, hogy az abc egy const pointer.

No ez nagyon nem igaz!

> Tovabb is varialhato a dolog. Barmely string egy pointer-kent fordul le. Es
> hasznalhato is ugy, mint egy pointer.

Pontosabban: barmely string egy char tomb.

> printf("%p\n", "ABCDE");
> printf("%p\n", "ABCDE");
> printf("%p\n", "ABCDEF");
...
> >a.out
> 20ae0
> 20aec
> 20af8
> 
> Jol lathato, hogy az ugyanolyan string-eket ez a fordito nem
> fesuli egybe. A Borlan TurboC-ben erre kulon opcio volt, hogy ilyet
> tegyen-e.

Nem csak ez a fordito van ezzel igy! Ugyanis a string az egy char 
tomb, nem pedig egy const char tomb!! Vagyis az erteke modosithato! 
Ezert nem szabad oket egyetlen helyre rakni, mert ha az egyiknek egy 
betujet modositja valami, akkor a tobbi is modosulna.

Hogy miert nem const char tomb a string eleve? Valoszinu azert, mert 
akkor megoszulne az ember, amig az osszes forrasaban vegigvezeti, 
hogy melyik char* -bol kell const char* -ot csinalnia, hogy hajlando 
legyen a fordito leforditani a kodot. ;-)

István

--  Istvan Marosi  --  http://www.sch.bme.hu/~marosi  --
--  Recosoft Ltd.  --  mailto:  --

On 23 Apr 99 at 19:35, Mink Barnabas > wrote:

> >   extern char abc[5];
> >   char *p = abc;
> >
> > illetve
> >
> >   extern char *abc;
> >   char *p = abc;

[...]

> A tomb offset <-> mutato kulonbseg szemantikailag: Az abc az elso
> peldaban egy konstans (-> nem lehet megvaltoztani), ami egy ervenyes
> helyre mutat,

Iiiigen, mondhatjuk igy is, bar ez IMHO inkabb ~~szintaktikai, mint 
szemantikai kulonbseg. (A szemantikai kulonbseg az, amit en irtam, 
hogy mas kod fordul belole.)

> es automatikusan le is lesz foglalva 5 byte ennel az
> offsetnel. A masodikban egy valtozo, ami mutathat akarhova is, es
> nincs automatice lefoglalva semmi hely ott, ahova mutat.

Viszont le van neki foglalva egy pointernyi hely valahol... A tombnel 
ilyen nincs.

> Utobbinal lehet
> pointer aritmetikat hasznalni (pl. ++abc, abc = xyz), elobbinel nem.
> 
> Helyes? :-)

Igen, durvan. Viszont a peldat masra akartam kihegyezni, csak rossz 
szokasom szerint csak a felet irtam le annak, amire gondolok, 
feltetelezve, hogy a masik felet ugyis mindenki kitalalja ;)

Szoval az akart lenni ez bovebben, hogy van az egyik forras:

file1.c:

char abc[5] = "abcd";
// stb.

Aztan van a masik forras ket valtozatban:

file2.v1.c:

extern char abc[];

void feldolgtomb()
{
    char *p = abc;
    ... stb...
}

file2.v2.c:

extern char *abc;

void feldolgtomb()
{
    char *p = abc;
    ... stb...
}

Nos, ez a feldolgtomb rutin a v1-ben jol mukodik, mig a v2-ben
hulyesegeket kezd el csinalni, core-t dump-ol, GPF ablakot hoz fel,
stb. C++ eseten jobb a helyzet, mert ott mar a linker hibat jelez, 
mert a name mangling miatt a ketfele abc-nek mas lesz a neve.

István
--  Istvan Marosi  --  http://www.sch.bme.hu/~marosi  --
--  Recosoft Ltd.  --  mailto:  --

On 23 Apr 99 at 6:55,  wrote:

abc[] tombrol van szo...

> Hmmm lehet, hogy szorszalhasogato vagyok, de szerintem valahogy
> ugy van ez a dolog, hogy a tomb neve fent abc egy pointer, ami
> konstans, tehat az erteket nem modosithatom

Felfoghato igy is a dolog, csak eppen pont e miatt a felfogas miatt 
irtam azt a cikket, mert vannak esetek, amikor rossz kodot eredmenyez 
ez a felfogas.

[...]

> char a[11]="abcdefghij";
> char *b;

[...]

> tehet "a" nem csak a fugvenyhivaskor lesz pointer, hanem az
> ertekadasnal, es a muveleteknel is az, de erteket nem
> valtoztathatjuk meg.

Igen. Ezt nem hangsulyoztam (mert nem ez a lenyeg), de termeszetesen
igy van. Ezt egyreszt a praktikussag, masreszt az ortogonalitas miatt
definialtak igy a C-ben, de az egesz onnan indult ki, hogy a tombot
nem ertek szerint, hanem cim szerint adjak at parameterkent.

(Amikor a C-t kitalaltak, abban az idoben a parameteratadas mikentje 
nagyon sokakat foglalkoztato elvi problema volt. Ezt a C egyszeruen 
megszuntette azzal, hogy dontse el a rutin hivoja, hogy erteket akar 
atadni, vagy pointert. A C++ mar visszahozta azt, hogy szintaktikai 
elemmel megadhato, hogy egy parameter milyen modon legyen atadva.)

> Szereny olvasatomban ez azt jeleti, hogy "a" egy konstans pointer.

A konstans pointer kifejezes teljesen masra van fenntartva, 
feltetelezem, hogy nem arra gondoltal. (Szoval nem const char*-ra)

> Ezert hibas a
> a="akarmi";             mig a
> b="akarmi";             helyes, bar itt vigyazni kell a
> b[7]=0;                viszont mar igen csak ketseges kimenetelt
> eredmenyez, mert ilyenkor olyan helyre irunk, amit csak a fordito
> fog tudni( mivel akarmi 6 hosszu + egy '0' az pont 7, es a tomb
> szamozasa 0 val kezdodik :)))
> vagyis ilyenkor csinaltunk egy olyan kodot, ami fugg attol, hogy milyen
> forditoval forditjuk le, ami nem biztos hogy a legszerencsesebb.

Ugyanilyen problemat okoz az a[11] is, ugyhogy ez nem kulonbseg. (Bar 
valoszinunek tartom, hogy ezt a tematol fuggetlenul irtad csak 
ide...)

Egyebkent itt leirtal egy olyan kodot, ami par eve engem nagyon 
meglepett, hogy szintaktikailag helyes:

  char *b;
  b = "akarmi";
  b[0] = 'A';

Ez tenyleg helyes szintax, es ez is resze annak a misztifikalasnak,
hogy a tomb es a pointer ugyanaz. Egyszeruen arrol van szo, hogy
mindketfele 'indexelesi' szintaktikat (b[x] illetve *(b+x)) lehet
tombre is meg pointerre is alkalmazni. Ettol meg szemantikailag a
tomb es a pointer nem lesz ugyanaz.

István
--  Istvan Marosi  --  http://www.sch.bme.hu/~marosi  --
--  Recosoft Ltd.  --  mailto:  --

On 23 Apr 99 at 2:28,  > wrote:

>    Lenne egyproblemam. Borland C++3.1, es GNU alatt elkezdtem nezni, ha
> egy stringbe kodokat tesztek ("\13" CR kod), akkor nem ez kerul bele,
> hanem a 13 helyet 11. Vagyis nem decimalisban, hanem oktalisban veszi az
> erteket.

Igen, ez igy lett kitalalva meg a kezdeti idokben.

>    Tud valaki olyan abrazolasi modot, ahol vagy decimalisban, vagy
> hexaba tudom ugy beirni a szamot, hogy barmilyen szoveg is lehesen
> utanna, de ne zavarja meg a kodot.

Egyreszt a leggyakoribb kodokra vannak \akarmi kodok, pl. CR="\r".
Ha pedig valami mas kodot akarsz beirni, lezarhatod idezojellel, ha 
felsz, hogy a \x szamot koveto betut/szamot is a hexa szam reszenek 
tekinti. Pl.: "\x09abcd" helyett irhatsz "\x9" "abcd" -t. A fordito 
osszeszedi a stringeket egybe.

István
--  Istvan Marosi  --  http://www.sch.bme.hu/~marosi  --
--  Recosoft Ltd.  --  mailto:  --

Hali Coder !

Andrew Schulman,... Undocumented DOS-bol (ISBN
0-201-57064-5):

/***************************************************
*	COUNTF.C - Jim Kyle
*	Last change   13 August 1990
***************************************************/

#include <stdio.h>
#include <dos.h>
#include <stdlib.h>

#ifndef MK_FP
#define MK_FP( s, o ) (void far *)(((long)(s) << 16) |
(unsigned)(o))
#endif
unsigned files(void) 
{
 union REGS regs;
 struct SREGS sregs;
 unsigned int far *ptr;
 int n = 0;

 if ( _osmajor < 2 )
 {
	puts( "FILES not supported in this DOS version.");
	exit(0);
 }
 regs.h.ah = 0x52;
 intdosx( ®s, ®s, &sregs );
 ptr = (unsigned int far *) MK_FP(sregs.es, regs.x.bx + 4 );
 ptr = (unsigned int far *) MK_FP( ptr[1], ptr[0] );
 while ( FP_OFF(ptr) != 0xFFFF )
 {
	n += ptr[2];
	ptr = (unsigned int far *) MK_FP( ptr[1], ptr[0] );
 }
 return n;
}

#ifdef TESTING
void main( void )
{
   printf("FILES=%d\n", files();
}
#endif

A 0x52 DOS funkcio (get list of lists) a DOS belso
tablazataihoz
ad egy pointert. Azok leirasa is megtalalhato ugyanabban a
konyvben.

Udv.

Szalai Gabor

Hello!

Nem tudom, mennyie jol dokumentaltak, de Linux ala van egy halom mp3
lejatszo forrassal egyutt... (www.freeamp.org, www.x11amp.org)

vagy:
http://www.mp3.com/software/linux/players.html

Barna

On Sat, 24 April 1999,  wrote:
> Sziasztok jatekos kedvu coder-ek!
            ^^^^^^^^^^^^^^^^^^^^^^
:-)

> Az rendben, hogy egy 256-os lookup tablaval egy indexelessel 
> megkaphatjuk, hogy egy byte-ban mennyi 1-es bit van. De hogyan tudjuk 
> ezt a tablazatot gyorsan inicializalni?

A kovetkezo negysorossal palyazok:

     int i, t, nsb_t[256] = {0};
     for (i=1;i<=128;i<<=1)
	  for (t=0;t<i;++t)
	       nsb_t[i+t]=nsb_t[t]+1;

A 0 erteke meg van adva, aztan a kovetkezo X mezot (X=az eddig
kitoltott mezok szama) mindig ugy tolti ki, hogy az eddigi ertekekhez 
hozzaad egyet, egeszen addig, ameddig mind a 256 ertek megvan.

Biztos lehetne meg optimalizalni...

Barna

Szia Istvan!

>Meg kellett szamolnom, hogy egy bitkepen mennyi 1-es erteku bit van,
>es elgondolkodtam kicsit, hogy hogyan lehetne ezt gyorsan csinalni.
>Az rendben, hogy egy 256-os lookup tablaval egy indexelessel
>megkaphatjuk, hogy egy byte-ban mennyi 1-es bit van. De hogyan tudjuk
>ezt a tablazatot gyorsan inicializalni?

Nem kodot irok, hanem matematikai oldalrol elemzem a problemat
/ne felj, en is a villanykaron tanultam matekot, par evvel alattad
jartam:))/

Ez is rekurziv megoldas. A legelso byte 0 egyes bitet tartalmaz. Ez az elso
lepes.
A kovetkezo bajtok 1-es bitjeinek a szamat ugy kapjuk, hogy az adott ponttol
annyi bajtra vegezzuk el a muveletet, ahany mar ki van a tablazatban
szamolva, es az ertek pedig a korabbi tablazat ertekek 1-el megnovelve.

Nehany lepest leirok, igy talan kevesbe felreertheto:
1. lepes utan a tablazat:    0
2. lepes utan a tablazat:    0 1
3. lepes utan a tablazat:    0 1 1 2
4. lepes utan a tablazat:    0 1 1 2 1 2 2 3
5. lepes utan a tablazat:    0 1 1 2 1 2 2 3 1 2 2 3 2 3 3 4

A 9. lepes utan kesz a tablazat. Amugy a megoldasra ugy jottem rá, hogy
leirtam 16-ig a szamokat binarisan es osszeszamolva az ertekeket feltunt
a szabaly.

udv.
Joco

>Meg kellett szamolnom, hogy egy bitkepen mennyi 1-es erteku bit van,
>es elgondolkodtam kicsit, hogy hogyan lehetne ezt gyorsan csinalni.
>Az rendben, hogy egy 256-os lookup tablaval egy indexelessel
>megkaphatjuk, hogy egy byte-ban mennyi 1-es bit van. De hogyan tudjuk
>ezt a tablazatot gyorsan inicializalni?
>
>Szoval ki tudja a leggyorsabb/legrovidebb algoritmust kitalalni?
>(Algoritmus kell, nem binaris include :) Ha lehet, olyan, ami nem
>shift-elessel szamolja ossze a biteket a byte-ban.
>
>En rekurzivat csinaltam, erdekel, hogy ki mit talal ki :)
>Johet C, asm, Pascal, akarmi.

Szia István!

Valoszinuleg nem a legkisebb...

;       al-ben a vizsgalando
;       cx-ben az eredmeny
;
        mov   cx,0        ; szamlalo torlese
t01:    test  al,01h      ; 0. bit vizsgalata
        jz    t02         ; ha Z: 0 volt
        inc   cx          ; egyel tobb 1-es
t02:    test  al,02h      ; 1. bit vizsgalata
        jz    t04         ; ha Z: 0 volt

 ... es igy tovabb, azt hiszem ertheto.

A test allitja a carry-t (nincs keznel leiras)? Akkor nem kellene az
ugras, csak adc al.
Szerintem fontosabb a jol olvashato kod mint a gyorsasag, kiveve, ha
a gyorsasag kritikus.

Veres Sandor

  kerdezte:
> megkaphatjuk, hogy egy byte-ban mennyi 1-es bit van. De hogyan tudjuk
> ezt a tablazatot gyorsan inicializalni?
> 
> Szoval ki tudja a leggyorsabb/legrovidebb algoritmust kitalalni?
> (Algoritmus kell, nem binaris include :) Ha lehet, olyan, ami nem
> shift-elessel szamolja ossze a biteket a byte-ban.

Ha nem lehet shiftelni, akkor en igy csinalnam:

int  egyszam( unsigned char c )
{
unsigned char  i;
int  n=0;		/*  Az egyesek szama  */

for( i=128 ; i > 0  &&  c ; i /= 2 ) {
  if( c >= i )  n++,  c -= i;
  }
return( n );
}


Ha fontos a gyorsasag:

int  egyszam( unsigned char c )
{
unsigned char  i;
int  n=0;		/*  Az egyesek szama  */

for( i=128 ;  ; i /= 2 ) {
  if( c >= i ) {
    n++;
    if( (c=c-i) <= 0 ) break;
    }
  if( i <= 1 ) break;
  }
return( n );
}



                       Aggod Jozsef

Hello!

Valakinek nincs meg veletlenul a Watcom C valamilyen ujabb verzioja
(10.5-tol nagyobb) vagy a Visual C? Tanulasi celzattal kellene. Lehet
teljes CD-s is.
                       Udv: Luka'cs A'rpa'd

Sziasztok !

Nem tudok megbirkozni a kov. feladattal: a tablabol torolt rekordokat
fizikailag is torolni kellene idonkent programbol.
Erre vonatkozoan a helpben semmifele utalast nem talaltam,
de megprobaltam mindenfele trukkot, amibol eddig a
BatchMove parancs volt a legjobb, de azzal is nagyon
sok godom akadt.
A Database Desktop-pal viszont nagyon korrektul tudok
tomoriteni, de nekem mindenkeppen programbol kellene.

Tehat lenne vagy 10-20 DBase tabla (most meg 10, de
fejlodik a program), amiket be kellene tomoriteni.
A sebesseg sem lenyegtelen, mert eleg nagy meretuek
lesznek a tablak, de a legfontosabb a megbizhatosag.

Minden mukodo otletet orommel vennek a postaladamban
is, mert sajnos a nagy kuzdelemben keves idom jut
a lista olvasasara...  :))))

Elore is koszonom:
---
Norbi )

Hello!

en nem tablaval csinaltam, csak siman bt-vel, szerintem
ezzel lehet a legrovidebbre megirni. (ami nem jelenti azt,
hogy az en verzion a legrovidebb).
viszont ugy tudom, hogy a bt nem a sebessegerol hires. bar
a pentiket ilyen szempontbol nem ismerem.
a kod:

	mov si,offset bitterkep
	mov cx,length(bitterkep)*8-1
	xor dx,dx
cycle:
	bt  [si],cx
	adc dx,0
	dec cx
	jns cycle

a ciklus 9 byte hosszu, 486-os procin ha jol szamoltam, 17 orajel.
a bt 12-t eszik :(

Bye,
	Panther / mnemonic

Hello!

Az assembly felteteles ugrasavial kapcsolatban lenne egy kerdesem. Meg
lehet-e azt oldani, hogy
egy ilyen ugrassal 128 bajtnal tavolabbi cimekre is lehessen kozvetlenul
ugorni?
Elore is koszi a valaszokat!

Feri
mailto: