Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>There are already some good answers here, but I want to address one additional point. Let's look very carefully again at your specific question: </p> <hr> <p>It is my understanding that the framework itself is written in C++ and C++ is susceptible to memory leaks.</p> <ul> <li>Is the underlying framework so well-written, that it absolutely does not have any possibility of internal memory leaks?</li> <li>Is there something within the framework's code that self-manages and even cures its own would-be memory leaks?</li> <li>Is the answer something else that I haven't considered?</li> </ul> <hr> <p>The key here is to distinguish between <em>your</em> code and <em>their</em> code. The .Net framework (and Java, Go, python, and other garbage-collected languages) promise that if you rely on <em>their</em> code, <em>your</em> code will not leak memory... at least in the traditional sense. You might find yourself in situations where some objects are not freed as you expect, but these cases are subtly different from traditional memory leaks because the objects are still reachable in your program.</p> <p>You are confused because you correctly understand that this is not the same thing as saying any program you create can't possibly have a traditional memory leak at all. There could still be a bug in <em>their</em> code that leaks memory. </p> <p>So now you have to ask yourself: would you rather trust your code, or their code? Keep in mind here that their code is not only tested by the original developers (just like yours, right?), it's also battle-hardened from daily use by thousands (perhaps millions) of other programmers like yourself. Any significant memory leak issues would be among the first things identified and corrected. Again, I'm not saying it's not possible. It's just that it's generally a better idea to trust their code than it is your own... at least in this respect.</p> <p>Therefore the correct answer here is that it's a variant of your first suggestion:</p> <blockquote> <p>Is the underlying framework so well-written, that it absolutely does not have any possibility of internal memory leaks?</p> </blockquote> <p>It's not that there's no possibility, but that it's much safer than managing it yourself. I'm certainly not aware of any <em>known</em> leaks in the framework.</p>
    singulars
    1. This table or related slice is empty.
    1. POWhy can .NET not have memory leaks?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USJoel Coehoorn
    1. USJoel Coehoorn
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POWhy can .NET not have memory leaks?
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COEric Lippert should read this whole question (hoping for a vanity search win here).
      singulars
      1. PO
      1. USJoel Coehoorn
    2. COJust to add to that: *their* code indeed has memory leaks (WPF has quite a few leaks, one example: https://connect.microsoft.com/VisualStudio/feedback/details/529736/wpf-progressbar-isindeterminate-true-causes-unmanaged-memory-leak). Not trying to bash (I like .net :)), just to give an example.
      singulars
      1. PO
      1. USMichael Stum
    3. CO@Michael: Well there is _their_ code and then there is _their_ code. That is there is stuff like the WPF ProgressBar and there is stuff like the `String` type. The WPF ProgressBar has as much chance of containing the odd bug or two as _our_ code, however the base .NET code on which we all rely ( _them_ and _us_ ) is much less likely to have such bugs.
      singulars
      1. PO
      1. USAnthonyWJones
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload