Gibt es eine Möglichkeit folgenden Code zu verkürzen?

int array[] = {1, 2, 3};
myfunc(array);

Ich hatte da an eine solche Variante gedacht: (die aber leider nicht geht)

myfunc({1, 2, 3});

Mfg X4rd3n

Abgesehen davon sollte man sowieso keine Arrays übergeben (zumindest nicht ohne Grössenangabe). Benutz doch STL-Container.

Längenangabe für das Array brauch ich nicht weil es immer gleich lang ist.

Soweit ich weiß müsste bei STL-Containern doch auch den Umweg über die Variable machen oder?

Ja. Man könnte zwar schon eine Frickelei mit temporären Objekten machen, aber das lohnt sich nicht (es sei denn, du benötigst nur einen der Containerkonstruktoren, z.B. für 5 gleiche Elemente). Was ist überhaupt so schlimm daran? Dass man es in Java kann und in C++ nicht? Falls ja, solltest du deine Einstellung von Grund auf ändern...

x4rd3n schrieb:

Längenangabe für das Array brauch ich nicht weil es immer gleich lang ist.

Wenn du die Längenangabe sowieso schon weisst, wieso machst du nicht eine Funktion mit genau so vielen Parametern?

x4rd3n schrieb:

Soweit ich weiß müsste bei STL-Containern doch auch den Umweg über die Variable machen oder?

Ja. Man könnte zwar schon eine Frickelei mit temporären Objekten machen, aber das lohnt sich nicht (es sei denn, du benötigst nur einen der Containerkonstruktoren, z.B. für 5 gleiche Elemente). Was ist überhaupt so schlimm daran? Dass man es in Java kann und in C++ nicht? Falls ja, solltest du deine Einstellung von Grund auf ändern...

Ich wollte mir halt die Arbeit sparen mir jedesmal neue Namen für das Array ausdeken zu müssen. Auch würde beim Umweg über die Initialiesierung auch jedesmal ein bisschen Speicherplatz belegt werden oder?

Nexus schrieb:

x4rd3n schrieb:

Längenangabe für das Array brauch ich nicht weil es immer gleich lang ist.

Wenn du die Längenangabe sowieso schon weisst, wieso machst du nicht eine Funktion mit genau so vielen Parametern?

Bei einem Array kann ich leichter mit optionalen Parameter arbeiten :).

void foo(int* arr) //...
foo((int[]){1,2,3,4,5});

Hach wie ich solchen Code doch liebe... ups ein , vergessen...

foo((int[]){1,2,3,45});

Und schon hat man einen Fehler im Programm, den der Compiler wohl in der Regel nicht finden kann... Und damit meine ich nicht einfach das es ein Wertefehler ist (undefiniertes Verhalten trifft die Sache durchaus auf den Punkt).

cu André

Wenn man sicher gehen will, dass das Array nachher nicht mehr existiert, weil es ja um die paar Byte schade sein könnte, kann man auch einen lokalen Block erstellen:

{
   int Array[] = {3, 1, 5, 7, 9};
   Function(Array);
}

Grundsätzlich wäre std::vector zwar sicherer, aber vielleicht für etwas konstantes, Datenbank-ähnliches nicht so komfortabel (zumal man für jedes Element push_back() aufrufen muss, wenn man nicht gerade mit Boost.Assign oder so arbeitet)...

//...
	size_t length = strlen(quelle);
	for(size_t i=0; i<=length; i++) ziel[i] = quelle[i];
//...

und die zweite Gruppe als:

//..
	while(*ziel++ = *quelle++);
//...

Ein erfahrener C/C++-Programmierer würde wohl das zweite Beispiel vorziehen.
Und wenn es ausreichend übersichtlich ist, dann packt man auch Einiges in eine Zeile.

@asc:
Na, das ist ja wunderbar. Dann halt:

const unsigned SIZE = 5;
foo( (int[SIZE]){1,2,3,4,5} );

Und hättest du hier ein Problem gehabt, dann würdest du auch mit einem benamten Array dieses Problem haben.

@asc:
Na, das ist ja wunderbar. Dann halt:

const unsigned SIZE = 5;
foo( (int[SIZE]){1,2,3,4,5} );

Und hättest du hier ein Problem gehabt, dann würdest du auch mit einem benamten Array dieses Problem haben.

Dann passen wir jetzt mal foo an, das es mit 6 Parametern arbeiten kann. Und ja, ich würde garnicht zum C-Array greifen. Die STL und TR1 bieten sicherere Alternativen. Sei es nun std::vector oder std::tr1::array.

cu André

Ein erfahrener C/C++-Programmierer würde wohl das zweite Beispiel vorziehen.

Und das aus gutem Grund. Der allerdings nicht darin besteht, dass die zweite Variante in eine Zeile passt. Das ist ein netter Nebeneffekt. Hauptgrund ist die höherere Performance. Wenn die Performance der ersten Variante höher wäre, dann wäre strcpy auch so implementiert, unabhängig davon ob's dafür mehr Zeilen braucht.

Womit schon wieder eine Zeile wegfallen würde.

