LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Non-*NIX Forums > Programming
User Name
Password
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


Reply
  Search this Thread
Old 06-26-2026, 10:12 AM   #76
teckk
LQ Guru
 
Registered: Oct 2004
Distribution: Arch
Posts: 5,818

Original Poster
Blog Entries: 7

Rep: Reputation: 2189Reputation: 2189Reputation: 2189Reputation: 2189Reputation: 2189Reputation: 2189Reputation: 2189Reputation: 2189Reputation: 2189Reputation: 2189Reputation: 2189

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;
}
 
Old 06-26-2026, 10:24 AM   #77
EdGr
Senior Member
 
Registered: Dec 2010
Location: California, USA
Distribution: I run my own OS
Posts: 1,134

Rep: Reputation: 533Reputation: 533Reputation: 533Reputation: 533Reputation: 533Reputation: 533
I searched my code. new[] outnumbers new by 20x.
Ed
 
Old 06-26-2026, 11:47 AM   #78
teckk
LQ Guru
 
Registered: Oct 2004
Distribution: Arch
Posts: 5,818

Original Poster
Blog Entries: 7

Rep: Reputation: 2189Reputation: 2189Reputation: 2189Reputation: 2189Reputation: 2189Reputation: 2189Reputation: 2189Reputation: 2189Reputation: 2189Reputation: 2189Reputation: 2189
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.
 
Old 06-26-2026, 11:51 AM   #79
rclark
Member
 
Registered: Jul 2008
Location: Montana USA
Distribution: KUbuntu, Fedora (KDE), PI OS
Posts: 843

Rep: Reputation: 323Reputation: 323Reputation: 323Reputation: 323
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.
Old 06-26-2026, 12:59 PM   #80
pan64
LQ Addict
 
Registered: Mar 2012
Location: Hungary
Distribution: debian/ubuntu/suse ...
Posts: 26,460

Rep: Reputation: 8608Reputation: 8608Reputation: 8608Reputation: 8608Reputation: 8608Reputation: 8608Reputation: 8608Reputation: 8608Reputation: 8608Reputation: 8608Reputation: 8608
Quote:
Originally Posted by jtsn View Post
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 View Post
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 View Post
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?)
 
Old 06-27-2026, 07:52 AM   #81
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 11,741
Blog Entries: 4

Rep: Reputation: 4301Reputation: 4301Reputation: 4301Reputation: 4301Reputation: 4301Reputation: 4301Reputation: 4301Reputation: 4301Reputation: 4301Reputation: 4301Reputation: 4301
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.
 
Old 06-27-2026, 09:33 AM   #82
wainamoinen
Member
 
Registered: Sep 2009
Location: Belgium
Distribution: Slackware
Posts: 52

Rep: Reputation: 43
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.
 
Old 06-28-2026, 09:14 AM   #83
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 11,741
Blog Entries: 4

Rep: Reputation: 4301Reputation: 4301Reputation: 4301Reputation: 4301Reputation: 4301Reputation: 4301Reputation: 4301Reputation: 4301Reputation: 4301Reputation: 4301Reputation: 4301
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.
 
Old 06-28-2026, 10:27 AM   #84
pan64
LQ Addict
 
Registered: Mar 2012
Location: Hungary
Distribution: debian/ubuntu/suse ...
Posts: 26,460

Rep: Reputation: 8608Reputation: 8608Reputation: 8608Reputation: 8608Reputation: 8608Reputation: 8608Reputation: 8608Reputation: 8608Reputation: 8608Reputation: 8608Reputation: 8608
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 View Post

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 View Post
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 View Post
"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.
 
Old 06-28-2026, 10:58 AM   #85
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 11,741
Blog Entries: 4

Rep: Reputation: 4301Reputation: 4301Reputation: 4301Reputation: 4301Reputation: 4301Reputation: 4301Reputation: 4301Reputation: 4301Reputation: 4301Reputation: 4301Reputation: 4301
@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.
 
Old 07-19-2026, 10:08 AM   #86
EdGr
Senior Member
 
Registered: Dec 2010
Location: California, USA
Distribution: I run my own OS
Posts: 1,134

Rep: Reputation: 533Reputation: 533Reputation: 533Reputation: 533Reputation: 533Reputation: 533
I replaced enum with enum class. C++ is getting better.
Ed
 
Old Yesterday, 03:24 AM   #87
jtsn
Senior Member
 
Registered: Sep 2011
Posts: 1,671

Rep: Reputation: 798Reputation: 798Reputation: 798Reputation: 798Reputation: 798Reputation: 798Reputation: 798
Quote:
Originally Posted by sundialsvcs View Post
@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.
 
Old Yesterday, 03:52 AM   #88
pan64
LQ Addict
 
Registered: Mar 2012
Location: Hungary
Distribution: debian/ubuntu/suse ...
Posts: 26,460

Rep: Reputation: 8608Reputation: 8608Reputation: 8608Reputation: 8608Reputation: 8608Reputation: 8608Reputation: 8608Reputation: 8608Reputation: 8608Reputation: 8608Reputation: 8608
Quote:
Originally Posted by jtsn View Post
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 View Post
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.
 
Old Yesterday, 02:24 PM   #89
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 11,741
Blog Entries: 4

Rep: Reputation: 4301Reputation: 4301Reputation: 4301Reputation: 4301Reputation: 4301Reputation: 4301Reputation: 4301Reputation: 4301Reputation: 4301Reputation: 4301Reputation: 4301
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.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Find with -mtime is finding EVERYTHING since, not everything older than NobleOne Linux - Newbie 6 08-16-2017 07:50 AM
[SOLVED] updated drivers, everything gone wrong, please help. insanity99 Ubuntu 16 06-10-2010 06:15 AM
LXer: Everything You Know About CSS is Wrong! LXer Syndicated Linux News 0 12-12-2008 02:30 AM
I own everything! (did 'chown -R' in the wrong place) oskar Linux - Newbie 9 03-19-2006 05:38 PM
What's wrong with MTV? EVERYTHING... Mega Man X General 141 09-29-2004 05:28 PM

LinuxQuestions.org > Forums > Non-*NIX Forums > Programming

All times are GMT -5. The time now is 05:43 PM.

Contact Us - Advertising Info - Rules - Privacy - Donations - Contributing Member - LQ Sitemap - "Weather apps tell you it'll rain. Wyndo tells you when to go."
Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions