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

[Zerex71]

In message





From the hint "// Also set /clr compile option in the project
properties" it sounds C++/CLI related to me. Despite the misleadingly
similar name, that's an entirely different language.


Keep digging, and all the knowledgeable posters here will surely push
you into the resulting pit, or their killfiles.

Did you read this part of the FAQ?

"Include the smallest, complete and compilable program that exhibits
your
problem."

That would as a minimum have included the definition of your "lock"
class or function, or whatever it is, since it is not a part of the C++
standard and nobody here can read minds.

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.

 

[peter koch]

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.

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

 

[Tim H]

I was asking because locking things, mutexing, etc. and so forth seems
a pretty standard C++ feature, even if by "standard" it is part of

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.

To me, there is nothing *that* off-topic about asking about this
question. Sure, there is the CLR keyword that jumps out, but lock is
part of C++, at least Microsoft's interpretation of it. Perhaps a

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

 

[dave_mikesell]

To me, there is nothing *that* off-topic about asking about this
question. Sure, there is the CLR keyword that jumps out, but lock is
part of C++, at least Microsoft's interpretation of it. Perhaps a
renaming of the newsgroup should be in order?

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?

 

[Yannick Tremblay]

Why is it that newbies always feel that the world how them?

I was asking because locking things, mutexing, etc. and so forth seems

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.

a pretty standard C++ feature,

It's not a C++ feature. It's a platform specific
facility/library/utility. But generic multithreading discussion are
welcome here.

To me, there is nothing *that* off-topic about asking about this
question. Sure, there is the CLR keyword that jumps out, but lock is
part of C++,

No it isn't. The concept of locks/mutex/etc is pretty much generic

at least Microsoft's interpretation of it.

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

I saw plenty of things
posted to this group that had the stamp of "programming question" on
it. If someone here doesn't like the content, then make the group
moderated.

Programming questions are perfectly on-topic here if they are about

If I had a truly Windows-specific question, then I would have went
looking there (i.e MFC, forms, .NET, UI, MSDN, etc.) but this seems
pretty generic. Oh well. On to bigger and better things.

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

 

[Erik Wikström]

I was asking because locking things, mutexing, etc. and so forth seems
a pretty standard C++ feature, even if by "standard" it is part of
some thing like the STL.

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).

My hope was that someone here had the answer rather than jumping on
me for the semantic equivalent of jaywalking.
http://msdn2.microsoft.com/en-us/library/ms177087.aspx

I had hoped someone who had done this in C++ had the answer.

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).

More effort has been expending on trying to get me to report than to
actually producing the answer (Lord knows how nerds hate when you put
something in the wrong box).

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.

To me, there is nothing *that* off-topic about asking about this
question. Sure, there is the CLR keyword that jumps out, but lock is
part of C++, at least Microsoft's interpretation of it.

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.

 

[Default User]

Zerex71 wrote:

Still sounds C++-related to me. Next?

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

 

[James Kanze]

You know, I tried that, and it didn't work for me. That is
similar to both of the LOCs I have seen in the MSDN and other
online examples, and it still didn't work.

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.

I've even tried "lock myLock = new lock(this)" or lock
l<MyClass> or things or that nature.

The technique of randomly changing code until it manages to get
through the compiler is not one I'd recommend for robust code.

None of it works. This lock.h, which is part of the MS CLR
(as evidenced by the namespace)

What namespace?

is not something some Joe Blow cooked up - it's
part of the native VS2005 package. I don't know where else to
turn.

If it's part of the system libraries for Windows, then a Windows
newsgroup would seem appropriate, no?

And, while we're on the topic of what's on topic, tell me
again why a poster wouldn't want to post a C++-related thread
on a newsgroup that is called "comp.lang.c++".

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]

I was asking because locking things, mutexing, etc. and so
forth seems a pretty standard C++ feature,

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.

[...]

To me, there is nothing *that* off-topic about asking about this
question. Sure, there is the CLR keyword that jumps out, but lock is
part of C++, at least Microsoft's interpretation of 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.

 

[jason.cipriani]

The technique of randomly changing code until it manages to get
through the compiler is not one I'd recommend for robust code.

It's been working for me for years! Think of it more as a study in
genetic algorithms. <g>

 

[Zerex71]

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?

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.

 

[Richard Herring]

In message

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.

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.

 

[Erik Wikström]

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.

Perhaps none of us have ever "done this", in that case we have helped
you as best as we could. Ever thought about that?

 

[mud209]

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.

 

[Dkudlay]

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.