Und was das Standardargument Performance betrifft: Woher weisst du, wie viel es ausmacht, wenn man zuerst ein Objekt erzeugt und dann dieses übergibt? Bzw. ob es überhaupt was ausmacht?

Naja, hier finde ich "premature optimization is the root of all evil in programming" ganz passend... Es gibt leider einfach zu viele Leute, die für einige Nanosekunden die Sicherheit und Übersichtlichkeit des Codes aufs Spiel setzen. Schau doch nur mal die C++-Streams an, die sind nicht gerade performant. Es ist aber auch jedem überlassen, printf() und Co. zu verwenden...

Und was das Standardargument Performance betrifft: Woher weisst du, wie viel es ausmacht, wenn man zuerst ein Objekt erzeugt und dann dieses übergibt? Bzw. ob es überhaupt was ausmacht?

Ich bin in keinem meiner Beiträge auf die Performance eingeganen, sondern auf die Prägnanz.

Die Beispiele sollten nur klar machen, dass man statt "lang und übersichtlich" wohl eher "kurz und übersichtlich" nehmen würde. Ich wollte gar nicht auf die Performance eingehen, da würe ich eher etwas in Richtung Duff's device nehmen, wenn sie gefordert wird.
Na dann halt so:

entweder:
//..
    while(*quelle != '\0'){
	*ziel = *quelle;
	*ziel++;
	*quelle++;
	}
    *ziel = '\0';
//...

oder:
//..
    while(*quelle != '\0'){
	*ziel++ = *quelle++;
	}
    *ziel = '\0';
//...

oder:
//..
    size_t i;
    for(i=0; quelle[i]!='\0'; i++) ziel[i] = quelle[i];
    quelle[i] = '\0';
//..

und nocht tausende weitere, wenn ihr wollt......

oder letzten Endes:
//..
    while(*ziel++ = *quelle++);
//...

Was jetzt? Irgendwelche Performance Unterschiede? Wohl eher nicht.
Und? Was werdet ihr nehmen? Klar, einfach std::string, oder? Aber davon haben wir gar nicht gesprochen.

Das Problem ist:
Gibt es eine Möglichkeit folgenden Code zu verkürzen?

int array[] = {1, 2, 3};
myfunc(array);

Ja.
Mein Vorschlag war:

myfunc( (int[3]){1, 2, 3} );

1. Das Problem wurde behoben: der Code ist kürzer geworden.
2. Ist der Code übersichtlich genug: ja, ja und noch mal ja.
3. Hätte die Ausführung des zweiten Fragments irgendwelche Laufzeitnachteile oder -vorteile gegenüber dem ersten: nein, jedenfalls sehe ich keine. Ein Array wird erzeugt, übergeben und danach zerstört. Der Unterschied ist bloß, dass im ersten Fragment ein benamter, im zweiten ein unbenamter Array erzeugt wird.

Das allgemeine Problem, dass man die Arraygröße bereits zur Compilerzeit wissen muss, um keine Fehler zu begehen, ist mir selbstverständlich bewußt. Dass in vielen Situationen Container die bessere Alternative zu Arrays sind, ist klar. Aber bei diesem Problem ist es nicht der Fall. Und eure kurze Sichtweise, dass man überall dort Container verwendet soll, wo es auch geht, ist falsch. C++ unterstützt viele Paradigmen. Bloß weil ihr euch nur auf eine stützt, macht aus euch keine besseren Programmierer.

Ich weiß nicht, was ihr jetzt noch ausdenken werdet. Jedenfalls behaupte ich nicht, dass man überall, wo es nur geht, diese unbenamte Array verwendet soll. Sondern nur dort, wo sie auch angebracht sind. Bei diesem Problem ist es der Fall gewesen.
Ich bin kein "eine Zeile"-Freak. Ich strukturiere meinen Code so übersichtlich wie es nur geht. Bei diesem Problem benutze ich einen unbenamten Array. Und ich glaube, viele würden das auch so machen. Schließlich gibt's noch Kommentare.
Wie dem auch sei, mein Vorschlag ist besser als eure.

Überzeugt mich, dass ich mich irre.

Und eure kurze Sichtweise, dass man überall dort Container verwendet soll, wo es auch geht, ist falsch. C++ unterstützt viele Paradigmen. Bloß weil ihr euch nur auf eine stützt, macht aus euch keine besseren Programmierer.

Ich halte mich tatsächlich aus einen Grund als besseren Programmierer:
Ich versuche Code zu schreiben der auch die nächste Wartung überstehen kann, und nicht so leicht unnötige Fehlerquellen einbaut, die man erst schwer zur Laufzeit ausmachen kann. Ich habe Compilerfehler lieber als laufzeitfehler.

// Getestet unter Visual C++ Express Edition, Servicepack 1
#include <array>
#include <iostream>

void foo(std::tr1::array<int, 5> const & arr)
{
    for(std::tr1::array<int, 5>::const_iterator it=arr.begin(), end=arr.end(); it!=end; ++it)
        std::cout << (*it) << std::endl;
}

