@saxus:
Ezzel vitatkoznék: papírnak az a hatalmas nagy előnye, hogy csak és kizárólag magadra vagy utalva.

@saxus:
C bool témához:

C-ben konkrétan egyébként sincs bool típus. A C99 már definiál egy _Bool nevű típust meg egy bool nevű makrót rá (illetve a true/false-ra is egy 1/0 értéket), de valójában attól még ugyanúgy egy int a háttérben.

http://pubs.opengroup.org/onlinepubs/007904875/basedefs/stdbool.h.html

#include <stdio.h>
void main()
{
	if ((~(1 == 1)) == (!(1 == 1))) // if (-2 == 0)
	{
		printf("yes\n");
	}
	else
	{
		printf("no\n");
	}
}

root@Csabi:~# gcc fostalicska.c
root@Csabi:~# a.out
no
root@Csabi:~#

@saxus:
Viszont az and/or/bitand/bitor stb. operátorok is egyértelműen definiálva vannak,

@TCH:
Hát amennyiben heurisztikus optimalizációval tolja - amit kétlek - és kiszúrja, hogy nem nyúlsz a tömbhöz a ciklusban, akkor lehet, de akkor meg a fordítási idő lesz sokkal több.
Normál esetben nem optimalizálhatja ki.

@TCH:
Én ezt is óvatosan kezelném a helyedben, mert ez nem Pascal, ahol boolean és integer közti művelettől hanyattvágja magár a compiler, hanem C, ahol simán végrehajtja, márpedig az and, or, xor, not az mind kétértelmű, mert vonatkozhatnak int-re és bool-ra egyaránt. Hogy érthetőbb legyek, ezek a bool-algebrás műveletek: && || ^^ !, ezek pedig az integerre vonatkozóak: & | ^ ~, ezek az operátorok implicit módon hordozzák a művelet típusát, míg az and, or, xor, not nem, ami mint mondtam Pascalban oké, mert mismatch error lesz ha kevered, de C-ben végrehajtja.
Egy példa:

@TCH:
Elhiszem, de szerintem ne is bánd, az a cég amelyik papíron kéri a próbafeladatot, az teljesen komolytalan, akkor is, ha nagy cég.

@saxus:
Meg esetleg a fordító hibaüzeneteire.

@saxus:
Eddig akárhány tesztet láttam, mindenhol max 5-10 sor volt, amit írni kellett egy feladatnál.

unsigned long long int whatever(signed char x, signed int y, unsigned char z, signed long int a, signed char b, signed long long int c, unsigned char i, signed char j, signed char k)
{
	return c ^ (((x & 0x80) >> 6) | ((y < 50 ? y : ~y) << 5) | ((z << 24) & (a ^ ((i >> 4) | ((i & 15) << 60)))) | (j > k ? k * k : (j < k ? j * j : j * k)));
}

@saxus:
Huhú, ha tudnád mennyit mesél az, hogy ki mit javított. Ez az, amit gépen sosem látsz, hogy hogyan gondolkodott az illető. Papíron még néha van valami nyoma.

@saxus:
hanem arra, hogy magadtól tudsz-e algoritmizálni.

@saxus:
Azért egy primitív prímkereső algoritmust az embernek magától ki kell tudnia találni.

Kibelezlek, te rohadt, szemét, hülye állat szuka!
- Az ipszilon hurkolásából egyértelműen kiderül, hogy egy nyugodt, derűs személyiséggel van dolgunk!
Szmodis Imre karikatúrája

@saxus:
Melyik C-ben? Az ANSI-ban semmit nem mond, csupán annyit, hogy a logikai hamis értéke az integer 0, minden más igaz érték. Ez van a szabványban.. A C99-be is kb. csak azért került bele, mert _olvashatósági okok_ miatt mindenki definiálta magának a true-t 1-nek a false-t 0-nak, meg hogy kissé igazodjon a C++-hoz.

@saxus:
De te is tudod jól, hogy pont az ilyenek miatt inkább egy hordozható assembly a C, mintsem egy alkalmazásfejlesztő nyelv (azt maximum a hupuk hiszik, akik leragadtak 40 évvel ezelőtt...).

@saxus:
Bár erre a feladatra a C++ is megbukott, még Stroustrup szeirnt is.

@saxus:
(Mondjuk a C++11-el vagy 8-10 évnyi lemaradást behoztak a 20-ból...).

bazeg nekem se tetszett először a Pascal, utána rohadtul nem fogtam az OOP lényegét a Delphiben, aztán most meg még ott is objektumot kreálok, ahol nem biztos, hogy kéne

@saxus:
de nem kevés régi NextSTEP/MacOS-es program is ebben készült

