I just want to lock() - is that so wrong?

Discussion in 'C++' started by Zerex71, Mar 25, 2008.

  1. Zerex71

    Zerex71 Guest

    I'm still stunned because the impression I get is that this group has
    blinders on and is only able to talk about the language from a
    language design perspective, having never coded something like what I
    am attemping in C++. I find it hard to believe - most people are more
    advanced than the simple concept I'm trying, from what I gather.
     
    Zerex71, Mar 26, 2008
    #21
    1. Advertisements

  2. Zerex71

    peter koch Guest

    Might be. Most of us, including myself, have written multithreaded
    software, but we have not used C++/CLI (and looking at the code, this
    lock-thing looks all wrong to me from the conceptual level). And even
    more important is that we reserve this newsgroup for more or less
    language-related stuff. By doing so, we reduce the noise-level and we
    benefit the posters by helping them to find the proper newsgroup. Your
    insistence that another language is on-topic here is just stupid -
    even if the language is close to C++.

    /Peter
     
    peter koch, Mar 26, 2008
    #22
    1. Advertisements

  3. Zerex71

    Tim H Guest

    But it's not. The current C++ standard does not address locking AT
    ALL. There is NOTHING about your question that is related to any
    other C++ implementation but Microsoft's. Hence the "go ask in an MS
    forum" responses. If it doesn't work, we can not point to a spec to
    say "here is how it works". We can not point to the code to say "this
    is how it is implemented". It's a closed piece of MS's toolchain.
    So go ask Microsoft why their documentation on this issue is
    insufficient for you to figure out how to make it work. Or go read
    the code to understand it. Or use a library that people here CAN help
    you on, like Boost. All the world is not Windows.

    Tim
     
    Tim H, Mar 26, 2008
    #23
  4. Zerex71

    Guest

    There are already several groups dedicated to MS C++. This one is for
    standard C++, so there's no need to rename it.

    Do you go to Protestant services and ask them repeated questions about
    Catholic sacraments? And then chide them when they say you should
    probably ask a priest?
     
    , Mar 26, 2008
    #24
  5. Why is it that newbies always feel that the world how them?

    Ideally generic multthreading discussion should go to
    comp.programming.threads. Platform specific ones or library specific
    ones should go to a platform specific or library specific discussion
    group.

    This allows peoples with a common interest to discuss their common
    interest together. The range of potential interest is so vast that it
    is impossible to discuss them all at one place.
    It's not a C++ feature. It's a platform specific
    facility/library/utility. But generic multithreading discussion are
    welcome here.
    No it isn't. The concept of locks/mutex/etc is pretty much generic
    It isn't either. It's part of Microsoft specific library that may or
    may not be C++ compatible. It's one of the many library one can use
    on Windows. There's a huge variety of them and I for one is unable to
    know them all. I've used MS CriticalSection in the past but never
    Programming questions are perfectly on-topic here if they are about
    But it is Windows specific and it isn't generic. Where do you think
    #include <msclr\lock.h> comes from?

    Basically, peoples here don't know what is in #include
    <msclr\lock.h>. It is not a part of C++. My only guess is that it is
    a header file for one of the multitude of multithreading library that
    exists. It's probably part of MS-CLR.

    Essentially, your problem is an incompatibility between the code you
    wrote and the way the lock from #include <msclr\lock.h> is supposed
    to be used. In order to solve your problem, you need to read the
    documentation about #include <msclr\lock.h> or the header file itself
    or find some experts on #include <msclr\lock.h> that can help you.
    Unfortunately for you, these expert don't live here. They are far
    more likely to be found in a Microsoft CLR specific discussion group.

    If instead of replying as an arrogant little newbie that think that the
    world how him an answer you had come back with say:
    -----------------------------------------------------------------------
    Sorry, I didn't realise that #include <msclr\lock.h> was not part of
    the C++ standard. However, here is the class definiton of lock taken
    from the header file:

    class lock
    {
    .....???? I have no idea what is here?
    }

    Here is my code:

    lock(this);

    This doesn't work, could anyone explain what I am doing wrong?
    -------------------------------------------------------------------

    Then you may very well have got a useful answer.

    The incompatibility between your code and the class definition is
    quite possibly a purely C++ issue. Without the class definition, we
    have no idea.

    Cheers anyway,

    Yan
     
    Yannick Tremblay, Mar 26, 2008
    #25
  6. While I'm sure that a lot of people would like to have locks and such in
    the standard library (note that STL is part of the standard library) we
    are not quite there yet (but will be with the next version of the standard).
    Even if they had it would not have helped you since (your) lock.h is
    part of the .Net library, and thus not C++ (while C++/CLR might suggest
    that it is some kind of dialect of C++ is it more like C# with C++ syntax).
    Had more effort be put on trying google (or MSDN) before posing none of
    this would ever have happened. Notice also that Martin York gave you
    the answer.
    First, Microsoft's interpretation of C++ have historically had little to
    do with standard C++ (thought they have become much better the last few
    years). Second, while adding the letters CLR might seem like a small
    thing it makes a large difference, since we are suddenly talking about a
    totally different language, which means that your question is not more
    topical here than it would be in a Java group.
     
    Erik Wikström, Mar 26, 2008
    #26
  7. Zerex71

    Default User Guest

    Zerex71 wrote:


    That demonstrates your ignorance of the C++ language. Fortunately, you
    have more knowledgable people who can tell you that it is indeed not
    part of the language, but rather a platform-specific extension.





    Brian
     
    Default User, Mar 26, 2008
    #27
  8. Zerex71

    James Kanze Guest

    Until we know how lock is declared, we can't say. There is no
    function "lock" in C++, nor any type lock, nor anything else.
    It's a user defined symbol, and without knowing how it's
    defined, it's impossible to say why the compiler is complaining.
    The technique of randomly changing code until it manages to get
    through the compiler is not one I'd recommend for robust code.
    What namespace?
    If it's part of the system libraries for Windows, then a Windows
    newsgroup would seem appropriate, no?
    Well, without seeing the declaration of lock, who knows whether
    the question is C++ related or not. I can't reproduce it with
    my compilers on my machines, because I don't have the
    corresponding headers. Show me what's in the headers, and I can
    have a stab at it.
     
    James Kanze, Mar 26, 2008
    #28
  9. Zerex71

    James Kanze Guest

    Actually, it's not, although it will be with the next release of
    the standard.

    In the mean time, there's no problem discussing threading issues
    in general here (although detailed discussions of a specific
    threading interface are better handled in the newgroup for the
    system defining the interface), but I've yet to see a threading
    issue provoke a compiler error.

    If lock is part of your system's interace (not the case on the
    systems I use), then you really should ask in a newgroup
    specialized for your system. If lock is part of the user code,
    then you'll have to show us the declaration---we can't guess it.

    [...]
    lock, per se, is not part of C++, in any way, shape or fashion.
    Any more than any class I happen to write in C++ is.

    That doesn't mean that your question doesn't have C++ related
    content. But until we see the declaration of lock, we can't say
    anything more.
     
    James Kanze, Mar 26, 2008
    #29
  10. Zerex71

    Guest

    It's been working for me for years! Think of it more as a study in
    genetic algorithms. <g>
     
    , Mar 27, 2008
    #30
  11. Zerex71

    Zerex71 Guest

    As a matter of fact, it's a favorite pastime of mine.

    I'm outta here - had enough. You could have answered the questions if
    you'd ever done this, and I mean that for anybody.
     
    Zerex71, Mar 27, 2008
    #31
  12. In message
    You appear to be trying to do something that is impossible using only
    the features of standard C++ because it requires platform-specific
    libraries.

    Translating from C# to C++/CLI (surely a pointless exercise, since it
    buys you nothing -- C++/CLI is not C++ and is no more portable than C#)
    means you are still committed to the same platform-specific library that
    C# used.

    Rewriting in standard C++ will mean you have to use some other
    platform-specific synchronisation library which almost certainly won't
    have the same semantics as the CLI one.

    And for other readers of this thread FWIW the definition of the class
    question turns out to contain lines like this:

    ref class lock
    {
    public:
    template<class T> lock( T ^ _object)

    so it is indeed not a C++ class, but a C++/CLI one.
     
    Richard Herring, Mar 27, 2008
    #32
  13. Perhaps none of us have ever "done this", in that case we have helped
    you as best as we could. Ever thought about that?
     
    Erik Wikström, Mar 27, 2008
    #33
  14. Zerex71

    mud209

    Joined:
    Jul 21, 2008
    Messages:
    2
    Likes Received:
    0
    locking

    You're probably trying to lock an object that has generic parameters, e.g.

    generic<class T>
    ref class MyClass { ... };

    Try locking a regular object instead, and it works as it should.
     
    mud209, Jul 21, 2008
    #34
  15. Zerex71

    Dkudlay

    Joined:
    Jul 3, 2016
    Messages:
    1
    Likes Received:
    0
    Ran into this problem. Then across this discussion. Typical pedantic nerd trash talk.
    The msclr::lock requires a managed object for a lock.
    MyClass in the OP is not a managed object. Hence the cryptic error.
     
    Dkudlay, Jul 3, 2016
    #35
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.