main-Aufruf -> argc = 1, warum?

[HumeSikkins]

fdhdfh schrieb:

Nein, der Pfad zu deiner *.exe ist immer der erste parameter

Der Programmename nicht der Pfad. Ob der Pfad teil des Programmnamens ist, ist implementationsspezifisch.

[Gast996611]

Außerdem muss es nicht zwingend eine *.exe Datei sein. Unter Windows mag das vielleicht stimmen.

[fdhdfh]

HumeSikkins schrieb:

fdhdfh schrieb:

Nein, der Pfad zu deiner *.exe ist immer der erste parameter

Der Programmename nicht der Pfad. Ob der Pfad teil des Programmnamens ist, ist implementationsspezifisch.

Bei meinem Visualstudio ist es der gesamte Pfad zur exe und nicht nur der name der exe.

Und das mit "muss nicht zwingend eine exe sein" ist für mich haarspalterei, exe oder ausführbare datei, Prinzip ist gleich und ändert nichts an meiner aussage.

Falls es aber so sein sollte das standardmäßig nur der name der exe übergeben wird hätte ich gerne einen link dazu, wie gesagt bei meinem visual studio ist das anders.

[Vellas]

Hi!

Weder VisualStudio noch andere IDEs unterstüzen den Standard 100%. Allerdings ist es imho manchmal vllt. von Vorteil, wenn der gesamte Pfad und nicht nur der Dateiname übergeben wird, aber kein Standard. Der Pfad gehört außerdem nicht zu dem Parametern, wenn du
C:\>meinOrder\meineExe.exe
aufrufst könnte ich mir fast vorstellen das der Ordner mit dabei ist im Parameter.

Und das die ausführebare Datei nicht unbedingt eine Exe sein muss ist hier wohl jedem klar....

Code-Hacker

[volkard]

Code-Hacker schrieb:

Und das die ausführebare Datei nicht unbedingt eine Exe sein muss ist hier wohl jedem klar....

klar, aber com-dateien tut der compiler nicht machen.

[Vellas]

Hi!

volkard schrieb:

Code-Hacker schrieb:

Und das die ausführebare Datei nicht unbedingt eine Exe sein muss ist hier wohl jedem klar....

klar, aber com-dateien tut der compiler nicht machen.

Jo, die Option habe ich auch noch bei keinem Compiler gefunden.

Code-Hacker

[Horst2]

Meiner Meinung nach kommt es nur darauf an was man in der Kommandozeile eingibt.
Gibt man nur

meinProg.exe

ein, dann ist argv[0] auch nur "meinProg.exe".

Gibt man einen absoluten oder einen relativen Pfad an, so wird dieser in argv[0] gespeichert

[Gast996611]

Ich hab auch noch keine com Option gefunden. Ich kann aber exe, elf und a.out generieren. Schon toll so ein gcc!

Stimmt, "Keine IDE unterstützt den Standard 100%ig". Warum sollte eine IDE auch irgendeinen Standard unterstützen? Der Compiler sollte den C/C++ Standard unterstützen. Und im Gegensatz zum VS(.net) tu es der gcc 3.4(.1) perfekt!

[Vellas]

Hi!

Also ich habe bisher die Erfahrung gemacht das VS.net2003 den C++-Standard besser als der gcc/g++ unterstüzt. Irgendwo gab es auch mal eine Prozentangabe wie gut welcher Compiler den Standard unterstüzen soll.
Wenn es um C geht so unterstüzt VS.net2003 C99 und C89 glaube ich gar nicht mehr.

Code-Hacker

[SirLant]

Code-Hacker dir ist bewusst, dass C89 eine Untermenge von C++ ist und somit der vc7.1 diesen vollständig unterstützt?

Es gibt Compiler die .com generieren könnten, schaut mal ins asm Forum da wird sowas als mal gebraucht für nen eigenes OS.

Unterstützt dein gcc 3.4(.1) denn auch das export Tag?

[Vellas]

Hi!

@SirLant:
Hmmm...stimmt. Naja, hatte ich noch nie Probeleme mit, da ich ohnehin nur C89 (nach C++) gelernt habe. Allerdings ist es doch etwas anders. Man kann im Compiler nur einstellen das als C-Code oder C++-Code kompiliert werden soll und C++ kann ja doch einiges mehr als C89, auf das man halt achten muss, sofern man C++ vor C geproggt hat.

Code-Hacker

[SirLant]

Es ist komfortabler in C++ C zu programmieren als unter einer Einstellung die Strikt nach C89 kompilliert, so muss man z.B. alle Variablen an den Anfang eines Codeblocks schreiben und vor jedes struct ein Typedef oder vor jede verwendung ein struct schreiben, usw.

Und Geschwindigkeitstechnisch steht C++ in C ja in nichts nach, also warum sollte man sich das Leben so schwer machen

