1. |
Re: String C++ (mind) |
123 sor |
(cikkei) |
2. |
PDA (WinCE) programozas (mind) |
10 sor |
(cikkei) |
3. |
Re: String C++ (#438) (mind) |
41 sor |
(cikkei) |
4. |
Re: IPC debug (mind) |
44 sor |
(cikkei) |
5. |
Re: TP7 (mind) |
13 sor |
(cikkei) |
6. |
Clipper error 16 (mind) |
16 sor |
(cikkei) |
7. |
Re: String C++ (mind) |
46 sor |
(cikkei) |
8. |
WRI es DOC beolvaso (mind) |
7 sor |
(cikkei) |
9. |
client32/DOS + packet driver? IGEN! (mind) |
94 sor |
(cikkei) |
10. |
C++ stringbe levo kodok (mind) |
20 sor |
(cikkei) |
11. |
Filehandles (mind) |
23 sor |
(cikkei) |
12. |
Ellipszis (mind) |
26 sor |
(cikkei) |
13. |
bitszamolas (mind) |
18 sor |
(cikkei) |
|
+ - | Re: String C++ (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Kedves Istvan!
> Felado : [Hungary]
>
> > > char abc[29];
> > > char *p;
>
> [...]
>
> > A masik azert nem jo, mert az abc maga egy pointer. Nem kell tehat
> > a p=&abc. p=abc megteszi.
> >
> > Remelem nem irtam nagy marhasagot...
>
> Csak egy picit :))
> Az abc ugyanis nem pointer.
Szerintem meg igen.
> On 21 Apr 99 at 18:32, Mink Barnabas wrote:
>
> > char def[29];
> > def = abc;
> >
> > Ez ugyan megy, de vigyazni kell, mert a string nem lett atmasolva,
> > csak a def megkapta az abc mutato erteket.
>
> Ez nem jo, nem kap meg def semmit!
Szerintem sem. A def egy const char *pointer (bizonyitast lasd alabb). Azaz a
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.
> Mindkettotoknel az a felreertes, hogy a C-ben a tomb es a pointer
> allitolag (sok konyv szerint is) ugyanaz a dolog. Ez nem igaz!
Szerintem meg igaz. A kulonbseg csak az, hogy a tomb egy const, a pointer meg
nem...
> Ez a felreertes abbol adodik, hogy egy szubrutinhivaskor a tombot cim
> szerinti parameteratadassal, minden mast pedig ertek szerint ad at a C.
> Tehat ugy tunik, mintha a tomb egy pointer lenne, de ez csak latszat.
Szerintem meg nem... :-)
> Legegyszerubb ugy megnezni ezt, hogy kiprobalod ezt a kettot:
>
> extern char abc[5];
> char *p = abc;
>
> illetve
>
> extern char *abc;
> char *p = abc;
>
> Az elso esetben ez arra fordul, hogy az offset abc-t tolti be a
> valtozoba, mig a masodikban az abc valtozo erteket. Es ez a ket dolog
> nagyon mas!
Mivel az elso esetben abc erteke az offset "tomb valahol a memoriaban", ezert
a ket dolog ugyan az (SZERINTEM).
Igyexem alatamasztani az allitasomat
---- pelda prog ----
void main() {
char abc[]="ABC";
char *p=abc;
printf("[%p|%p]\n", abc,p);
}
--------------------
>cc x.c
>a.out
[effffc24|effffc24]
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.
Az a kulonlegessege, hogy const. Bizonygatas:
---- pelda prog ----
void main() {
char abc[]="ABC";
char *p=abc;
abc=p;
printf("[%p|%p]\n", abc,p);
}
--------------------
>cc x.c
"x.c", line 4: left operand must be modifiable lvalue: op "="
Szoval levonhato az a kovetkeztetes, hogy az abc egy const pointer.
Tovabb is varialhato a dolog. Barmely string egy pointer-kent fordul le. Es
hasznalhato is ugy, mint egy pointer.
---- pelda prog ----
void main() {
int i;
printf("%p\n", "ABCDE");
printf("%p\n", "ABCDE");
printf("%p\n", "ABCDEF");
for(i=0; i<5; i++) putchar("ABCDE"[i]);
}
--------------------
>cc x.c
>a.out
20ae0
20aec
20af8
ABCDE
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.
Udv From:, a hetero- GEN
Idot, penzt, faradsagot takarit meg, ha idot, penzt, faradsagot takarit meg...
|
+ - | PDA (WinCE) programozas (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Udv mindenkinek!
Olyan embereket keresek, akik a subj.-ban emlitett teruleten
mar alkottak maradandot ;)
Szoval kivancsi vagyok, mit erdemes hasznalni Win CE-vel
megaldott kezi szamitogepeken, mint fejlesztoeszkozt.
Feladat: adatbevitel, adatok internetes cserebereje.
Aki tud valami okosat, kerem e-mailjen (akar maganba is,
hatha nem ez mindenki problemaja...)
Uff!
Hody
|
+ - | Re: String C++ (#438) (mind) |
VÁLASZ |
Feladó: (cikkei)
|
On Fri, 23 April 1999, wrote:
> On 21 Apr 99 at 18:32, Mink Barnabas wrote:
>
> > char def[29];
> > def = abc;
> >
> > Ez ugyan megy, de vigyazni kell, mert a string nem lett atmasolva,
> > csak a def megkapta az abc mutato erteket.
>
> Ez nem jo, nem kap meg def semmit!
Igazad van. Kicsit faradt voltam. 'char *def'-t kellett volna irni, mert
a fenti peldaban a def nem valtozo (es persze az sem volt helyes, hogy
az abc-t mutatonak neveztem).
> Legegyszerubb ugy megnezni ezt, hogy kiprobalod ezt a kettot:
>
> extern char abc[5];
> char *p = abc;
>
> illetve
>
> extern char *abc;
> char *p = abc;
>
> Az elso esetben ez arra fordul, hogy az offset abc-t tolti be a
> valtozoba, mig a masodikban az abc valtozo erteket. Es ez a ket dolog
> nagyon mas!
Tehat:
A tomb offset <-> mutato kulonbseg szemantikailag: Az abc az elso
peldaban egy konstans (-> nem lehet megvaltoztani), ami egy ervenyes
helyre mutat, 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. Utobbinal lehet
pointer aritmetikat hasznalni (pl. ++abc, abc = xyz), elobbinel nem.
Helyes? :-)
Barna
|
+ - | Re: IPC debug (mind) |
VÁLASZ |
Feladó: (cikkei)
|
>Hogy lehet t?bb processt debuggolni?
>A gdb a fork() ut?n a sz?l?n marad. De a bugom az valahol a k?t process
>k?z?tti kommunik?ci?n?l van.
Hat oszinten megmondom, hogy nem vagyok abban biztos, hogy ez a
legegyszerubb megoldas (lehet, hogy van valami undocumented funkcio, ami
kapasbol megmondja). Viszont ez is mukodik (Borland C++ 3.1-el probaltam).
#include <stdio.h>
#include <dos.h>
struct SFTstru {
struct SFTstru far *Next;
unsigned num;
/* a tobbi nem lenyeges most */
}; /* FSstru */
int main (int argc, unsigned char *argv[])
{
struct SFTstru far *SFT; /* Pointer to File System Table */
union REGS regs;
struct SREGS sregs;
unsigned sum = 0; /* ebben szamoljuk ossze az egyszerre megnyithato
file-ok szamat */
regs.h.ah = 0x52; /* List invar */
intdosx(®s, ®s, &sregs);
/* +4, hogy rogton a SFT-re mutato pointerre mutasson */
SFT = MK_FP(sregs.es,regs.x.bx+4);
SFT = SFT->Next; /* Most kapja meg az elso System File Table cimet */
while (FP_OFF(SFT) != 0xFFFF)
{
sum += SFT->num; /* ebben az SFT-ben levo file-ok szama */
SFT = SFT->Next; /* kovetkezo SFT */
} /* while */
printf("FILES=%u\n",sum);
return 0;
} /* main */
|
+ - | Re: TP7 (mind) |
VÁLASZ |
Feladó: (cikkei)
|
CODER #438 szamaban irta:
>A kerdesem a kovetkezo: TP7.0 ban normal graph unitot hasznalva keszult
>kepernyo tartalmat szeretnem kimenteni barmilyen ismert kepformatumban.
Lehet, hogy most adok egy pofont a szinvonalnak :-), de en pancser modon
azt csinaltam, hogy kepszerkesztovel lementettem egy ures 640x480x16c
kepernyot bmp formatumban. Megneztem, melyik bit valtozik, ha valamelyik
sarokba pontot teszek. Ebbol mar tudni lehet a bitkep szerkezetet,
a fejlecet meg adatkent kinyomtam ele. Gyorsabb volt, mint keresgelni
valami kesz rutint. Szerencsere a NeoPaint meg a TP szinpalettaja meg
egyezett is...
Udv:NBela
|
+ - | Clipper error 16 (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Van itt egy 1992-es evjaratu clipper program. A verziojat nem tudom, mert
PkLite tomoritve van. (Fura, de az 1996-os PkLite nem tudja kicsomagolni.)
Sem a forras, sem a keszitoje mar nincs a cegnel. A progi dos alatt 500 k
alatti hagyomanyos memoriaval kifogastalan. Viszont sem Win3, sem Win98 alatt
nem tudom neki a dos kornyezetet beallitani, hogy rendesen fusson, mindig ki
kell lepni dos modba. Ha a win ott figyel a hatterben, akkor a progi futas
kozben internal error 16 hibajelzessel (irodalom szerint "Az adatbazis nincs
nyitva.") kiakad. A hagyomanyos memoria 600 k, az egyeb memoriakat pedig
probaltam automatikusra, fixre, ems-t engedni, tiltani, de nem megy.
Set clipper=f60;e0 dos es win alatt is. A config.sys-ben probaltam picit
nagyobbra allitani a buffers, files, stacks, fcbs kapcsolokat, de tovabbra
is csak tiszta dos alatt hajlando menni. A win indito parancs tulajdonsagainal
talan minden pipat megprobaltam mar ki-be kapcsolni, de semmi eredmeny.
Otletek?
Udv:NBela
|
+ - | Re: String C++ (mind) |
VÁLASZ |
Feladó: (cikkei)
|
> Mindkettotoknel az a felreertes, hogy a C-ben a tomb es a pointer
> allitolag (sok konyv szerint is) ugyanaz a dolog. Ez nem igaz!
>
> Ez a felreertes abbol adodik, hogy egy szubrutinhivaskor a tombot cim
> szerinti parameteratadassal, minden mast pedig ertek szerint ad at a
> C. Tehat ugy tunik, mintha a tomb egy pointer lenne, de ez csak
> latszat.
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 modosithatomabc++; nem mukodik :)))
de ugyanakkor egy pointer, mert :
char a[11]="abcdefghij";
char *b;
void main()
{
a[10]=0; // csak a string vege miatt.
printf("%s\n",a);
b=a; // tehat, hogyha "a" nem pointer, akkor
ez sem mukodne
printf("%s\n",b);
b++; // na itt van az, hogy ez megy, mert "b"
valtozo, es az "a++"
printf("%s\n",b); //nem menne, mert "a constans"
b=a+1; // na de itt a lenyeg, a erteket megnovelem
1 el, es ez nem
//1 byte-ot jelent, hanem annyit,
amekkorak a tomb elemei
printf("%s\n",b);
b="akarmi";
printf("%s\n",b);
}
tehet "a" nem csak a fugvenyhivaskor lesz pointer, hanem az ertekadasnal,
es a muveleteknel is az, de erteket nem valtoztathatjuk meg. Szereny
olvasatomban ez azt jeleti, hogy "a" egy konstans pointer. 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.
remelem nem voltam tul hosszu.
PP
|
+ - | WRI es DOC beolvaso (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Ha van valakinek kozuletek Delphi ala olyan unitjai amik segitsegevel
*.wri azaz windows write allomanyokat lehet megjeleniteni, vagy olyan ami
*.doc azaz Winword dokumenteket tud beolvasni, akkor elkuldhetne nekem.
Elore is kosz.
Elekes Karoly
|
+ - | client32/DOS + packet driver? IGEN! (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Szevasztok!
Sikerult vegre utana jarnom, hogy lehet-e packet drivert illeszteni a
Netware Client32/DOS-hoz. IGEN a valasz. Tenyleg megy, igen gyors. A
client32 egyszeruen zsenialis. Nem foglal helyet 640K alatt, meg az
UMB-ben sem.
Igy kell a client32-hoz a packet drivert megcsinalni:
1. Telepiteni kell a client32-t, vagy a Netware-hez adott CD-rol, vagy a
http://www.novell.com/download-on lehet megtalalni. A TCPIP telepitese
nem szukseges, de nem is baj.
2. Mind a negy ethernet frame-et (_802.2, _802.3, _II, _SNAP) telepiteni
KELL, e nelkul nem fog menni a packet driver. Tenyleg nem!
3. Ha a netware-be belepes, meg minden egyeb jol megy, akkor a
startnet.bat-ba kell meg harom sor:
lsl.com
pdoseth.com
odipkt.com
4. A NET.CFG-be is kellenek am dolgok:
Link support
buffers 1 1600
Link Driver PDOSETH
Frame ETHERNET_II
Figyelem!
- A [Link Support] resz nelkul az ODIPKT valahogy nem megy (nalam
legalabbis).
- Ha a pdoseth nem akar elindulni, az lehet azert, mert nem mind a negy
ethernet frame van benne a startnet.bat-ban!
- Ha nem mennek a packet driver-es programok, mert nem ethetner packet
drivert talalnak, akkor az ODIPKT-t esetleg
odipkt 1 0x60
modon kell hasznalni. Fontos, hogy mikor elindul, ilyet irjon ki:
Using Ethernet framing, class 1
Registered as high priority chained default stack
ODIPKT is installed and ready.
Iderakom az en STARTNET.BAT-omat es NET.CFG-met okulasul:
~~~~~ STARTNET.BAT ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Link support
buffers 1 1600
Link Driver PDOSETH
Frame ETHERNET_II
# Protocol IPX 8137 ethernet_II
# Protocol ip 0800 ethernet_II
# Protocol arp 0806 ethernet_II
# Protocol rarp 8035 ethernet_II
NetWare DOS Requester
NETWARE PROTOCOL = NDS, BIND
BIND RECONNECT = ON
FIRST NETWORK DRIVE = N
PREFERRED SERVER = xxxxx
preferred tree = xxxxxxx
SHOW DOTS = ON
file cache level 1
~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~ NET.CFG ~~~~~~~~~~~
@ECHO OFF
CD C:\NOVELL\client32
SET NWLANGUAGE=ENGLISH
C:\NOVELL\CLIENT32\NIOS.EXE /l > \boot.log
LOAD C:\NOVELL\CLIENT32\NBIC32.NLM >> \boot.log
LOAD C:\NOVELL\CLIENT32\LSLC32.NLM >> \boot.log
LOAD C:\NOVELL\CLIENT32\CMSM.NLM >> \boot.log
LOAD C:\NOVELL\CLIENT32\ETHERTSM.NLM >> \boot.log
LOAD C:\NOVELL\CLIENT32\PCISRV.LAN FRAME=ETHERNET_802.3 >> \boot.log
LOAD C:\NOVELL\CLIENT32\PCISRV.LAN FRAME=ETHERNET_II >> \boot.log
LOAD C:\NOVELL\CLIENT32\PCISRV.LAN FRAME=ETHERNET_SNAP >> \boot.log
LOAD C:\NOVELL\CLIENT32\PCISRV.LAN FRAME=ETHERNET_802.2 >> \boot.log
rem LOAD C:\NOVELL\CLIENT32\TCPIP.NLM >> \boot.log
LOAD C:\NOVELL\CLIENT32\TRANNTA.NLM >> \boot.log
LOAD C:\NOVELL\CLIENT32\IPX.NLM >> \boot.log
LOAD C:\NOVELL\CLIENT32\SPX_SKTS.NLM >> \boot.log
LOAD C:\NOVELL\CLIENT32\CLIENT32.NLM >> \boot.log
lh lsl.com >> \boot.log
lh pdoseth >> \boot.log
lh odipkt >> \boot.log
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Graff Zotyo'
|
+ - | C++ stringbe levo kodok (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Sziasztok,
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.
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.
Pl: hexaban ha ascii 2-t szertnek beteni es utanna a default szot
irom, akkor a fordito nem fogadja el ("\x02default"). Jelenleg ez csak
oktalisban van megoldva (!?), mert ott mindig pontosan harom jegyet
(vagy kevesebbet) ker, igy elo '0'-kal kiegieszitve az oktalis szamot,
soha nem lehet gond a koveto uzenettel, meg akkor sem, ha az szam.
Ha valaki foglakozott mar ezzel a problemaval es meg tudja mondani,
hogy miert igy van, es mit lehet ellene tenni, kerem irjon
Koszonettel
Szasz Oliver
|
+ - | Filehandles (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Hi !
> Dos -os kornyezetben hogyan lehet lekerdezni, hogy az oprencer
> hany szabad file kezelot biztosit (dos, win95/98/nt dos ablaka).
[...]
> Van erre elegans megoldas, vagy nyissak meg valamit ahanyszor csak tudok,
> es ezt szamoljam? :)
A Clipper Toolsban mintha lett volna ilyesmi fuggveny.
Mindenesetre lenne egy kevesse elegans megoldasom.
Annal amit te felvetettel a fenti idezetben mondjuk elegansabb ! :-)))
Talan inkabb nyisd meg a config.sys/config.nt file-t es olvasd ki belole
!! :-))
Ha van OS=Windows_NT kornyezeti valtozod akkor NT-ben futsz, ha nincs
akkor w95-ben, vagy masban. (ez ahhoz kellhet, hogy tudd mit keress)
Azert remelhetoleg kapsz erre valami egyszerubb rutin hivasos megoldast
is.
Udv:
--
Csiszar L.
http://www.stadium.hu/szt/
|
+ - | Ellipszis (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Sziasztok, ime nehany ellipszises dolog:
Kerulete K:=pi*(((a+b)/2)+sqrt((a*a+b*b)/2))
vagy K:=pi*(1.5*(a+b)-sqrt(a*b))
vagy K:=4*(pi*a*b+(a-b)*(a-b))/(a+b)
Metszes pontok, felteve, hogy az elso kanonikus, a masodik
kozeppontja illeszkedik az x tengelyre, azaz
Elso egyenlete:
x*x/(a*a)+y*y/(b*b)=1
a,b:feltengelyek
Masodik egyenlete:
(x-u)*(x-u)/(c*c)+y*y/(d*d)=1
u:kp. x koordinataja, c,d feltengelyek
Az
x*x(b*b/(a*a)-d*d/(c*c))+x*(2*u*d*d/(c*c))+(d*d-b*b-u*u)=0
egyenlet megoldasa adja a metszespontok x koordinatajat.
Rajzolashoz az affinitas miatt:
x:=a*cos(fi);
y:=b*cos(fi);
a,b:feltengelyek.
Remelem nem gepeltem el semmit....
Falu, aki egyebkent nem matematikus, 'csak' matek
szakos
|
+ - | bitszamolas (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Sziasztok jatekos kedvu coder-ek!
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.
István
-- Istvan Marosi -- http://www.sch.bme.hu/~marosi --
-- Recosoft Ltd. -- mailto: --
|
|