| Zeige Beiträge 1 bis 15 von 44 Treffern |
Seiten (3): [1] 2 3 nächste » |
 Thema: Programmieren lernen |
|
|
Naja, die Diskussion ist tatsächlich wenig erträglich. Abgesehen von allen Argumenten die ich als Softwareentwickler gegen Java habe halt ich C++ trotzdem nicht für eine falsche Wahl, auch für Anfänger. Bei uns an der Uni wurde z.B. Programmieren mit C++ begonnen, Java kam dann erst später.
|
|
| Thema: Programmieren lernen |
|
|
| Zitat: |
Original von ed209
Ich bevorzuge die Sprache Java, wegen des höheren Grades an Abstraktion. Die Sprache ist klar definiert (Der Java Language Spec stehen mehrere C++ und C Standards sowie ABIs für die verschiedenen Platformen gegenüber, die alle berücksichtigt werden müssen).
lch grad mal wieder im Genuß C++ zu programmieren und ärger mich grad über wirre Compiler/Linker-Meldungen, bei denen ich Probleme habe zu verstehen was der Compiler überhaupt will (Und Compilerbau war mein Schwerpunkt).
Bei Java reicht ein Blick in die Spec und ich weiß genau was erwartet wird.
Und grad einem Anfänger ist nicht geholfen, wenn ihm erzählt wird er habe eine undefined referenced auf die vtable. |
Naja, wie mans nimmt. Compilermeldungen sind kein Sprachbestandteil, und wirkliche Probleme die Meldungen zu verstehen hatte ich bisher auch nicht. 
| Zitat: |
Original von ed209
Deine strikte Trennung von Schnittstellen zur Implementation existiert auch nur aus sicht eines Programmierers der linear programmiert, nicht objekt-orientiert.
Interfaces als Typen wie in Java gibt es in C++ nur behelfsmäßig über abstrakte Klassen. |
Versteh ich nicht, das ist eigentlich nicht was ich angesprochen hab. Was hat es mit linearer Programmierung zu tun wenn ich das Interface (nein, der Begriff bezieht sich nicht nur auf Interfaces die von Java ode C# bekannt sind) und dessen Implementierung trenne? Das hat in erster Linie nichts mit irgendwelchen Paradigmen zu tun sondern ist ein Ding der Übersichtlichkeit.
| Zitat: |
Original von ed209
Versteh mich nicht falsch, C++ hat sicher seine Berechtigung. Aber es ist ganz und gar nciht verwunderlich einem Anfänger zu Java zu raten. Da finde ich genug Gründe:
- klare Objekt-Orientierung (auch wenn nicht unbedingt strikt)
- hohes Abstraktionslevel (verglichen mit C++, keine Pointer, kein Speicherverwaltung)
- Klare Laufzeitumgebung (bei dem meisten Standardzeug kann man erwarten daß es überall gleich läuft)
- Verständlichere Compilermeldungen |
Nun, du nennst hier wieder genau die Gründe die immer genannt werden.
Zum Beispiel der erstgenannte Punkt: Wie gesagt ich empfinde den zwang zur Objektorientierten Programmierung eher als Negativbeispiel. Ich will als Programmierer lieber Freiheit bezüglich Problemlösungen haben. Objektorientierung bildet sich einfach manchmal nicht gut auf Problemlösungen ab und ich möchte lieber einen Prozeduralen Ansatz, oder ich schieß mit einem "funktionalen" Ansatz auf das Problem...
Ich musste bisher ein Projekt in Java entwickeln und hab aus diesen 6 Monaten wirklich nichts mitgenommen ausser das Java eigentlich alle interessanten Features von C++ entfernt hat.
|
|
| Thema: Programmieren lernen |
|
|
Wenn ich das mal kommentieren darf:
| Zitat: |
Original von CookieMonsta
Keine Header schreiben
-- Ok, das mag für Anfänger wirr erscheinen ist aber an sich ein sehr gutes Konzept das ich auf keinen Fall missen möchte (saubere Trennung von Interface und Implementierung). Und so wirklich problematisch ist das auch wieder nicht.
Grosse übersichtliche Bibliotheken
-- C++ bietet in seiner Standard Bibliothek (als auch TR1 und quasi C++ integriert boost (etcpp)) einen Haufen Bibliotheken an. So unübersichtlich sind die gar nicht. Bei C++ gibts eher dann Probleme wenn man Bibliotheken von Drittanbietern integrieren will und deren Konzepte sich, von z.B. der STL, unterscheiden. Allerdings macht die Java Library auf mich z.T. auch nen "patchwork" Eindruck, irgendwie wirkt das Ganze nicht so schön wie z.B. das .NET Framework. UND das Javazeug leidet extrem an nem Überdesign, schon wenn man sich die krassen Ableitungsbäume anschaut könnt man echt meinen, dass die Autoren manche Kernideen der OOP einfach missverstanden haben.
Kein pointer und referenzwirrwarr
-- Ich weiß nicht, und hab jetzt auch schon vermehrt die Zustimmung von Anfängern bekommen, wieso Pointer und Referenzen so einen schlechten Nachgeschmack hinterlassen, wenn davon gesprochen wird.
bessere Debugger zur Verfügung
-- Da muss ich dir wiedersprechen. Ich kenn keinen besseren Debugger als der den Visual Studio mitliefert.
Keine "unerklärlichen" Laufzeitfehler aufgrund von irgendwelchen Variablen
die aber const sein müssten und so quatsch
-- Das Argument versteh ich leider nicht ganz.
Bessere Tutorials Online
-- Für C++ gibts auch einige gute
Reihenfolge der Methoden wie sie in der .java vorkommen ist egal (Bei C++ z.b. sind alle Methoden die unter einer Methode X sind, von X nicht aufrufbar, d.h. nicht bekannt)
-- Das hat beim lesen Vorteile find ich. Und zur Not gibts ja die Möglichkeit Funktionen vorher zu deklarieren. |
|
|
| Thema: Programmieren lernen |
|
|
| Zitat: |
Original von CookieMonsta
[...] is einfach so |
Ist aber keine besonders gute Begründung! :P
|
|
| Thema: Programmieren lernen |
|
|
| Zitat: |
Original von 3FingerbreitNougat
| Zitat: |
Original von David_pb
Möglicherweisse macht die "steile" Lernkurve die Sprache ja für Anfänger attraktiv... |
Wenn du dir schon selbst das KO gibst: Genau das möchte man als Anfänger! |
Du solltest vielleicht nochmal genau lesen was ich geschrieben hab... Ich seh das ehrlich gesagt nicht als wirkliches KO Kriterium an.
Selbst als Anfänger sollte man sich überlegen ob man nicht lieber eine potentiell interessante Sprache einer Sprache wie Java vorzieht, selbst wenn das ggf (und ich persönlich zweifel stark daran, daher schrieb ich auch "steile") einen geringen Mehraufwand mit sich zieht.
|
|
| Thema: Programmieren lernen |
|
|
Schade das hier so viele Leute zu Java raten. Ich find die Sprache hat einfach nichts was sie wirklich interessant macht. Die am häufigst genannten Vorteile wie: strenge Objektorientierung, automatisierte Speicherverwaltung, Platformunabhängigkeit usw... sind für mich als Programmierer kaum von wirklicher Interesse. Ich hab das Speichermanagement lieber selbst unter Kontrolle und (auch wenn alle Akademiker aufschreien) es ist praxisfern erzwingen zu wollen ein Paradigma strikt durchziehen zu müssen, da bietet mir C++ doch die besseren Alternativen...
Möglicherweisse macht die "steile" Lernkurve die Sprache ja für Anfänger attraktiv... Ich kann leider nicht dazu raten, aus meiner Sicht (und der praktischen Erfahrung) würde ich tendenziell eher C++ empfehlen.
|
|
| Thema: Rückgabe eines Wertes bei einer Funktion!!!! |
|
|
Hi,
sorry ist zwar schon zu spät aber trotzdem! 
In einigen Sprachen (z.B. Pascal) gibts eine strikte trennung zwischen den Begriffen Funktion und Prozedur. Karakteristisch für Funktionen ist eben das sie einen Wert zurückgeben, was Prozeduren eben nicht tun.
Eine Prozedur ist quasi ein in sich abgeschlossenes Stück Code das ausgeführt wird ohne das ein direktes Resultat erwartet wird:
| code: |
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
|
procedure mywrite(xyz : string)
{
writeln('xyz = ', xyz);
}
function add(a : integer, b : integer) : integer
{
add := a + b;
}
program test;
var
x : integer;
begin
mywrite('test');
x := add(32, 10);
writeln( 'ergebnis = ', x );
end.
|
|
(Falls Fehler im Code sein sollten, ich hab schon ewig kein Pascal mehr gecoded, also bitte etwas Nachsicht!
)
Wie du siehst liefert add dir einen Wert zurück mit dem du weiter arbeiten kannst.
Das gleiche Konzept lässt sich auf C/C++ anwenden. Da haben "Prozeduren" einfach den Rückgabetyp void:
| code: |
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
|
void mywrite(const char* xyz)
{
printf( "xyz = %s\n", xyz);
}
int add(int a, int b)
{
return a+b;
}
int main()
{
mywrite("test");
int x = add(32, 10);
printf( "ergebnis = %d\n", x);
} |
|
|
|
| Thema: Zahl ausgeben... |
|
|
Du solltest dich dringend mal mit den Grundlagen beschäftigen!
| code: |
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
|
#include<stdio.h>
#include<stdlib.h>
int main (int argc, char* argv[])
{
// Funktionsdefinitionen dürfen nicht lokal sein. Nach der Signatur haben Definitionen kein Semikolon. Funktionsaufrufe sind keine Funktionsdefinitionen und auch nicht damit vereinbar...
void PrintBitLine (4711);
{
int i;
for (i=0; i <16; i ++) // i ++ ist unschön!
{
// 0 x8000 ist schlichtweg falsch. Das Leerzeichen muss weg! Außerdem existiert "us" nicht.
if(us & (0 x8000 >>i))
printf ("1");
else
printf ("0");
}
// Hier fehlt eine schließende Klammer
printf ("\n");
} |
|
Also nochmal zusammengefasst:
| code: |
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
|
#include <stdio.h>
#include <stdlib.h>
void PrintBitLine(int us)
{
int i;
for (i=0; i < 16; i++)
{
if(us & (0x8000 >>i))
printf ("1");
else
printf ("0");
}
printf ("\n");
}
int main (int argc, char* argv[])
{
PrintBitLine(4711);
return 0;
}
|
|
|
|
| Thema: HD5-Hash entschlüsseln?? |
|
|
| Zitat: |
Original von Wanze
hmm nee das geht nich. |
Naja, dafür sind Einwegfunktionen auch nicht gedacht...
|
|
| Thema: HD5-Hash entschlüsseln?? |
|
|
Du kannst aus dem Hashwert nicht die Orginaldaten rekonstruieren. Das einzige was du tun kannst ist Bruteforcemäßig testen ob der Hashwert von verschiedenen Werten gleich ist.
|
|
| Thema: Problem bei der Ausführungsreihenfolge |
|
|
Das Beispiel ist überhaupt nicht kniffelig. Der Compiler wählt immer die Methode mit dem besten 'Match' aus. Wenn es keine Methode gibt die genau zutrifft kann eine Methode gewählt werden die zutreffen würde wenn ein impliziter Cast möglich ist (z.B. oo.gg(uu) => B). Unabhängig davon ist es erlaubt Methoden zu überschreiben, was die Auswahl ggf nach oben verschiebt (Ableitungshierarchie).
Du musst also Unterscheiden zwischen Typ der Referenz (oder wie das in Java auch immer heißen mag) und Objekttyp. Beispiel:
oo.gg(ff); => A
oo.gg(uu); => B
Referenztyp und Objekttyp sind 'Oben'. Die Auswahl der möglichen Methoden beschränkt sich also auf das was die Klasse 'Oben' anbietet (es kann also auch nichts überschrieben werden usw...). Die Referenztypen von ff und uu sind 'Oben' (!) und 'Unten'. Für ff wird also gg(Oben) ausgewählt (passt ohne downcast) für uu gibts keinen passenden match, also wird gg(Mitte) gewählt.
ff.gg(ff); => L
Hier ist der Referenztyp von ff 'Oben' und der Objekttyp 'Mitte'. Da in 'Mitte' die Methode gg(Oben) überschrieben wurde wird diese gewählt, da perfekt zutreffend (nochmals: der Referenztyp von ff ist 'Oben').
ff.gg(uu); => B
Das ist gar nicht mal so interessant. Da ff den Referenztyp 'Oben' hat kann der Compiler nur von dort ausgehen (er findet gg(Unten) erst gar nicht). Würde Mitte z.B. gg(Mitte) überschreiben würde diese Methode gewählt werden...
|
|
|
| Zeige Beiträge 1 bis 15 von 44 Treffern |
Seiten (3): [1] 2 3 nächste » |
|
|
