Beiträge von amok

[QUOTE=xxfunkxx]

char *playlist_container;
     strcat(playlist_container, "xxx"); [color=Red]// segmentation fault[/color]

playlist_container ist ein pointer auf char der gerade auf irgendeine adresse
zeigt die du nicht kennst weil du keinen speicherplatz reserviert hast. dann rufst
du strcat auf und das versucht in genau diesen speicherplatz zu schreiben.

while( fgets (my_string, 100, my_stream) != NULL) {
         strcpy(playlist_container+number_of_playlists, my_string); [color=Red]// funktioniert nicht[/color]

         printf ("%s", playlist_container[number_of_playlists]);        
         number_of_playlists++;
     }

hier das selbe problem. playlist_container zeigt noch immer irgendwo hin, nur nicht in einen speicherbereich den du kontrollierst.

lg
amok

Zitat

Das wesentliche steckt natürlich im get_next_playlist_name(). Da muss ich
mit popen oder dem umweg über eine Datei (ls *lst>playlisten.txt)
die namen nacheinander einlesen.
Eleganterweise aus dem wirklichen Namen und Listenlänge die Größen der Arrays ableiten oder dynamisch anpassen.

da gibt es mehrere moeglichkeiten.

1. so wie du das gesagt hast:
fork, umbiegen von stdout in eine pipe, exec des programms (zb ls) lesen aus der pipe.
oefnnen der files und einlesen.

2. dein programm mit commandline parametern aufrufen:
dein_programm *.lst => sie shell expandet *.lst auf alle files und du
hast sie alle in argv[1...] ... oeffnen der files, einlesen der files ...

3. haendisch: man 3 readdir, man 2 stat

lg
amok

ps:

buf=(char*)malloc(111);
    buf=get_next_playlist_name();

aufpassen, das ist garantiert ein memory leak.

Zitat von marX

also erst mal folgendes:
du hast dein prog. mit "return(0);" beendet
...das funktionniert zwar, aber return ist KEINE funktion
-> du solltest "return 0;" schreiben...ich habe in der htl den selben fehler gemacht worauf mich dann mein info-prof aufmerksam gemacht hat...

das ist eine ziemlich irrelevante stilfrage. es hat ja auch niemand behauptet
dass return eine funktion waere. die klammerung hier ist zwar nicht noetig,
man findet diesen stil aber oefters.

Zitat von marX

NEIN in c/c++ funktioniert das logischerweise nicht...
in c wird zb. "a^2" in "a*a" umgewandelt...also einfach ausmultipliziert
...wie soll der compiler das aber mit 0.5 machen ?

entschuldige bitte den rueden ton, aber dein htl lehrer haette dir lieber beibringen sollen, dass der binaere operator ^ sowohl in c als auch in c++ eine bitweise exclusiv-or verknuepfung durchfuehrt und nichts ausmultipliziert oder umwandelt.

Zitat von marX

