|
Hinnavaatlus
:: Foorum
:: Uudised
:: Ärifoorumid
:: HV F1 ennustusvõistlus
:: Pangalink
:: Telekavad
:: HV toote otsing
|
|
| autor |
|
taurib
HV vaatleja
liitunud: 26.08.2010
|
26.01.2012 19:11:10
Programm C keeles programeerimiseks |
|
|
| Selline küsimus, et kas on mingit head programmi, millega saaks ilusti C keeles programmeerida. Eelistaks midagi taolist, nagu on Microsoft Visual Studio, kuid ma ei näinud kusagil midagi, mis oleks lihtsalt C keeles :/
|
|
| tagasi üles |
|
 |
lehm2
Kreisi kasutaja

liitunud: 19.09.2004
|
26.01.2012 20:05:27
|
|
|
Võid ju proovida vim-i täitsa C keeles kirjutatud ja rohkemate võimalustega kui visual studio.
_________________ Piilu siia, progreja!
Vajad abi Node.JS-ga ?
Võta ühendust ! |
|
| Kommentaarid: 15 loe/lisa |
Kasutajad arvavad: |
   |
:: |
0 :: |
0 :: |
13 |
|
| tagasi üles |
|
 |
Mnator
HV Guru
liitunud: 18.10.2007
|
26.01.2012 20:08:35
Re: Programm C keeles programeerimiseks |
|
|
| taurib kirjutas: |
| Selline küsimus, et kas on mingit head programmi, millega saaks ilusti C keeles programmeerida. Eelistaks midagi taolist, nagu on Microsoft Visual Studio, kuid ma ei näinud kusagil midagi, mis oleks lihtsalt C keeles :/ |
MS Visual Studio võimaldab väga ilusti puhtalt C programmi kirjutada. Ma ei saa aru milles üldse probleem.
|
|
| Kommentaarid: 1 loe/lisa |
Kasutajad arvavad: |
   |
:: |
0 :: |
0 :: |
1 |
|
| tagasi üles |
|
 |
tonism
Kreisi kasutaja
liitunud: 30.06.2002
|
26.01.2012 20:25:59
|
|
|
| Lisaks on veel olemas Microsoft Visual Studio Express, mis on t2iesti tasuta. Sealt saab valida installimise ajal, et tahad ainult C-d ning korras.
|
|
| Kommentaarid: 5 loe/lisa |
Kasutajad arvavad: |
   |
:: |
0 :: |
0 :: |
5 |
|
| tagasi üles |
|
 |
taurib
HV vaatleja
liitunud: 26.08.2010
|
|
| tagasi üles |
|
 |
Fukiku
Kreisi kasutaja

liitunud: 06.11.2003
|
|
| Kommentaarid: 2 loe/lisa |
Kasutajad arvavad: |
   |
:: |
0 :: |
0 :: |
2 |
|
| tagasi üles |
|
 |
Ho Ho
HV Guru

liitunud: 16.02.2002
|
26.01.2012 22:08:32
|
|
|
QT creatorist asisemat c/c++ IDE't pole lihtne leida: http://qt.nokia.com/products/developer-tools/
_________________ Teach a man to reason and he'll think for a lifetime
Common sense - so rare that it's a damn superpower
Vaadates paljude inimeste sõnavõtte siin ja mujal jääb üle ainult klassikuid tsiteerida - "I weep for humanity" |
|
| Kommentaarid: 107 loe/lisa |
Kasutajad arvavad: |
   |
:: |
0 :: |
1 :: |
87 |
|
| tagasi üles |
|
 |
keevitaja
AM 10 aastat

liitunud: 05.11.2001
|
|
| Kommentaarid: 51 loe/lisa |
Kasutajad arvavad: |
   |
:: |
1 :: |
3 :: |
40 |
|
| tagasi üles |
|
 |
Timukas0
HV kasutaja

liitunud: 20.03.2007
|
27.01.2012 01:52:55
|
|
|
| Visual Studio töötab väga hästi. Projekti tehes vali "Visual C++ Empty Project" vms, projektile faile lisades võta "C++ File (.cpp)", aga käsitsi muuda faililaiend .c-ks ja töötab kenasti.
|
|
| Kommentaarid: 3 loe/lisa |
Kasutajad arvavad: |
   |
:: |
0 :: |
0 :: |
3 |
|
| tagasi üles |
|
 |
taurib
HV vaatleja
liitunud: 26.08.2010
|
27.01.2012 17:31:03
|
|
|
Aga kas ta töötab ka sedasi, et ta annab soovitusi ja leiab koodis vigaseid kohti üles?
Kuna see siiski ju mõeldud olema C++ keele jaoks
|
|
| tagasi üles |
|
 |
keevitaja
AM 10 aastat

liitunud: 05.11.2001
|
27.01.2012 17:47:07
|
|
|
taurib, proovi seda lcc-d
_________________ Hinnavaatlus ei ole koht arvamuse avaldamiseks! |
|
| Kommentaarid: 51 loe/lisa |
Kasutajad arvavad: |
   |
:: |
1 :: |
3 :: |
40 |
|
| tagasi üles |
|
 |
Ho Ho
HV Guru

liitunud: 16.02.2002
|
27.01.2012 18:04:40
|
|
|
| taurib kirjutas: |
Aga kas ta töötab ka sedasi, et ta annab soovitusi ja leiab koodis vigaseid kohti üles?
Kuna see siiski ju mõeldud olema C++ keele jaoks |
c on c++ alamhulk seega valdavalt näitab küll.
Samas msvc pole puhta c jaoks kaugeltki mitte parim kompilaator kuna c99 tugi on suht vilets ning tasuks pigem eelistada muid asju mis on korrektselt c jaoks tehtud a'la GCC kollektsioon. Muidugi IDE pead siis nende ümber ka otsima. Too eespool välja käidud qt-creator töötab väga edukalt sellena. samuti dev-cpp kuid too on suht ürgajast ning ei pruugi olla eriti stabiilne
_________________ Teach a man to reason and he'll think for a lifetime
Common sense - so rare that it's a damn superpower
Vaadates paljude inimeste sõnavõtte siin ja mujal jääb üle ainult klassikuid tsiteerida - "I weep for humanity" |
|
| Kommentaarid: 107 loe/lisa |
Kasutajad arvavad: |
   |
:: |
0 :: |
1 :: |
87 |
|
| tagasi üles |
|
 |
mihkelv
HV kasutaja
liitunud: 25.02.2004
|
|
| Kommentaarid: 6 loe/lisa |
Kasutajad arvavad: |
   |
:: |
0 :: |
1 :: |
5 |
|
| tagasi üles |
|
 |
poles
HV kasutaja
liitunud: 13.02.2006
|
29.01.2012 14:36:08
c |
|
|
| mina kasutan c õppimiseks codeblocks.siis on olemas veel imagecraft ja avr i jaoks AVR Studio.saab mikrokontrollerisse proge sisse lugeda(avr i)
|
|
| Kommentaarid: 36 loe/lisa |
Kasutajad arvavad: |
   |
:: |
0 :: |
0 :: |
33 |
|
| tagasi üles |
|
 |
neros
HV Guru

liitunud: 26.11.2003
|
30.01.2012 06:48:09
|
|
|
Ma küsiks lihtsalt sportlikust huvist mille tarbeks just nimelt C'd kirjutada? Lihtsalt enese arendamiseks sobib ka Visual Studio, aga kui plaanis on kernelit kirjutama hakata, on "programm C keeles programmeerimiseks" küll su kõige väiksem mure...
_________________ GitHub
.NET Core & Azure baasil lahendused ja arhitektuur - kontakt. |
|
| Kommentaarid: 48 loe/lisa |
Kasutajad arvavad: |
   |
:: |
0 :: |
1 :: |
40 |
|
| tagasi üles |
|
 |