Ausgenommen natürlich, wenn man keine andere Möglichkeit hat.

[Vellas]

Hi!

SirLant schrieb:

Ausgenommen natürlich, wenn man keine andere Möglichkeit hat.

Genau die hat man in der Ausbildung leider nicht...
Obwohl in der letzten Vorlesung (war leider nicht da) von OOP gesprochen wurde, was es bekanntlich nicht in C gibt.....

Code-Hacker

[chullain]

Hallo,

..wie ich sehe, seid ihr ja schon Profis, was die c++-Programmierung angeht *schleim* ,
darum wollte ich fragen, ob ihr wisst, wie man ein COM-Objekt in eine Konsolenanwendung einbindet...ich hab es über den ATL-Wizard versucht, jedoch klappt das nicht, weil er dann anmeckert, es können nur ATL-Objekte zu bestimmten MFC-Projekten hinzugefügt werden...

weiss einer von euch, wie ich da vorgehen soll?

Gruss,

chullain

[SirLant]

ATL ist ja die kleine Version von der MFC deshalb geht das wohl nicht.
Ich habe 1mal etwas mit COM gemacht und das war mit Hilfe des MFC Assistenten und das war mir schon schrecklich genug, ich wollte es nicht in nem Winapi-Programm machen

Also das Beispiel von mir (Einmal nen COM Server und einmal nen Client) könnt ich dir mailen wenn du willst, aber wie gesagt ist mit MFC/ATL gemacht

[Vellas]

Hi!

chullain schrieb:

..wie ich sehe, seid ihr ja schon Profis, was die c++-Programmierung angeht *schleim*

RÖFL.
Falls ich gemeint bin halte ich das für ein Gerücht. Ich bin vielleicht kein Anfänger mehr, aber sich kein Profi.

chullain schrieb:

darum wollte ich fragen, ob ihr wisst, wie man ein COM-Objekt in eine Konsolenanwendung einbindet...ich hab es über den ATL-Wizard versucht, jedoch klappt das nicht, weil er dann anmeckert, es können nur ATL-Objekte zu bestimmten MFC-Projekten hinzugefügt werden...

weiss einer von euch, wie ich da vorgehen soll?

Wenn du VS benutzt kannst du einstellen das deine Konsolenanwendung die MFC verwenden soll. Dann musst du nur noch die Header einbinden (afx.h). Vielleicht kannst du dann ja auch die ATL versuchen zu verwenden, das kann man glaube ich ebenfalls einstellen. Guck mal ein wenig rum in dem Projekteinstellungen.

In VS.net 2003 findest du die Einstellungen für die MFC so:
Projekt->Eigenschaften->Konfigurationseigenschaften->Allgemein
->Verwendung von MFC
->Verwendung von ATL

Code-Hacker

[volkard]

SirLant schrieb:

ATL ist ja die kleine Version von der MFC deshalb geht das wohl nicht.

seltsam. das klingt, als gäbe es keine mfc-konsole-anwendungen. gibt's aber. hab selber mal eine gebaut, weil CSocket oder sowas so praktisch war.

[volkard]

Gast996611 schrieb:

Ich hab auch noch keine com Option gefunden. Ich kann aber exe, elf und a.out generieren. Schon toll so ein gcc!

ja, das war die idee.
neueste forschunen in unseren unterirdischen geheimlabors haben ergeben, daß man mit jedem compiler com-dateien machen kann.
einfach die a.out oder a.exe nach a.com umnennen.
windows führt die so erstellte a.com klaglos aus.
linux führt die so erstellte a.com auch klaglos aus.
sogar bsd gesellt sich in den reigen.
nur dos schwächelt ein wenig und reagiert seltsam, aber das benutzt ja keiner mehr, außer ich.

[Irgendwer]

Code-Hacker dir ist bewusst, dass C89 eine Untermenge von C++ ist und somit der vc7.1 diesen vollständig unterstützt?

was ist mit:

void*a;
char*b=a;

oder mit

void foo();
foo(5);

unter vollständig versteh ich was anderes.

Unter Windows wird main(int,char**) eine aufgespaltene Version der commandline die zum Aufruf des Programes geführt hat übergeben. Also wenn ich in der Console:

cd C:\
myapp

eingebe dann ist argv[0] "myapp.exe". Wenn ich aber:

C:\myapp

eingebe dann ist argv[0] "C:\myapp.exe".

Die genaue Formatierung häng allerdings von Compiler ab. MinGW würde zum Beispiel "c:/myapp.exe" angeben wogegen BC5.5 "C:\myapp.exe" angeben würde

[Bashar]

volkard schrieb:

nur dos schwächelt ein wenig und reagiert seltsam, aber das benutzt ja keiner mehr, außer ich.

Im Ernst? Das letzte mal, dass ich das probiert habe, ging es doch eigentlich noch (exe nach .com umbenennen und ausführen.)