NEIN in c/c++ funktioniert das logischerweise nicht...
....
-> 2 möglichkeiten:
1. du verwendest sqrt (egal ob's in dem buch schon erklärt wurde oder nich)
2. du schreibst dir selbst eine wurzel(a, b) fkt.

contradictio sine qua non! wenn sich der OP selber eine funktion schreiben kann -- und das will er offensichtlich -- geht es natuerlich.

lg
amok

Zitat von ravaged

Es muss noch einen anderen Weg geben. Ohne irgendwelche Includes..also denk dir das cmath mal weg...:D

Dann verweise ich dich auf die Lva's fuer Numerische Mathematik sowie das
exzelente Buch:
[2002] William H. Press, Saul A. Teukolsky, William T. Vettering, Brian P. Flannery; Nummerical Recipies in C++; Cambridge University Press

lg
amok

Zitat von ravaged

Es muss einen anderen weg geben. (a*a + b*b)^0.5 ungefähr

#include <cmath>
...
double a, b, c;
...
c = std::pow(a*a + b*b, 0.5);
...

der grosse vorteil hiervon bleibt mir aber leider verborgen

lg
amok

Zitat von ravaged

Wie gebe ich diese Rechnung bei C++ ein? Ich hab zwar gelesen das man wurzeln mit sqrt() zieht, aber diesen Befehl kenn ich bisher noch nicht

#include <cmath>
...
double a, b, c;
...
c = std::sqrt( a*a + b*b );
...

lg
amok

ps: wenn du sowas in c machst musst du die math library dazulinken. in c++
ist es inzwischen in der standardlib drin, was das ganze erleichtert.

Zitat von Guardian

soweit ich mich noch aus meinen c++ zeiten erinnere fehlt mir ein void main() der sogenannte programmeinsprungspunkt

nein. void main() wuerde den standard verletzen. der OP hat es richtig gemacht
und int main() verwendet. im geposteten code fehlt lediglich die '}' am ende.

das problem liegt in den while scheifen. dort bleibt das programm je nach eingabe
in einer endlosschleife haengen. ueberleg mal warum.

ein weiteres problem sind die berechnungen der 5 2 und 1 cent muenzen.
diese stimmen ueberhaupt nicht. schau dir an wie du es bei den 50, 20 und 10 cent
muenzen gemacht hast.

noch ein tip zum code:

std::cout << anzahl_1 << " 1er.\n";

wuerde ich mit:

std::cout << anzahl_1 << " 1er." << std::endl;

tauschen. das '\n' in einem string literal ist nicht so leserlich und der
stream-manipulator std::endl flushed auch gleich den output.

lg
amok

Zitat von fuxi17

Mit #define definierte Konstanten sind global was meistens zu vermeiden ist!! Mit const definierte Konstanten gehorchen den gewöhnlichen Sichtbarkeitsregeln und sind daher in den meisten Fällen zu bevorzugen.

nein. mit define definierte macros sind weder konstanten noch haben sie
einen sope (koennen deshalb auch nicht global sein). die macros werden
vor dem compilieren durch den praeprocessor ab der sichbarkeit des macros
bis zum ende des programmcodes oder eines #undef dieses macros ersetzt.

macros haben keinen typ und sind deshalb auch nicht typsicher. diese typsicherheit
kann durch verwenden von user-defined constanten erreicht werden. das schluesselwort const definiert dabei nicht notwendigerweise eine konstante sondern gibt den compiler lediglich den hint, dass dieses speicherobjekt als read-only zu betrachten ist. es ist syntaktisch kein konstanter ausdruck und kann durch cast auch veraendert werden.
/edit: was unter umstaenden undefined behaviour ausloest.

das schluesselwort const macht also nicht genau das was man denken koennte

die moeglichkeit die dem, was der OP machen will, am ehesten entspricht
sind enums.

die frage, wann was verwendet werden soll haengt stark vom problem ab,
das man loesen will. wenn man typsicherheit erzwingen will so kommt man
an einer user-defined constant oder eine enum nicht vorbei.

lg
amok

Zitat von iveo

Code

#include <iostream.h>
 
 int main();
 int main()
 {
 cout << "Hello World!\n";
 return 0;
 }

wäre das "richtiger"? - sofern es sowas bei Programmiersprachen überhaupt gibt?

es ist zumindest strict ansi conform obwohl auch hier die alten header verwendet
werdn (was nicht verboten ist aber langsam und sicher aus neuem codeverschwinden
wird). die definition von main vor der declaration main ist in diesem beispiel sinnlos.

Zitat von iveo

4. Ich würde eigentlich gerne mit dem Galilieobuch weiterarbeiten - möchte jedoch auch nichts falsches einstudieren - sollte ich es beiseite legen und mir ein anderes Lehrbuch suchen oder kann ich dabei bleiben?
(Ich meine das ist jetzt bestimmt schwer kalkulierbar für euch, da ihr das Buch wahrscheinlich nicht kennt - doch wenn zu grobe Fehler drin sind, dann leg ichs lieber weg!)

wenn dir das buch gefaellt und du damit gute fortschritte machst, lerne ruhig damit
weiter. du solltest dir aber bewusst sein dass du spaeter c++ code sehen wirst, der
ganz anders aussieht bzw. deine programme mit unterschiedlichen compilern nicht
ohne probleme compilierbar sein werden.

das ist als anfaenger kein problem. wenn du allerdings ernsthaft projekte in c++
realisieren willst solltest du dich mit literatur befassen, die sich standardkonformer
und penibler mit der sprache auseinander setzt.

lg
amok

Zitat von iveo

Wenn ich eine weitere Ausgabe hab und dann eine Eingabe nach zum Beispiel "Y" für yes fordere - dann funktioniert das - aber das muss doch auch irgendwie anders gehn - oder?

dein problem liegt _nicht_ im bereich deines programmes. dein programm wird ausgefuehrt und beendet sich. dann schaltet sich windows ein und fragt nach einer taste um das terminal zu schliessen (siehe wolfmanns posting).

irgendwo in den tiefen der windows configurationsdialoge kann man dieses verhalten
sicher mit einem hakerl abschalten

Zitat von iveo

Das hier wäre zum Beispiel der erste Übungsquellcode aus meinem Buch:

dein buch scheint nicht das neueste zu sein und nebenbei nicht besonders viel
vom c++ standard zu halten.

// das sind die alten c++ header in denen die classen und funktionen nicht
 // in die namespaces gemapt werden. man sollte sich von ihnen verabschieden 
 // und statt dessen die neuen verwenden.
 // #include <iostream>
 #include <iostream.h>


  // der standard erlaubt keine funktionsdeclarationen ohne typ 
  // mehr (im gegensatz zum c standard)


 // int main()
 main()
 {
 	int Zahleingabe;
 	int Doppel;
 	int Enter;

        // wegen den neuen headern brauchen wir auch namespaces
        // std::cout << .... << std::endl; 
        // ...
 	cout << "Bitte geben Sie eine Zahl ein!" << endl;
 	cin >> Zahleingabe;
 	Doppel = Zahleingabe * 2;
 	cout << "Das Doppelte dieser Zahl ist " << Doppel << endl;
 
 // jetzt muessen wir natuerlich auch ein integer zurueckgeben
 // return 0;
}

[/QUOTE]

Zitat von dumpfbacke

Ja da hast du recht aber es ändert nichts an der Tatsache das er trotzdem den Email Client öffnet und es nicht direkt verschickt.

ja, das von dir gewuenschte verhalten ist browserabhaengig (netscape irgend a 3er version machte genau das was du willst).

zitiert aus partels einfuehrung:

Manche (wenige) Web-Browser bieten die Möglichkeit, Formulare per E-Mail zu verarbeiten. Dazu würden Sie im Formular mit
<form action="mailto:user@host.domain" enctype="text/plain">
Ihre eigene Mail-Adresse angeben, und jedesmal, wenn ein Leser dann den Submit-Knopf "drückt", bekommen Sie den Formularinhalt als lesbaren Text per E-Mail in Ihre Mailbox gesendet und können ihn dann händisch oder mit einem auf Ihrem Computer laufenden Programm verarbeiten.

Allerdings werden solche Mailto-Formulare von sehr vielen Web-Browsern nicht unterstützt. Diese Methode kann daher nur innerhalb von kleinen, geschlossenen Benutzergruppen eingesetzt werden, bei denen man sicher ist, dass sie alle eine dafür geeignete Browser-Version verwenden, abe nicht für allgemein verwendbare Anwendungen.

lg
amok

Zitat von dumpfbacke

Ich habe jetzt vor <body> die Zeile eingefügt und nach </body> beendet mit </form>

wuerde dir empfehlen das <form> tag auch dort zu verwenden wo es hingehoert,
naemlich _in_ den <body> part. desweiteren solltest du dir vielleicht einen
html einfuehrungstext zu gemuete fuehren.
zb: den etwas aelteren aber leicht verstaendlichen text von hubert partl unter http://www.boku.ac.at/htmleinf/hein.html

lg
amok

ich empfehle allen die diese "diskussion" (sachlich oder emotional) fuehren den essay von neal stephenson "In The Beginning Was The Commandline"

freie versionen davon gibts zu hauf im netz. zb unter:
http://artlung.com/smorgasborg/C_…M_I_C_O_N.shtml

ihr werdet solche glaubenskriege mit ganz anderen augen sehen, versprochen.

lg
amok

Zitat von JohnFoo

... aber zur Einführung hat mir das Buch "OpenGL Game Programming" von David Astle & Kevin Hawkins (ISBN 0761533303) ganz gut gefallen.

ich wuerde von den game programming buechern von prima tech abraten. sie bieten weder im bereich spiele programmierung noch im grafik bereich mehr als eine oberflaechliche einfuehrung.

fuer opengl empfehle ich 'Woo, Neider, Davis, Shreiner; OpenGL Programming Guide, Fourth Edition; Addison Wesley'. dieses buch wird dir auch in den computergrafik lvs wertvolle dienste leisten (als ergaenzung zu 'hearn, baker; computer graphics; prentice hall' die in der dritten edition uebrigens auch opengl beispiele enthalten).

lg
amok

http://discuss.fogcreek.com/joelonsoftware…ow&ixPost=25943

lg
amok

Zitat von djmaecki

Aha, C99 hab ich mir noch nicht reingezogen, bin eher C89 gewöhnt ;-). Oder war das damals auch schon so? Man lernt ja nie aus.

