CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Page 3 of 3 FirstFirst 123
Results 31 to 43 of 43
  1. #31
    Join Date
    Oct 2008
    Posts
    1,456

    Re: When to use pointers?

    Quote Originally Posted by nuzzle View Post
    Well, then you've learned something new because these words are commonly used about designs in general, but less so in the context of design of standards. In fact I don't think I've ever a heard a standard being called connected, brittle or monolithic, even though I suppose standards can be all of that.
    I totally ignore what's your claim here ... yes, the STL is a standard but it's also a library design, so what's your logical point ??

    Quote Originally Posted by nuzzle View Post
    You claim parametric scales better than subtype but you haven't explained how?
    yes, but sice I want to avoid yet another flame war based on loose terminology and ambiguous problem statements, before explaning we should agree on what we're speaking about ... otherwise, it's just time wasted speaking of nothing. Anyway, your answer implies you don't agree on the problem formulation itself, so, I'm fine stopping here on this issue.

    Quote Originally Posted by nuzzle View Post
    There is no special heap synchronization necessary if the default heap internally manages one heap per thread. Then threads aren't competing for a single heap, they all have their own.
    but what happens if a thread tries to delete something new-ed by another thread ? in the worst case, you'll get UB ( for example, this is the case on winapi heap functions with synchornization turned off ), at best you'll get a performance degradation due to the inevitable synchronization. Note that not only the standard allows memory de/allocations between different thread, it also promotes them ( see for example the new exception_ptr specification ).

  2. #32
    Join Date
    May 2009
    Posts
    2,413

    Re: When to use pointers?

    Quote Originally Posted by superbonzo View Post
    I totally ignore what's your claim here ... yes, the STL is a standard but it's also a library design, so what's your logical point ??
    You introduced STL as an example of good template based design. I say fine but since STL is a standard it's at most an example of a well designed programmer's interface. It doesn't tell much about the state of template designs in general. Even if you think Mr. Stepanov got STL right, concrete STL libraries may be complete disasters internally as template designs tend to be.

    We don't need a problem formulation, we need you to finally explain what you mean. Otherwise there's not much to discuss is there.

    but what happens if a thread tries to delete something new-ed by another thread ?
    The inner workings of the default allocator is an implementation detail. From the programmer's perspective it's business as usual. Multithreading must be properly synchronized. The only thing a programmer may notice (if one heap per thread is used rather than a global shared heap) is that allocations are faster.
    Last edited by nuzzle; April 24th, 2013 at 08:54 AM.

  3. #33
    Join Date
    Jan 2006
    Location
    Singapore
    Posts
    6,765

    Re: When to use pointers?

    Quote Originally Posted by nuzzle
    I say fine but since STL is a standard it's at most an example of a well designed programmer's interface.
    I agree since the standard specifies the interface, not the implementation, but that's the thing: when I think of "library design", I think of the interface provided by the library, in this case the parts of the standard library that come from the STL. When you wrote "template based designs", the thought that came to my mind was "the design of the interface", not "implementation". Hence, superbonzo's assertion that '"connected", "brittle" and "monolithic" are properties related to a (library) design, not its implementation' makes sense to me. Have you never heard of the design of library interfaces being described as such?
    C + C++ Compiler: MinGW port of GCC
    Build + Version Control System: SCons + Bazaar

    Look up a C/C++ Reference and learn How To Ask Questions The Smart Way
    Kindly rate my posts if you found them useful

  4. #34
    Join Date
    Apr 2000
    Location
    Belgium (Europe)
    Posts
    4,626

    Re: When to use pointers?

    Quote Originally Posted by nuzzle View Post
    The inner workings of the default allocator is an implementation detail. From the programmer's perspective it's business as usual. Multithreading must be properly synchronized. The only thing a programmer may notice (if one heap per thread is used rather than a global shared heap) is that allocations are faster.
    And yet... The compiler cannot KNOW that memory allocated on one thread will never be deallicated in another thread. So the default implementation for any allocator must always assume synchronisation is needed. Only if you --the programmer-- know for sure that x-thread access to allocator isn't ever happening can you safely use an unsynced heap by explictely defining this in your code.


    The one possible exception to this is if you link against a single threaded runtime lib that doesn't offer any kind of support for multithreading.


    Most multithreaded apps don't need multiple heaps because even with synchronisation, the heap is rarely the bottleneck. And if it is... then separate heaps per thread (even if feasible) rarely help enough to make a real change to performance. If your bottleneck is the heap, it's more likely that fragmentation if your real culprit and multiple heaps won't really fix that. custom allocators can.

  5. #35
    Join Date
    May 2009
    Posts
    2,413

    Re: When to use pointers?

    Quote Originally Posted by laserlight View Post
    Hence, superbonzo's assertion that '"connected", "brittle" and "monolithic" are properties related to a (library) design, not its implementation' makes sense to me. Have you never heard of the design of library interfaces being described as such?
    No, I've never really heard programmer interfaces to libraries being discussed in those terms. But I'm positive they can because after all they're designs too.

    I think superbonzo threw STL into the discussion by mistake, and then just couldn't bring himself to admit STL in fact is a standard and has little to do with this discusson.

    And I know why he did it. It's because the STL standard was designed by Mr. Stepanov who is also the father of the design methology superbonzo claimes is superior (or at least scales better) than object orientation.

    This becomes pretty clear in superbonzo's post #25 where he defines "template based design" in terms verbatim from the book Elements of Programming by the very Mr. Stepanov (even though Mr. Stepanov never makes C++ templates the basis of his design methology).

    So sure, there's tension between OO and the design methology of Mr. Stepanov (a high profile critic of OO). But for C++ it doesn't mean OO designs scale worse than template based designs. As I've argued, they scale approximately the same in practice.

    Every C++ programmer should be aware of both design approaches and be able to mix and match. Programming still is an art.
    Last edited by nuzzle; April 24th, 2013 at 06:49 PM.

  6. #36
    Join Date
    May 2009
    Posts
    2,413

    Re: When to use pointers?

    Quote Originally Posted by OReubens View Post
    And yet... The compiler cannot KNOW that memory allocated on one thread will never be deallicated in another thread. So the default implementation for any allocator must always assume synchronisation is needed.
    According to C++ an object may only be deleted once and that's the responsibility of the programmer, not the memory allocator.

    So "undefined behaviour" may take a whole new meaning with a memory allocator that uses one heap per thread, but that's all.
    Last edited by nuzzle; April 24th, 2013 at 06:56 PM.

  7. #37
    Join Date
    Oct 2008
    Posts
    1,456

    Re: When to use pointers?

    laserlight, I think it's time to surrender to nuzzle's mind reading abilities ... now, I'm just curious to see if OReubens has more patience than I have ...

  8. #38
    Join Date
    Mar 2006
    Posts
    151

    Re: When to use pointers?

    At the risk of sticking my neck out, I wonder if I could give my two cents on the issue of the usage pointers vs. references discussed back in posts 5 through 9 of this thread? (Please excuse me if this distract's too much from the way the thread has evolved since then.)

    In my opinion, the problem with references is that they hide pointers, and thus obfuscate what is really going on in many cases.

    For an example please see my comments on this very topic in a post last month: http://forums.codeguru.com/showthrea...t=#post2111485.

    As I discussed there, references hide ownership issues. I meant to state (but as laserlight pointed out, failed to clearly do so) that they also hide when an object can be modified by a callee.

    In the case of std::swap(a, b) you assume from the function name that objects and a and b will be modified, but what if the function name is not clear? What if you come across a line of code that says something like
    Code:
    bravo.CalculateAndStoreMetaData(a, b, c); // Example 1
    ?
    In a system that is rampant with misused references, how can you tell from this line of code where the meta-data will get stored? Does it get stored in the bravo object or in a, b, or c?

    If instead you see
    Code:
    bravo.CalculateAndStoreMetaData(a, b, &c); // Exmaple 2
    Now you've got a clue that c might be an argument to an "out" parameter.

    Really, the power of what I advocate comes from the combination of const-correctness, not using references, and Intellisense.

    Using the above fictitious example, if a and b are large objects, it's nice to know whether they are being deep-copied (I usually work in time-critical code and thus usually care) but if a and b are arguments to reference parameters, then again that issue is obfuscated. Instead, I would much rather see
    Code:
    bravo.CalculateAndStoreMetaData(&a, &b, &c); // Example 3
    and thereby I'm far closer to knowing with a single glance what is really going on. If I also know the code is const-correct, I can then use Intellisense to see that a and b are arguments to pointers-to-const, but that c is an argument to a pointer-to-mutable. Now I know that the function verly likely either takes ownership of or modifies it's third argument.

    With Example 1, you can use Intellisense and const-correctness to figure out the modification/ownership issue, but you are required to use that second step, whereas instead with pointers it's often (in my experience) sufficient simply to know the objects aren't being deep-copied, but with only one glance you just can't get that information with obfuscators, er um, I meant to say references.

    I do like references quite well in some specific uses (as I mentioned in my other post linked above). Otherwise, I thus far haven't seen that they are of any non-negligible benefit at all (did I miss some reason why I should be trying to make C++ look more like Visual Basic?) except for the parameter-can't-be-null issue (which in my opinion doesn't outweigh the above disadvantages most of the time) and for some specific uses in obtaining type-information for template classes.
    Last edited by GeoRanger; April 28th, 2013 at 07:54 PM. Reason: Make URL navigable

  9. #39
    Join Date
    Jul 2005
    Location
    Netherlands
    Posts
    2,042

    Re: When to use pointers?

    Quote Originally Posted by GeoRanger View Post
    For an example please see my comments on this very topic in a post last month: http://forums.codeguru.com/showthrea...t=#post2111485.

    As I discussed there, references hide ownership issues. I meant to state (but as laserlight pointed out, failed to clearly do so) that they also hide when an object can be modified by a callee.
    Seems to me that you want to communicate too much with a pointer. It should communicate ownership and 'out' parameters, but it is also the only (descent) way to have optional function parameters. That means that whenever I see a pointer being used, I still don't know why it is used.
    Quote Originally Posted by GeoRanger View Post
    In the case of std::swap(a, b) you assume from the function name that objects and a and b will be modified, but what if the function name is not clear? What if you come across a line of code that says something like
    Code:
    bravo.CalculateAndStoreMetaData(a, b, c); // Example 1
    ?
    In a system that is rampant with misused references, how can you tell from this line of code where the meta-data will get stored? Does it get stored in the bravo object or in a, b, or c?

    If instead you see
    Code:
    bravo.CalculateAndStoreMetaData(a, b, &c); // Exmaple 2
    Now you've got a clue that c might be an argument to an "out" parameter.
    Or it might be an optional parameter. Why not just return the value of c?
    Even if you have multiple return values, you can std::tie.
    Quote Originally Posted by GeoRanger View Post
    If I also know the code is const-correct, I can then use Intellisense to see that a and b are arguments to pointers-to-const, but that c is an argument to a pointer-to-mutable. Now I know that the function verly likely either takes ownership of or modifies it's third argument.
    You can also use intellisense to see if a function takes a parameter by value, by const reference or by reference. You just argued against this.
    Besides, I don't find "knowing that either ... or ..." a strong argument when talking about code clarity. You still don't know what's going on, so the code is still not clear.
    Quote Originally Posted by GeoRanger View Post
    I do like references quite well in some specific uses (as I mentioned in my other post linked above). Otherwise, I thus far haven't seen that they are of any non-negligible benefit at all (did I miss some reason why I should be trying to make C++ look more like Visual Basic?) except for the parameter-can't-be-null issue (which in my opinion doesn't outweigh the above disadvantages most of the time) and for some specific uses in obtaining type-information for template classes.
    I think the point is that you are trying to solve the wrong problems with references. You cannot convey ownership with references or pointers; use smart pointers instead, because they do convey ownership. Regarding out parameters, my advice would be to try to avoid them where possible. In the case of multiple return values, just return a tuple (or a dedicated struct/class that communicates the meaning of each return value).
    Cheers, D Drmmr

    Please put [code][/code] tags around your code to preserve indentation and make it more readable.

    As long as man ascribes to himself what is merely a posibility, he will not work for the attainment of it. - P. D. Ouspensky

  10. #40
    Join Date
    Oct 2008
    Posts
    1,456

    Re: When to use pointers?

    Quote Originally Posted by GeoRanger View Post
    (Please excuse me if this distract's too much from the way the thread has evolved since then.)
    no problem ( anyway, in the meantime those topics went in a dead end for some reason ... )

    regarding the pointer VS reference issue, if one strictly restricts himself to C with classes then your arguments do make sense to me. But, when you start using STL-like libraries and things like smart pointers, etc... you'll end up using references anyway, so imposing a pointer-only coding style to your own code would result in making the code even more confusing, wouldn't it ?

    in any case, as D_Drmmr pointed out, the benefits you mentioned fade away the higher level the code becomes, because in this case you'll need more complex ownership/value passing abstractions than a simple pointer can handle anyway, the net result being just polluting the code with "&*"'s everywhere ...

  11. #41
    Join Date
    Apr 2000
    Location
    Belgium (Europe)
    Posts
    4,626

    Re: When to use pointers?

    Quote Originally Posted by GeoRanger View Post
    In my opinion, the problem with references is that they hide pointers, and thus obfuscate what is really going on in many cases.
    it is neither the purpose nor the intention of either pointers or references to "obfuscate".
    Pointers have their uses, and so do references. Sometimes their uses are interchangable in which case going for the reference is better because it removes a level of indirection and thus provides code clarity.
    Sometimes they aren't interchangable in which case the discussion is moot, use the one that needs to be used.

    As I discussed there, references hide ownership issues.
    Pointers by themselves do not imply ownership of anything. Now if you're talking smart pointers, then yes, some of those have ownership semantics built in.

    Are you implying that if you create a dynamic array (let's take a std::vector), and you do something like: foo* pFoo = &fooVector[4]; that the pointer now ownes the element at index 4 while the vector owns the rest ? what do you expect to happen when the vector gets deleted ? Or are you implying that writing code like this is (or should be) invalid because it breaks your notion of ownership ?

    I meant to state (but as laserlight pointed out, failed to clearly do so) that they also hide when an object can be modified by a callee.
    The 'right to' modify is not an inherent trait of pointers or references.
    if you want to convey that a parameter is not modified by the function, then that's what const is for.

    if you want to more closely convey input, output or onput/output parameters, then this is information that currently is not part of the standard. There are however several attempts with various degrees of compiler assistance at solving this with annotation. MS has such an annotation throughtout (most of) the platform SDK

    If instead you see
    Code:
    bravo.CalculateAndStoreMetaData(a, b, &c); // Exmaple 2
    Now you've got a clue that c might be an argument to an "out" parameter.
    This is a shortsighted approach that may work for you, but wouldn't work as a general approach.
    Now what if the 3rd parameter was optional. So you make it a pointer so you can pass NULL to say that there is no object for that 3rd parameter... does this then imply it still has to be an out ? or could it be an in also (a lot of the Windows SDK uses this).

    How would you convey a parameter that is both in and out ?


    Using the above fictitious example, if a and b are large objects, it's nice to know whether they are being deep-copied (I usually work in time-critical code and thus usually care) but if a and b are arguments to reference parameters, then again that issue is obfuscated.
    Reference parameters are never copied that's why they are references and not value parameters.

    If you pass pointers... Then how (if at all) do you make sure that the user of the function knows that they aren't allowed to pass NULL ?

    Instead, I would much rather see
    Code:
    bravo.CalculateAndStoreMetaData(&a, &b, &c); // Example 3
    and in doing so you enforce your vision onto everyone else, and you now have 3 out parameters ? (they're all modifiable by your former definition), and parameters that could be passed as NULL.

    and thereby I'm far closer to knowing with a single glance what is really going on.
    and this is an archaic way of thinking. You seem to want 'control' over what you think the compiler should be doing rather than telling the compiler what you want and letting the compiler figure out the most optimal code.

    This same way of thinking is what makes people write weird convoluted code sequences because they think that will result in more optimal code. Optimizing compilers have evolved to the point where most of those tricks only make your code harder to read and maintain but don't give you better code (on the contrary, you might get worse code).


    Now I know that the function verly likely either takes ownership of or modifies it's third argument.
    taking ownership... no. You have made it harder to understand because now that option (as well as NULL) could be potentially possible. So you have to know more about how the function works to be sure. This makes your solution "less oop".


    instead with pointers it's often (in my experience) sufficient simply to know the objects aren't being deep-copied
    This implies you desire control at the caller side, which again goes against basic oop principles. The functions knows best if it requires deep copying or not, or it was coded by someone that doesn't understand what they're doing which is bad any way you look at it.

    The caller really has no choice in this matter. If a function has a value parameter, then this means the creator of that function desired a deep copy, it's not the caller fault if this is the case, nor is there anything you can really do other than not calling the function which is likely not be an option.

    You p.o.v. seems to imply the caller does have choice in things while they don't, so why do you make things harder by introducing pointers when what you really want is a reference ?

  12. #42
    Join Date
    May 2009
    Posts
    2,413

    Re: When to use pointers?

    Quote Originally Posted by superbonzo View Post
    laserlight, I think it's time to surrender to nuzzle's mind reading abilities ... now, I'm just curious to see if OReubens has more patience than I have ...
    It didn't take any mind reading to see the obvious. What I find curious is why you didn't reveal your "source of inspiration" up front. After all Mr. Stepanov is an authority figure of STL fame. His methology is well established and has a substantial following and by many considered the major alternative to OO.

    Sorry to see you regress when opposed with strong argumentation. When OReubens realizes he's wrong I hope at least he is upstanding enough to admit it.

  13. #43
    Join Date
    Oct 2008
    Posts
    1,456

    Re: When to use pointers?

    Quote Originally Posted by nuzzle View Post
    It didn't take any mind reading to see the obvious. What I find curious is why you didn't reveal your "source of inspiration" up front. After all [...]Sorry to see you regress when opposed with strong argumentation. When OReubens realizes he's wrong I hope at least he is upstanding enough to admit it.
    I'm so sorry I must confess, sometimes I get really confused, sometimes I don't even remember if I read a book or not ( but luckily you know better than me ! ) ... then, dominated by embarassment I try to hide the truth foolishly hoping nobody will disclose me. So, now that I've been sunk by your powerful dialectics, please, be charitable and leave me alone in shame ... I really, really hope OReubens will be wise enough to retract before being too late, for his own good, for the good of all of us ... ... ... seriously, sometimes your provocative tone is really entertaining ...

Page 3 of 3 FirstFirst 123

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  





Click Here to Expand Forum to Full Width

Featured