@saxus:
De ez igazából nem probléma, máshogy definiálja a dolgokat a két nyelv. Egyébként ennek szerintem nagyon egyszerű az oka: PDP-11-en volt egy BIT nevű utasítás, ami lényegében a bitenkénti AND-nak felel meg és csak flag registert állít. Így két utasításból megvan az if. Ha -1-et követelsz meg mindenképp, akkor előtte még kell egy MOV és egy CMP. De ugyanez van x86-on is most is x86-on.

@saxus:
Arról nem is beszélve, hogy ezzel, hogy a logikai igaz-t úgy definiálták, hogy "minden, ami nem 0", kizárták azt, hogy legyen definiálatlan eset.

@kemi:
A Python nem soronként interpretál, hanem behúzza az egész kódot, gépi kódra fordítja, majd futtatja.

@kemi:
and, or, not vonatkozik a logikai műveletekre, bitand, bitor, compl, xor vonatkozik a bitenkénti műveletekre.

@kemi:
Valahogy kezdem úgy érezni, hogy ez nem tudás/képességfelmérés, hanem arra megy ki, hogy kibasszanak mindenkit aki nem csókos.

int max2nd(int* a, int len_a) {
    if (len_a <= 1) return NULL;
    int max = INT_MIN;
    int lastmax = INT_MIN;
    int count = 0;
    int first = a[0];

    for (int i = 0; i < len_a; i++) {
        if (a[i] > max) {
            lastmax = max;
            max = a[i];
        }

        if (a[i] > lastmax and a[i] < max) lastmax = a[i];

        if (a[i] == first) count++;
    }

    if (count == len_a) return NULL;
    return lastmax;
}

@TCH:
https://wiki.theory.org/YourLanguageSucks
XDDD

@kemi:
Akkor viszont az elsővel megegyező elemeket kell számolni, és úgy már helyesen le van kezelve az az eset, ha csak azonos értékekből áll.

@kemi:
Azért a C++-os részbe itt-ott bele lehet kötni:

@CppThis @ https://wiki.theory.org/Talk:YourLanguageSucks#Object-oriented_programming_sucks.3F_Perhaps_not.:
OOP doesn't suck, but a lot of OOP fanboys make it suck by expecting it to be a magical panacea to all problems everywhere. A well-architected procedural application scales just fine, and crappy OOP is impossible to leverage for anything beyond its intended purpose. My professional experience is due to the rise of ".NET communities" there is a lot more bad OOP (.NET) out there than bad procedural.

@saxus:
Mondjuk ahol ilyet írnak, így egy sorban, azt ütném szívlapáttal...

@saxus:
De az stdbool.h igen.

@saxus:
Amúgy Stroustrup szerint ott bukott meg a C++, mint alkalmazásfejlesztő nyelv, hogy magas szintű programnyelvnek nem elég magas szintű, mert túl sok mindenre kell figyelned így is, viszont ahhoz már magas szintű, hogy, a C-vel egy lapon lehessen említeni.

@saxus:
Egyik NetBSD-s arc mesélte múltkor, hogy ki akarja próbálni az OOP-s/C++-os megközelítést a NetBSD-n, mondván, hogy sokszor ugyanazt csinálják meg C-ben, amit egyébként a C++ nyújt nyelvi szintén.

@TCH:
A C-nél lassabb, de gyorsabban lehet benne fejleszteni, a Pascalnál gyorsabb, de lassabban lehet benne fejleszteni. Egy középút, ha úgy tetszik.

@kemi:
Pascalt manapság az égvilágon senki nem használ

@kemi:
a manapság használt fosnet meg dzsuvához képest meg milliárdszor jobb, még alkalmazásfejlesztésre is, mert mindent támogat ami ahhoz kell.

@saxus:
A példakódodban? Na ne már...

#include <stdio.h>
void main()
{
	if ((~(1 == 1)) == (!(1 == 1))) // if (-2 == 0)
	{
		printf("yes\n");
	}
	else
	{
		printf("no\n");
	}
}

@saxus:
Már milliószor elpofáztam, hogy nem az a lényege az OOP-nek, hogy objektumokat csinálsz ész nélkül, ha nem akarod érteni, ne értsd.

@saxus:
OOP nem ott kezdődik, hogy objektumaid vannak, hanem, hogy elkezdesz interface-kban, egységekben gondolkodni.

unit anyad;

interface

procedure lofaszt_a_seggedbe(name: string);

implementation

procedure lofaszt_a_seggedbe(name: string);
begin
	write('Lófaszt a seggedbe ' + name + '!' + #10);
end;

end.

@saxus:
C-ben ezt jellemzően úgy oldják meg, hogy csinálnak egy struct-ot, ott van egy halom fv pointer (pl. egy driver interface-ja), majd arra felaggatják az egyes fv-k pointerét.

@saxus:
Mondanám azt is, hogy olvasd el a porgramtervezési minták című könyvet, de úgy se tennéd...