war damals genauso, nur die nummerierung war anders

lg
amok

Zitat von djmaecki

Code

#ifndef _COLPRINTF_H
    #define _COLPRINTF_H

   /* [...] */
 
    #endif /* _COLPRINTF_H */

Dann kann es dir nämlich nicht mehr passieren, dass der Linker sich über Nameclashes bei den globalen Variablen aufregt.

auch auf die gefahr hin, paedantisch zu wirken, muss ich doch einwenden, dass du im code beispiel durch die verwendung des identifiers _COLPRINTF_H einen schlechten tip gibst.

der standard reserviert die nutzung von identifieren die mit _<grossbuchstabe> sowie __ beginnen (ISO/IEC 9899:1999 7.1.3). auch wenn es hier in diesem fall keine gefahr ist sollte man genau sowas nicht verwenden um nameclashes mit zukuenftigen library versionen zu verhindern.

lg
amok

Zitat von michi204

Code

colprintf.o(.data+0x0): In function `colprintf':
/home/mj/programming/c/colprintf/colprintf.c:7: multiple definition of `COLOR_SPECIAL_RESET'
.
. (das gleiche für jede Konstante)
.
test.o(.data+0x0):/home/mj/programming/c/colprintf/test.c:4: first defined here
collect2: ld returned 1 exit status
make: *** [all] Error 1

ohne den code zu kennen wird dir wohl niemand etwas konkreteres sagen koennen als
der compiler. du hast diese konstanten oefters definiert.

lg
amok

Zitat von Plantschkuh!

test -s wär auch eine Möglichkeit. Generell kann test ganz viele tolle Sachen.

oh, cool, dachte das ueberprueft nur ob das file existiert ... aber manpage lesen macht schlau

diese moeglichkeit is dann ja wohl die beste

Zitat von bimbo

ähem... wie machet man das genau?

da gibts viele moeglichkeiten.

zb gibt dir
find <filename> -printf "%s"
die anzahl der bytes zurueck.