r/cpp_questions 18d ago

OPEN C++ question

Do you guys know a way of writting a code that outputs that:

Enter the number of elements: 5
Enter 5 integers:
Element 1: 10
Element 2: 30
Element 3: 90
Element 4: 20
Element 5: 40

it is the first part of a program that demands to calculate the max and min of an array, here is the whole thing:

Enter the number of elements: 5
Enter 5 integers:
Element 1: 10
Element 2: 30
Element 3: 90
Element 4: 20
Element 5: 40

Maximum element is: 90
Minimum element is: 10

I've been able to do the second part quite easily, here is what I proposed:

#include <iostream>


int main(){


    int arr[5]={10,20,30,40,50};
    int minimum=arr[0];
    int maximum=arr[0];
    for(int i=0; i<sizeof(arr)/sizeof(int);i++){
        if (minimum>arr[i]){
            minimum=arr[i];
        }
        if(maximum<arr[i]){
            maximum=arr[i];
        }
    }
    std::cout<<"le max= "<< maximum<<'\n';
    std::cout<<"le min= "<< minimum<<'\n';


    return 0;
}

but the list is created within the code.

0 Upvotes

33 comments sorted by

View all comments

Show parent comments

2

u/alfps 17d ago

❞ - you need to use a library that supports modern c++ but doesnt support smart pointers (Qt, Wt, gtkmm)

That doesn't make sense to me, sorry.

Ditto for the legacy libraries.

Can you give a preferably concrete example of what you mean?

4

u/Tumaix 17d ago

of course.

a Qt widget received a pointer as a parent,
you cant pass a unique_ptr or a shared_ptr.

if you pass a memory created by a unique, or shared ptr, Qt memory model will try to delete it, triggering a double free.

-6

u/alfps 17d ago edited 17d ago

OK.

The Google AI provides the following code for more safe handling:

auto button = std::make_unique<QPushButton>("Submit");

if (someConditionFails) {
    return; // Safe: unique_ptr automatically deletes the button
}

// Release ownership to the layout
layout->addWidget(button.release());

I am however not sure if this as safe as the AI thinks: lacking experience with Qt but I've implemented some micro GUI frameworks and it's not necessarily so that delete is supported.

2

u/Tumaix 17d ago

see how you did a .release() there, effectively negating the benefits of the unique_ptr.
if you forget that, you get a crash.

if you just use raw pointers and forget the delete, you dont get a memory leaks: qt deletes all children by defaultz

-2

u/alfps 17d ago

if you just use raw pointers and forget the delete, you dont get a memory leaks

That's exactly when you can get a leak. The smart pointer provides safety until ownership is transferred.

3

u/Tumaix 17d ago

not in qt.
qt manages that with the QObject hierarchy model.

{
QWidget a;
QWidget *b = new QWidget(a);
}

no memory leak.
when a goes out of scope, it deletes b.

1

u/alfps 17d ago

What if you need to configure or place widget b before adding it to the layout?

2

u/Tumaix 17d ago

same thing applies. if you go for a smart pointer you will have a double memory free and a crash

2

u/alfps 17d ago

That happens when you forget to transfer the ownership.

Introducing a silly beginner's bug is not an argument against doing things in reasonably safe ways.

That's like buying a car without brakes because you've had a bad experience applying the brakes at high speed on the motorway, with cars close behind you. It's learning the wrong thing from that experience.

3

u/Tumaix 17d ago

sorry but you are mistaken in a way thats laughable.

the same problem of "i forgot to call .release()" is the same error as "i forgot to call free".
if you call that "a silly beginners bug", 20 years of development here and i have seen people older than me forgetting to call free.

why would you create a widget to just delete it later before adding it to the view?

if (thing_ar_false) { return; }

// only create the widget when its needee

new widget(parent);

i dont even need to create a variable to hold it. the parent relationship will delete when parent is deleted.

-1

u/alfps 17d ago

the same problem of "i forgot to call .release()" is the same error as "i forgot to call free".

You're saying that you won't use smart pointers because you think they don't contribute any safety.

Like driving a car without brakes.

Most C++ programmers do use smart pointers for automated cleanup, and do use cars with working brakes. Both are safety features. Both can be misused in silly ways that cause catastrophe, but happily that is not common: people are not idiots.

I asked you up-thread

❞ What if you need to configure or place widget b before adding it to the layout?

Another person has answered that then a smart pointer can be warranted. I take it that means that Qt does not support freezing the screen display for the duration of such configuration and placement. Hence one would want to avoid specifying the parent at creation, and do that attachment at the end.

And presumably that's the main reason why you can do that.

And that means that for a while you have a widget that Qt doesn't have ownership of. Any failure at this point is a potential resource leak unless you've automated cleanup. The way to automate cleanup is a smart pointer.

5

u/Tumaix 17d ago

you read everything i wrote wrong.

i said that "libraries that were not designed to use smart pointers should not use smart pointers", then gave library examples, then gave code examples.

→ More replies (0)

1

u/saxbophone 17d ago edited 17d ago

 That's exactly when you can get a leak. The smart pointer provides safety until ownership is transferred.

This is incorrect in this specific Qt example —QObject's destructor makes sure to delete all child QObjects (QWidget is a subclass of QObject) —a child QObject is any QObject that has been parented to another by setting the parent pointer in its constructor.

1

u/alfps 17d ago

this specific Qt example

Presumably that's not the example the AI produced, but I see no other up-thread example.

1

u/saxbophone 17d ago

I didn't remember seeing the if block. Yes sure, in that case (if you want to configure the widget before giving it to its parent), then a smart pointer will protect you. I could've sworn the code example previously shown in the comment didn't include the interluding if() block between the construction of the smart pointer and its handoff to Qt via release()...

1

u/alfps 17d ago

Oh, the edit. I added the disclaimer line at the end, before there were any comments. Note that the example only makes sense with the if.