Der Grund, warum C einfach schlecht ist

pointercrash**

Ich hab's mir fünf oder sechsmal anschauen müssen, bevor ich das kapiert habe, also habe ich wohl noch nicht "zuviel" in C gemacht, immerhin.

Aber das ist ja kein funktionaler Code, weil er keinen zwangsweise so zu codierenden Sinn enthält, sondern nur eine Schwäche freistellt, oder ist mir da was Wesentliches entgangen? Sowas schreibt doch niemand, der einen Nutzen davon haben will.
Auf der Schiene gefahren, fallen mir etliche Beispiele ein, wie ich Macro- fähige ASMs ins Schleudern bringe, hab' mir selbst oft genug darüber ins Knie geschossen.

Das ist von der Sorte Elchtest; wer weiß, was er macht, kriegt die Kiste auch so rum, wer das Programmierer- ESP braucht, sollte einfach seinen C- Führerschein abgeben und gemütlicheres Zeug benutzen.

C trifft keine schuld - der Code stammt aus dem Linux Kernel.

Shade Of Mine

~fricky schrieb:

wieso stolz? dass irgendso'n nöchtegern-haxxor exotische features eines speziellen compilers verwendet, um damit wirren code zu produzieren, kann man doch nicht als argument nehmen, um gegen C zu wettern. was unser OP-troll offensichtlich vor hat.

Diese technik ist aber eigentlich ziemlicher standard.

__builtin_types_compatible_p
suckt vom namen her, ein is_same<a,b> ist schoener als ein __builtin_types_compatible_p(a,b) - aber das prinzip ist das selbe.

Schoener ist es natuerlich, wenn man es noch in ein makro auslagert dass FORCE_ARRAY oder so heisst...

Das ganze mit schoeneren Namen:

#define IS_SAME(a,b) __builtin_types_compatible_p(a,b)
#define STATIC_ASSERT(val) (typeof(int[1-val]))
#define FORCE_ARRAY(arr) (STATIC_ASSERT(IS_SAME(arr, &arr[0])))
#define ARRAY_SIZE(arr) (sizeof(arr)/sizeof(arr[0]) + sizeof(FORCE_ARRAY(arr))*0)

Syntax Fehler vorbehalten.

pointercrash() schrieb:

Das ist von der Sorte Elchtest; wer weiß, was er macht, kriegt die Kiste auch so rum, wer das Programmierer- ESP braucht, sollte einfach seinen C- Führerschein abgeben und gemütlicheres Zeug benutzen.

für C braucht man zum glück weder führer- noch waffenschein. aber naja, wenn ich den code von da oben sehe, bin ich mir plötzlich nicht mehr sicher, ob's anders nicht wohl besser wär. hier ist übrigens ein video von diesem geisterfahrer, der das da^^ verbrochen hat: http://www.builderau.com.au/program/java/soa/Why-C-remains-relevant/0,339024620,339284206,00.htm

Shade Of Mine schrieb:

Diese technik ist aber eigentlich ziemlicher standard.

wo ist das standard? der 0815-c-compiler kennt weder 'typeof' noch '__builtin_types_compatible'. ersteres hab' ich mal bei C# gesehen, wobei das mehr dem 'instanceof' von Java entspricht. mit irgendwelchen speziellen compiler-features zu verhindern, dass jemand irgendwas anderes als ein array übergibt, mag zwar nett sein, aber es nagelt den code unweigerlich auf diesen compiler fest.

groovemaster

pointercrash() schrieb:

Aber das ist ja kein funktionaler Code, weil er keinen zwangsweise so zu codierenden Sinn enthält, sondern nur eine Schwäche freistellt, oder ist mir da was Wesentliches entgangen? Sowas schreibt doch niemand, der einen Nutzen davon haben will.

Noch besser, die Änderungen des Patches haben nicht mal was mit ISO C zu tun. Daher ist es recht sinnfrei, über Hacks oder dergleichen bezüglich C Repräsentativität zu philosophieren. Man müsste dann schon eine Grundsatzdiskussion über saubere Sprachansätze führen. Aber dazu ist unser "Javafan" wohl nicht in der Lage. Hauptsache ein bisschen rumtrollen und sich profilieren, anstatt etwas produktives zu machen. Ich kenne mich mit diesem Klientel wenig aus. Aber ist das das Niveau der Java Programmierer?

groovemaster schrieb:

Ich kenne mich mit diesem Klientel wenig aus. Aber ist das das Niveau der Java Programmierer?

Ja, ich hab gehört, dass die sogar Alkohol drinken.

pumuckl

ich kenn auch einen von denen. Echt schlimm, der raucht...

http://blog.fefe.de/?ts=b6015e3e schrieb:

Wer den auf Anhieb versteht, sollte sich direkt erschiessen, weil er zu viel C gemacht hat.
[...]
Wer das furchtbar findet, sollte von C++ weiträumig Abstand halten.

lol, wer c und c++ in den gleichen topf wirft sollte abstand halten von solchen aussagen :p

http://blog.fefe.de/?ts=b6015e3e schrieb:

Proudly made without PHP, Java, Perl, MySQL and Postgres

Don06

_D schrieb:

lol, wer c und c++ in den gleichen topf wirft sollte abstand halten von solchen aussagen :p

Genau das hab ich mir auch gedacht
Übrigens so sähe das in C++ aus:

template <typename Type, std::size_t Size>
std::size_t array_size(Type const (& array)[Size])
{
    return Size;
}

Produziert auch gleich einen Fehler, wenn man versucht einen Zeiger oder ähnliches zu übergeben. Ausserdem funktioniert das bei allen (standardkomformen) Kompilern. Aber der Autor des Textes hat ja schon bewiesen, dass er sowohl von C als auch von C++ keine Ahnung hat.

