Hahó, lányok, programozni menő!

A prezi nem munkaajánlatot tett, hanem egyfajta tanfolyamot indít, amiből nem következik a programozói állás. Nem tudom, hogy sikerült összemosnod a kettőt.

[félig ide, inkább Poli felvetésére]

Egy fokkal nagyobb baj a C-vel szvsz., hogy nem lehet egyszerűen kezdeti sikerélményt adni vele, vagy ha igen, akkor az tele lesz a szokásos "ezzel most ne foglalkozz"-szöveggel:

#include <stdio.h> <- ezzel most ne foglalkozz, mert ahhoz a fordítási folyamatot kéne értened

int main(int argc, char** argv) <- ezzel most ne foglalkozz, ezt így kell, mert csak. Lehet main(void) is, mert miért ne, de nem illik, ne foglalkozz vele
{
    printf("Hello World\n"); <- printf-el tudsz kiíratni stringet, amit a "" jelek közt rakhatsz, a \n a sortörés kivéve ahol nem, ne foglalkozz vele
    return 0; <- ezzel térsz vissza (hogy igazából egy függvényből térsz most vissza, azzal ne foglalkozz), a 0-val ne foglalkozz, majd egyszer elmagyarázzuk, hogy a processzeknek van exit kódja és sikerességet illik 0-val jelezni
}

De pl. egy Java-nál is teljesen ugyanez lenne:

package ...; <- kódszervezés, ne foglalkozz vele, majd később nézzük

import java.foo.asd; <- erre az osztályra (hogy mi az osztály, azzal most ne törődj) szükségünk lesz

class Pelda { <- ezzel deklarálunk egy osztályt, hogy mi az osztály, azzal most ne törődj

  public static int main(String[] args) { <- azzal, hogy mi a 1) public, 2) static, 3) String[] most ne törődj, így kell
     System.out.println("Hello World"); <- A System.out.println()-al tudsz szöveget kiírni, utána új sort kezdve
  }
}

Mindkettőnél 1 sornyi tényleges kódért oda kellett tenni rengeteg "zajt", amit rossz esetben akár hónapokig nem fognak érteni, de bemagolják, mert ÍGY KELL.

Úgyhogy igenis valami script nyelvvel kellene kezdeni, amiből az algoritmizálást megtanulják (és nem azzal szopnak, hogy a "fordítási folyamat így néz ki"), aztán fokozatosan be lehet vezetni a fenti "zajt", amint a hozzájuk kapcsolódó koncepciókat már értik. Szerintem, de nem vagyok tanár.

BlackY

lock

Fenti fv semmit nem fog kiírni, mert az összeszerkesztésnél elhal a dolog. Egyrészt a main hiánya miatt, de sokkal fontosabb, hogy nincs println :-)
X struktúra 12, Y pedig 13 byte méretű. Az már más kérdés, hogy feltételeztem, hogy a 32-bites architektúrán az int 32-bites, ami viszont - amikor én tanultam - egyértelműen fordító (rosszabb esteben fordítóparaméterezés) függvénye volt.

Én egyébként C-hez értőknek ezt a kódot szoktam feltenni kérdésként (szerintem már itt is írtam korábban). (ioccc.org, 1981, David Korn - ugye a Korn-shellről elnevezett emberke):

main() {
printf( &unix[ "\021%six\012\0" ], (unix) [ "have" ] + "fun" - 0x60 );
}

Feltétel: UNIX, vagy UNIX-like rendszer (nálam itt bukott el az AIX, mert nem tudta lefordítani); jó fordító (gcc jó, clang/llvm jó, pcc nem jó, de parancssori paraméterrel jóvá tehető); és mindez ASCII (vagy azzal felülről kompatibilis, pl. UTF-8) kódolású rendszeren (EBCDIC nem jó) - mondjuk ez utóbbi nem komoly feltétel.

Sok sikert!

Nos. Kezdem akkor, de olvasd is végig!

1. Tegyük fel, nem lennék képes megválaszolni a kérdéseidet. Ez semmit nem bizonyítana, nem lenne ellenérv arra amit fentebb írtam, mert minden programnyelvben fel lehet tenni olyan kérdéseket, amik csak igen mély ismeretek birtokában válaszolhatóak meg. Nyilvánvaló ugyanakkor, bármely nyelven kezdik is el tanítani a gyerekeket programozni, nem ilyen mélységben kezdik. Az általad felsorolt példák tipikusan ilyenek. Én például bár C nyelven oktatnám a programozást a kisiskolásoknak, de semmi esetre se a sizeof() -fal kezdeném.

2. Eddig nem tudtam róla, hogy létezne println függvény a C-ben. Megtippelem hogy ez talán a Java nyelv része, vagy kevered a writeln utasítással ami emlékeim szerint a Pascalban van. Mindenesetre ha van is ilyen a C-ben én még sosem használtam, becsületesen bevallom.

3. Épp ami a sizeof kérdéseidet illeti, azt semmiképp se válaszolhatom meg úgy, hogy bele ne köthess ha akarsz. Tudniillik, épp most e téren annyira vérprofi vagyok (mert muszáj a programnyelvem tervezéséhez e kérdéskör) hogy teljesen tisztában vagyok vele, a struktúrák mérete architektúra- és implementációfüggő, még akkor is, ha eltekintünk az olyan apróságoktól hogy némely mezőt netán nagy aljasul szóhatárra igazít a compiler! (holott az is megtörténhet). Nem beszélve arról, hogy te a struktúrába pointert is belepakoltál, az meg végképp olyasmi, aminek a mérete semmi esetre se garantálható „ránézésre”.

