Hilfe bei einer C++ Aufgabe



  • Firefighter schrieb:

    wenn du Eigeninitiative zeigst, hilft dir hier keiner.

    Hat er ja nicht, also mach mal, lol.



  • hehe du hast mich ertappt, hatte mich verschrieben 🙂



  • #define ARRAY_SIZE( array ) \
    	static_cast< size_t >( sizeof( array ) / sizeof( *array ) )
    
    unsigned long
    Summe_Restwerte(
    	const int *array_a,
    	size_t count_a,
    	const int *array_b,
    	size_t count_b,
    	unsigned long divisor )
    {
    	unsigned long modulus( 0 );
    
    	for( size_t i( 0 ); i < count_a; ++i ) {
    
    		modulus += ( array_a[ i ] % divisor );
    	}
    
    	for( size_t i( 0 ); i < count_b; ++i ) {
    
    		modulus += ( array_b[ i ] % divisor );
    	}
    
    	return modulus;
    }
    
    int main( )
    {
    	int foo[ ] = { 1, 2, 3, 4, 5, 6, 7, 8 };
    	int bar[ ] = { 3, 6, 9, 12, 15 };
    
    	Summe_Restwerte( foo, ARRAY_SIZE( foo ), bar, ARRAY_SIZE( bar ), 4 );
    }
    

    Erklären muss es dir ein anderer... 🙄

    cheers, Swordfish



  • Swordfish schrieb:

    //...
    

    Erklären muss es dir ein anderer... 🙄

    cheers, Swordfish

    Mal abgesehen, dass der Code mäßig ist, was soll sowas?



  • Tachyon schrieb:

    Mal abgesehen, dass der Code mäßig ist, [...]

    Klär mich bitte auf: Was ist daran "mäßig"?

    Tachyon schrieb:

    [...] was soll sowas?

    W T F !?

    cheers, Swordfish



  • @Swordfish: Meinst Du es ist wirklich sinnreich für andere hier Hausaufgaben zu lösen, vor allem wenn keine Eigeninitiative ersichtlich ist?

    Zu "Mäßig":
    1. Ich hätte eine Grundfunktion Summe_Restwerte geschrieben, die einen Array aufnimmt als Argument, und diese dann erweitert durch eine Überlagerung, die 2 Arrays aufnimmt:

    Summe_Restwerte(
        const int *array,
        size_t count,
        unsigned long divisor );
    Summe_Restwerte(
        const int *array_a,
        size_t count_a,
        const int *array_b,
        size_t count_b,
        unsigned long divisor )
    

    2. Halte ich die Konstrukor schreibweise für PODs und int's für nicht sonderlich lesbar und unüblich. Aber das ist eher eine Geschmacksfrage würde aber in unserer Firma nicht durch die Codingrichtlinien abgedeckt. 🕶
    3. Sind die Klammern in den += % Ausdrücken überflüssig. Auch hier ist für mich der Code eher irritierend durch zu viele Klammern.
    4. Ist Deine main Funktion definiert, so dass sie ein int returniert. Du gibst aber keinen Wert zurück!



  • Martin Richter schrieb:

    1. Ich hätte eine Grundfunktion Summe_Restwerte geschrieben, die einen Array aufnimmt als Argument, und diese dann erweitert durch eine Überlagerung, die 2 Arrays aufnimmt:

    ... was nicht der Aufgabe entspricht.

    2. Halte ich die Konstrukor schreibweise für PODs und int's für nicht sonderlich lesbar und unüblich. Aber das ist eher eine Geschmacksfrage würde aber in unserer Firma nicht durch die Codingrichtlinien abgedeckt. 🕶

    Eure Sache. Ist aber erlaubt und ganz gewiß nicht unüblich.

    3. Sind die Klammern in den += % Ausdrücken überflüssig. Auch hier ist für mich der Code eher irritierend durch zu viele Klammern.

    Für dich.

    4. Ist Deine main Funktion definiert, so dass sie ein int returniert. Du gibst aber keinen Wert zurück!

    Muss laut Standard auch nicht sein.

    Willst dich wichtig machen? Wirkt so. Auch wenn es wenn ein lächerlicher Versuch war.



  • Martin Richter schrieb:

    @Swordfish: Meinst Du es ist wirklich sinnreich für andere hier Hausaufgaben zu lösen, vor allem wenn keine Eigeninitiative ersichtlich ist?

    Sinnreich? Für irgendjemand der über diesen Thread stolpert weil er sich für die Übergabe eines Arrays als Parameter und das Zählen von Arrayelementen interessiert: Ja. Für den OP kann man das schwer beurteilen: Entweder er ist tatsächlich an einer Erklärung interessiert und hat nun einen Ansatzpunkt um Google die Richtigen Fragen(tm) zu stellen/sein C++ Buch zu konsultieren/whatever oder er gibt es einfach so ab. Im ersteren Fall hilfts vielleicht, im zweiten Fall fällt er - sofern das seine übliche Vorgehensweise ist - irgendwann auf die Schnauze -> schadet niemandem.

    Ich bin in solchen Threads oft der erste der "Denk doch selbst nach" schreit. Heute aus einer Laune heraus einmal nicht - na und?

    Martin Richter schrieb:

    Zu "Mäßig":
    1. Ich hätte eine Grundfunktion Summe_Restwerte geschrieben, die einen Array aufnimmt als Argument, und diese dann erweitert durch eine Überlagerung, die 2 Arrays aufnimmt [...]

    Hab ich zuerst auch vorgehabt aber dann doch noch an KISS gedacht.

    Martin Richter schrieb:

    2. Halte ich die Konstrukor schreibweise für PODs und int's für nicht sonderlich lesbar und unüblich. Aber das ist eher eine Geschmacksfrage würde aber in unserer Firma nicht durch die Codingrichtlinien abgedeckt. 🕶
    3. Sind die Klammern in den += % Ausdrücken überflüssig. Auch hier ist für mich der Code eher irritierend durch zu viele Klammern.

    Wie du sagst: Geschmacksfrage. 😉

    Martin Richter schrieb:

    4. Ist Deine main Funktion definiert, so dass sie ein int returniert. Du gibst aber keinen Wert zurück!

    schäm dich 🤡

    ISO/IEC 14882:2003(E) - 3.6.1 Main function schrieb:

    1. If control reaches the end
      of main without encountering a return statement, the effect is that of executing return 0;

    cheers, Swordfish



  • Martin Richter schrieb:

    Zu "Mäßig":
    1. Ich hätte eine Grundfunktion Summe_Restwerte geschrieben, die einen Array aufnimmt als Argument, und diese dann erweitert durch eine Überlagerung, die 2 Arrays aufnimmt.
    2. Halte ich die Konstrukor schreibweise für PODs und int's für nicht sonderlich lesbar und unüblich. Aber das ist eher eine Geschmacksfrage würde aber in unserer Firma nicht durch die Codingrichtlinien abgedeckt. 🕶
    3. Sind die Klammern in den += % Ausdrücken überflüssig. Auch hier ist für mich der Code eher irritierend durch zu viele Klammern.
    4. Ist Deine main Funktion definiert, so dass sie ein int returniert. Du gibst aber keinen Wert zurück!

    Zu 1.: kann man machen, muss man aber nicht, ist aber auf jeden Fall kein Argument, den Code als mäßig zu bezeichnen.
    zu 2.: Die Schreibweise ist durchaus üblich und standardkonform und nicht unübersichtlicher als einei Initalisierung per '='. Dass du es nicht gewohnt bist weils in deiner Firma nicht den Richtlinien entspricht ist deine persönliche Sache und macht den Code nicht schlechter.
    zu 3.: Ist auch eher Geschmackssache. Mit Klammern kann man arithmetische Ausdrücke wie die vorliegenden gliedern und übersichtlicher gestalten.
    zu 4.: main ist IMMER so definiert dass es int zurückgibt (void main ist C und nicht im C++-Standard), es muss aber kein explizites return aufgerufen werden.

    aber von mir ein
    5.: das ARRAY_SIZE - Makro ist völlig überflüssig und sorgt wie alle unnötigen Makros für kaltes Grausen. Das geht besser (weil typsicherer) mit templates

    edit: bullshit
    

    mit entsprechenden Erweiterungsmöglichkeiten...


  • Mod

    pumuckl schrieb:

    5.: das ARRAY_SIZE - Makro ist völlig überflüssig und sorgt wie alle unnötigen Makros für kaltes Grausen. Das geht besser (weil typsicherer) mit templates

    template <class T>
    size_t array_size(T arr) {return sizeof(arr)/sizeof(*arr);}
    

    mit entsprechenden Erweiterungsmöglichkeiten...

    Autsch. Das Argument ist sicher nicht verkehrt, aber mit diesem Template wird es Probleme geben.

    Die Frage mit den Klammern bei der Initialisierung von primitiven Variablen ist sicherlich Geschmackssache. Persönlich halte ich sie für scheußlich. Insbesondere, wenn ich Code nur überfliegen will, bleibe ich an solchen Stellen hängen, weil sie ihrer Struktur nach schwer von Funktionsdeklarationen zu unterscheiden sind, wenn man nicht auf die Argumentliste schaut. Und dieser Fakt erfüllt ziemlich genau meine Definition von unübersichtlich. Es ist ja gar keine Frage, dass man herausbekommen kann, was diese Zeile tut, oder das das besonders schwer wäre. Mir will auch kein Vorteil einfallen, den diese Form haben könnte. Deshalb vermute ich, dass hier mal wieder sinnloser Vereinheitlichungswahn am Werk ist. Trotzdem ist das selbstverständlich nur meine ganz persönliche Meinung dazu.



  • camper schrieb:

    pumuckl schrieb:

    5.: das ARRAY_SIZE - Makro ist völlig überflüssig und sorgt wie alle unnötigen Makros für kaltes Grausen. Das geht besser (weil typsicherer) mit templates

    template <class T>
    size_t array_size(T arr) {return sizeof(arr)/sizeof(*arr);}
    

    mit entsprechenden Erweiterungsmöglichkeiten...

    Autsch. Das Argument ist sicher nicht verkehrt, aber mit diesem Template wird es Probleme geben.

    Jup, autsch. Und sorry. War kurz vor Mittag und Blutzufuhr bereits auf Magen umgeleitet 🙄



  • pumuckl schrieb:

    mit entsprechenden Erweiterungsmöglichkeiten...

    template< typename T, size_t N >
    constexpr size_t countof( T ( &ary )[ N ] )
    {
        return N;
    }
    

    😉



  • pumuckl schrieb:

    [...] (void main ist C [...]

    Nein. Wenn man von plattformspezifischen Implementierungen absieht gilt

    ISO/IEC 9899:TC2 schrieb:

    5.1.2.2.1 Program startup
    1 The function called at program startup is named main . The implementation declares no
    prototype for this function. **It shall be defined with a return type of int **and with no
    parameters: int main(void) { /* ... */ } or with two parameters [...]

    pumuckl schrieb:

    5.: das ARRAY_SIZE - Makro ist völlig überflüssig und sorgt wie alle unnötigen Makros für kaltes Grausen. Das geht besser (weil typsicherer) mit templates

    Stimmt. Ich dummes Gewohnheitstier. Ich werd's mir hinter die Ohren schreiben.

    @Martin & Tachyon: Ich finde den entstandenen Austausch ganz und gar nicht sinnlos und auch nichts, das man mit einem "Was soll das?" kommentieren muss. Wie seht ihr das?

    cheers, Swordfish



  • Swordfish schrieb:

    ...
    Sinnreich? Für irgendjemand der über diesen Thread stolpert weil er sich für die Übergabe eines Arrays als Parameter und das Zählen von Arrayelementen interessiert...

    Über diesen Thread wird aber (dank des absolut nichtssagenden Titels) niemand "stolpern", der eine fachliche Frage hat....

    Mein Problem ist eher: Je öfter hier fauler Leute Hausaufgaben gelöst werden, desto mehr Kumpels laden sie ein ... und die wirklich interessanten Themen sind hier unter all den "Cindy braucht Eure Hilfe", "Hilfe", "Problem", "Brauche Lösung", .... - Threads nicht mehr zu finden.

    Ich wäre ja dafür, dass für solche Ansinnen ein eigenes Unterforum eingerichtet (oder das bisherige "Projekte"-Unterforum redefiniert) wird ... und zügig dahin verschoben wird. Da können sich dann die Leute, die Freude daran haben, solche Aufgaben zu lösen, austoben. 😃

    Gruß,

    Simon2.



  • Vielen herzlichen Dank.
    Ich studiere Energie und habe als Nebenfach Programmiertechnik...

    Leider ist das nicht ganz mein Themengebiet und somit auch nicht meine Stärke.

    Danke nochmals... Gruss



  • hundibundi schrieb:

    ...
    Leider ist das nicht ganz mein Themengebiet und somit auch nicht meine Stärke...

    Wird's dann wohl auch nicht mehr. :p 😉 😃

    Gruß,

    Simon2.


Anmelden zum Antworten