Programming This 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.
Are you new to LinuxQuestions.org? Visit the following links:
Site Howto |
Site FAQ |
Sitemap |
Register Now
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.
|
 |
|
06-26-2026, 10:12 AM
|
#76
|
|
LQ Guru
Registered: Oct 2004
Distribution: Arch
Posts: 5,818
Original Poster
|
new example for those "new" to cpp.
new.cpp
Code:
//g++ new.cpp -o new
#include <iostream>
#include <string>
using namespace std;
int main()
{
int *ptr = NULL;
ptr = new int();
int *var = new int(12);
if(!ptr) {
cout << "Bad memory allocation" << endl;
}else{
cout << "Memory allocated successfully" << endl;
*ptr = 10;
cout << "*ptr = " << *ptr << endl;
cout << "*var = " << *var << endl;
}
double *myarray = NULL;
myarray = new double[10];
if(!myarray) {
cout << "Memory not allocated" << endl;
}else{
for(int i=0;i<10;i++)
myarray[i] = i+1;
cout << "myarray values : ";
for(int i=0;i<10;i++)
cout << myarray[i] << "\t";
}
delete ptr;
delete var;
delete[] myarray;
cout << endl;
return 0;
}
|
|
|
|
06-26-2026, 10:24 AM
|
#77
|
|
Senior Member
Registered: Dec 2010
Location: California, USA
Distribution: I run my own OS
Posts: 1,134
|
I searched my code. new[] outnumbers new by 20x.
Ed
|
|
|
|
06-26-2026, 11:47 AM
|
#78
|
|
LQ Guru
Registered: Oct 2004
Distribution: Arch
Posts: 5,818
Original Poster
|
I use that sometimes with some larger installed base software, where I want to change a default, where something is already defined in a class that gets called with <include>
(I've had interest in web browsers for a couple of years) A Qt6Webengine example:
Code:
#include <QWebEnginePage>
#include <QWebEngineProfile>
#include <QWebEngineUrlRequestInterceptor>
#include <QWebEngineView>
QApplication app(argc, argv);
QWebEngineProfile *profile = new QWebEngineProfile();
profile->setHttpUserAgent(Agent);
QWebEngineUrlRequestInterceptor *interceptor = new UrlRequestInterceptor();
profile->setUrlRequestInterceptor(interceptor);
QWebEngineView *view = new QWebEngineView();
view->setAttribute(Qt::WA_DeleteOnClose);
QWebEnginePage *page = new QWebEnginePage(profile, view);
view->setPage(page);
view->show();
A few lines on code, and got my changes into the base software.
|
|
|
|
06-26-2026, 11:51 AM
|
#79
|
|
Member
Registered: Jul 2008
Location: Montana USA
Distribution: KUbuntu, Fedora (KDE), PI OS
Posts: 843
|
Gotta line up those brackets correctly to be fully readable. Leaned that years ago after my company experimented with different styles...
Code:
int main()
{
int *ptr = NULL;
ptr = new int();
int *var = new int(12);
if (!ptr)
{
cout << "Bad memory allocation" << endl;
}
else
{
cout << "Memory allocated successfully" << endl;
*ptr = 10;
cout << "*ptr = " << *ptr << endl;
cout << "*var = " << *var << endl;
}
double *myarray = NULL;
myarray = new double[10];
if (!myarray)
{
cout << "Memory not allocated" << endl;
}
else
{
for (int i=0;i<10;i++)
myarray[i] = i+1;
cout << "myarray values : ";
for (int i=0;i<10;i++)
cout << myarray[i] << "\t";
}
delete ptr;
delete var;
delete[] myarray;
cout << endl;
return 0;
}
|
|
|
1 members found this post helpful.
|
06-26-2026, 12:59 PM
|
#80
|
|
LQ Addict
Registered: Mar 2012
Location: Hungary
Distribution: debian/ubuntu/suse ...
Posts: 26,460
|
Quote:
Originally Posted by jtsn
C++ started das Cfront, a frontend for C compilers.
|
Yes, it had to start somehow. That doesn't mean it was the good solution, it was only the initial step. And actually it was also abandoned because the translator was not able to support all the c++ language elements.
Quote:
Originally Posted by jtsn
The new statement thought out in the ivory tower was turned into a call of malloc() and delete into a call of free(). That's the reality and it is still sitting inside millions of LoC of legacy C++ software in real world production.
|
And in fact, all memory allocations in every language will somehow be redirected to malloc, because this is the low-level implementation for allocating memory.
Quote:
Originally Posted by jtsn
Malloc()ing single objects off the heap was always the worst design pattern for any real-world hardware back then and now. And yet it became part of the C++ programming language (!) (not even standard library, the language itself) and every single C++ textbook.
|
Improper use would obviously be ineffective, but again, this is a matter of design rather than language (or compiler?)
|
|
|
|
06-27-2026, 07:52 AM
|
#81
|
|
LQ Guru
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 11,741
|
The beauty of the "GNU compiler suite" is how many different languages it now supports from what is basically the same "back-end."
But, "C++" is definitely the one language that has been under "continuous evolution" for the longest time.
|
|
|
|
06-27-2026, 09:33 AM
|
#82
|
|
Member
Registered: Sep 2009
Location: Belgium
Distribution: Slackware
Posts: 52
Rep:
|
Talking aboug GNU compiler suite. It's peculiar/funny  that the C++ code in the GNU compiler suite tries not to use all C++ features, like: RTTI, exceptions, iostream, multiple inheritance. Take a look at the C++ coding conventions for GCC:
https://gcc.gnu.org/codingconvention...xx_Conventions
Templates: To avoid excessive compiler size, consider implementing non-trivial templates on a non-template base class with void* parameters.
RTTI and dynamic_cast: ...However, by default, RTTI is not permitted and the compiler must build cleanly with -fno-rtti.
Exceptions: Exceptions and throw specifications are not permitted and the compiler must build cleanly with -fno-exceptions.
The Standard Library: ...For long-term code, at least for now, we will continue to use printf style I/O rather than <iostream> style I/O.
Class Definitions: ...Single inheritance is permitted. ... Complex hierarchies are to be avoided. Take special care with multiple inheritance...
Default Arguments: ...Default arguments must always be POD values, i.e. may not run constructors. Virtual functions should not have default arguments.
|
|
|
|
06-28-2026, 09:14 AM
|
#83
|
|
LQ Guru
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 11,741
|
Interesting observations.
I, too, have always avoided "multiple inheritance" in my designs. The simple principle is that, whenever I look at some block of source-code that I suspect has a bug in it, I want to immediately know what this block is actually doing. Furthermore, I need to know if the bug is "here," or "somewhere else."
When and if the bug is "somewhere else," now my trouble-sleuthing exercise has just expanded: "where else might this bug appear?" Are there are other areas of the program which are, in fact, "buggy," but where the bug has not yet externally manifested itself?
"Multiple inheritance" makes it considerably more difficult to know, with certainty, exactly what a particular block of code is actually doing. It also greatly expands the areas where I have to look. It also binds together all of the areas of the program which use this inheritance structure. So, it is a design principle that I studiously avoid using. The "benefits," to me, are just not worth the price.
|
|
|
|
06-28-2026, 10:27 AM
|
#84
|
|
LQ Addict
Registered: Mar 2012
Location: Hungary
Distribution: debian/ubuntu/suse ...
Posts: 26,460
|
Interesting, yes, for example RTTI (runtime type information) was already implemented and used in the previous century, without the compiler (This means that the class(es)/structs had their own type information that could be checked in real time during execution). This was mainly necessary due to incorrect use of pointers and inadequate (?) static code checkers. But not because of inheritance. (this was implemented in our project).
Quote:
Originally Posted by sundialsvcs
I, too, have always avoided "multiple inheritance" in my designs. The simple principle is that, whenever I look at some block of source-code that I suspect has a bug in it, I want to immediately know what this block is actually doing. Furthermore, I need to know if the bug is "here," or "somewhere else."
|
I think that if we have a task (a program that needs to be implemented), the question is not whether we want multiple inheritance or not, but how we want to implement it in the first place. Using C, C++, or whatever language(s)
Quote:
Originally Posted by sundialsvcs
When and if the bug is "somewhere else," now my trouble-sleuthing exercise has just expanded: "where else might this bug appear?" Are there are other areas of the program which are, in fact, "buggy," but where the bug has not yet externally manifested itself?
|
Finally, regardless of the language, you have to implement everything, so the error is always in the code. Not surprisingly. The difference is that in C++ the code is much more structured, organized (it can be), so it is easier to find the error. But again, this is more a matter of design, not inheritance.
Quote:
Originally Posted by sundialsvcs
"Multiple inheritance" makes it considerably more difficult to know, with certainty, exactly what a particular block of code is actually doing. It also greatly expands the areas where I have to look. It also binds together all of the areas of the program which use this inheritance structure. So, it is a design principle that I studiously avoid using. The "benefits," to me, are just not worth the price.
|
Multiple inheritance means more reusable code. Obviously it is much more difficult to find the bug if you don't know where is it coming from. Does that mean you'd rather duplicate it, just to be sure it works? (that won't work any better).
Ultimately, the complexity is determined by the task at hand, and you can increase it further as you wish during the design phase. The classes and hierarchy should be designed accordingly.
|
|
|
|
06-28-2026, 10:58 AM
|
#85
|
|
LQ Guru
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 11,741
|
@pan64: No, my point was simply that "more-complicated inheritance schemes" make it more difficult to locate the problem. You start by isolating a particular piece of "problem code," but now you have to understand what is actually happening when that code executes. I have to understand what the compiler and/or the runtime system actually did.
In my own software designs, I avoid multiple inheritance. However, as a consultant, I regularly have to wade into (now-troubled ...) projects that very often did. I am therefore looking at unfamiliar code, created by somebody else. This is not a pleasant experience.
Part of the problem, of course, is that "software evolves." The original design might have been squeaky-clean, but when you have a bug to fix, you fix the bug. Over time, that adds up.
And of course, it has nothing whatsoever to do with the language.
Last edited by sundialsvcs; 06-28-2026 at 10:59 AM.
|
|
|
|
07-19-2026, 10:08 AM
|
#86
|
|
Senior Member
Registered: Dec 2010
Location: California, USA
Distribution: I run my own OS
Posts: 1,134
|
I replaced enum with enum class. C++ is getting better.
Ed
|
|
|
|
Yesterday, 03:24 AM
|
#87
|
|
Senior Member
Registered: Sep 2011
Posts: 1,671
|
Quote:
Originally Posted by sundialsvcs
@pan64: No, my point was simply that "more-complicated inheritance schemes" make it more difficult to locate the problem. You start by isolating a particular piece of "problem code," but now you have to understand what is actually happening when that code executes. I have to understand what the compiler and/or the runtime system actually did.
|
Back in the 1980s you ran the C++ code through Cfront, then you had the C code with mangled identifiers describing to the backend C compiler what was actually supposed to happen.
Nowadays you are looking at disassembled machine code. Hopefully with enough symbols to help debugging.
|
|
|
|
Yesterday, 03:52 AM
|
#88
|
|
LQ Addict
Registered: Mar 2012
Location: Hungary
Distribution: debian/ubuntu/suse ...
Posts: 26,460
|
Quote:
Originally Posted by jtsn
Back in the 1980s you ran the C++ code through Cfront, then you had the C code with mangled identifiers describing to the backend C compiler what was actually supposed to happen.
|
That was really long time ago. But I don't think we tried to understand the generated c code and tried to use that for troubleshooting. Otherwise this translator was not perfect, but that is another story.
Quote:
Originally Posted by jtsn
Nowadays you are looking at disassembled machine code. Hopefully with enough symbols to help debugging.
|
And I never tried to do anything with disassembled machine code (of compiled C++). If C++ code was available. There are much better/faster/more efficient ways to troubleshoot.
|
|
|
|
Yesterday, 02:24 PM
|
#89
|
|
LQ Guru
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 11,741
|
Fortunately for all of us, products like the gcc: GNU compiler suite discovered nice things like "grammars." They built a system with multiple "front ends," covering a diversity of source languages, and a fairly common "back end" that actually spits out the code. And, the entire "downstream food-chain" matured to handle it.
So, when you write "C++" versus "C" code these days, it is in many ways just "another way of saying it." You're talking to the same code generator.
Microsoft took an analogous approach to enable them to support Visual Basic and "C#" ... two completely-different languages if ever there was one ... on the same back-end architecture. It was "quite a cool hack." 
Last edited by sundialsvcs; Yesterday at 02:27 PM.
|
|
|
|
All times are GMT -5. The time now is 05:43 PM.
|
|
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
|
Latest Threads
LQ News
|
|