I recently (re)discovered data binding in Windows Forms thanks to its
advances in Visual Studio 2005. As I looked a little deeper, however, I
realize that it still suffers from an irksome tendency to stick a whole
bunch of literal strings in my code. Quite frankly, I consider them a
plague imposed on developers by the RAD designers that come with Visual
Studio. The problem with using literal strings to refer to controls, data
sources, objects, etc. and their properties is quite obvious: if any of them
are changed by hand in code, or if the programmer onadvertently removes a
letter from one of such magic strings no one will notice until the
application is run and this very piece of code gets executed most often with
unpleasant consequences (typically some type of an ugly exception).
The problem could be completely eliminated if we could use some construct
that could be verified by the compiler at compile time. In this case if a
typo occurred the project simply wouldn't build. Unfortunately, as things
stand right now there appears to be no way of doing this.
As I thought about it some more it occurred to me that the solution
shouldn't be too hard to provide. All that is needed is a new operator that
the compiler could evaluate in very much the same fashion that
typeof(ClassName) works. I would call this operator
nameof(ClassName.PropertyName) or perhaps nameof(objectName.PropertyName),
or something similar. It seems to me that the compiler has easy access to
this type of information, or else it wouldn't be able to build my code.
If such a construct existed I could rewrite this line:
new System.Windows.Forms.Binding("EditValue", someObject, "LastName", true)
to look like this
new System.Windows.Forms.Binding(nameof(myTextBox.Text ), someObject,
nameof(someObject.LastName), true)
and be entirely compile-time verifiable.
This same concept could be used not only in data binding but in many other
contexts where the designers currently stick literal strings. It could also
be implemented differently to return not just the name of the property or
method of a given class, but actually return the full descriptors that could
be used for further "reflection".
I would like to here some comments about this. Is there a technical reason
why such a construct cannot be added to the language?
Andrew
17  1890 
This sounds like an excellent idea, although your example is wrong. I
would expect
new System.Windows.Forms.Binding(nameof(myTextBox.Text ), someObject,
nameof(someObject.LastName), true);
to be equivalent to
new System.WindowsForms.Binding("Text", someObject, "LastName", true);
Perhaps you wanted the Name of myTextBox, which you can already do like
this:
new System.WindowsForms.Binding(myTextBox.Name, someObject, "LastName",
true);
However, that still doesn't help with the object property name.
I love your idea because I have lots of object-to-control bindings, and
this would be a huge help.
Have you tried putting in this suggestion at: http://lab.msdn.microsoft.com/productfeedback/
? When you do post it to the feedback site, post the feedback number
here, so that we can go and vote for it.
Jedrzej Miadowicz wrote: I recently (re)discovered data binding in Windows Forms thanks to its
advances in Visual Studio 2005. As I looked a little deeper, however, I
realize that it still suffers from an irksome tendency to stick a whole
bunch of literal strings in my code. Quite frankly, I consider them a
plague imposed on developers by the RAD designers that come with Visual
Studio. The problem with using literal strings to refer to controls, data
sources, objects, etc. and their properties is quite obvious: if any of them
are changed by hand in code, or if the programmer onadvertently removes a
letter from one of such magic strings no one will notice until the
application is run and this very piece of code gets executed most often with
unpleasant consequences (typically some type of an ugly exception).
The problem could be completely eliminated if we could use some construct
that could be verified by the compiler at compile time. In this case if a
typo occurred the project simply wouldn't build. Unfortunately, as things
stand right now there appears to be no way of doing this.
As I thought about it some more it occurred to me that the solution
shouldn't be too hard to provide. All that is needed is a new operator that
the compiler could evaluate in very much the same fashion that
typeof(ClassName) works. I would call this operator
nameof(ClassName.PropertyName) or perhaps nameof(objectName.PropertyName),
or something similar. It seems to me that the compiler has easy access to
this type of information, or else it wouldn't be able to build my code.
If such a construct existed I could rewrite this line:
new System.Windows.Forms.Binding("EditValue", someObject, "LastName", true)
to look like this
new System.Windows.Forms.Binding(nameof(myTextBox.Text ), someObject,
nameof(someObject.LastName), true)
and be entirely compile-time verifiable.
This same concept could be used not only in data binding but in many other
contexts where the designers currently stick literal strings. It could also
be implemented differently to return not just the name of the property or
method of a given class, but actually return the full descriptors that could
be used for further "reflection".
I would like to here some comments about this. Is there a technical reason
why such a construct cannot be added to the language?
Andrew
Hm... saomething tells me that you can do this using reflection... Basicly you pass a property and
you want to get it's name as a string... i'll take a look tomorrow...
MuZZy <tn*@newsgroups.nospam> wrote: Hm... saomething tells me that you can do this using reflection...
Basicly you pass a property and you want to get it's name as a
string... i'll take a look tomorrow...
No, you couldn't do that using reflection - if you pass the property to
something, it won't pass the PropertyInfo, it'll evaluate the property
and pass the *result* to whatever you're passing it to.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Jedrzej,
I think that this is a good idea. I would recommend posting it on the
product feedback center: http://lab.msdn.microsoft.com/productfeedback/
Also, I wouldn't go with a nameof operator though, I would go with
something like infoof (read "in-foof", ha).
This would return the reflection information for whatever you passed to
it. So a method would return a MethodInfo instance, a field returns a
FieldInfo instance, etc, etc.
Then, you could do:
infoof(myTextBox.Text).Name
However, there is only one problem with this. Unless there is an IL
instruction which will get the property/method/type information really quick
(like typeof, which gets a runtime type handle), this has the potential to
slow down your code.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com
"Jedrzej Miadowicz" <je****@ku.edu> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl... I recently (re)discovered data binding in Windows Forms thanks to its
advances in Visual Studio 2005. As I looked a little deeper, however, I
realize that it still suffers from an irksome tendency to stick a whole
bunch of literal strings in my code. Quite frankly, I consider them a
plague imposed on developers by the RAD designers that come with Visual
Studio. The problem with using literal strings to refer to controls, data
sources, objects, etc. and their properties is quite obvious: if any of
them are changed by hand in code, or if the programmer onadvertently
removes a letter from one of such magic strings no one will notice until
the application is run and this very piece of code gets executed most often
with unpleasant consequences (typically some type of an ugly exception).
The problem could be completely eliminated if we could use some construct
that could be verified by the compiler at compile time. In this case if a
typo occurred the project simply wouldn't build. Unfortunately, as things
stand right now there appears to be no way of doing this.
As I thought about it some more it occurred to me that the solution
shouldn't be too hard to provide. All that is needed is a new operator
that the compiler could evaluate in very much the same fashion that
typeof(ClassName) works. I would call this operator
nameof(ClassName.PropertyName) or perhaps nameof(objectName.PropertyName),
or something similar. It seems to me that the compiler has easy access to
this type of information, or else it wouldn't be able to build my code.
If such a construct existed I could rewrite this line:
new System.Windows.Forms.Binding("EditValue", someObject, "LastName",
true)
to look like this
new System.Windows.Forms.Binding(nameof(myTextBox.Text ), someObject,
nameof(someObject.LastName), true)
and be entirely compile-time verifiable.
This same concept could be used not only in data binding but in many other
contexts where the designers currently stick literal strings. It could
also be implemented differently to return not just the name of the
property or method of a given class, but actually return the full
descriptors that could be used for further "reflection".
I would like to here some comments about this. Is there a technical
reason why such a construct cannot be added to the language?
Andrew
You're right. I copied and pasted something and then tried to simplify it
and forgot to do so in one place.
"Bruce Wood" <br*******@canada.com> wrote in message
news:11*********************@g49g2000cwa.googlegro ups.com... This sounds like an excellent idea, although your example is wrong. I
would expect
new System.Windows.Forms.Binding(nameof(myTextBox.Text ), someObject,
nameof(someObject.LastName), true);
to be equivalent to
new System.WindowsForms.Binding("Text", someObject, "LastName", true);
Perhaps you wanted the Name of myTextBox, which you can already do like
this:
new System.WindowsForms.Binding(myTextBox.Name, someObject, "LastName",
true);
However, that still doesn't help with the object property name.
I love your idea because I have lots of object-to-control bindings, and
this would be a huge help.
Have you tried putting in this suggestion at:
http://lab.msdn.microsoft.com/productfeedback/
? When you do post it to the feedback site, post the feedback number
here, so that we can go and vote for it.
That's exactly the problem. Reflection suffers from an annoying chicken and
egg issue in that you can't find the name (or any other aspect) of a
property (or method) without knowing the name of that property in the form
of a string at runtime. What I'm referring to here is that there is no way
to get from MyClass.MyProperty to "MyProperty" other than by the developer
typing the latter by hand which is error prone. You can do it for a class
by using typeof(MyClass) and then you can find out anything you want about
the class. You can even find out about all of its properties (and methods,
and attributes, etc.) but there is no way to find out about the details of a
specific property you are interested in, unless you know its name (as in
"MyProperty") or perhaps its position in the collection of all the
properties of the class. Hard coding either one of them by hand is
dangerous. Hence, my suggestion.
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... MuZZy <tn*@newsgroups.nospam> wrote: Hm... saomething tells me that you can do this using reflection...
Basicly you pass a property and you want to get it's name as a
string... i'll take a look tomorrow...
No, you couldn't do that using reflection - if you pass the property to
something, it won't pass the PropertyInfo, it'll evaluate the property
and pass the *result* to whatever you're passing it to.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Thanks for the suggestion. I'll make sure I post it on the feedback site.
As to whether this could be done and what performance penalty it could
incur, here's how I see it. It would be nice to get to the whole MethodInfo
or PropertyInfo instance by using this new operator. Incidentally, that's
what I meant when I mentioned property descriptors in my original post. I'm
not sure at which point these objects are created (whether it's at runtime
or compile time), but I would think they would need to begin their existence
at the same time that the class info objects are instantiated. If that's
the case the performance of the in-foof (I like the name in this form ;-))
should be no worse than that of typeof.
The whole thing could, however, be much simpler if only the name of the said
property was required. It would give the developer the same power given
that he/she could just go in with this name and use reflection to find out
anything else they need about the property. The code would be longer to do
so, but it's possible. Now, the benefit of this approach would be that if
you only needed a name (which I believe would be the most common usage) you
could get the best performance out of it. In fact, in this case the
operator could be resolved strictly at the pre-processing stage of the
compilation process (if I remember my compilers class from many years ago).
The compiler would simply need to replace nameof(MyClass.MyProperty) with
"MyProperty". It's all out there spelled out for it, and it knows what the
token MyClass.MyProperty stands for, and it fact it generates the property
info for that property into which it sticks the string "MyProperty" as the
name. Thus it could simply substitute that name for the
nameof(MyClass.MyProperty) and the deal is done. And I as a programmer
don't have to worry about typos, property name changes, etc. ever again!
Andrew
"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote in
message news:eL**************@TK2MSFTNGP12.phx.gbl... Jedrzej,
I think that this is a good idea. I would recommend posting it on the
product feedback center:
http://lab.msdn.microsoft.com/productfeedback/
Also, I wouldn't go with a nameof operator though, I would go with
something like infoof (read "in-foof", ha).
This would return the reflection information for whatever you passed to
it. So a method would return a MethodInfo instance, a field returns a
FieldInfo instance, etc, etc.
Then, you could do:
infoof(myTextBox.Text).Name
However, there is only one problem with this. Unless there is an IL
instruction which will get the property/method/type information really
quick (like typeof, which gets a runtime type handle), this has the
potential to slow down your code.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com
"Jedrzej Miadowicz" <je****@ku.edu> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...I recently (re)discovered data binding in Windows Forms thanks to its
advances in Visual Studio 2005. As I looked a little deeper, however, I
realize that it still suffers from an irksome tendency to stick a whole
bunch of literal strings in my code. Quite frankly, I consider them a
plague imposed on developers by the RAD designers that come with Visual
Studio. The problem with using literal strings to refer to controls, data
sources, objects, etc. and their properties is quite obvious: if any of
them are changed by hand in code, or if the programmer onadvertently
removes a letter from one of such magic strings no one will notice until
the application is run and this very piece of code gets executed most
often with unpleasant consequences (typically some type of an ugly
exception).
The problem could be completely eliminated if we could use some construct
that could be verified by the compiler at compile time. In this case if
a typo occurred the project simply wouldn't build. Unfortunately, as
things stand right now there appears to be no way of doing this.
As I thought about it some more it occurred to me that the solution
shouldn't be too hard to provide. All that is needed is a new operator
that the compiler could evaluate in very much the same fashion that
typeof(ClassName) works. I would call this operator
nameof(ClassName.PropertyName) or perhaps
nameof(objectName.PropertyName), or something similar. It seems to me
that the compiler has easy access to this type of information, or else it
wouldn't be able to build my code.
If such a construct existed I could rewrite this line:
new System.Windows.Forms.Binding("EditValue", someObject, "LastName",
true)
to look like this
new System.Windows.Forms.Binding(nameof(myTextBox.Text ), someObject,
nameof(someObject.LastName), true)
and be entirely compile-time verifiable.
This same concept could be used not only in data binding but in many
other contexts where the designers currently stick literal strings. It
could also be implemented differently to return not just the name of the
property or method of a given class, but actually return the full
descriptors that could be used for further "reflection".
I would like to here some comments about this. Is there a technical
reason why such a construct cannot be added to the language?
Andrew
I went to MSDN feedback with the intention to add my suggestion but I
did the mandatory search I found the following suggestion (FDBK19141)
that pretty much mirrors mine. It was made over a year ago, and much
to my surprise, it was simply dismissed as not significant enough by
Microsoft. I find this rather ignorant, as this could greatly improve
the robustness of the code we all create. I will try to vote for this
suggestions even though it's closed. I will also post a new suggestion
and hope for a different outcome. I'll let you all know when it's in
and what it's number is.
Andrew
Here is the feedback ID for the one I just submitted: FDBK43926. I
found some other items that are somewhat related as well. If you like
this idea maybe you could drop in a vote.
Thanks.
Andrew
I voted in favour, although I prefer that nameof() return the simple
property / method / class name as a string. This would make the feature
free at runtime: the compiler simply substitutes a string for the
nameof(...). You can always get Reflection info if you want it:
myObject.GetType().GetProperty(nameof(myObject.Pro pertyName))
for example. However, if you're doing binding, where you don't need
Reflection info at all, you get more maintainable code for no runtime
penalty at all.
>I voted in favour, although I prefer that nameof() return the simple property / method / class name as a string.
I agree, and I see some problems with the infoof Nick suggested that a
simple nameof wouldn't have.
First, I would expect it to work on all identifiers in the C# code
even if the name gets lost in the compilation process. The prime
example is local variables that don't have their names in metadata,
only in the debug symbols (and hence LocalVariableInfo doesn't have a
Name property).
Second, if the operator returns a MethodInfo for methods you would
somehow have to specify which overload you wanted if there's more than
one. And I would hate it if I had to write something like
infoof(MyMethod(int, string, bool)).Name just to get the string
"MyMethod".
Mattias
--
Mattias Sjögren [C# MVP] mattias @ mvps.org http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup. an**************@gmail.com wrote: Here is the feedback ID for the one I just submitted: FDBK43926. I
found some other items that are somewhat related as well. If you like
this idea maybe you could drop in a vote.
They have resolved it as duplicate, but the duplicate has nothing to do
with infoof/nameof. This feature is really important! I actually don't
use data binding and stay away from reflection wherever possible because
of that. I don't get why they still don't have anything like that even
in the C# 3.0 specs!
I'll have the whole team vote for this.. but what feedback ID should we
agree to vote on? Yours has been resolved, so voting on it is not
possible anymore!
Max
Here is what I propose.
There are currently three feedback suggestions that pertain to this problem.
One is the original post that request exactly the nameof() operator in a
clear and succint way (FDBK19141). There is the one that TAG refers to as
the duplicate of mine, but which is quite convoluted and starts of talking
about default values of attributes (FDBK20362). And finally, there is my
new post (FDBK43926).
I believe we can vote even on closed suggestions, but I did notice that once
they changed the status of my suggestion all the previous votes disappeared.
I suggest we drop our votes on all three of these suggestions, and also post
comments to all of them indicating clearly what it is that we want.
Comments seem to always be open and persist even if the status is closed or
otherwise changes.
My feeling is that Microsoft is evaluating a very broad (and complex) scheme
of providing any reflection information via some form of operator (or
operators) which may prove difficult to implement or use. I think they
should focus it more narrowly first, while giving the broader scope some
consideration. But I would hate to see the nameof() be dropped because the
all-reflection-info-of() proved to be to difficult to do.
Help me out.
Thanks,
Andrew
"Markus Stoeger" <sp******@gmx.at> wrote in message
news:%2****************@TK2MSFTNGP14.phx.gbl... an**************@gmail.com wrote: Here is the feedback ID for the one I just submitted: FDBK43926. I
found some other items that are somewhat related as well. If you like
this idea maybe you could drop in a vote.
They have resolved it as duplicate, but the duplicate has nothing to do
with infoof/nameof. This feature is really important! I actually don't use
data binding and stay away from reflection wherever possible because of
that. I don't get why they still don't have anything like that even in the
C# 3.0 specs!
I'll have the whole team vote for this.. but what feedback ID should we
agree to vote on? Yours has been resolved, so voting on it is not possible
anymore!
Max
If you try and vote on your new entry, you are automatically redirected to
FDBK22652 which is now showing as re-opened.
I for one have voted with a 5 as I think this would be a major enhancement
for any developer.
"Jedrzej Miadowicz" <je****@ku.edu> wrote in message
news:%2****************@TK2MSFTNGP14.phx.gbl... Here is what I propose.
There are currently three feedback suggestions that pertain to this
problem. One is the original post that request exactly the nameof()
operator in a clear and succint way (FDBK19141). There is the one that
TAG refers to as the duplicate of mine, but which is quite convoluted and
starts of talking about default values of attributes (FDBK20362). And
finally, there is my new post (FDBK43926).
I believe we can vote even on closed suggestions, but I did notice that
once they changed the status of my suggestion all the previous votes
disappeared. I suggest we drop our votes on all three of these
suggestions, and also post comments to all of them indicating clearly what
it is that we want. Comments seem to always be open and persist even if
the status is closed or otherwise changes.
My feeling is that Microsoft is evaluating a very broad (and complex)
scheme of providing any reflection information via some form of operator
(or operators) which may prove difficult to implement or use. I think
they should focus it more narrowly first, while giving the broader scope
some consideration. But I would hate to see the nameof() be dropped
because the all-reflection-info-of() proved to be to difficult to do.
Help me out.
Thanks,
Andrew
"Markus Stoeger" <sp******@gmx.at> wrote in message
news:%2****************@TK2MSFTNGP14.phx.gbl... an**************@gmail.com wrote: Here is the feedback ID for the one I just submitted: FDBK43926. I
found some other items that are somewhat related as well. If you like
this idea maybe you could drop in a vote.
They have resolved it as duplicate, but the duplicate has nothing to do
with infoof/nameof. This feature is really important! I actually don't
use data binding and stay away from reflection wherever possible because
of that. I don't get why they still don't have anything like that even in
the C# 3.0 specs!
I'll have the whole team vote for this.. but what feedback ID should we
agree to vote on? Yours has been resolved, so voting on it is not
possible anymore!
Max
Jedrzej Miadowicz wrote: Here is what I propose.
There are currently three feedback suggestions that pertain to this problem.
One is the original post that request exactly the nameof() operator in a
clear and succint way (FDBK19141). There is the one that TAG refers to as
the duplicate of mine, but which is quite convoluted and starts of talking
about default values of attributes (FDBK20362). And finally, there is my
new post (FDBK43926).
I believe we can vote even on closed suggestions, but I did notice that once
they changed the status of my suggestion all the previous votes disappeared.
I suggest we drop our votes on all three of these suggestions, and also post
comments to all of them indicating clearly what it is that we want.
Comments seem to always be open and persist even if the status is closed or
otherwise changes.
I left a comment on FDBK22652 (yours is listed a duplicate of that) and
voted for both FDBK22652 and FDBK19141 with a 5. I know my colleagues
also want something like nameof() since a long time too, I'll get their
votes on monday.
Max
FDBK43926 has been re-opened!
I have voted for this also (with a 5)
I suggest everybody else votes as well in order to get this on the list.
"Jedrzej Miadowicz" <je****@ku.edu> wrote in message
news:%2****************@TK2MSFTNGP14.phx.gbl... Here is what I propose.
There are currently three feedback suggestions that pertain to this
problem. One is the original post that request exactly the nameof()
operator in a clear and succint way (FDBK19141). There is the one that
TAG refers to as the duplicate of mine, but which is quite convoluted and
starts of talking about default values of attributes (FDBK20362). And
finally, there is my new post (FDBK43926).
I believe we can vote even on closed suggestions, but I did notice that
once they changed the status of my suggestion all the previous votes
disappeared. I suggest we drop our votes on all three of these
suggestions, and also post comments to all of them indicating clearly what
it is that we want. Comments seem to always be open and persist even if
the status is closed or otherwise changes.
My feeling is that Microsoft is evaluating a very broad (and complex)
scheme of providing any reflection information via some form of operator
(or operators) which may prove difficult to implement or use. I think
they should focus it more narrowly first, while giving the broader scope
some consideration. But I would hate to see the nameof() be dropped
because the all-reflection-info-of() proved to be to difficult to do.
Help me out.
Thanks,
Andrew
"Markus Stoeger" <sp******@gmx.at> wrote in message
news:%2****************@TK2MSFTNGP14.phx.gbl... an**************@gmail.com wrote: Here is the feedback ID for the one I just submitted: FDBK43926. I
found some other items that are somewhat related as well. If you like
this idea maybe you could drop in a vote.
They have resolved it as duplicate, but the duplicate has nothing to do
with infoof/nameof. This feature is really important! I actually don't
use data binding and stay away from reflection wherever possible because
of that. I don't get why they still don't have anything like that even in
the C# 3.0 specs!
I'll have the whole team vote for this.. but what feedback ID should we
agree to vote on? Yours has been resolved, so voting on it is not
possible anymore!
Max
"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote in
message news:eL**************@TK2MSFTNGP12.phx.gbl... Also, I wouldn't go with a nameof operator though, I would go with
something like infoof (read "in-foof", ha).
Calling it nameof() wouldn't be without precedent however, eg
System.Reflection.AssemblyName has a lot more than an assembly's name.
infoof() seems a little "foofy" to me... :-)
-- Alan This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: shank |
last post by:
1) I'm getting this error: Syntax error (missing operator) in query
expression on the below statement. Can I get some advice.
2) I searched ASPFAQ and came up blank. Where can find the "rules"...
|
by: Paul Davis |
last post by:
I'd like to overload 'comma' to define a concatenation operator for
integer-like classes. I've got some first ideas, but I'd appreciate a
sanity check. The concatenation operator needs to so...
|
by: Frank Natoli |
last post by:
Have two tables "abc" and "xyz", where "xyz" is a superset, column-wise, of
"abc".
Is there any simple way to inject all the rows of "abc" into "xyz"?
Tried "insert into xyz select * from abc"...
|
by: Tim Clacy |
last post by:
Please illuminate; what operator of class 'Event' will get matched for these
two cases :
Event ev1;
Event ev2;
// Case 1
//
if (ev1)
;
|
by: gugdias |
last post by:
I'm coding a simple matrix class, which is resulting in the following
error when compiling with g++ 3.4.2 (mingw-special):
* declaration of `operator/' as non-function
* expected `;' before '<'...
|
by: sandeep chandra |
last post by:
Hey guys, I am new to this group.. i never know wot s going on in this
group.. but wot made be brought here is cpp.. guys am currently a
part of onw reaserch ... am new to everything.. i...
|
by: palo |
last post by:
I appologize for suggesting (though very humbly) a syntax extension
(maybe particularly idiotic) but just as a wild fantasy, what would you
think about this:
as a substitute for filter, people...
|
by: bisuvious |
last post by:
hello C++ gurus,
I am having a problem and want help fom you.
Here is my problem-------------
I am designing a class for matrix which dynamically creates a 2d array
to hold data and have its...
|
by: =?utf-8?B?5Zyw55CD5Y+R5Yqo5py6?= |
last post by:
In C++ we can not overload the explicit typecast operator like
static_cast, dynamic_cast, const_cast and reinterpret_cast. The only
we can do is the implicit typecast operator like operator...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
| |