Ist es eigentlich bezeichnend, dass ein angagiertes Forenmitglied wesentlich besseren Code schreibt als die Linux-Entwickler? (Ich rede hier von Shade, sein Code übertrifft den angegeben Hack ja um Längen in Lesbarkeit und Wartbarkeit).

Gruß
Don06

Don06 schrieb:

Ist es eigentlich bezeichnend, dass ein angagiertes Forenmitglied wesentlich besseren Code schreibt als die Linux-Entwickler? (Ich rede hier von Shade, sein Code übertrifft den angegeben Hack ja um Längen in Lesbarkeit und Wartbarkeit).

Gruß
Don06

linus trollwalds hat eh keine ahnung von gutem code

ihr habt keine ahnung.

ich kann nur über die leute hier lachen, die meinen, sie wären in der lage uns kernelhacker zu kritisieren. was habt ihr denn bisher geleistet oder programmiert? und jetzt kommt mir nicht mit euren trivialen windows fenster anwendungen oder irgendwelchem kleinen mist.

Oder um es in Martin Richters Worten zu sagen

Martin Richter schrieb:

Dieses Forum kann kaum noch tiefer sinken...
Just my 2 cents!

abc.w

Don06 schrieb:

Übrigens so sähe das in C++ aus:
template <typename Type, std::size_t Size>
std::size_t array_size(Type const (& array)[Size])
{
    return Size;
}
Produziert auch gleich einen Fehler, wenn man versucht einen Zeiger oder ähnliches zu übergeben. Ausserdem funktioniert das bei allen (standardkomformen) Kompilern. Aber der Autor des Textes hat ja schon bewiesen, dass er sowohl von C als auch von C++ keine Ahnung hat.

Aus reiner Neugier (abgesehen von dem Sinn des Templates, den ich nicht verstehe), wie setzt man so ein Template ein? Hab nämlich auf die schnelle ausprobiert, geht nicht...
Mein ein wenig modifizierter Code:

template <typename Type, unsigned int Size>
unsigned int array_size(Type const (& array)[Size])
{
    return Size;
} 

int main(int argc, char *argv[])
{
    char buf[20u] = { 0u };

    argc = argc;
    argv = argv;

    printf("size of buf: %u\n", array_size(buf, 20u));

    return 0;
}

Mein Makefile:

all:
	g++ main2.cpp -o main2.o -Wall -Wextra -pedantic -O2
	g++ main2.o -o main2.exe -Wall -Wextra -pedantic -O2

Version von g++:

g++ (GCC) 3.4.5 (mingw-vista special r3)

Bekomme Fehlermeldung:

main2.cpp:18: error: no matching function for call to `array_size(char[20], unsigned int)'

ascda schrieb:

Oder um es in Martin Richters Worten zu sagen

Martin Richter schrieb:

Dieses Forum kann kaum noch tiefer sinken...
Just my 2 cents!

ist das nicht der kerl, der hinter jeden satz ein ausrufezeichen setzt?. das ist sein beitrag zum niedergang des boards.

Don06

printf("size of buf: %u\n", array_size(buf, 20u));

Das tolle an der Funktion ist ja, dass du die Größe eben nicht explizit angeben musst, sie wird aus dem Parameter hergeleitet.

printf("size of buf: %u\n", array_size(buf));

Gruß
Don06

rüdiger

@abc.w

Natürlich übergibt man nicht die Länge als Parameter

(und btw warum den Code falsch machen, wenn er schon richtig mit std::size_t geschrieben wird? und kein printf!)

#include <iostream>

template <typename Type, std::size_t Size>
std::size_t array_size(Type const (&)[Size])
{
  return Size;
}

int main()
{
  int buf[20u] = { 0 };
  std::cout << "länge: " << array_size(buf) << '\n';

  return 0;
}

Dravere

Don06 schrieb:

_D schrieb:

lol, wer c und c++ in den gleichen topf wirft sollte abstand halten von solchen aussagen :p

Genau das hab ich mir auch gedacht
Übrigens so sähe das in C++ aus:
template <typename Type, std::size_t Size>
std::size_t array_size(Type const (& array)[Size])
{
    return Size;
}

Genau sowas hatte ich mir auch gedacht. Bzw. vor allem habe ich mir dann gedacht, dass man in C++ halt erst gar keine C-Arrays einsetzen würde, sondern std::vector und Konsorten nehmen würde. Und die Funktion std::vector::size ist ja wirklich nicht so schwer zu verstehen.

Edit:
@rüdiger,
Das /sizeof(Type) ist aber unnötig

Grüssli

rüdiger

Dravere schrieb:

Edit:
@rüdiger,
Das /sizeof(Type) ist aber unnötig

ups

abc.w

Hallo,

Danke schön für die Korrekturen, jetzt geht's, war noch ein Fehler in meinem Makefile. So ist es richtig:

all:
	g++ -c main2.cpp -o main2.o -Wall -Wextra -pedantic -O2
	gcc main2.o -o main2.exe -Wall -Wextra -pedantic -O2

Und wenn man noch "inline" verwendet, pusht der Compiler nur die Konstanten auf den Stack, also, kein Verlust an Geschwindigkeit durch Funktionsaufruf oder so was. Scheint genauso gut wie ein Makro zu sein...

rüdiger

Das hat mit inline nichts zu tun. inline ist außerdem eher eine Anweisung für den Linker, als für den Optimierer (der inlined eh, was er kann und für sinnvoll hält) und template-Funktionen sind eh implizit inline.