Na de kérdem én, egy kezdőt akit C nyelvre akarsz oktatni, ezzel fárasztanál le a legelején?! Én amikor elkezdtem tanulni a C nyelvet, nem a pointerekkel kezdtem. Hamar megbarátkoztam velük az igaz, de a MÉRETÜK soká-soká nem érdekelt, emiatt a sizeof() sem. Remekül megvoltam ezek nélkül tényleg nagyon sokáig. Azaz a C ettől még simán alkalmas kezdőknek.

Végezetül hogy ne hidd azt, hogy mindezt igazából nem tudtam, s netán mások irkálmányaiból puskáztam, idemásolom a programnyelvemről íródó könyvemnek pont azt a részét ami e kérdéskört boncolgatja (mert muszáj volt sajna...):

-------------- IDÉZET KEZDŐDIK! ---------------

Azaz, vegyük csak fel a következő deklarációt:

union V { // Az univerzális változó

unsigned char      c[16]; // Mérete  1 bájt
  signed char      C[16]; // Mérete  1 bájt
unsigned short int i[ 8]; // Mérete  2 bájt
  signed short int I[ 8]; // Mérete  2 bájt
unsigned int       l[ 4]; // Mérete  4 bájt
  signed int       L[ 4]; // Mérete  4 bájt
float              f[ 4]; // Mérete  4 bájt
unsigned long long g[ 2]; // Mérete  8 bájt
  signed long long G[ 2]; // Mérete  8 bájt
double             d[ 2]; // Mérete  8 bájt
long double D;            // Mérete 16 bájt

};

// A V unionban elhelyezkedő mezők egymáshoz viszonyított pozíciói:

// |  c[0] |  c[1] |  c[2] |  c[3] |  c[4] |  c[5] |  c[6] |  c[7] |  c[8] |  c[9] | c[10] | c[11] | c[12] | c[13] | c[14] | c[15] |
// |  C[0] |  C[1] |  C[2] |  C[3] |  C[4] |  C[5] |  C[6] |  C[7] |  C[8] |  C[9] | C[10] | C[11] | C[12] | C[13] | C[14] | C[15] |
// |     i[0]      |     i[1]      |     i[2]      |     i[3]      |     i[4]      |     i[5]      |     i[6]      |     i[7]      |
// |     I[0]      |     I[1]      |     I[2]      |     I[3]      |     I[4]      |     I[5]      |     I[6]      |     I[7]      |
// |             l[0]              |             l[1]              |             l[2]              |             l[3]              |
// |             L[0]              |             L[1]              |             L[2]              |             L[3]              |
// |             f[0]              |             f[1]              |             f[2]              |             f[3]              |
// |                             g[0]                              |                             g[1]                              |
// |                             G[0]                              |                             G[1]                              |
// |                             d[0]                              |                             d[1]                              |
// |                                                               D                                                               |

Sajnos az union változóinak fentebb felvázolt egymáshoz viszonyított elhelyezkedése csak ROPPANT VALÓSZÍNŰ (mármint Intel processzoros PC gépek esetében, 64 bites gépen), de igazából nem garantált. Azért nem, mert valami perverz indíttatástól vezettetve a C és C++ nyelveket úgy konstruálták meg, hogy ezen alaptípusoknak már a MÉRETE SEM GARANTÁLT, hanem architektúra- és implementációfüggő. Elméletileg - azt hallottam legalábbis - még az se garantált, hogy egy char változó 8 bites. Mondjuk ez elég valószínű persze, de akkor se TOTÁL biztos azért. Mindenesetre, többnyire azért biztosak lehetünk a fent felvázolt elhelyezkedésben, s abban, hogy 1 ilyen union összesen 16 bájtot foglal el, eképp a teljes unsigned char tartományra eső 256 darab efféle mindösszesen 4096 bájtot, vagyis pont 4 kilobájtot, ez majdnem biztos hogy így lesz igaz minden épeszű architektúrán. De akkor is csak MAJDNEM lesz biztos és nem TELJESEN, mert vannak nem épeszű architektúrák és fordítóprogramok is, vagy legalábbis effélék nem kizárhatóak. Mint említettem, mindezt Intel processzoros gépen próbáltam ki, 64 bites architektúrán, konkrétan egy Lenovo ThinkPad T530 -as gépen, s természetesen Linux operációs rendszerrel, a GCC csomag 4.8.1 -es verziójával, annak g++ fordítóprogramjával.

Ami a 32 bites rendszereket illeti, ott feltételezhető, hogy a long int felel meg a 4 bájtos méretnek, és a long double mérete 10 bájt, miközben a közönséges (signed vagy unsigned) int mérete csak 2 bájt. Hogy szarjon sündisznót de ne is egyet az a seggfej, aki efféle kavarást megengedhetőnek tartott és így találta ki e nyelvet!

----------- IDÉZET VÉGE! ---------------

A fentiekből kitűnik, vannak a C-nek olyan tulajdonságai, amik nekem nagyonis nem tetszenek. Ezek ellenére, igenis ezt tartom a legjobbnak jelenleg kb majdnem minden célra. Oktatásra pláne.

Akkor is igaz lesz ez ha elkészül a magam programnyelve. Az cseppet se oktatási célra lesz szánva, s előre biztos vagyok benne hogy bár nem lesz túl nehéz, de a C akkor is könnyebb lesz mint az „én” nyelvem.