kalvis
Kreisi kasutaja
liitunud: 20.10.2009
|
30.01.2012 16:00:19
|
|
|
Dev-C++ IDE eelis on et on suhteliselt lihtne. Ja MinGW kirjutatud programme saad kasutada nii Linuxis kui Windowsis. Dev-C++ häda algab, kui kasutad väga keerukaid kompileerimisi, vähemalt ma ei tea MAKE tegemise võimalust. Teine viga, et Dev-C++ pole edasi arendatud, võiks C uusima standardi asjad kasutusel olla.
Codeblock on algselt välja arendatud Dev-C++-st ja talle on kilokaupa lisatud uusi võimalusi, kuid ma upun nendesse. Igatahes, kui juba tunned et Dev-C++ hakkab kitsaks jääma, kolid Codeblock-i üle. Või mõnda teise keskkonda.
Minu soovitus on, et kui kirjutad kuhugi programme siis arenda ennast neis keskkondades, mis on universaalsed. Et töötab nii Linuxis kui Windowsis. See linuxi tugi on ju oluline ka uutele android mobladele, kui Mac-le. Ja see võimalus on ju olemas.
C eelis teiste kõrgkeelte ees on suurem paindlikkus ja pigem tasuks rohkem C++ orienteeruda, kuid mis teha, väga palju programme või librareid on C kirjutatud ja erinevus C++ on imeväike. Minu jaoks on nad üks ja seesama sõltuvalt kumba rohkem vajatakse.
C suurimaks puuduseks pean tüüpides valitsevat segadust, uusim standard justkui hakkas seda lahendama, kuid kompilaatorite vilets toetus, äraspidised lahendused jne. Ei teagi, kas soovitada kolimist ükskõik millisele teisele kõrgkeelele või assemlerisse, jään edaspidi foorumit sellel teemal jälgima. Miks seda tõstatasin on lihtne - tänapäevased protsessorid on 32/64 bitti ja mälu on üksjagu, kuid C keele keskkond on justkui pärit 8 bit maailmast. Halvad andmetüübid takistavat kiiret andmetöötlust. Teistes kõrgkeeltes pole sedagi võimalust. C pluss on ka paljude kontrollerite toetus.
|
|
| tagasi üles |
|
 |
Ho Ho
HV Guru

liitunud: 16.02.2002
|
30.01.2012 16:49:21
|
|
|
| kalvis kirjutas: |
| Ja MinGW kirjutatud programme saad kasutada nii Linuxis kui Windowsis |
Sõltub tugevalt milliseid teeke kasutad. Kui ikka rõõmsalt directx'i või winapit torgid siis ega ikka ei kasuta küll niisama lihtsalt muude OS'ide all. Samuti porditav on ainult kood selles mõttes, et tegu on GCC'ga mis on ise porditud eri platvormidele ning suudab igal pool töötada.
| kalvis kirjutas: |
| Igatahes, kui juba tunned et Dev-C++ hakkab kitsaks jääma, kolid Codeblock-i üle. Või mõnda teise keskkonda. |
Ise ütleks, et pigem üldse dev-cpp vahele jätta ning kohe miskit asist kasutama hakata. Viimased devcpp kasutamised jäid kusagile 2002-2004 vahele ning ka tol ajal oli tegu üsnagi ebastabiilse asjaga. Arvestades, et juba siis oli tegu üsna mahajäetud asjaga siis väga ei imestaks kui ta praegugi ebastabiilne oleks. Samuti on selles debugimine vaat et hullemgi, kui otse GDB käsureal möllata. Ehk siis nagu ütlesin tasuks dev-cpp vahele jätta. Vähemalt ma ei näe ainsamatki mõistlikku põhjust miks seda võiks keegi tahta kasutada.
| kalvis kirjutas: |
| C eelis teiste kõrgkeelte ees on suurem paindlikkus ja pigem tasuks rohkem C++ orienteeruda, kuid mis teha, väga palju programme või librareid on C kirjutatud ja erinevus C++ on imeväike. Minu jaoks on nad üks ja seesama sõltuvalt kumba rohkem vajatakse. |
Nii ja naa. C99 küll laias laastus küll mingil määral ühilduv c++ kuid alates c++98 ning eriti c++11 puhul on juba tegu suhteliselt suure erinevusega asjadega kus enam korrektne ja c99 standardeile vastav kood ei pruugi c++'na kompileeruda.
| kalvis kirjutas: |
| C suurimaks puuduseks pean tüüpides valitsevat segadust |
Pead silmas noid (u)intN_t tüüpe? MS on juba ammu öelnud, et nemad ei plaanigi oma kompilaatoris noid ega paljusid teisi c99 featureid toetama hakata. Muud kompilaatorid aga toetavad neid üsna kenasti ning ma küll ei ütleks, et nendega erilist probleemi oleks.
| kalvis kirjutas: |
| Miks seda tõstatasin on lihtne - tänapäevased protsessorid on 32/64 bitti ja mälu on üksjagu, kuid C keele keskkond on justkui pärit 8 bit maailmast. Halvad andmetüübid takistavat kiiret andmetöötlust |
Pead silmas SIMD käskude puudulikkust? Intrinsicud töötavad üsna kenasti, miskit asisemat tahad siis tuleb mõnd erispets libraryt pruukima hakata. Kui pead silmas miskit muud siis räägi lähemalt kuna peale 16bit borlandi nodi pealt uuemate peale kolimist pole ma erilisi probleeme täheldanud.
_________________ Teach a man to reason and he'll think for a lifetime
Common sense - so rare that it's a damn superpower
Vaadates paljude inimeste sõnavõtte siin ja mujal jääb üle ainult klassikuid tsiteerida - "I weep for humanity" |
|
| Kommentaarid: 107 loe/lisa |
Kasutajad arvavad: |
   |
:: |
0 :: |
1 :: |
87 |
|
| tagasi üles |
|
 |
andreie
HV vaatleja

liitunud: 09.09.2006
|
31.01.2012 17:10:35
|
|
|
Ho Ho, head uudised - MSVS 2010-ga tuleb kaasa <stdint.h>. Kogu aeg kasutan Muidugi, <stdbool.h> on ikka veel puudu.
_________________ Unix survives only because everyone else has done so badly. |
|
| Kommentaarid: 5 loe/lisa |
Kasutajad arvavad: |
   |
:: |
0 :: |
0 :: |
5 |
|
| tagasi üles |
|
 |
Ho Ho
HV Guru

liitunud: 16.02.2002
|
31.01.2012 17:52:27
|
|
|
| andreie kirjutas: |
Ho Ho, head uudised - MSVS 2010-ga tuleb kaasa <stdint.h>. Kogu aeg kasutan  |
Tean jah kuid sellest on vähe kasu kui c99 standardile kompilaator endiselt ei vasta. Samas mind isiklikult see niiväga ei kurvasta kuna pigem kasutan c++11't ning tolle tugi peaks tolles MSVC versioonis suht-koht asjalik olema
_________________ Teach a man to reason and he'll think for a lifetime
Common sense - so rare that it's a damn superpower
Vaadates paljude inimeste sõnavõtte siin ja mujal jääb üle ainult klassikuid tsiteerida - "I weep for humanity" |
|
| Kommentaarid: 107 loe/lisa |
Kasutajad arvavad: |
   |
:: |
0 :: |
1 :: |
87 |
|
| tagasi üles |
|
 |