int main()
{
    std::tr1::array<int, 5> arr = {1,2,3,4,5};
    foo(arr);
}

Der Code ist nun etwas länger, aber wenigstens bekommt man einen Fehler, wenn man jetzt die Funktion anpasst und statt 5 nun z.B. 10 Werte benötigt.

...
Das allgemeine Problem, dass man die Arraygröße bereits zur Compilerzeit wissen muss, um keine Fehler zu begehen, ist mir selbstverständlich bewußt. Dass in vielen Situationen Container die bessere Alternative zu Arrays sind, ist klar. ...

Und woher soll der geneigte Leser hier wissen, was Dir "selbstverständlich" und "klar" ist ?
Du (bzw. jemand, der den jederzeit frei verfügbaren Nick "user13" genutzt hat) hast hier unkommentiert ein "unübliches" Stückchen Code in die Runde geworfen - als Antwort auf die Frage eines (vermeindlichen) Anfängers (zumindestens lässt die Syntaxfrage das vermuten).

=> Du hast am falschen Ende gespart (oder wolltest eigentlich nur eine Diskussion über Deine Kompetenz initiieren).

Gruß,

Simon2.

user13 schrieb:

...
Das allgemeine Problem, dass man die Arraygröße bereits zur Compilerzeit wissen muss, um keine Fehler zu begehen, ist mir selbstverständlich bewußt. Dass in vielen Situationen Container die bessere Alternative zu Arrays sind, ist klar. ...

Und woher soll der geneigte Leser hier wissen, was Dir "selbstverständlich" und "klar" ist ?
Du (bzw. jemand, der den jederzeit frei verfügbaren Nick "user13" genutzt hat) hast hier unkommentiert ein "unübliches" Stückchen Code in die Runde geworfen - als Antwort auf die Frage eines (vermeindlichen) Anfängers (zumindestens lässt die Syntaxfrage das vermuten).

=> Du hast am falschen Ende gespart (oder wolltest eigentlich nur eine Diskussion über Deine Kompetenz initiieren).

Gruß,

Simon2.

Weil ja jeder anfänger mit

// Getestet unter Visual C++ Express Edition, Servicepack 1 
#include <array> 
#include <iostream> 

void foo(std::tr1::array<int, 5> const & arr) 
{ 
    for(std::tr1::array<int, 5>::const_iterator it=arr.begin(), end=arr.end(); it!=end; ++it) 
        std::cout << (*it) << std::endl; 
} 

int main() 
{ 
    std::tr1::array<int, 5> arr = {1,2,3,4,5}; 
    foo(arr); 
}

direkt was anfangen kann...

Weil ja jeder anfänger mit ...
direkt was anfangen kann...

Und deshalb soll man einen Anfänger also fehlerträchtigen Code vermitteln und C-Arrays verwenden, die ebenso komplex sind (Wenn man die vielen Fragen zur Zuweisung, Kopie, Übergabe etc. bedenkt kann niemand behaupten, das Arrays einfacher zu verstehen sind).

Ja, ich hätte den Code "vereinfachen" können (using namespace; Indexzugriff; Call-By-Value). Aber ich halte auch Anfänger in der Lage, Fragen zu stellen, und zeige ihnen lieber wie der Code in einer Anwendung in etwa aussehen sollte. Ich habe etwas dagegen Code zu vermitteln der
a) Unnötig fehlerträchtig ist...
b) ... in sauberen Anwendungen daher eh nicht eingebaut werden sollte...
c) ... und damit unnötiges Wissen darstellt.
Lieber liefer ich eine weitere Erläuterung nach.

Zum einen sehe ich dann, das der Anfänger auch wirklich Interesse hat (Nachfragen kostet nichts, außer vielleicht Zeit), und das er sich zumindestens mal mit den Code auseinander gesetzt hat (ohne fehlerträchtigen Code 1:1 in seinen Code per Copy/Paste zu übernehmen).

cu André
P.S: Ich will garnicht behaupten das ich von Anfang an sauberen Code gelernt habe, aber dennoch kenne ich es von mir das man alte Gewohnheiten schwerer ablegt. Wieso sollte ich also gleich Gewohnheiten schaffen von denen ich weiß, das er sie später ablegen muss?

Wenn man Arrays immer per Reference übergeben würde, hätte mein viele Probleme weniger.

Vor allem, weil man dann die Größe immer zur Compilezeit festlegen müsste

Felix

Vor allem, weil man dann die Größe immer zur Compilezeit festlegen müsste

Compiletime ist doch immer schön.

Wenn alle Lib-Entwickler ihre "Array-Funktionen" so definieren würden, hätte wir ne Menge weniger Ärger:

template<int S>
void printArray( int (&array)[S] )
{
    for(int i = 0; i < S; ++i) cout << array[i] << endl;
}

Ohne die Referenz würde das gar nicht funktionieren.

Oder das ganze für alle Typen:

template<typename T ,int S>
void printArray( T (&array)[S] )
{
    for(int i = 0; i < S; ++i) cout << array[i] << endl;
}

Edit: Gibt es dieses Idiom schon, wenn nicht ist es nun das KasF-Idiom