ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
...
You didn't tell me how to obtain the necessary files, preferably in Arch package format. If using a different distro would be much more practical, then maybe I'll be willing to do an Arch/(Some other more ASM programming freindly distro) dual boot.
First of all, every normal package format allows extraction of separate files from a package, so obtaining the necessary files is a matter of locating the package containing them and learning how to extract the files.
Secondly, you need to learn how to control the linker - as I said before.
The items to pay attention to are output format and the way/places library directory are looked for. You might pleasantly surprised just by patiently reading
Code:
ld --help | less
- there are a few relevant pieces in the output of the above command.
Click here to see the post LQ members have rated as the most helpful post in this thread.
I have been enjoying the informative part of this question and definitely value the input from all of, from
what I can tell, experienced C/C++ advocates here
May I ask that the conversation is kept on point, ie discussing the relevant differences / preferences between C & C++
I believe (and I may be wrong as I am definitely NOT at the same level as most replying) the current course of discussion
on asm and ld, whilst I understand are / can be used in conjunction with C/C++, is not really on topic. Maybe this
new discussion should be in its own thread?
If I am wrong about its relevance, I apologise
But please continue the discussion on this topic, because as I said above, it is very informative
I believe (and I may be wrong as I am definitely NOT at the same level as most replying) the current course of discussion
on asm and ld, whilst I understand are / can be used in conjunction with C/C++, is not really on topic.
I agree. It's just that MTK358 and Sergei have a bit of a problem with each other, and neither of them can seem to ignore the other...
Maybe this
new discussion should be in its own thread?
I'm sorry about my part in hijacking your thread for the mixed ASM with C discussion, and I'll stop replying to that topic in this thread. I have what I think are constructive replies to that side track topic, but I'll need to wait until that discussion goes back to its own threads (it has at least one thread of its own already). Hopefully the other parties to the hijack will also take it out of this thread.
Meanwhile on the original topic, I also have some strong opinions on why C++ is better than any preprocessor you might invent to translate some other OO superset of C back into C. Also on the benefits of several other features of C++ that have been maligned in some of the posts above.
But I don't really think it is likely any of that will convince anyone. It is another of the many topics on which the typical participants in the discussion had immutable opinions before the discussion started.
...
I also have some strong opinions on why C++ is better than any preprocessor you might invent to translate some other OO superset of C back into C. Also on the benefits of several other features of C++ that have been maligned in some of the posts above.
...
So, what are the benefits ? But if answering, please take into account that:
CPP is a preprocessor by its name/definition;
C++ template engine is a preprocessor whose output can't be easily seen (unlike the one of CPP).
Furthermore, C++ template engine a functional (opposed to proceudral) language/engine, while C++ is not. CPP is a procedural language too. So, there is no consistency in C++ as a whole WRT programming paradigms.
No matter what I tried I could not get 32-bit ASM code to work on my 64-bit desktop.
Would you be so kind as to open a new thread? I'll try an example when I get to one of my 64-bit PCs later and let you know what I find.
PS:
Johnsfine - no: I haven't tried it on arch. I have zero first-hand experience with ArchLinux, and whether or not they support parallel 32- and 64-bit development and runtime environments like, say, SuSE or Ubuntu do.
First a comment on the defective communication from the compiler to the debugger when significant (especially templated) code is inlined:
That defect is not an inherent flaw in the C++ language itself. It is a practical flaw in C++ because it seems to be a flaw in every common implementation of C++. But it is a flaw that could be fixed with no change in the language definition.
I was especially surprised at the earlier comment contrasting that specific C++ flaw with the hypothetical benefits of a hypothetical preprocessor for a hypothetical OO superset of C. It's hard to present any concrete argument against such a hypothetical, but in general the quality of info the compiler can pass to the debugger is even worse in that kind of preprocessor design than it is in current C++.
Expressive languages tend to violate the clean hierarchical design that makes things easier for a compiler writer. That's OK, because the language design should focus on benefits for the programmer, not for the compiler writer. A true "preprocessor" design depends on cleaner boundaries between lexical and syntactic features and even more so between syntactic and semantic features. So a "preprocessor" for a language as powerful as C++ cannot be a preprocessor. It must be a full scale translator, translating from the source language to the target language. At that level, there is little advantage left to choosing C rather than machine language as the target language for your translator.
Quote:
Furthermore, C++ template engine a functional (opposed to proceudral) language/engine, while C++ is not. CPP is a procedural language too. So, there is no consistency in C++ as a whole WRT programming paradigms.
Above ASM there is no consistent procedural language. Useful high level languages are necessarily inconsistent across the functional/procedural boundary. Lisp is a nearly pure functional language, but still is partly procedural. C and C++ are nearer the most convenient midpoint of that spectrum. The consistency I think you're talking about would be counter productive.
In less abstract terms, the templating of C++ is an incredibly powerful feature. In complex projects it lets you accomplish things that just aren't practical in other languages. A lot of the specific rules of C++ templating have odd consequences that seem to have led the standards committee to layer on stupider rules to cover the flaws of earlier rules that were accepted before their consequences were thought through. So some hypothetical language much better than C++ would be possible. But so far as I know, that language doesn't exist and the software industry would have too much inertia to switch to it even if it did exist.
Meanwhile, I think a well chosen subset of C++ would be a better language than any other generally available for beginning to moderately skilled programmers to write easy programs. Then a much wider subset of C++ fills the role of the expert programming language for which there really is no plausible alternative.
First a comment on the defective communication from the compiler to the debugger when significant (especially templated) code is inlined:
That defect is not an inherent flaw in the C++ language itself. It is a practical flaw in C++ because it seems to be a flaw in every common implementation of C++. But it is a flaw that could be fixed with no change in the language definition.
I was especially surprised at the earlier comment contrasting that specific C++ flaw with the hypothetical benefits of a hypothetical preprocessor for a hypothetical OO superset of C. It's hard to present any concrete argument against such a hypothetical, but in general the quality of info the compiler can pass to the debugger is even worse in that kind of preprocessor design than it is in current C++.
Expressive languages tend to violate the clean hierarchical design that makes things easier for a compiler writer. That's OK, because the language design should focus on benefits for the programmer, not for the compiler writer. A true "preprocessor" design depends on cleaner boundaries between lexical and syntactic features and even more so between syntactic and semantic features. So a "preprocessor" for a language as powerful as C++ cannot be a preprocessor. It must be a full scale translator, translating from the source language to the target language. At that level, there is little advantage left to choosing C rather than machine language as the target language for your translator.
Above ASM there is no consistent procedural language. Useful high level languages are necessarily inconsistent across the functional/procedural boundary. Lisp is a nearly pure functional language, but still is partly procedural. C and C++ are nearer the most convenient midpoint of that spectrum. The consistency I think you're talking about would be counter productive.
In less abstract terms, the templating of C++ is an incredibly powerful feature. In complex projects it lets you accomplish things that just aren't practical in other languages. A lot of the specific rules of C++ templating have odd consequences that seem to have led the standards committee to layer on stupider rules to cover the flaws of earlier rules that were accepted before their consequences were thought through. So some hypothetical language much better than C++ would be possible. But so far as I know, that language doesn't exist and the software industry would have too much inertia to switch to it even if it did exist.
Meanwhile, I think a well chosen subset of C++ would be a better language than any other generally available for beginning to moderately skilled programmers to write easy programs. Then a much wider subset of C++ fills the role of the expert programming language for which there really is no plausible alternative.
So, what is wrong if I choose a completely different template engine which generated a template-less C++ with clear indications (at lest in the form of comments) to the original source ?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
s.
