Announcement: there is an English version of this forum on Hello I'm currently working in a C++ project and I'm excited to explore methods for optimizing code efficiency. My aim is to confirm that my code runs as efficiently as possible while maintaining readability and ease of maintenance. I would greatly appreciate any suggestion for enhancing the performance of C++ code. Specifically, I'm interested in learning about techniques for boosting runtime performance and minimizing memory usage , Common errors to watch out for and how to avoid them to prevent inefficient code. Recommendations for tools and approaches to identify and resolve performance issues effectively. Strategies for writing code that is both efficient and well-structured for future maintenance. Whether you're a experienced C++ developer or have valuable insights to offer, I'm eager to learn from your experiences . Thank you in advance !
Do not help the compiler: straight code, no tricks. Enable highest Compiler Optimization. If you want to rewrite Code, check that it really is a bottleneck, then ask specifically again.
Greg B. schrieb: > My aim is to confirm that my code runs as efficiently as > possible while maintaining readability and ease of maintenance. Maintaining readability and ease of maintenance is much more important, than performance. Optimize performance only if really necessary, and only where necessary. If you optimize your code for low CPU/memory manually, you waste a lot of time and risk to introduce new problems. The next larger/faster computer is often the better option (easier, cheaper, faster to get, better to maintain). > boosting runtime performance and minimizing memory usage is mainly the job of the compiler. After a while, you will learn to avoid some very bad things. For example manipulating large strings to produce a HTTP response can often be replaced by a sequence of shorter writes. Reading the same data repeatedly from an external source may benefit from a cache (which might be a simple array or hash-map). For PC and servers I can recommend Dynatrace. It helps you a lot to find the hot spots, even in a productive environment. Wait until you have a real bottleneck, then try their demo. https://www.dynatrace.com
Greg B. schrieb: > I'm currently working in a C++ project and I'm excited to explore > methods for optimizing code efficiency. Arbeite einfach die bekannten Bücher durch. Da kannst du eine Menge lernen. Darüberhinaus sind so allgemeine Fragen eher ineffektiv, viel besser ist es, direkt problematische Code-Abschnitte zu zeigen. Du würdest dich sehr wundern, was da so alles geht ;)
Rbx schrieb: > Darüberhinaus sind so allgemeine Fragen eher ineffektiv Anders kanns ChatGPT halt nicht. Oliver
The question might have a historical reason. In the '80s a good programmer had to know how to optimize source code for the limited machine. But in the meantime, the compilers became much better, and the computers became 1000x more powerful. Now we can quickly develop huge programs that get out of control due to their complexity. Read about the KISS priciple!
Na ja, wie immer kommts auf die Anwendung an. Manchmal reicht KISS nicht aus. cppcon hat da ein paar sehr nette Beispiele. So wie das hier: https://youtu.be/NH1Tta7purM?si=zCVdc6cYjAfbcSZH Oliver
Oliver S. schrieb: > Anders kanns ChatGPT halt nicht. Das war auch mein erster Gedanke! Mittlerweile scheinen die LLMs ja proaktiv das Netz abzugrasen. Und sie haben auch schon gelernt welche Vornamen man benutzen muss um instantan Welpenschutz zu erhalten.
Greg B. schrieb: > I'm currently working in a C++ project and I'm excited to explore > methods for optimizing code efficiency. My aim is to confirm that my > code runs as efficiently as possible while maintaining readability and > ease of maintenance. Well, ok, just the quest for the holy grail, nothing less than that. Good luck! > I would greatly appreciate any suggestion for enhancing the performance > of C++ code. Specifically, I'm interested in learning about techniques > for boosting runtime performance and minimizing memory usage , Common > errors to watch out for and how to avoid them to prevent inefficient > code. Well, as someone said in this thread before in different words: optimization is just the last 1%, the remaining 99% are driven directly by your technical architecture. First spot to search for optimizing speed of your software is there. If there's no room available in there - well, there's only one thing possible to do: profiling your code and find the performance weak spots. > Recommendations for tools and approaches to identify and resolve > performance issues effectively. > Strategies for writing code that is both efficient and well-structured > for future maintenance. Do MISRA-C++, and this is meant seriously. It might help you writing clean code and will punish you for doing magical, tricky programming style. Do apply Google C++ coding style. Learn Clean Code C++ development somewhere. But don't primarily focus on writing the fastest code on the planet. If you want to go that way, learn to program Commodore C64/Amiga demos in Assembler :)
Bruno V. schrieb: > Do not help the compiler: Of course you can help the complier; provided the compiler allows contribution. The compiler is the key point when it comes to producing efficient code. Hence the place to go is the compiler.
Da müsste man erstmal die Fähigkeiten kennen. Außerdem müsste man die Plattform kennen. Ein Code für eine ATmega328 sollte beispielsweise keine komplexe Mathematik enthalten, während das auf einem Intel i7 kein Problem ist. Wenn du noch nicht den Startpunkt, den Weg, sondern nur das Ziel definieren kannst, solltest du erst dort anfangen.
Johann L. schrieb: > The compiler is the key point when it comes to producing efficient code. Yes, but current compilers are the last point where additional optimization makes sense, because they are all already very good.
C++ bietet natürlich von seiner Architektur her auch grandiose Möglichkeiten, hochineffizienten Code zu schreiben - da sich auch hinter Dingen, die aussehen wie simple Zuweisungen, hochkomplexe Funktionen verbergen können, muss man also wissen, was der Code tut, den man da so hinschreibt. Gerade beim so beliebten Einsatz fremden Codes (sei es in Form eines "Frameworks", einer Klassenbibliothek oder was auch immer) kann sich hinter einer simplen Fassade erstaunlich komplexes verbergen. Es empfiehlt sich daher, fremden Code nicht einfach zu verwenden, sondern auch mal reinzusehen und nachzuvollziehen, was der so treibt.
Steve van de Grens schrieb: > Johann L. schrieb: >> The compiler is the key point when it comes to producing efficient code. > > Yes, but current compilers are the last point where additional > optimization makes sense, because they are all already very good. Both of you are right: the TO should focus on basics, because experts like Johann contributed to compilers, the key part for efficient Code
Greg B. schrieb: > I'm excited to explore > methods for optimizing Übrigens sind die Bethesda-Leute auch immer so aufgeregt, was sie wieder "aktuell" zusammengecodet haben. Jetzt sehen die vor lauter Aufregung aber gar nicht mehr den Scherbenhaufen, den sie angerichtet haben. -> mal runterkommen von dem Trip, etwas entspannter werden, und mit nüchternen Blick auf die Situation schrittweise Hindernisse und Missverständnisse abbauen.
Mich wundert das noch keiner gesagt hat, das man für wirklich effizienten kleien schnellen Code nur Assembler nutzen kann. Und das dann das Geschrei los geht ach wie toll doch Compiler sind. Und der Witz des ganzen ist, das beide Seiten recht haben, je nach Maschine und Situation. Harald K. schrieb: > Es empfiehlt sich daher, fremden Code nicht einfach zu verwenden, > sondern auch mal reinzusehen und nachzuvollziehen, was der so treibt. Verstehen heißt das zauberwort. Stichwort Sicherheitslücken, was bedeutet je nach Anwendung des Ganzen kann man fremder Leute Code gar nicht einsetzen, aber Dank Scrum und Konsorten muss man weil man sonst nicht fertig wird. Resultat: großer lahmer Code mit unwartbarem Fremdcode und dadurch unstopfbaren Sicherheitslöchern. Oder 5-Minuten-Arduinoprojekte, die einfach tun.
Steve van de Grens schrieb: > In the '80s a good programmer had to know how to optimize source code > for the limited machine. Yes. > But in the meantime, the compilers became much better, No. Just have a look at the compiler generated code: still the same bullshit. > and the computers > became 1000x more powerful Yes, but the resulting application programs still run as slow. That's because the developer stops optimizing, if the small samples he tries on his powerful development machine runs barly fast enough.
Greg B. schrieb: > My aim is to confirm that my code runs as efficiently as possible You do this by looking at the machine instructions that are executed to solve the problem - including error checking. If no instruction can be omitted to solve the given problem, even after reordering, than your implementation is as efficient as possible (given the selected algorithms). Ok, additionally considering the impact of the cache on instructions and operands. And IT IS possible to write a program in C and even in C++ that only executes the strictly neccessary instructions. You just have to check what your coding practice and structure generates on the machine level. A lot of work, but possible. A C++ program does not need to be slower and bulkier than a C program. Only use the handy language constructs when they are contributing for good.
Michael B. schrieb: > Yes, but the resulting application programs still run as slow. Programs become slower faster than computers become faster, isn't it? Michael B. schrieb: > You just have to check > what your coding practice and structure generates on the machine level. So, bascially, you say i should write in C but check und understand what the compiler does in assembly, and optimize the C so it gives perfect assembly? Then why not write in assembly directly? I'll only need to learn one language, need only to check and understand one language and can use the IDE much more efficient.
Jens M. schrieb: > Then why not write in assembly directly If you really want Greg B. schrieb: > that my code runs as efficiently as possible than you should do it. Readability may also gained in assembly using comments. But most people today are too lazy to write large assembly programms and are able to keep track of the program as a whole. Lets say your overview extends only to a certain amount of lines of code, let it be 300 for beginners or 3 million for experts. Than your C++ program may tackle larger problems than your assembly code
Jens M. schrieb: > Programs become slower faster than computers become faster, isn't it? No. I don't want my 286er back. Jens M. schrieb: > why not write in assembly directly? Because programming complex programs in assembly takes much more time. Also assembly does not support you in structuring large programs. You are a very lucky man if you find a patreon who pays you for that.
Michael B. schrieb: > But most people today are too lazy It' not a question if laziness. We (programmers) are artist, but we need money to live, like all others as well. By the way: I won an assembler contest long ago. The most beautiful Screensaver below 1k. My was only 99 Bytes.
Steve van de Grens schrieb: > No. I don't want my 286er back. I don't, too. But you can't deny that programs become bigger and bigger, Linux the same as Windows the same as every application that is around for some time. And especially when you try new versions of OS's on the same machine you can not ignore that the newer version can do more, but mostly useless stuff, and gets a lot bigger and slower. Michael B. schrieb: > If you really want You said that, basically ;) Steve van de Grens schrieb: > Because programming complex programs in assembly takes much more time. Yup. It was a reply to Michael B. that said "you should check your C to see what it does in assembly, and optimize the C so that the assembly is best", and so i said why not write assembly directly? C is there for a reason... Steve van de Grens schrieb: > We (programmers) are artist, but we need > money to live, like all others as well. So, it's the BWLers, as always... :D Funky how we treat the AI request of the OP as a leader and reply in a foreign language on a german forum. Not that ucnet has a english sister forum...
Use efficient algorithms. Not trying to do what the compiler does better anyway, perhaps may decrease performance by 10%. Choosing an inefficient algorithm may decrease performance by a factor of 10. Or more. And the compiler won't help you.
Greg B. schrieb: > I'm currently working in a C++ project and I'm excited to explore > methods for optimizing code efficiency. My aim is to confirm that my > code runs as efficiently as possible while maintaining readability and > ease of maintenance. So basically this is about performance optimization. On that, there are three famous quotes you should know: 1. "Premature optimization is the root of all evil." (Donald E. Knuth) 2. "Make it work, make it right, make it fast." (Kent Beck) 3. "Measure, don't guess." (Kirk Pepperdine) This said, what you're asking for is generally a bad idea, for what you're trying to accomplish is in fact premature optimization. But until you have at least something very similar to your final application, there is no way to predict its runtime characteristics (unless, maybe, you are a genius). In the end, you first need something that is "right" in the sense of Kent Beck's quote, that is it basically should correctly do what it's supposed to. Then and only then you have something that you can measure (or "profile") to answer questions, the first of which should be: Does your program meet its performance requirements? If it does, everything is fine and you're done. If not, then you can profile your program and gain insights about its runtime characteristics, such as: which function or method takes which amount of runtime, which data structure uses most of the memory, where does your program spend most of its runtime? Spending time on the optimization of programs that meet their requirements is a total waste of time. Then, you should be clear about the direction of your optimization. Often you can trade one thing such as memory comsumption against another thing such as cpu usage or runtime, that is: your program might require less memory but use more cpu cycles instead, or vice versa. You also might keep in mind how your program interacts with the underlying operating system and your hardware. For example, the dynamic allocation, reallocation and deallocation of memory (library functions malloc(3) and free(3), system calls brk(2) and mmap(2)) will each require two context switches. On modern operating systems context switches are an expensive operation, thus -- depending on your use case -- it might be more efficient to once allocate all of the needed memory size rather than allocating lots of small memory chunks. In other use case you might want to save memory, the allocation of smaller chunks might be more efficient. You might find that your program takes most of its time for disk or network I/O, which is common for programs that don't do a lot of complex calculations or programs that do calculations on big amounts of data. Unfortunately, most of the time there is not much you can do about that, because disks and networks are the slowest parts in your computer and improvements are hard to achieve without switching to other technologies, eg. replace your HDDs with SSDs or SSDs with NVMe devices, or pimp your network from 1 gigabit ethernet to, for example, 10 gigabit ethernet. Depending on your use case, such improvements might be expensive and thus maybe not profitable. (Don't stick to this point, it's just an example here). Then you might find that some methods or functions either take a lot of time because they are called very often or because their algoritm is not efficient. These functions or methods are the best and sometimes even the only candidates where you can significantly improve performance, and here you have the reason why it's so important to measure (or "profile") first. Different compilers, compiler settings and even compiler versions might use different strategies for their optimization. Non-trivial programs, that is: programs that do real work, you can never predict what the compiler and especially its optimizer will make out of you source code. So measure, don't guess. This said, what can you do in the early stages of development? Well, think about your program, especially about its algorithms and data structures. There are good reasons why the C++ Standard Template Library has (for example) multiple map containers, such as std::map and std::unordered_map. Both have different performance characteristics for different use cases, so learn about these characteristics and choose the container with the best fit for most of what your program uses. Every other approach you might try will have negative impacts on read- and maintainability, make it harder for the compiler to optimize your programs, and might even have a negative impact on the efficiency of your program. And even if you're lucky and do not face these negative consequences, you will spend your time on optimizing of code with minimal effects, which obviously isn't too efficient either. For example, most of the time there is no point in optimizing code that parses and validates your configuration files, as these things are usually only done on program startup. Performance optimization is a fine art that profits from experience, the more the better, and there are no standard recipes anyone can rely on. Sorry for that, I know that is not what you wanted. Instead, the most valuable tool for performance optimization is between your ears, so learn about the different data types and the algorithms you needs, then build your program so that it does what it's supposed to, then measure (profile) its characteristics at runtime, and then use your brains not only to first identify the places where optimization is efficient and second think about the inner workings of these places and what you can do to improve them. Good luck and have fun!
Neben netten Zitaten und Allgemeinplätzen zum Thema sollte man aber schon von einigen Stichworten gehört haben: - https://agner.org - Allignment - Register-Renaming - Registerabhängigkeiten - Sprungvorhersage - Effizienz, bzw. effiziente Algorithmen (https://de.wikipedia.org/wiki/Effizienz_(Informatik)) - Rundungsfehler - Worst Pessimum - Lernen durch Üben - Üben, Üben, Üben - Übung macht den Meister ..oder auch: - https://stackoverflow.blog/2020/07/08/improving-performance-with-simd-intrinsics-in-three-use-cases/ - https://www.boost.org - https://dlang.org ..und wird feststellen müssen, dass einiges nur deswegen an C++ bindet, weil C++ einigermaßen hardewarefreundlich wie auch stark erfahrungsabhängig oder auch verbreitet ist.
Rbx schrieb: > Neben netten Zitaten und Allgemeinplätzen zum Thema sollte man aber > schon von einigen Stichworten gehört haben: Despite the TO seemed to look for this sort of standard recipes (and, well... "Allgemeinplätzchen") you mention, exactly that was what I wanted to avoid. I've seen far too many developers who follow such recipes whenever possible, no matter if suitable. In the end their code gets hard to maintain and might even restrain the compiler's optimizer. Edit: missing space added.
:
Bearbeitet durch User
Ein T. schrieb: > exactly that was what I > wanted to avoid. Die Textmauer da oben muss ja auch irgendwie gefiltert werden, und in Referenz gesetzt werden, und so steht halt etwas konkreteres da drunter. Ein T. schrieb: > In the end their code > gets hard to maintain and might even restrain the compiler's optimizer. Ist auch klar, die Dummen sind natürlich immer die anderen. Was soll man von Leuten halten, die das Forum schon lange nutzen, aber trotzdem (immer noch) nicht in der Lage sind, auf die Schnelle brauchbares Bildmaterial auf eine Frage zu liefern?
Rbx schrieb: > Die Textmauer da oben muss ja auch irgendwie gefiltert werden, und in > Referenz gesetzt werden, I don't think so, and even if, ... > und so steht halt etwas konkreteres da drunter. ...you think contextless catchwords are "etwas konkretes"? > Ist auch klar, die Dummen sind natürlich immer die anderen. Was soll man > von Leuten halten, die das Forum schon lange nutzen, aber trotzdem > (immer noch) nicht in der Lage sind, auf die Schnelle brauchbares > Bildmaterial auf eine Frage zu liefern? Oh, I see, you don't want to help the TO, but just contradict me. Otherwise you would have used the TO's language. Thank you.
Ein T. schrieb: > Oh, I see, you don't want to help the TO, but just contradict me. > Otherwise you would have used the TO's language. Thank you. Wieso. Es wurde in ein deutschsprachiges Forum gepostet. Man stelle sich mal den umgekehrten Fall vor: Ich poste eine Frage bei https://stackoverflow.com auf Deutsch. Die Logik funktioniert generell in beide Richtungen. So gesehen bist du nicht gut in Logik wenn du aufgrund des Spracheinsatzes oder von relativen Beitragsergänzungen auf Hilfsverweigerung schließt.
Rbx schrieb: > Ein T. schrieb: >> Oh, I see, you don't want to help the TO, but just contradict me. >> Otherwise you would have used the TO's language. Thank you. > > Wieso. Es wurde in ein deutschsprachiges Forum gepostet. I see. You do not only piss me off, but also patronize the TO.
Rbx schrieb: > Wieso. Es wurde in ein deutschsprachiges Forum gepostet. Ich antworte hier auch immer in Deutsch. Wieso erwarten alle immer von uns, dass wir als Minimum Englisch antworten? Kann doch die Seite auf Englisch übersetzen. Davon ab, auch wenn ich es gut verstehe, ich bin über 40 Jahre aus der Schule und schreibe selten bis nie Englisch. Soll froh sein, dass er überhaupt eine Antwort bekommt.
Frank O. schrieb: > Ich antworte hier auch immer in Deutsch. Du tust gerade so, als gebe es einen Zwang, hier zu antworten. Aber wer kein Englisch kann, zu eingerostet oder zu faul dazu ist, muß das gar nicht. > Wieso erwarten alle immer von > uns, dass wir als Minimum Englisch antworten? In einem Forum, das sich mit Mikrocontrollern und Technik beschäftigt? Davon abgesehen zeigt sich daran natürlich recht eindeutig, wer anderen helfen will und wer nur zum Stänkern hier ist.
Ein T. schrieb: > In einem Forum, das sich mit Mikrocontrollern und Technik beschäftigt? > Davon abgesehen zeigt sich daran natürlich recht eindeutig, wer anderen > helfen will und wer nur zum Stänkern hier ist. Sprich in England oder in Amerika deutsch. Sprechen die dann automatisch deutsch mit dir? Und, natürlich kann man auch was zum Thema schreiben. Wenn jemand Hilfe annehmen will, dann wird er doch wohl in der Lage sein den Text zu übersetzen.
:
Bearbeitet durch User
Frank O. schrieb: > Sprich in England oder in Amerika deutsch. Sprechen die dann automatisch > deutsch mit dir? Spreche bei mir um die Ecke (in Deutschland) in einem beliebigen Laden Arabisch. Antworten die dann auf Arabisch? Ja!
> Specifically, I'm interested in learning about techniques > for boosting runtime performance and minimizing memory usage This is not specific to any programming language, so there is no specific recommendation other than studying mathematics, particularly numerical analysis. See also: Niklaus Wirth: "Algorithmen und Datenstrukturen" (ISBN: ISBN-13 978-3519022503) And also remember Amdahl's law .
:
Bearbeitet durch User
Beitrag #7668563 wurde von einem Moderator gelöscht.
Ein T. schrieb: > In einem Forum, das sich mit Mikrocontrollern und Technik beschäftigt? Da es vom Forenbetreiber auch ein englischsprachiges Forum gibt, und die Haussprache hier halt eben nicht englisch ist, gehört es sich nicht, hier ausschweifende Diskussionen auf Englisch zu führen. Es mag den einen oder anderen überraschen, aber in diesem Forum sind auch Leute unterwegs, die Ahnung von Dingen haben und trotzdem keine oder nur sehr schlechte Englischkenntnisse haben. (Zwischen Englischkenntnissen und Fachkompetenz besteht keine Korrelation) Letztlich geht es um Umgangsformen. Genausowenig, wie man in deutschsprachigen Internetforen plenkt, genausowenig sollte man dort ohne Not mit einer Fremdsprache ankommen. Hier Deutsch zu schreiben ist eine Bringschuld, bei der die Verwendung von Onlineübersetzern seitens der nicht des Deutschen mächtigen durchaus erwartet werden kann. Deepl.com und seit einiger Zeit auch translate.google.com liefern brauchbare Ergebnisse. -- For those inept to communicate in german: please use an online translation service such as deepl.com or translate.google.com. This forum is a german-speaking forum, and posting in other languages is considered somewhat rude if not offensive. And not everyone here who's on a helpful mission is abled to answer in decent and sufficient non-ambiguous english.
> Letztlich geht es um Umgangsformen. Genausowenig, wie man in > deutschsprachigen Internetforen plenkt, genausowenig sollte man dort > ohne Not mit einer Fremdsprache ankommen. Love it or leave it or just ignore it ...
Bradward B. schrieb: > Love it or leave it or just ignore it ... Nee, Jüngelchen, so funktioniert das hier nicht. Und warum empfiehlst Du jemandem auf Englisch ein deutschsprachiges Buch? Das ist auch ein bisschen widersprüchlich, meinst Du nicht auch?
Frank O. schrieb: > Sprich in England oder in Amerika deutsch. Sprechen die dann automatisch > deutsch mit dir? Naja, in Pennsylvania versuchen einige Natives es immerhin. Auch an Unis kann man schonmal auf Leute treffen, die keine gebürtigen Deutschen sind, aber trotzdem recht gut Deutsch sprechen (und das auch wollen). Aber klar: Selbst bei meinem (leider recht lausigen) Englisch wird das Mittel der Wahl i.d.R. Englisch sein. Ausnahme ist natürlich, wenn man auf einen Deutschen trifft, der aus dem einen oder anderen Grund im englischsprachigen Ausland werkelt. Aber selbst dann ist es fast immer so, dass man zugunsten der anderen am Gespräch beteiligten nach ein, zwei freundlichen Sätzen wieder auf Englisch umschaltet.
Harald K. schrieb: > For those inept to communicate in german: please use an online > translation service such as deepl.com or translate.google.com. This > forum is a german-speaking forum, and posting in other languages is > considered somewhat rude if not offensive. ...and obviously there are a lot of childish people around here.
Bradward B. schrieb: > Love it or leave it or just ignore it ... True that. And then, if i remember correctly, there was a time when the postings from embdev.net have also been posted here. In English, oh my god.
Ein T. schrieb: > True that. And then, if i remember correctly, there was a time when the > postings from embdev.net have also been posted here. In English, oh my > god. Tja, seitdem viele erkannt haben, dass dieses Feature von einigen (genaue interne Bezeichnung zensiert) Deutschen missbräuchlich genutzt wurde, hat sich das zum Glück weitgehend erledigt. Aber irgendein grenzdebiler Honk probiert's halt immer mal wieder, damit durchzukommen...
Ein T. schrieb im Beitrag #7668563: > Some words are the same in both languages. Idiot and Kindergarten for > exampl Kindergarten wusste ich nicht. Aber ich kann dir gerne zeigen was rechts und links heißt. Sag mal wo du wohnst!
Ob S. schrieb: > Naja, in Pennsylvania versuchen einige Natives es immerhin. Was ich damit sagen wollte, dass bei uns erwartet wird, dass wir selbstverständlich in der Sprache des anderen oder alternativ immer Englisch sprechen, wenn wir mit Fremden zu tun haben. Leider erwarten wir, was auch nicht richtig ist und ich unbedingt für mich ändern muss, dass die Holländer immer deutsch mit uns sprechen. Ich verstehe die recht gut, aber sprechen, na ja. Wie hier schon geschrieben wurde, es gibt auch das µC.net in Englisch. Heute hatte ich noch mit China zu tun. Selbstverständlich schreibe ich dann auch in Englisch. Aber hier ist nun mal ein deutsches Forum. Die einzige Ausnahme, der TT-Thread, da kann man schon mal in Englisch schreiben, weil der wohl ziemlich international ist. Eigentlich könnte man den Startbeitrag schon als Affront ansehen. Schreib doch mal in einem Englischen Forum einen Beitrag in Deutsch und erwarte, dass dir alle in Deutsch antworten. Aber was ist so schlimm daran, wenn man in Deutsch antwortet? Hauptsache ist doch, dass geholfen wird.
:
Bearbeitet durch User
> Aber hier ist nun mal ein deutsches Forum. Nope, die Reichweite erstreckt sich mindestens auf D-A-CH und spätestens bei CH sind etliche dabei, für die Hochdeutsch eine ausgemachte Fremdsprache ist. > Eigentlich könnte man den Startbeitrag schon als Affront ansehen. Was man als Affront ansieht und was nicht ist doch eine sehr individuelle Einschätzung, die auch stark von den persönlichen Fähigkeiten abhängig ist. So wird ein Einbeiniger auf die Auforderung zum gemeinsamen Lauf eher vergnatzt reagieren. Oder der Abstinzler die Aufforderung zum Gehaltvollen Umtrunk. Andere sehen Anfragen als Affront an, die der TO mit minimalen google-Aufwand selbst lösen könnte ... BTW: Ist jetzt die Verwendung von Funk-Kürzeln wie Q-Gruppen etc. ein Affront für die "Unwissenden" ?? 73 Конец передачи
Bradward B. schrieb: > ist doch eine sehr > individuelle Einschätzung, die auch stark von den persönlichen > Fähigkeiten abhängig ist. Da hast du recht. Wie auch immer. Ich beende, zumindest für mich, die Diskussion darüber.
Frank O. schrieb: > Ein T. schrieb im Beitrag #7668563: >> Some words are the same in both languages. Idiot and Kindergarten for >> exampl > > Kindergarten wusste ich nicht. > Aber ich kann dir gerne zeigen was rechts und links heißt. > Sag mal wo du wohnst! LOL!
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.