taurib
HV vaatleja
liitunud: 26.08.2010
|
31.01.2012 20:17:41
|
|
|
Point on selles, et ma ise kasutan ka Microsoft Visual C# Seal on see hea asi, et ta tunneb ära, kus kohas on koodis vead sees ja kõik on väga mugavalt organiseeritud ja saab ka ise vajadusel välimust organiseerida. Koolis soovitati kasutada Geany't, mis ei ole just eriti mugav programm (vähemasti mulle ei meeldi).
C keelt ma õpin hetkel ka selle tõttu, et koolis olid mul valik ained ja ma leidsin, et programine on kõige mõistlikum nende seast minu jaoks, ning siis ma võtsin selle. Kahjuks oli valik ainult C keelt õppida, kuid samas, see ei ole (tohiks) olla nii väga erinev teistest taolistest (C++, C#), et sealt edasi õppimisega ei tohiks nii väga raskusi olla
Ma proovisin ka Microsoft Visual Stuidos (C# omas) C keeles teha, kuid ta ei tundnud väga ära seda keelt, või ei oska ma seda lihtsalt õigesti seadistada seal
|
|
| tagasi üles |
|
 |
kalvis
Kreisi kasutaja
liitunud: 20.10.2009
|
01.02.2012 13:07:59
|
|
|
| tsitaat: |
Sõltub tugevalt milliseid teeke kasutad. Kui ikka rõõmsalt directx'i või winapit torgid siis ega ikka ei kasuta küll niisama lihtsalt muude OS'ide all. Samuti porditav on ainult kood selles mõttes, et tegu on GCC'ga mis on ise porditud eri platvormidele ning suudab igal pool töötada.
|
Teekide kasutamisel eelistan teeke, mida saab kasutada nii Linuxis, kui Windowsis. DirectX peaaegu ei kasuta, kuna on rohkem only Windows toode. Maailmas on ühe ja sama asja tegemiseks neid teeke ikka üksjagu samasuguseid ja vähe erinevad. Käsk teeb üht ja sama asja, kuid ühel on piiratud programmi kasutus vaid ühe op.süsteemiga, teisel kasuta kus iganes. Kasulikum on seega õppida pigem kus iganes keskkonna oma.
| tsitaat: |
Ise ütleks, et pigem üldse dev-cpp vahele jätta ning kohe miskit asist kasutama hakata. Viimased devcpp kasutamised jäid kusagile 2002-2004 vahele ning ka tol ajal oli tegu üsnagi ebastabiilse asjaga. Arvestades, et juba siis oli tegu üsna mahajäetud asjaga siis väga ei imestaks kui ta praegugi ebastabiilne oleks. Samuti on selles debugimine vaat et hullemgi, kui otse GDB käsureal möllata. Ehk siis nagu ütlesin tasuks dev-cpp vahele jätta. Vähemalt ma ei näe ainsamatki mõistlikku põhjust miks seda võiks keegi tahta kasutada.
|
Olen proovinud Dev-C++ pealt muudele üle kolida, allesjäämiseks on Dev-C++ keskkonna lihtsus. Kui erilisi teeke ei kasuta, on väga lihtne ja hea keskkond alustamiseks. Arvasin sama, et kolin vingemale keskkonnale üle, kiideti CodeBlocki, installeerisin ja peatselt kolisin tagasi või noh-niiöelda kasutan fifty-fifty - Codeblockis peamiselt kirjutan ja Dev-C++ kompileerin. Codeblock on minu jaoks praegu kummaline raketiteadus, programm kompileerub ilma ühegi veata, Dev-C++ töötab sama programm nii nagu peab, Codeblocki oma aga mitte. Lihtsalt ignoreerib teekides mõningaid käske. Juu siis on kompileerimisel mingid parameetrid paigast ära aga viga ei anna.
Äkki soovitad veel C keele kompilaatori vabavaralisi programme - milles oleks lihtne teeke kasutada ja juurde lisada (et see poleks raketiteadus) ja oleks tugi MAKE ja INSTALL tüüpi juhtumitele. Väga Bro oleks kui oleks tugi ka assemblerile, oskan viimast kasutada (peamiselt mikrokontrolleritele neis kirjutangi) ja üha enam on soov kiiruskriitilised asjad otse C-s assembleris kirjutada, võibolla õudusunenägu kuid just läbisegamini niimoodi - mitmed bitioperatsioonid, täisarvude lihtaritmeetika, muutujate omistamine ja ühest tüübist teise konverteerimine jne. teha assembleris, kus tehtele kulub vaid üks assembleri käsk, kuid C keskkonda jätaksin keerulised aritmeetika tehted, samuti mitte aegkriitilised teegid, failide operatsioonid (kus assembleris läheks käske kilokaupa). Mind huvitab igas programmis just kiirus, kiirus...
| tsitaat: |
Pead silmas noid (u)intN_t tüüpe? MS on juba ammu öelnud, et nemad ei plaanigi oma kompilaatoris noid ega paljusid teisi c99 featureid toetama hakata. Muud kompilaatorid aga toetavad neid üsna kenasti ning ma küll ei ütleks, et nendega erilist probleemi oleks.
|
JAH. Ma olen praegu suure dilemma ees mida teha. On vaja suuri andmemassiive töödelda kiiresti (multimeedia bitiväljad). 32 bit prosele oleks kiireim meetod 32 bitiga data ette anda ja teha operatsioone (lihtsad JA/VÕI/XOR tehted bittide, maskide omavahel ja lihtsalt ühest muutjast teise). Point on selles, et paljud C lähenemised on 8 bitiga. ma kaotan 4 korda töökiirust kui peaksin 8 bitiga mässama. Mul on vaja lugeda 8 bitist masiivi 32 bitina, töödelda ja tagasi kirjutada 8 bitisesse massiivi 32 bitina. Kusjuures on veel Low ja High kirjutamise eripära. Vot nüüd ongi mängus C tüübid. Praegused C tüübid ei lase mul lihtsalt 8 <-> 32 bitiseid lähenemisi teha. On kaks lahendust - kasutada kas assemblerit või C muid tüüpe. C tüüpide lahendust proovisin, osade trikkidega kompileerus, kuid sain runtime errorid. Üldiselt kipub C asi ummikusse minema. Seevastu assembleris toimib. Kuid mu eesmärk oleks kirjutada only C programm.
| tsitaat: |
Pead silmas SIMD käskude puudulikkust? Intrinsicud töötavad üsna kenasti, miskit asisemat tahad siis tuleb mõnd erispets libraryt pruukima hakata. Kui pead silmas miskit muud siis räägi lähemalt kuna peale 16bit borlandi nodi pealt uuemate peale kolimist pole ma erilisi probleeme täheldanud.
|
EI. Eespool on asja kirjeldatud, kogu maailmas on sarnast asja küsitud, kuid vastused on ikka umbmäärased, kui C kompilaator välja mõeldi, seda probleemi polnud. Seal oligi vastus, et C hästi ei saa (sõltub kompilaatori kirjutajast), kasutage assemblerit. No ma siis kasutan.
Kuna tundub asisemad vastused/küsimused olevat siis küsin veel:
Kus, kas on eestis foorumit, kus saaks C ja assembleri või muude programmeerimiskeelte kohta küsimusi vastuseid lugeda, arutada jne. Vanasti kasutasin newsgroupi ja sellest piisas, kuid kui ISP ja tööandja lõpetasid nende toe siis enam ei saa neid lugeda/kirjutada.
Sama asi maailmas - kus saaks progemisalaseid küsimusi/vastuseid. Kui ma ikka küsin siis mitte "Hello world" teemal vaid ikka raualähedasi või keerulisi asju. Progemiselt olen ikka harrastaja ja rohkem raua tasand huvitab.
|
|
| tagasi üles |
|
 |
Ho Ho
HV Guru

liitunud: 16.02.2002
|
01.02.2012 15:13:59
|
|
|
| kalvis kirjutas: |
| Olen proovinud Dev-C++ pealt muudele üle kolida, allesjäämiseks on Dev-C++ keskkonna lihtsus |
dev-c++ oli enam-vähem kasutatav kui projekt koosnes <10 failist. Üle selle läks asi üsna käest ära. Stabiilsus, koodilõpetus lõpetas töötamise ning makefile'i muutmine oli pehmelt öeldes tülikas. Rääkimata debugimisest mis on sõltumata projekti suurusest seal pehmelt öeldes ebamugav. Samuti sõltumata projekti suurusest on üsna lootusetu üritada sama projektifaili kaudu kompileerida oma softi eri platformidele
| kalvis kirjutas: |
| Codeblock on minu jaoks praegu kummaline raketiteadus, programm kompileerub ilma ühegi veata, Dev-C++ töötab sama programm nii nagu peab, Codeblocki oma aga mitte. Lihtsalt ignoreerib teekides mõningaid käske. Juu siis on kompileerimisel mingid parameetrid paigast ära aga viga ei anna. |
Arvestades, et mõlemad kasutavad sama kompilaatorit (GCC) siis on suure tõenäosusega jah viga kompilaatoriseadetes. Muidugi tuleks arvestada ka sellega, et dev-cpp kasutab tänapäeva mõistes ürgset üle 7a vanust GCC'd. Ma väga ei imestaks, kui nii vana versioon suudab kompileerida vigast koodi mida uuemad enam ei suuda. Muidugi kui annaksid konkreetse koodinäite ning veateated siis oleks võimalik paremini öelda milles asi.
| kalvis kirjutas: |
| Äkki soovitad veel C keele kompilaatori vabavaralisi programme - milles oleks lihtne teeke kasutada ja juurde lisada (et see poleks raketiteadus) ja oleks tugi MAKE ja INSTALL tüüpi juhtumitele. |
Hetkel vist ikka tahad IDE't aka töökeskonda, mitte kompilaatorit. Ehk siis dev-c++, code::blocks ja qt-creator on IDE'd kes kõik vaikimisi kasutavad gcc kompilaatorit. Assembleri tugi sõltub samuti kompilaatorist, IDE võib lihtsalt seda ilusamaks värvida sulle.
Üks asi mis veel wini all jookseb on Eclipse koos c++ arenduse pluginatega kuid pole eriti kursis kui kaugele selle arendusega jõutud on. Viimati sai seda torgitud rohkem kui 5a tagasi. Linuxis on muidugi IDE'sid jalaga segada
Ise kasutan igal võimalikul juhul qt-creatorit kuna sel on üsna asjalik debuggeri ja profileerija tugi + qmake'i põhine projektifailidega majandamine mis on oluliselt lihtsam otse käsitsi makefile'de tegemisest kuid mis vajadusel geneerib sulle ka noodsamad makefile'd et saaksid neid ilma qmake'ta jooksutada. Loomulikult on ka tekstiredaktor ise vägagi asjalik, julgeks väita et oluliselt parem kui MSVC. Samuti oskab juba enne kästitsi kompileerimist ära öelda kui mõni viga koodis on.
Kui on vaja winmobile peale nodi kirjutada siis tuleb ka paratamatult MSVC'd kasutada kuid too ei ole vabavaraline ning ei suuda ka gcc'ga eriti hästi koostööd teha. Debugger on küll päris hea kuid nii mõnegi muu koha pealt jätab soovida, vähemalt kui eesmärk kirjutada c/c++ rakendusi.
Edasine kisub juba pisut offtopicuks kui jutt on kompilaatoritest-IDE'dest:
| kalvis kirjutas: |
| Mind huvitab igas programmis just kiirus, kiirus |
Kergelt offtopic aga millal sa otsustad mis hetkel tuleks mingi algoritmi osa assembleris kirjutada? Loodan, et sellele ikka eelneb põhjalik profileerimine ning hiljem ka võrdlus c/c++ vs assembleri kiiruses. Niisama kohvipaksu järgi suvalise koha pealt optimeerimine kaugele ei vii, eriti arvestades kui asjalikuks on muutunud GCC 4.x seeria optimeerimisvõimalused. Tean inimesi kes kirjutasid reaalaja ray tracing graafikamootoreid ning jätsid seal optimeerimise kompilaatori hooleks kuna ükskõi kui palju ka üritati ei suudetud assembleri kaudu paremat tulemust välja võluda
| kalvis kirjutas: |
| On vaja suuri andmemassiive töödelda kiiresti (multimeedia bitiväljad). 32 bit prosele oleks kiireim meetod 32 bitiga data ette anda ja teha operatsioone (lihtsad JA/VÕI/XOR tehted bittide, maskide omavahel ja lihtsalt ühest muutjast teise). Point on selles, et paljud C lähenemised on 8 bitiga. ma kaotan 4 korda töökiirust kui peaksin 8 bitiga mässama. Mul on vaja lugeda 8 bitist masiivi 32 bitina, töödelda ja tagasi kirjutada 8 bitisesse massiivi 32 bitina. |
Hetkel jääb vägisi mulje, et teed midagi fundamentaalsel tasemel valesti. Alles paar aastat tagasi sai tegeldud suht-koht suure andmehulga reaaalajas töötlemisega ning polnud vähimatki probleemi vector<char> massiive töödelda kui 32bit int'e. Mis sulle täpsemalt seal probleeme tekitab? Ehk tekitaksid selle kohta uue teema et ei peaks siin teemaväliseid probleeme lahkama? Seda ka muidugi, et SIMD käsustikku kasutades saaksid sa töödelda korraga andmeid vähegi uuemal prosel 128bit blokkide kaupa, veel uuematel 256biti kaupa ning seejuures võid selle jagada 8, 16, 32 või 64bit "ühikuteks". Ehk siis peaks tulemus olema veel kordades kiirem, kui lihtsalt niisama 32biti kaupa möllates.
| kalvis kirjutas: |
| Kus, kas on eestis foorumit, kus saaks C ja assembleri või muude programmeerimiskeelte kohta küsimusi vastuseid lugeda, arutada jne. |
Kohalikke foorumeid vist polegi eriti, vähemalt ühtki mis praegu elutseks. Küll on mõned php ja veebiarendusse puutuvad kohad kuid seal vaevalt eriti c/c++ kohta abi leiad. Välismaistest sai kunagi aktiivselt osaletud siin. Ehkki asi on suunatud hobikorras mänge arendavatele tegelastele ei jäänud kordagi vastuseta ka väga keerukad küsimused üldisematel programmeerimisteemadel. Ehk siis sealt on üsna kindlalt oodata vastust kui selle vähegi normaalselt sõnastada suudad
_________________ Teach a man to reason and he'll think for a lifetime
Common sense - so rare that it's a damn superpower
Vaadates paljude inimeste sõnavõtte siin ja mujal jääb üle ainult klassikuid tsiteerida - "I weep for humanity" |
|
| Kommentaarid: 107 loe/lisa |
Kasutajad arvavad: |
   |
:: |
0 :: |
1 :: |
87 |
|
| tagasi üles |
|
 |
Bssldr
HV kasutaja
liitunud: 05.12.2009
|
01.02.2012 17:37:46
|
|
|
C'd saab kirjutada MSVC's, kuid vana standardi järgi (C/C++ -> Advanced -> Compile As -> C). Muidugi on võimalik teha selline trikk, et kompileerida C++'na ja kirjutada ainult C'd, aga siis on oht C++ poolele ära kalduda, kuna kompilaator lubab. Võiks kasutada uusimat gcc/MinGW koos mõne ühilduva IDE'ga.
| Ho Ho kirjutas: |
| andreie kirjutas: |
Ho Ho, head uudised - MSVS 2010-ga tuleb kaasa <stdint.h>. Kogu aeg kasutan  |
Tean jah kuid sellest on vähe kasu kui c99 standardile kompilaator endiselt ei vasta. Samas mind isiklikult see niiväga ei kurvasta kuna pigem kasutan c++11't ning tolle tugi peaks tolles MSVC versioonis suht-koht asjalik olema  |
Kui MSVC10 välja tuli, oli C++11 tugi ikka teiste kompilaatoritega võrreldes väga hea. Nüüd on asi pisut nukker - on teada, et MSVC11 toetab C++11 standard library't täies ulatuses, aga keele enda elemendid on samas seisus (Microsoft otsustas keskenduda oma Metro frameworkile ja C# 5.0'le). Üldse huvitav, mis hakkab juhtuma, kui C++11 laiemalt kasutusele võetakse. Paljudel frameworkidel oma string klassid, STL klassid, threadid, ja sinna otsa nüüd C++11 threadid. Jube palju dubleerimist, kisub segaseks ära juba. Oleks vist aeg need frameworkid uuesti kirjutada. Samas see ei lahendaks probleemi: C++ standardiseerimiskomitee liikmed saavad 10a viivitusega aru, et on vaja keelele teeke juurde lisada (varsti siis Boost.Asio TR2 raames) - ja tulemus ongi see, et selleks ajaks on kõik kohad sarnase ülesandega teeke täis.
|
|
| Kommentaarid: 9 loe/lisa |
Kasutajad arvavad: |
   |
:: |
0 :: |
0 :: |
8 |
|
| tagasi üles |
|
 |
andreie
HV vaatleja

liitunud: 09.09.2006
|
02.02.2012 16:55:15
|
|
|
| kalvis kirjutas: |
| Kus, kas on eestis foorumit, kus saaks C ja assembleri või muude programmeerimiskeelte kohta küsimusi vastuseid lugeda, arutada jne. Vanasti kasutasin newsgroupi ja sellest piisas, kuid kui ISP ja tööandja lõpetasid nende toe siis enam ei saa neid lugeda/kirjutada. |
Seesama foorum ja http://www.pinu.ee/ . Ega ma rohkem teagi.
Ilmselt on paljud kirjutanud assemblerit ühel või teisel tasemel; tõsi, mina viimati 16a tagasi. Aga võid ju C/assembler muresid ka siin küsida.
_________________ Unix survives only because everyone else has done so badly. |
|
| Kommentaarid: 5 loe/lisa |
Kasutajad arvavad: |
   |
:: |
0 :: |
0 :: |
5 |
|
| tagasi üles |
|
 |
taurib
HV vaatleja
liitunud: 26.08.2010
|
02.02.2012 21:26:19
|
|
|
| Bssldr kirjutas: |
| C'd saab kirjutada MSVC's, kuid vana standardi järgi (C/C++ -> Advanced -> Compile As -> C). Muidugi on võimalik teha selline trikk, et kompileerida C++'na ja kirjutada ainult C'd, aga siis on oht C++ poolele ära kalduda, kuna kompilaator lubab. Võiks kasutada uusimat gcc/MinGW koos mõne ühilduva IDE'ga. |
Kust kohast ma MSVC selle Compile sätted üles leian? Ma kasutan 2010 versiooni hetkel
|
|
| tagasi üles |
|
 |
kalvis
Kreisi kasutaja
liitunud: 20.10.2009
|
04.02.2012 14:23:12
|
|
|
| tsitaat: |
| dev-c++ oli enam-vähem kasutatav kui projekt koosnes <10 failist. Üle selle läks asi üsna käest ära. |
Juba 2 faili koos kompileerimine osutub algajale raketiteaduseks. Mu soovitus lähtus ikka algaja vaatenurgast...
Tegelen multimeedia intepretaatori kirjutamisega või skriptitöötlejaga või library , vahet pole (pole mingit takistus kasutada CAD elemente kus iganes ja kuidas tahan). Idee pärit ammustest aegadest, kui oli MSX basic ja seal oli sarnane asi olemas (muidugi mitte nii võimsalt, seal oli puhas 2D ja palju vähem võimalusi). Praegu juba tüüpasjad toimivad. Why not, kui muud maailma asi huvitab, saab tasuta kõigile (olen ikkagi harrastusprogeja).
Huvitab, bititöötlus 32 (64) bit tasandil. On oluline, et muutuja oleks just 32 (64) bitti ja ei midagi muud, muidu võib algoritmiga kergesti vale tulemuse saada (otse carryt ei saa kasutada, seega tuleb negatiivset või positiivset arvu kasutada aga see kehtib vaid 32 bit muutuja korral.
Vajan kõiki tüüpbititöötluse elemente, mitte ainult nihe paremale või vasakule (C olemas). Carry-ga, XOR, ringnihked, vaata kõiki inteli assembleri tüüptehteid. Otse assembleris on need käsud olemas ja isegi rohkem kui soovisin. Aga C keeles võiksid ka olla. Täna ei tea et oleks. Ei kujuta ette kuidas saaks veel kiiremini kui laadida 32 (64) bitti datat protsessorile, teha üks bititehe ja salvestada mällu tagasi (seega 3 käsku +1) ja võtta järgmine 32 bitti mälus ette, kui teha seesama tehe 8 bitiga...
Teine töötlus on stringidega, vaja oleks teisendada 32 bitti 4 kohaline string int32 ja vastupidi. (64 bit keskkonnas samamoodi 8 ühikut). assembleris teadupärast ei kulu teisenduseks midagi... C on praegu asi lahendamata (runtime error, kaude on võimalik (char 8 bitti saab teha) soovin otse). Ja vastupidi samuti
Kolmas asi on 32 bitti muutuja teisendus 4 8 bitiseks (siin vahet pole kas char, int või mis iganes tüüpi). Unioniga saab. Vastupidi tehe on olemas kuid teistpidi on just low-hi bitivärk üliohtlik. Nimelt C ei garanteeri midagi, võimalik, et konkreetses keskkonnas saan paremalt vasakule ja teises vastupidi... Siin võiks C keeles see asi kindel olla, et sõltumata mis protsessor või mälumudel (või on olemas kompilatoril see säte, vot see lahendaks probleemi)
Praegu kasutan põhiliselt Windows keskkonda, kuid siiani on kõik proged ka Linuxis gcc töötanud. (seepärast Dev-C++ või Codeblocki valik...). Et kasutan tööl Windowsi ja kodus Linuxit ja windowsi...
|
|
| tagasi üles |
|
 |
Ho Ho
HV Guru

liitunud: 16.02.2002
|
04.02.2012 14:48:44
|
|
|
kalvis, enamus assemblerikäske on otse c's kasutatavad intrinsic'ute näol mida saad muu koodi vahele torgata täpselt nagu suvalisi muid funktsioone kuid kuna kompilaatoril on märksa vabamad käed nendega ümber käimiseks siis suudab ta neid ka optimeerida. Otse ASM'i kirjutades seda teha ei saa.
| kalvis kirjutas: |
| Teine töötlus on stringidega, vaja oleks teisendada 32 bitti 4 kohaline string int32 ja vastupidi. (64 bit keskkonnas samamoodi 8 ühikut). assembleris teadupärast ei kulu teisenduseks midagi... C on praegu asi lahendamata (runtime error, kaude on võimalik (char 8 bitti saab teha) soovin otse). Ja vastupidi samuti |
Näita konkreetset C koodi millega seda teisendust teha üritasid. Karvane tunne, et tegid miskit valesti seal.
| kalvis kirjutas: |
| Siin võiks C keeles see asi kindel olla, et sõltumata mis protsessor või mälumudel |
Võiks jah aga näedsa, ei ole paraku. Samuti ega ASM sind ei päästa kuna ikka pead tegema kaks eri varianti vastavalt kas kasutuses little või big endian prose.
_________________ Teach a man to reason and he'll think for a lifetime
Common sense - so rare that it's a damn superpower
Vaadates paljude inimeste sõnavõtte siin ja mujal jääb üle ainult klassikuid tsiteerida - "I weep for humanity" |
|
| Kommentaarid: 107 loe/lisa |
Kasutajad arvavad: |
   |
:: |
0 :: |
1 :: |
87 |
|
| tagasi üles |
|
 |
kalvis
Kreisi kasutaja
liitunud: 20.10.2009
|
04.02.2012 18:26:45
|
|
|
Koperdasin mingile paremale aga seal oli vist ca 10 küsimust... (hiljuti)
Kunagil varem oli mingi hea netileht mingite näidete (ca 5 aastat tagasi) ja foorumiga.. aga vat seda pole enam kohanud. Ju siis Kauts tegi neile lõpu ku nad just ise harakiri ei teinud.
Kas newsgroupi kuiskil mingi nipiga ei hingitse või on kuskil välismaal olemas hea programmeerijate foorum...
|
|
| tagasi üles |
|
 |
andreie
HV vaatleja

liitunud: 09.09.2006
|
05.02.2012 19:25:45
|
|
|
| kalvis kirjutas: |
Huvitab, bititöötlus 32 (64) bit tasandil. On oluline, et muutuja oleks just 32 (64) bitti ja ei midagi muud, muidu võib algoritmiga kergesti vale tulemuse saada (otse carryt ei saa kasutada, seega tuleb negatiivset või positiivset arvu kasutada aga see kehtib vaid 32 bit muutuja korral.
Vajan kõiki tüüpbititöötluse elemente, mitte ainult nihe paremale või vasakule (C olemas). Carry-ga, XOR, ringnihked, vaata kõiki inteli assembleri tüüptehteid. Otse assembleris on need käsud olemas ja isegi rohkem kui soovisin. Aga C keeles võiksid ka olla. Täna ei tea et oleks. Ei kujuta ette kuidas saaks veel kiiremini kui laadida 32 (64) bitti datat protsessorile, teha üks bititehe ja salvestada mällu tagasi (seega 3 käsku +1) ja võtta järgmine 32 bitti mälus ette, kui teha seesama tehe 8 bitiga... |
Bitikaupa XOR on olemas: ^
Carry ja ringnihkeid minu teada pole. Mõningate mööndustega saab neid üsna mugavalt teostada 64-bitise protsessori peal, kasutades 64-bitisest sõnast ülemist 32-bitti puhtalt carry jaoks.
Ringnihet võib teha näiteks järgmiselt, kuna praegu peast proovisin, siis kiiruse poolest ei tarvitse see optimaalne variant olla:
#include <stdint.h>
static inline uint32_t rotate_left(const uint32_t x) const
{
return ((x << 1) | (x >> 31))
}
|
Alati võib (muidugi, soovitav ei ole) võib ka C-d assembleriga segada. GCC "inline asm-i" täitsa sobib kasutada. Algus on muidugi konarlik, sest puhas assembler see ka ei ole - tuleb näiteks eraldi võtmesõnaga ära märkida, mis muutujaid "inline asm" kasutab ja kuhu ta tulemuse kirjutab.
| kalvis kirjutas: |
| Teine töötlus on stringidega, vaja oleks teisendada 32 bitti 4 kohaline string int32 ja vastupidi. (64 bit keskkonnas samamoodi 8 ühikut). assembleris teadupärast ei kulu teisenduseks midagi... C on praegu asi lahendamata (runtime error, kaude on võimalik (char 8 bitti saab teha) soovin otse). Ja vastupidi samuti |
Stringi all pead silmas mitte tekstilist sõnet, vaid massiivi? (mälu järgi inteli manuaalides kasutati stringi selles tähenduses).
Ma küll hästi aru ei saa, aga kuna Sa vihjad, et assembleris ei kulu teisenduseks midagi, siis loogiline järeldus on, et soovid andmed mälus samaks jätta, kuid käsitleda neid teistmoodi. Siis see küll kattub järgmise küsimusega, nii et võib-olla pakun siin hoopis vastust välja järgmisele küsimusele. Keeles "C" on selle jaoks tüübiteisendus (type cast).
Kuna inteli prosed lubavad nn. unaligned mälupöördust, siis tüübiteisendus on väga lihtne:
#include <stdint.h>
#define INT32_OF4BYTES(pointer_to_bytes) ((uint32_t)(*(pointer_to_bytes)))
#define BYTEARRAY_OF_INT32(integer32) ((uint8_t*)(&(integer32)))
|
| kalvis kirjutas: |
Kolmas asi on 32 bitti muutuja teisendus 4 8 bitiseks (siin vahet pole kas char, int või mis iganes tüüpi). Unioniga saab. Vastupidi tehe on olemas kuid teistpidi on just low-hi bitivärk üliohtlik. Nimelt C ei garanteeri midagi, võimalik, et konkreetses keskkonnas saan paremalt vasakule ja teises vastupidi... Siin võiks C keeles see asi kindel olla, et sõltumata mis protsessor või mälumudel (või on olemas kompilatoril see säte, vot see lahendaks probleemi)
|
Vt. ka eelmist küsimust.
See on kinni protsessori nn. endianness-ist ja mitte C kompilaatorist. Kui teed bitinihetega, siis seda probleemi pole.
Bitinikerdamise trikke (mitte küll päris küsitut) on käsitletud siin: http://graphics.stanford.edu/~seander/bithacks.html Ehk aitab järjele.
Kui vabas vormis matemaatilise valemina kirjutad mõned lihtsamad funktsioonid, mis Sul assembleris olemas, võin mõned ise C-ks ringi kirjutada. Kuigi, kui on assembleris olemas, siis võib-olla lihtsam on teha nn. inline asm-iks.
_________________ Unix survives only because everyone else has done so badly. |
|
| Kommentaarid: 5 loe/lisa |
Kasutajad arvavad: |
   |
:: |
0 :: |
0 :: |
5 |
|
| tagasi üles |
|
 |
taurib
HV vaatleja
liitunud: 26.08.2010
|
07.02.2012 21:36:57
|
|
|
Tundub, et see C keele kirjutamine MSVSis on ikka päris suur jamamine, ma saan siiski pigem Geany'ga hakkama :/
Vähemasti ma leidsin igasugu keerulisi õpetusi, kus peab midagi seal CMD promptis ära tegema ja selle siis siduma selle MSVSiga kuidagi moodi
|
|
| tagasi üles |
|
 |
andreie
HV vaatleja

liitunud: 09.09.2006
|
09.02.2012 14:21:09
|
|
|
Oops. Olen unustanud öelda, et saab ka väga lihtsalt - teed C++ projekti, aga uute failide lisamisel märgid käsitsi faili laiendiks ".cpp" asemel ".c". Siis käib kõik automaatselt, kompilaator piirdub vaid C keele võimalustega jne.
_________________ Unix survives only because everyone else has done so badly. |
|
| Kommentaarid: 5 loe/lisa |
Kasutajad arvavad: |
   |
:: |
0 :: |
0 :: |
5 |
|
| tagasi üles |
|
 |
Supiplex
HV veteran

liitunud: 11.12.2002
|
09.02.2012 17:01:07
|
|
|
Ma julgen väita, et algaja huvilise jaoks pole küll IDE esmatähtis. Esiteks seetõttu, et kuni paarituhande realise C programmi jaoks pole IDE overhead kuidagi vajalik. Teiseks seetõttu, et nii õpib tööriistu paremini tundma.
Kompilaator, süntaksit värvida oskav tekstiredaktor (Notepad++, Programmers Notepad) ja make nõuavad alguses väikese õppimiskõvera ületamist, aga tasuvad hiljem kuhjaga ära. Jäävad ära igasugu totakad projektiwizardid, sättungitest kompilaatori optionite otsimine, kummaliste projektistruktuuride järgi paindumine jne.
_________________ The young lady had an unusual list,
Linked in part to a structural weakness.
She set no preconditions. |
|
| Kommentaarid: 38 loe/lisa |
Kasutajad arvavad: |
   |
:: |
0 :: |
1 :: |
34 |
|
| tagasi üles |
|
 |
kalvis
Kreisi kasutaja
liitunud: 20.10.2009
|
09.02.2012 17:15:06
|
|
|
Sai lõpuks järgi proovitud ... ja asi toimib. Üksjagu pusimist oli enne kui sai piisavalt netist see teisenduste olemus selgeks tehtud.
Lisaks leidsin otsesed näited Hi-Low baitide ümbertõstmisest ja mis seal salata, nüüd on muudki optimeerimised tulemas. Saan palju lihtsamini mälumassiivide kirjetel just mind huvitavaid täisbaite lugeda. Tuleb vaid õieti viitade tüüpidega mängida ja nende aadresse arvutada. Enne sai liiga palju bitinihetega liigutatud, nüüd pole vaja. Bitmaptöötluses mõned nihked jäävad ikka.
Lõppkokkuvõttes tegi kurvaks, et koodi kirjutamine ei ole protsessorist ega keskkonnast täiesti sõltumatu, mida võiks kõrgkeelelt rohkem oodata. Kuid kuna minu mänguruum jääb esialgu Intel prosede juurde siis mulle probleemi sellest ei teki.
|
|
| tagasi üles |
|
 |
Ho Ho
HV Guru

liitunud: 16.02.2002
|
09.02.2012 17:19:55
|
|
|
| kalvis kirjutas: |
| Lisaks leidsin otsesed näited Hi-Low baitide ümbertõstmisest ja mis seal salata, nüüd on muudki optimeerimised tulemas. Saan palju lihtsamini mälumassiivide kirjetel just mind huvitavaid täisbaite lugeda. Tuleb vaid õieti viitade tüüpidega mängida ja nende aadresse arvutada. Enne sai liiga palju bitinihetega liigutatud, nüüd pole vaja. Bitmaptöötluses mõned nihked jäävad ikka. |
Ehk viitsiksid oma avastused ning veel lahendamata probleemid kusagile eraldi teemasse kirja panna? Kõlab igatahes üsnagi huvitavalt ning üsna tõenäoliselt jõuaks kambakesi su koodi veelgi ilusamaks-paremaks muuta
| kalvis kirjutas: |
| Lõppkokkuvõttes tegi kurvaks, et koodi kirjutamine ei ole protsessorist ega keskkonnast täiesti sõltumatu, mida võiks kõrgkeelelt rohkem oodata |
c/c++ ei ole päris tavapärased kõrgkeeled vaid pigem suudavad teha kõike nii otse raua tasemel (intrinsic'ud ja inline ASM) kui ka väga high-level (C++ templated, OO ja RAII). Lihtsalt kui sa kasutad keele väga madala otsa asju siis pole erilist lootust, et seal asi väga üldine oleks ning töötaks ühtviisi efektiivselt ja muutmata kõigil platformidel. "Päris" kõrgkeeltes võid säärase platformist sõltumatuse küll saavutada kuid sel juhul kaotad ka kõvasti efektiivsust kuna kompilaatoril pole halli aimugi mida saavutada üritad ning ei oska seetõttu asju korralikult optimeerida.
_________________ Teach a man to reason and he'll think for a lifetime
Common sense - so rare that it's a damn superpower
Vaadates paljude inimeste sõnavõtte siin ja mujal jääb üle ainult klassikuid tsiteerida - "I weep for humanity" |
|
| Kommentaarid: 107 loe/lisa |
Kasutajad arvavad: |
   |
:: |
0 :: |
1 :: |
87 |
|
| tagasi üles |
|
 |
kalvis
Kreisi kasutaja
liitunud: 20.10.2009
|
10.02.2012 12:05:05
|
|
|
Miks mitte. Aga kuhu ja kuidas. Tuleks teha eraldi teema ja kuhugi link siis programmi kättesaamisele. Kuskil peaks server olemas kus siis kood pesitseks ja saaksime faile üles riputada. Ma kolisin oma koodil tagasi C keskkonnale, peapõhjus oli selles, et C -s kirjutades ei tulnud asi raskem välja, C-s olid aga põhilibrarid (OpenGL, SDL, akendevärk toetatud). Ja mis seal salata, C-s kirjutasin oma esimese programmi 15 aastat tagasi juba aga C++ alles nüüd. Harjumus on suur. Eraldi tuleks veel skriptikäskude formaati arendada, ideid on kilokaupa, igaühel omad plussid ja miinused. Esmane eesmärk on siis vaja saada tööle failist interpretaator - failis on graafiliste primitiivide käsud koos andmetega ja joonistab siis kas 2D-s või 3D-s. Praegu asendasin selle otsese OpenGL formaatide toega, momendil joonistab OpenGL failist otse primitiive. Et failiks võib kasutada kõiki tuntud vabavaralisi 3D vidinaid ja joonistab (algnäited olid Nehe jt. variandid), kuid ma modisin nende koodi veelgi lühemaks ja dünaamilisemaks ja otse omavahel kasutatavaks. Loomulikult saab asja ka C-s otse kasutada, ei pea intepretaator olema, seal kutsud välja vastava funktsiooni otse. Momendil on toorkood olemas bitmapfailide laadimiseks ja AVI striimide kasutamiseks... ja ka vastupidi - skript võimaldab valmistehtud ka mõnda muude faili panna (salvestamine, ümberkodeerimine). Et interpretaator võimaldab ka kõiki videosi läbisegamini piltide, tekstide jne. kasutamisega või kasvõi mõnel oma lemmikfilmi vaadata (eesmärk ei ole VLC-d kirjutada, lihtsalt ta võimaldab seda minimiseeritult skriptina kasutada).
Ma umbes pool progemise ajast kulutan optimiseerimise ja multimeedia formaatide kohta infot otsides. Ühest kohast oli meeldiv teada saada, et C-s enam niiväga koodi kirjutades optimiseerimisele mõtlema ei pea, kaasaegsed paralleeltöötlus võimaldab ka halvasti optimiseeritud koodi maksimumis joosta. Eelkõige huvitab just C-s (C++) optimiseerimine, kasvõi kõik üldpõhimõtete kohta linkide saamine. Näiteks, kui dünaamiliselt mälu võtan siis idee järgi teatud blokid ja õigete andmetega lähenemine meeldivad kompilaatorile rohkem ja annavad kiirusevõitu. Vot ma siis nende blokkide kaupa mälu võtaksingi (praegu võtan 4 kB kaupa või sellega jagunevalt). Ja teine on koodis tarbetud muutujate teisenduste minimiseerimine.
Eraldi teemana huvitaks mind otse andmete saatmine videokaarti või nii otse kui võimalik. Lähim mõiste on linear framebuffer, kuid soov on ka sellega seotud kõiki muid parameetreid näppida niipalju kui vähegi saaks. Kui videokaartide programmeerimine on kellelgi käpas siis väga ootaks, DOS ajastu oma oskan, kuid tänapäeva op.süsteemid seda meetodit ei luba. Miinimum oleks Linuxis asi tööle saada, Windowsis mõned ideed on kuidas saaks.
|
|
| tagasi üles |
|
 |
matik
HV kasutaja
liitunud: 28.05.2008
|
12.02.2012 23:38:43
|
|
|
| kalvis kirjutas: |
Sai lõpuks järgi proovitud ... ja asi toimib. Üksjagu pusimist oli enne kui sai piisavalt netist see teisenduste olemus selgeks tehtud.
Lisaks leidsin otsesed näited Hi-Low baitide ümbertõstmisest ja mis seal salata, nüüd on muudki optimeerimised tulemas. Saan palju lihtsamini mälumassiivide kirjetel just mind huvitavaid täisbaite lugeda. Tuleb vaid õieti viitade tüüpidega mängida ja nende aadresse arvutada. Enne sai liiga palju bitinihetega liigutatud, nüüd pole vaja. Bitmaptöötluses mõned nihked jäävad ikka.
Lõppkokkuvõttes tegi kurvaks, et koodi kirjutamine ei ole protsessorist ega keskkonnast täiesti sõltumatu, mida võiks kõrgkeelelt rohkem oodata. Kuid kuna minu mänguruum jääb esialgu Intel prosede juurde siis mulle probleemi sellest ei teki. |
Optimiseerimise aluseks soovitan võtta ikkagi profileerimise, neid tasuta vahendeid nt linuxi all on mitmeid ning windowsi alla leiab ka.
Sisetunde järgi optimeerimine võib üsna rappa viia, meil oli sama lugu - arvasin, et üks programmiviga oli threadis mutexite taga ootamine ja lukustus, ent profileerides tuli välja palju huvitavam probleem - kuna programm allokeeris ja vabastas new/delete abil pidevalt uusi eri suurusega mäluplokke, siis lõpuks allokeeritud plokid hakkasid paiknema mälus väga suurte vahedega, mille tulemusel tekkis väga palju CPU "cache misse" ning programmi kiirus degradeerus tasapisi, ent järjekindlalt. Lahenduseks oli std new/delete asemel placement new kasutamine ja käsitsi spetsiifilise allokaatori kirjutamine.
Sellise probleemi peale annab ikka sisetunde järgi tulla. Soovitan soojalt profileerida korraliku tööriistaga.
Ja noh, sellise probleemi korral selle lõigu ASM-i kirjutamine muidugi mitte mingit võitu ei anna.
|
|
| tagasi üles |
|
 |
andreie
HV vaatleja

liitunud: 09.09.2006
|
14.02.2012 15:51:00
|
|
|
| kalvis kirjutas: |
| Eraldi teemana huvitaks mind otse andmete saatmine videokaarti või nii otse kui võimalik. Lähim mõiste on linear framebuffer, kuid soov on ka sellega seotud kõiki muid parameetreid näppida niipalju kui vähegi saaks. |
Simple Directmedia Layer, teek ligipääsuks madalal tasemel videokaardile ja muudele meediaseadmetele, kasutatav nii Windowsis kui ka Linuxis, http://www.libsdl.org/
_________________ Unix survives only because everyone else has done so badly. |
|
| Kommentaarid: 5 loe/lisa |
Kasutajad arvavad: |
   |
:: |
0 :: |
0 :: |
5 |
|
| tagasi üles |
|
 |
kalvis
Kreisi kasutaja
liitunud: 20.10.2009
|
07.03.2012 22:14:13
|
|
|
SDL ammu kasutamisel, kuid lugesin, et nad ise ei pääse otse videokaardile ligi vaid kasutavad Windowsis windowsi API-t (directX-i). SDL on praegu just universaalsuse nimel kasutusel, esialgu ajab asja ära. Niipalju olen leidnud, et DirectX-ga pidi saama palju lähemale, peaaegu et otse (datat saab kirjutada ja lugeda), kuid mitte ramdaciga seotud parameetreid. Kahjuks pole seni leidnud puust ja punaseks näidet, et kuidas siis directx saaks kas akent või täisekraani jagu lihtsalt viidaga mälubloki videokaarti saata. Arvan, et niipea ma rohkem ei tahagi, kuigi lõppunistus oleks ka videokaardi ramdac custom modes teha (vaja just videode veavabaks presenteerimiseks).
Vahepeal tekkis uus probleem. On keegi Mesa edukalt windowsil kompileerinud, probla selles, et katsetamisel kasutatavad arvutid on nõrga OpenGL toega ja saadavad mind riistvaras pikalt. Softis on aga tugi vaid 1.1 -le, MESA annaks aga 2.1-le, millest mulle on isegi ülearu. Kompileerimine läheb algul justkui käima (MESA 7.4) kuid pika töö järel annab nii error 1 kui error 2 MinGW-ga kompileerimisel. Ainus vihje on seni, et Makes on vist mingi bug, mistõttu mingi (ma_types.exe???) exe asjast ja tema asukohast kompileerimisel tekib tõrge. MESA sellid on kõik teinud, et keegi nende softi kohta mingit abi ei saaks. Teised uuemad MESA versioonid ei jõua algreast kaugemale, error 1-ga, vist linkimise kataloog (no ei ütle mis faili tahab saada). Kui saaks toimima siis piisaks mul enamuses vaid SDL-ist ja OpenGL-ist, kui aga mitte siis, eks siis tuleb OpenGL asemel DirectX-le kolida, esialgu ei tahaks seda teha.
Heli, praegu piisab SDL-ist, kuid kummale tasuks rohkem panustada - kas DirectX-le (Directsound) või OpenAL-le? OpenAL API uurides ei leidnud ma sealt midagi vaimustavat ja kommentaarid olid vähelubavad. Perspektiivsem tundus DirectX (kuna video tuleb vist sellele nagunii viia kuna OpenGL ei taha kuidagi toimida) sest praegused multimeedia tegelased kasutavad just seda.
|
|
| tagasi üles |
|
 |
Ho Ho
HV Guru

liitunud: 16.02.2002
|
07.03.2012 22:24:53
|
|
|
Räägi mida sa täpselt saavutada üritad selle otsese ligipääsuga ning miks standardlahendused (a'la opengl'i ram'is elavad tekstuuride majandamise extensionid) ei sobi. Hetkel jääb mulje, et lähened probleemile väga vale nurga alt ning raiskad üüratus koguses ressursse lahendamaks probleemi mille ise tekitasid kuna ei tea kuidas GPU'd kasutada
Mesa otsene kasutamine on sarnaselt kummaline ettevõtmine kui sul on sama funktsionaalsus (ja palju enamatki) saadval standartsete GPU'ga kaasa tulnud draiveritega ning seda koos korraliku riistvaralise kiirendusega.
Heli koha pealt pigem vaataks openal'i. Ka päris suured-tuntud mängude tegijad eelistavad toda kõiksugu muudele alternatiividele.
_________________ Teach a man to reason and he'll think for a lifetime
Common sense - so rare that it's a damn superpower
Vaadates paljude inimeste sõnavõtte siin ja mujal jääb üle ainult klassikuid tsiteerida - "I weep for humanity" |
|
| Kommentaarid: 107 loe/lisa |
Kasutajad arvavad: |
   |
:: |
0 :: |
1 :: |
87 |
|
| tagasi üles |
|
 |
kalvis
Kreisi kasutaja
liitunud: 20.10.2009
|
07.03.2012 23:11:13
|
|
|
Vaja oleks ligipääsu PAL videostandardile vajaliku VGA signaali genereerimiseks. Kuid miksiksin kokku nii video kui ka muud 2D ja 3D elemendid, seejuures osa datat võib tulla ka võrgust ja saadetakse sinna ka tagasi. St. arvutist saab multimeediakeskus otse teleka taga ning datat sisse ja välja tuleb nagu Linuxis tavaline kõikjalt (peamiselt pult, hiir, klaviatuur ja võrk). Bitmapis tuleksid juhtmenüüd ja muud asjad. Klient ja server ei pea üldse asuma samas võrgus, võivad täitsa vabalt asuda kasvõi erinevates riikides.
PAL-le on vaja moonutusevabalt nii täpset sünkroniseerimist, üleridade õiget data saatmist. Praegused meediaplayerid windowsis seda ei võimalda, Linuxis võimaldavad. Esimeses etapis rahuldabki, et server saab olema Linuxis ja tõenäoliselt klient on Windowsis või nutitelefon. Mõlemal programmil peab olema samad objektid ja töötlus. Kuna kasutan üle võrgu juhtimist ja virtuaalset pildi vaatamist siis peab programm olema võimeline töötama mis tahes op. süsteemis.
Loomulikult saab samu asju kasutada kasvõi mängude progemiseks või lihtsalt arvuti kaughalduseks, neis pole videokaardile otsest ligipääsu vaja.
Videotöötlus on väga ressursimahukas, seega on vajalikud kiired algoritmid.
|
|
| tagasi üles |
|
 |
Ho Ho
HV Guru

liitunud: 16.02.2002
|
07.03.2012 23:30:27
|
|
|
Kõlab äärmiselt huvitava ettevõtmisega.
Kas on mõni mõjuv põhjus miks sa lihtsalt sisse tulevaid kaadreid videomälu tekstuurile ei kopeeri, sinna otsa kõiksugu vajalikke imevidinad renderdada ja too tekstuur vabalt valitud resoga (PAL) edasi saata? Kui sa just otseselt PAL'i signaali sisse mingit lisainfot ei kodeeri siis töötaks selline asi igati normaalselt. Mingit sorti moonutusi sealt sisse ei saa tulla ning interlaced outputi eest hoolitseb raudvara automaagiliselt.
_________________ Teach a man to reason and he'll think for a lifetime
Common sense - so rare that it's a damn superpower
Vaadates paljude inimeste sõnavõtte siin ja mujal jääb üle ainult klassikuid tsiteerida - "I weep for humanity" |
|
| Kommentaarid: 107 loe/lisa |
Kasutajad arvavad: |
   |
:: |
0 :: |
1 :: |
87 |
|
| tagasi üles |
|
 |
kalvis
Kreisi kasutaja
liitunud: 20.10.2009
|
08.03.2012 12:40:36
|
|
|
| Ma olen selle VGA -> PAL vidinaga mässanud. Pilt on parim teadaolevatest, kuid ikkagi on moonutused sees. Nüüdseks on selgunud, et veapõhjuseks on valel ajal data saatmine videokaarti, seda tuleb teha sünkroniseeritult vastavalt kiire tagasijooksmise hetkel kaadrivahetusel ja tuleb veel arvet pidada paaris ja paaritu kaadri osas. Oluline on ajastus, data peab saabuma ainult kiire tagasijooksu ajal videokaardi mällu ja hiljem tuleb just blokkida. On ka veel muid lahendusi, kuid kõigel on omad vead. See saatmine on kõige lihtsam ja kiirem lahendus ja tegelikult ei nõua midagi erilist.
|
|
| tagasi üles |
|
 |
andreie
HV vaatleja

liitunud: 09.09.2006
|
|
| Kommentaarid: 5 loe/lisa |
Kasutajad arvavad: |
   |
:: |
0 :: |
0 :: |
5 |
|
| tagasi üles |
|
 |
kalvis
Kreisi kasutaja
liitunud: 20.10.2009
|
14.03.2012 11:48:07
|
|
|
See oli justkui tõesti see, mida otsin. MS DirectX on võimas multimeedia librarid, kuid maht on ka võimas. Õppimine võtab kaua aega, leidmine veelgi rohkem.
Vahepeal otsisin DirectX kasutamise võimaluste kohta Linuxis, kas tõesti pole mitte keegi viitsinud seni teha ühtegi DirectX API-ga librarit, mis töötaks otse X serveris? Wine jaoks on olemas? Otse X serverile mitte või ma ei leidnud ühtegi viidet.
|
|
| tagasi üles |
|
 |
neros
HV Guru

liitunud: 26.11.2003
|
14.03.2012 12:16:38
|
|
|
Ahem... DirectX'l pole X'ga mitte midagi pistmist. DirectX on Windowsi eksklusiivne API. Wine peal mingi DirectX'i emulatsioon töötab, aga ma ei usaldaks seda 100%liselt. Linuxi all natiivselt töötavat DirectX'i loota on naiivne. Kui sa tahad midagi mis ekraanile paneks asju, siis OpenGL ongi enamvähem üks ainukesi linuxilisi.
_________________ GitHub
.NET Core & Azure baasil lahendused ja arhitektuur - kontakt. |
|
| Kommentaarid: 48 loe/lisa |
Kasutajad arvavad: |
   |
:: |
0 :: |
1 :: |
40 |
|
| tagasi üles |
|
 |
LiivaneLord
Sõpradele "Olavi"
liitunud: 20.06.2006
|
01.04.2012 23:49:56
|
|
|
Kas keegi oskab soovitada mingit programmi, mis suudaks konstruktsioone (if, for, foreach, while jne) taandega esile tuua? Notepad++, Editplus ja paljud, mis olen proovinud, suudavad seda küll teha, kui kirjutan järjest, aga kui vaja midagi muuta, siis nad ei suuda õiget asetust taastada.
Praegusel juhul on vim selles suhtes ideaalne, aga see on krdi tagasihoidliku välimusega programm ning ei sobi mulle. Vim loob taanded õigesti.
|
|
| Kommentaarid: 20 loe/lisa |
Kasutajad arvavad: |
   |
:: |
0 :: |
0 :: |
19 |
|
| tagasi üles |
|
 |
HellWalKeR
HV kasutaja

liitunud: 20.11.2006
|
02.04.2012 03:00:45
|
|
|
| LiivaneLord kirjutas: |
Kas keegi oskab soovitada mingit programmi, mis suudaks konstruktsioone (if, for, foreach, while jne) taandega esile tuua? Notepad++, Editplus ja paljud, mis olen proovinud, suudavad seda küll teha, kui kirjutan järjest, aga kui vaja midagi muuta, siis nad ei suuda õiget asetust taastada.
Praegusel juhul on vim selles suhtes ideaalne, aga see on krdi tagasihoidliku välimusega programm ning ei sobi mulle. Vim loob taanded õigesti. |
Eclipses selekteeri kood ja ctrl+f. Lööb kõik taanded ja tühikud sinu code style järgi.
|
|
| Kommentaarid: 5 loe/lisa |
Kasutajad arvavad: |
   |
:: |
1 :: |
0 :: |
3 |
|
| tagasi üles |
|
 |
LiivaneLord
Sõpradele "Olavi"
liitunud: 20.06.2006
|
02.04.2012 10:30:11
|
|
|
HellWalKeR, tänan vastamise eest. Eile pika googeldamise ja mitme programmi installimise peale leidsin suurepärase programmi, Sublime Text 2. Reindent käsk loob oma koodud koodist vaat et kunstiteose ning kõik konstruktsioonid on kenasti eraldatud ja neid on võimalik ka kahandada. Kõige parem on see, et valides kogu teksti, luuakse kõik taanded ja programm suudab arvestada ka HTML tagidega.
Otsimise ajal oli küll vahepeal tunne, et otsin midagi võimatut, sest kõik programmid kasutasid automaatset taandamist ühtviisi vigaselt.
|
|
| Kommentaarid: 20 loe/lisa |
Kasutajad arvavad: |
   |
:: |
0 :: |
0 :: |
19 |
|
| tagasi üles |
|
 |
Ho Ho
HV Guru

liitunud: 16.02.2002
|
02.04.2012 10:36:38
|
|
|
Vähegi asjalikemates IDE'des on kasutuses confitav koodiformaatija. Väga tahad võid ka ise miskit astyle'i põhjal kokku leiutada. Viimast kasutab baasina ka qt creator.
_________________ Teach a man to reason and he'll think for a lifetime
Common sense - so rare that it's a damn superpower
Vaadates paljude inimeste sõnavõtte siin ja mujal jääb üle ainult klassikuid tsiteerida - "I weep for humanity" |
|
| Kommentaarid: 107 loe/lisa |
Kasutajad arvavad: |
   |
:: |
0 :: |
1 :: |
87 |
|
| tagasi üles |
|
 |
|