|
Array delete operator, delete[] invokes the destructor of each array element before freeing the array. For an array of integers, it doesn't make any difference. Meanwhile, if the objects in the array have a non-trivial destructor you should call the delete[] operator.
Mircea
|
|
|
|
|
Mircea Neacsu wrote: For an array of integers, it doesn't make any difference.
It is true that no destructor is called for each element of an int[] array, but that does not mean that the memory layout is compatible with delete. For example, the compiler might allocate additional space for a variable containing the size of the array and return a pointer to memory after this variable. When using delete, the heap will be corrupted.
The heap layout is implementation-dependent, and therefore you should always match new/delete and new[]/delete[]!
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
While you are absolutely right, I don't know of any heap manager that behaves the way you describe. Let's say that calling delete on an int array is a smaller sin, a "peccadillo" that will place you on one of the first circles of hell. 
Mircea
|
|
|
|
|
As noted you should use the correct one.
I know for a fact that long ago using the wrong one would cause memory stack corruption.
I presume that now that isn't possible or is less likely.
Although I would be curious if the spec deals with that specific issue.
|
|
|
|
|
In any case, smart pointers are preferable in almost all cases to new/delete. I imagine that there are some cases where new and delete are preferred to smart pointers, but for most applications, a smart pointer is the better option.
"A little song, a little dance, a little seltzer down your pants"
Chuckles the clown
|
|
|
|
|
I'm using NtQueryInformationProcess[^] to find the parent process of a specified process. I'm passing a PROCESS_BASIC_INFORMATION structure and using the InheritedFromUniqueProcessId member to get the parent.
I then call this function recursively with each parent process to find the parent of the parent, and so on.
The problem is that sometimes it starts returning process IDs that it has already returned in earlier calls, leading to infinite recursion.
For instance, in successive calls it will return process IDs 3, then 2, then 1. Then when called for process ID 1 it will return 3 again! How can this be?
I can easily work around this by checking to see if the returned parent process ID was already returned earlier in the call stack, and if it was, breaking out of the loop.
But my question is, why?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Dynamic versus static structures? Different types of parents / qualifying information?
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
Can you elaborate? I didn't know there were different types of parents. And I don't know what you mean by dynamic versus static structures.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
If I'm climbing a tree and the branch I'm climbing gets moved, what am I climbing?
I child can have multiple parents. You need to know which parent you're dealing with. If they inherit the same base, they "look" the same but aren't.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
I don't see how a process can have more than one parent process. This is something I hadn't considered.
If Process A calls CreateProcess and launches Process B. Then A is the parent. I don't see how any other process can be a parent of B.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Some sort of circular dependency? You see a similar behavior if you've ever used Dependency Walker.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
Yes I see what you're saying. The only kind of dependency that I am familiar with is the static kind used by DLLs.
What kind of dependency are you discussing?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
I have seen that also. Annoying when it showed up an I always ignored it without considering the reason why.
|
|
|
|
|
Seems like an interesting question.
Googling I found nothing that answers that.
From the other post I did find a comment in 'Dependency Walker' but that only stated that it occurred but not why.
Maybe you could determine the cause by looking at the detailed process information and comparing them?
|
|
|
|
|
Thanks for your responses.
I wish I had a line to Mark Russinovich. I'm sure he would know.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
I wonder if somebody could help me to resolve this issue?
If so I be happy to provide details,, however, this is the issue in nutshell...
My code complies - no errors , but when I try "Run" this is my error:
<pre>/mnt/usb-Seagate_Expansion_NA833BDC-0:0-part4/BT__PROGRAMS/FT857_DEC11/BT_LIBRARY/mdi/mdi: error while loading shared libraries: libBT_Utility_Library.so.1: cannot open shared object file: No such file or directory
Press <RETURN> to close this window...
That tells me my "link / reference " to the library is wrong...
I posted same request in another forum and getting nowhere...
I would post a compiler output if it helps.
THANKS
|
|
|
|
|
Assuming Linux:
1: Tell the linker where to look for the library using LD_LIBRARY_PATH
$ LD_LIBRARY_PATH=$HOME/project1/lib:$HOME/project2/lib project3/bin/program
alternatively, you can export LD_LIBRARY_PATH:
$ export LD_LIBRARY_PATH=$HOME/project1/lib:$HOME/project2/lib
$ project3/bin/program1
$ project3/bin/program2 If you are going to be using it a lot, you may want to add the export to your shells init scripts. For bash, that would either be $HOME/.bash_profile, or $HOME/.bashrc Other shell programs use different init scripts - sometimes called rc (or .rc) scripts
2: you can use the linker option -Wl,-rpath=$HOME/project1/lib at compile time, which will add "magic" to the executable, so it knows where to look for the library. I've not used this to specify how to check more than one directory. I expect that -Wl,-rpath=location1 -Wl,-rpath=location2 will work, but you'll have to do some research to find out. You'd use this like
$ gcc file1.c file2.c file3.c -o program -Wl,-rpath=project/lib Check with your IDE on how you might change CFLAGS, or LDFLAGS
3: If you have root, you can add the library locations on a more permanent basis by adding to /etc/ld.so.conf.d
These files are just text files that list additional places for the linker to look. Assuming that you have your libraries in /home/user/project/lib then /etc/ld.so.conf.d/project would just contain the single line /home/user/project/lib. After creating that file, you need to remember to run ldconfig, as root, so the system updates its list of places to look. After that, when you launch your program, the linker should be able to find the necessary libraries.
You can check that you've got things covered by using the program ldd. This will list all the shared libraries a given program uses, and where they are located. If a given library can not be found ldd output shows "not found"
[k5054@localhost]$ ldd /usr/bin/vim
linux-vdso.so.1 (0x00007ffefb5e4000)
libm.so.6 => /lib64/libm.so.6 (0x00007fc6a2520000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x00007fc6a2a9c000)
libtinfo.so.6 => /lib64/libtinfo.so.6 (0x00007fc6a2a68000)
libsodium.so.23 => /lib64/libsodium.so.23 (0x00007fc6a2a0f000)
libacl.so.1 => /lib64/libacl.so.1 (0x00007fc6a2516000)
libgpm.so.2 => /lib64/libgpm.so.2 (0x00007fc6a250e000)
libc.so.6 => /lib64/libc.so.6 (0x00007fc6a232f000)
/lib64/ld-linux-x86-64.so.2 (0x00007fc6a2ae7000)
libpcre2-8.so.0 => /lib64/libpcre2-8.so.0 (0x00007fc6a2292000)
libattr.so.1 => /lib64/libattr.so.1 (0x00007fc6a228a000)
[k5054@localhost]$
"A little song, a little dance, a little seltzer down your pants"
Chuckles the clown
|
|
|
|
|
I appreciate your reply, unfortunately, I am using QT to build the project, hence i do not pay much attention to compiler / linker options...
for simple selfish reason - since it does the job most of the time...
Here is the latest
I have made an error "add libabry" (IDE option) SOURCE CODE by adding it as "internal" library
For time beeing I wont wont elaborate what QT calls "internal library"...
HOWEVER
when ADDED as "external library " (QT makes note it is NOT part of "regular build process ' (??)
I was lead to add .so file BUT such file was NOT located in project structure ( not part regular build process ??)
adding it as .so makes sense , however , QT build .so in ENTIRELY different folder !
and THAT is I BELIEVE CAUSED THE WHOLE ISSUE
HENCE
when the SOURCE is added AS INTERNAL LIBRARY , it builds fine BUT the linker has no info where,,,
|
|
|
|
|
Salvatore Terress wrote: when the SOURCE is added AS INTERNAL LIBRARY , it builds fine BUT the linker has no info where,,,
That makes no sense. The linker uses the provided information to build the final executable, and if a library file cannot be located you would see link errors in the build. You still need to ensure that the library can be located at run time by the system loader, just as k5054 describes.
|
|
|
|
|
Actually, it does make sense. For example, suppose I have /usr/local/project/lib/libfoo.so When I compile I use
g++ project.c -L /usr/local/project/lib -l foo -o project
That will compile just fine, the compiler knows to look in /usr/local/project/lib to find the shared library to do its magic to create an executable. Unless I've told the link-loader to check /usr/local/projec/lib, when I try to run it I'll get the message about not being able to find the library.
"A little song, a little dance, a little seltzer down your pants"
Chuckles the clown
|
|
|
|
|
I thought that's what I said. 
|
|
|
|
|
Salvatore Terress wrote: could help me to resolve this issue?...linker
In your post there is nothing that suggests this is a "linker" problem.
Code development parts
1. Write code
2. Compile code, which includes linking.
3. Run code.
What you posted is 3. Not 2.
So you have an executable binary. It runs. The executable and OS together attempt to load libraries requested by the binary.
It is not finding them.
So as per the other post, in linux/unix there are various ways to provide that information to the OS to do that job. By providing a 'library path'.
Your question references "QT". Not sure what that is but guessing you are referring to 'QT Creator'.
And you are, perhaps, running it in the IDE.
If so the steps above still apply. The only difference is that in 'QT Creator' there is going to be an option somewhere that allows you to specify one or more 'library paths'. Getting the format of that correct is not often simple to figure out in my experience. That is because determining a separator is not obvious. But perhaps QA Creator allows (forces) you to add one at a time.
Keep in mind that when you deliver your binary you MUST deal with the same issue. And that will NOT be a QT Creator problem nor question.
|
|
|
|
|
jschell wrote: 2. Compile code, which includes linking.
Not strictly true. And I have tried to explain to the OP a number of times why that is so.
|
|
|
|
|
in another words HOW the QT (IDE) presents the name of the library ( it did find it as expected, the path to it is known to it... ) in an option box and when finished the compiler / linker builds the .so files . These .so files are , with little patience, visible in compiler/ linker output.
What remains is to find , as noted , WHY the result is another folder / directory inserted in code...structure
Where in the QT IDE is the option controlling that
and
why the run process (?) cannot find the build / constructed .so files
|
|
|
|
|
Note: you do not need to use bold text, we are all quite capable of reading normal font.
As to your questions:
Salvatore Terress wrote: Where in the QT IDE is the option controlling that (another folder / directory inserted in code...structure
)
No idea, this is the C++ forum, you need to ask in the QT support site.
Salvatore Terress wrote: why the run process (?) cannot find the build / constructed .so files
As we have explained before, the system loader has a set of predefined locations which it searches for shared object libraries when the program runs. If your library is not within one of these directories then you need to add its location to the LD_LIBRARY_PATH environment variable.
modified 14-Dec-23 7:35am.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
