When setting the [Flags] attribute on an enum, why should I have to specify
powers of 2 when the compiler should see this is a bitfield and set the
range accordingly, why should I have to do the work that the compiler can
do?
To me this is just asking for errors to be introduced by offloading this
responsibility onto the programmer.
Sure we should be able to override a value in the bitfield enum to allow
ranges like All = Enum1Val | Enum2Val; etc.
16  890 
To me, the automatic compiler support is asking for errors. If you reorder
your enum, you break their values, e.g. an enum saved to a file (before the
reordering), won't be read properly (after the reordering). If you are too
lazy to set bit masks, you can always define enums in this way:
[Flags]
public enum Whatever
{
None = 0,
Flag1 = 1,
Flag2 = Flag1 << 1,
Flag3 = Flag2 << 1,
// etc.
CheckMask = Flag1 | ... | FlagN
}
Cheers,
Stoyan
"Mr.Tickle" <Mr******@mrmen.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl... When setting the [Flags] attribute on an enum, why should I have to
specify powers of 2 when the compiler should see this is a bitfield and set the
range accordingly, why should I have to do the work that the compiler can
do?
To me this is just asking for errors to be introduced by offloading this
responsibility onto the programmer.
Sure we should be able to override a value in the bitfield enum to allow
ranges like All = Enum1Val | Enum2Val; etc.
Well, we have already automatic support for enums, its overridable, so why
not have it consistant to that of non Flag enums?
If we are lazy? Enums currently (for non bitmasks) are already defined.
Youre lazy argument falls flat on its face.
"Stoyan Damov" <st*****@code.bg> wrote in message
news:eN**************@TK2MSFTNGP11.phx.gbl... To me, the automatic compiler support is asking for errors. If you reorder
your enum, you break their values, e.g. an enum saved to a file (before
the reordering), won't be read properly (after the reordering). If you are too
lazy to set bit masks, you can always define enums in this way:
[Flags]
public enum Whatever
{
None = 0,
Flag1 = 1,
Flag2 = Flag1 << 1,
Flag3 = Flag2 << 1,
// etc.
CheckMask = Flag1 | ... | FlagN
}
Cheers,
Stoyan
"Mr.Tickle" <Mr******@mrmen.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl... When setting the [Flags] attribute on an enum, why should I have to
specify powers of 2 when the compiler should see this is a bitfield and set the
range accordingly, why should I have to do the work that the compiler
can do?
To me this is just asking for errors to be introduced by offloading this
responsibility onto the programmer.
Sure we should be able to override a value in the bitfield enum to allow
ranges like All = Enum1Val | Enum2Val; etc.
I couldn't understand anything. Sorry if I have offended you in any way.
Cheers,
Stoyan
"Mr.Tickle" <Mr******@mrmen.com> wrote in message
news:ub*************@TK2MSFTNGP10.phx.gbl... Well, we have already automatic support for enums, its overridable, so why
not have it consistant to that of non Flag enums?
If we are lazy? Enums currently (for non bitmasks) are already defined.
Youre lazy argument falls flat on its face.
"Stoyan Damov" <st*****@code.bg> wrote in message
news:eN**************@TK2MSFTNGP11.phx.gbl... To me, the automatic compiler support is asking for errors. If you
reorder your enum, you break their values, e.g. an enum saved to a file (before
the reordering), won't be read properly (after the reordering). If you are
too lazy to set bit masks, you can always define enums in this way:
[Flags]
public enum Whatever
{
None = 0,
Flag1 = 1,
Flag2 = Flag1 << 1,
Flag3 = Flag2 << 1,
// etc.
CheckMask = Flag1 | ... | FlagN
}
Cheers,
Stoyan
"Mr.Tickle" <Mr******@mrmen.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl... When setting the [Flags] attribute on an enum, why should I have to
specify powers of 2 when the compiler should see this is a bitfield and set
the range accordingly, why should I have to do the work that the compiler
can do?
To me this is just asking for errors to be introduced by offloading
this responsibility onto the programmer.
Sure we should be able to override a value in the bitfield enum to
allow ranges like All = Enum1Val | Enum2Val; etc.
Simple. Enums are currently automatic, except they are AUTOMATIC INCORRECTLY
when FLAGS attribute is set.
Its INCORRECT behaviour for the Flags attribute. Since when is a bitfield
automaticly set to 1, 2, 3, 4, 5`?? Thats what it does.
What I am asking is if we can have it automatically set to 1, 2, 4, 8, 16...
CORRECTLY.
"Stoyan Damov" <st*****@code.bg> wrote in message
news:e8**************@TK2MSFTNGP12.phx.gbl... I couldn't understand anything. Sorry if I have offended you in any way.
Cheers,
Stoyan
"Mr.Tickle" <Mr******@mrmen.com> wrote in message
news:ub*************@TK2MSFTNGP10.phx.gbl... Well, we have already automatic support for enums, its overridable, so
why not have it consistant to that of non Flag enums?
If we are lazy? Enums currently (for non bitmasks) are already defined.
Youre lazy argument falls flat on its face.
"Stoyan Damov" <st*****@code.bg> wrote in message
news:eN**************@TK2MSFTNGP11.phx.gbl... To me, the automatic compiler support is asking for errors. If you reorder your enum, you break their values, e.g. an enum saved to a file
(before the reordering), won't be read properly (after the reordering). If you are too lazy to set bit masks, you can always define enums in this way:
[Flags]
public enum Whatever
{
None = 0,
Flag1 = 1,
Flag2 = Flag1 << 1,
Flag3 = Flag2 << 1,
// etc.
CheckMask = Flag1 | ... | FlagN
}
Cheers,
Stoyan
"Mr.Tickle" <Mr******@mrmen.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...
> When setting the [Flags] attribute on an enum, why should I have to
specify
> powers of 2 when the compiler should see this is a bitfield and set the > range accordingly, why should I have to do the work that the
compiler can > do?
>
>
> To me this is just asking for errors to be introduced by offloading
this > responsibility onto the programmer.
>
> Sure we should be able to override a value in the bitfield enum to allow > ranges like All = Enum1Val | Enum2Val; etc.
>
>
>
It's fairly common for people to define values that are combinations of the
others:
enum Test
{
First = 0x01,
Second = 0x02,
AllBits = 0x03,
NoBits = 0x00,
}
--
Eric Gunnerson
Visit the C# product team at http://www.csharp.net
Eric's blog is at http://blogs.gotdotnet.com/ericgu/
This posting is provided "AS IS" with no warranties, and confers no rights.
"Mr.Tickle" <Mr******@mrmen.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl... When setting the [Flags] attribute on an enum, why should I have to
specify powers of 2 when the compiler should see this is a bitfield and set the
range accordingly, why should I have to do the work that the compiler can
do?
To me this is just asking for errors to be introduced by offloading this
responsibility onto the programmer.
Sure we should be able to override a value in the bitfield enum to allow
ranges like All = Enum1Val | Enum2Val; etc.
So if we just say
[Flags]
enum Test
{
First,
Second,
Third,
Fourth
}
Guess what the compiler generates?
First = 0, Second = 1 , Third = 2, Fourth = 3
So thats correct behaviour for a Flag? Dont make me laugh.
"Eric Gunnerson [MS]" <er****@online.microsoft.com> wrote in message
news:OB**************@TK2MSFTNGP09.phx.gbl... It's fairly common for people to define values that are combinations of
the others:
enum Test
{
First = 0x01,
Second = 0x02,
AllBits = 0x03,
NoBits = 0x00,
}
--
Eric Gunnerson
Visit the C# product team at http://www.csharp.net
Eric's blog is at http://blogs.gotdotnet.com/ericgu/
This posting is provided "AS IS" with no warranties, and confers no
rights. "Mr.Tickle" <Mr******@mrmen.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl... When setting the [Flags] attribute on an enum, why should I have to
specify powers of 2 when the compiler should see this is a bitfield and set the
range accordingly, why should I have to do the work that the compiler
can do?
To me this is just asking for errors to be introduced by offloading this
responsibility onto the programmer.
Sure we should be able to override a value in the bitfield enum to allow
ranges like All = Enum1Val | Enum2Val; etc.
On Tue, 14 Oct 2003 08:35:03 +0200, "Mr.Tickle" <Mr******@mrmen.com>
wrote: So if we just say
[Flags]
enum Test
{
First,
Second,
Third,
Fourth
}
Guess what the compiler generates?
First = 0, Second = 1 , Third = 2, Fourth = 3
So thats correct behaviour for a Flag? Dont make me laugh.
"Eric Gunnerson [MS]" <er****@online.microsoft.com> wrote in message
news:OB**************@TK2MSFTNGP09.phx.gbl... It's fairly common for people to define values that are combinations of
the others:
enum Test
{
First = 0x01,
Second = 0x02,
AllBits = 0x03,
NoBits = 0x00,
}
--
Eric Gunnerson
Visit the C# product team at http://www.csharp.net
Eric's blog is at http://blogs.gotdotnet.com/ericgu/
This posting is provided "AS IS" with no warranties, and confers no
rights. "Mr.Tickle" <Mr******@mrmen.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl... > When setting the [Flags] attribute on an enum, why should I have to
specify > powers of 2 when the compiler should see this is a bitfield and set the
> range accordingly, why should I have to do the work that the compilercan > do?
>
>
> To me this is just asking for errors to be introduced by offloading this
> responsibility onto the programmer.
>
> Sure we should be able to override a value in the bitfield enum to allow
> ranges like All = Enum1Val | Enum2Val; etc.
>
>
>
Idiot
On Mon, 13 Oct 2003 18:18:39 +0200, "Mr.Tickle" <Mr******@mrmen.com>
wrote: Simple. Enums are currently automatic, except they are AUTOMATIC INCORRECTLY
when FLAGS attribute is set.
Its INCORRECT behaviour for the Flags attribute. Since when is a bitfield
automaticly set to 1, 2, 3, 4, 5`?? Thats what it does.
What I am asking is if we can have it automatically set to 1, 2, 4, 8, 16...
CORRECTLY.
"Stoyan Damov" <st*****@code.bg> wrote in message
news:e8**************@TK2MSFTNGP12.phx.gbl... I couldn't understand anything. Sorry if I have offended you in any way.
Cheers,
Stoyan
"Mr.Tickle" <Mr******@mrmen.com> wrote in message
news:ub*************@TK2MSFTNGP10.phx.gbl... > Well, we have already automatic support for enums, its overridable, sowhy > not have it consistant to that of non Flag enums?
>
> If we are lazy? Enums currently (for non bitmasks) are already defined.
> Youre lazy argument falls flat on its face.
>
>
>
> "Stoyan Damov" <st*****@code.bg> wrote in message
> news:eN**************@TK2MSFTNGP11.phx.gbl...
> > To me, the automatic compiler support is asking for errors. If you
reorder > > your enum, you break their values, e.g. an enum saved to a file(before > the
> > reordering), won't be read properly (after the reordering). If you are
too > > lazy to set bit masks, you can always define enums in this way:
> >
> > [Flags]
> > public enum Whatever
> > {
> > None = 0,
> > Flag1 = 1,
> > Flag2 = Flag1 << 1,
> > Flag3 = Flag2 << 1,
> > // etc.
> > CheckMask = Flag1 | ... | FlagN
> > }
> >
> > Cheers,
> > Stoyan
> >
> > "Mr.Tickle" <Mr******@mrmen.com> wrote in message
> > news:%2****************@tk2msftngp13.phx.gbl...
> > > When setting the [Flags] attribute on an enum, why should I have to
> > specify
> > > powers of 2 when the compiler should see this is a bitfield and set
the > > > range accordingly, why should I have to do the work that thecompiler > can
> > > do?
> > >
> > >
> > > To me this is just asking for errors to be introduced by offloading
this > > > responsibility onto the programmer.
> > >
> > > Sure we should be able to override a value in the bitfield enum to
allow > > > ranges like All = Enum1Val | Enum2Val; etc.
> > >
> > >
> > >
> >
> >
>
>
Idiot
yankstain
"ozbear" <oz****@no.bigpond.spam.com> wrote in message
news:3f8bc8cc.191775406@news-server... On Mon, 13 Oct 2003 18:18:39 +0200, "Mr.Tickle" <Mr******@mrmen.com>
wrote:
Simple. Enums are currently automatic, except they are AUTOMATIC
INCORRECTLYwhen FLAGS attribute is set.
Its INCORRECT behaviour for the Flags attribute. Since when is a bitfield
automaticly set to 1, 2, 3, 4, 5`?? Thats what it does.
What I am asking is if we can have it automatically set to 1, 2, 4, 8,
16...CORRECTLY.
"Stoyan Damov" <st*****@code.bg> wrote in message
news:e8**************@TK2MSFTNGP12.phx.gbl... I couldn't understand anything. Sorry if I have offended you in any
way.
Cheers,
Stoyan
"Mr.Tickle" <Mr******@mrmen.com> wrote in message
news:ub*************@TK2MSFTNGP10.phx.gbl...
> Well, we have already automatic support for enums, its overridable,
sowhy > not have it consistant to that of non Flag enums?
>
> If we are lazy? Enums currently (for non bitmasks) are already
defined. > Youre lazy argument falls flat on its face.
>
>
>
> "Stoyan Damov" <st*****@code.bg> wrote in message
> news:eN**************@TK2MSFTNGP11.phx.gbl...
> > To me, the automatic compiler support is asking for errors. If you
reorder
> > your enum, you break their values, e.g. an enum saved to a file
(before > the
> > reordering), won't be read properly (after the reordering). If you
are too
> > lazy to set bit masks, you can always define enums in this way:
> >
> > [Flags]
> > public enum Whatever
> > {
> > None = 0,
> > Flag1 = 1,
> > Flag2 = Flag1 << 1,
> > Flag3 = Flag2 << 1,
> > // etc.
> > CheckMask = Flag1 | ... | FlagN
> > }
> >
> > Cheers,
> > Stoyan
> >
> > "Mr.Tickle" <Mr******@mrmen.com> wrote in message
> > news:%2****************@tk2msftngp13.phx.gbl...
> > > When setting the [Flags] attribute on an enum, why should I have
to > > specify
> > > powers of 2 when the compiler should see this is a bitfield and
set the
> > > range accordingly, why should I have to do the work that the
compiler > can
> > > do?
> > >
> > >
> > > To me this is just asking for errors to be introduced by
offloading this
> > > responsibility onto the programmer.
> > >
> > > Sure we should be able to override a value in the bitfield enum
to allow
> > > ranges like All = Enum1Val | Enum2Val; etc.
> > >
> > >
> > >
> >
> >
>
>
Idiot
On Mon, 13 Oct 2003 15:35:46 -0700, "Eric Gunnerson [MS]"
<er****@online.microsoft.com> wrote: It's fairly common for people to define values that are combinations of the
others:
enum Test
{
First = 0x01,
Second = 0x02,
AllBits = 0x03,
NoBits = 0x00,
}
--
Eric Gunnerson
The documentation does seem to be incorrect. I am using the 1.1
framework, if that matters, and given the declaration:
enum answer {yes, no maybe};
i can declare a variable of type -answer- and use the C# OR
operator...
answer test = answer.yes | answer.no;
According to the doco, I need the [Flags] attribute applied to my
-answer- enumeration, yet the C# compiler accepts the above test =
assignment without complaint. In other words...the presence or
absence of [Flags] makes no difference to the /assignment/.
I accept that it will affect other things like ToString(), etc.
Oz
The compiler generates 0, 1, 2, 3, 4, 5, 6 which is NOT bitfield values in
powers of 2, even the flags attributem, thats the issue, its INCORRECT
values by default, sure people set them but its INCORRECT otherwise, so go
ahead and act the egotistical yankstain and ship incorrect products.
I just laugh at thee errors. Im on the other side of the wall dont forget
and will abuse those errors.
"ozbear" <oz****@no.bigpond.spam.com> wrote in message
news:3f8bc8f2.191812953@news-server... On Mon, 13 Oct 2003 15:35:46 -0700, "Eric Gunnerson [MS]"
<er****@online.microsoft.com> wrote:
It's fairly common for people to define values that are combinations of
theothers:
enum Test
{
First = 0x01,
Second = 0x02,
AllBits = 0x03,
NoBits = 0x00,
}
--
Eric Gunnerson
The documentation does seem to be incorrect. I am using the 1.1
framework, if that matters, and given the declaration:
enum answer {yes, no maybe};
i can declare a variable of type -answer- and use the C# OR
operator...
answer test = answer.yes | answer.no;
According to the doco, I need the [Flags] attribute applied to my
-answer- enumeration, yet the C# compiler accepts the above test =
assignment without complaint. In other words...the presence or
absence of [Flags] makes no difference to the /assignment/.
I accept that it will affect other things like ToString(), etc.
Oz
ozbear <oz****@no.bigpond.spam.com> wrote: The documentation does seem to be incorrect. I am using the 1.1
framework, if that matters, and given the declaration:
enum answer {yes, no maybe};
i can declare a variable of type -answer- and use the C# OR
operator...
answer test = answer.yes | answer.no;
According to the doco, I need the [Flags] attribute applied to my
-answer- enumeration, yet the C# compiler accepts the above test =
assignment without complaint. In other words...the presence or
absence of [Flags] makes no difference to the /assignment/.
I accept that it will affect other things like ToString(), etc.
It should work as per the above according to sectino 14.10.2 of the
ECMA spec.
The documentation you were talking about is the FlagsAttribute remarks,
presumably? If so, it's quite an interesting case - it's up to a
language to decide what it allows, so I don't think the FlagAttribute
documentation should really be talking about that at all. What it
could/should be talking about is that when [Flags] is applied, bitwise
operations are *expected* to give useful results (whereas they may not
otherwise). A language *could* decide to only allow bitwise operations
on enumerations which are marked with the [Flags] attribute, of course.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
[Flags]
enum bitfield
{
one,
two,
three,
four,
five,
six,
all = one | two | three | four | five | six
}
man thats gonna throw up some interesting results, thanks to Eric
Gunnarson's ignorance.
Three cheers for da man that supports bad code like the above. Bitfields
should be set to the base of the machine, ie powers of 2, you dumbschmuck.
Flags in reality does jack all, except permit logical operators on enums, so
lets look the other way when it comes to the above and yet claim from the
rooftops that C# is da biz for safe coding, well it aint in the above case.
"Eric Gunnerson [MS]" <er****@online.microsoft.com> wrote in message
news:OB**************@TK2MSFTNGP09.phx.gbl... It's fairly common for people to define values that are combinations of
the others:
enum Test
{
First = 0x01,
Second = 0x02,
AllBits = 0x03,
NoBits = 0x00,
}
--
Eric Gunnerson
Visit the C# product team at http://www.csharp.net
Eric's blog is at http://blogs.gotdotnet.com/ericgu/
This posting is provided "AS IS" with no warranties, and confers no
rights. "Mr.Tickle" <Mr******@mrmen.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl... When setting the [Flags] attribute on an enum, why should I have to
specify powers of 2 when the compiler should see this is a bitfield and set the
range accordingly, why should I have to do the work that the compiler
can do?
To me this is just asking for errors to be introduced by offloading this
responsibility onto the programmer.
Sure we should be able to override a value in the bitfield enum to allow
ranges like All = Enum1Val | Enum2Val; etc.
I would like to see you attempt an & operator on those values ROFL
Assuming it starts at 0 for bitfield.one. What if I want to pick off the
value bitfield.four? Im screwed.
Sure sure go ahead, say "but you have to set them all in powers of 2
yourself", well what if i dont want to and just want the following
[Flags]
enum bitfield
{
None = 0,
one,
two,
three,
four,
five,
six,
all = one | two | three | four | five | six
}
Well the above SHOULD work, but it doesnt because you DEFAULT to non base 2
values.
Take yer cranium from yer rectum ye ninney.
"Mr.Tickle" <Mr******@mrmen.com> wrote in message
news:OJ**************@TK2MSFTNGP10.phx.gbl... [Flags]
enum bitfield
{
one,
two,
three,
four,
five,
six,
all = one | two | three | four | five | six
}
man thats gonna throw up some interesting results, thanks to Eric
Gunnarson's ignorance.
Three cheers for da man that supports bad code like the above. Bitfields
should be set to the base of the machine, ie powers of 2, you dumbschmuck.
Flags in reality does jack all, except permit logical operators on enums,
so lets look the other way when it comes to the above and yet claim from the
rooftops that C# is da biz for safe coding, well it aint in the above
case.
"Eric Gunnerson [MS]" <er****@online.microsoft.com> wrote in message
news:OB**************@TK2MSFTNGP09.phx.gbl... It's fairly common for people to define values that are combinations of
the others:
enum Test
{
First = 0x01,
Second = 0x02,
AllBits = 0x03,
NoBits = 0x00,
}
--
Eric Gunnerson
Visit the C# product team at http://www.csharp.net
Eric's blog is at http://blogs.gotdotnet.com/ericgu/
This posting is provided "AS IS" with no warranties, and confers no
rights. "Mr.Tickle" <Mr******@mrmen.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl... When setting the [Flags] attribute on an enum, why should I have to
specify powers of 2 when the compiler should see this is a bitfield and set
the range accordingly, why should I have to do the work that the compiler can do?
To me this is just asking for errors to be introduced by offloading
this responsibility onto the programmer.
Sure we should be able to override a value in the bitfield enum to
allow ranges like All = Enum1Val | Enum2Val; etc.
On Tue, 14 Oct 2003 11:11:25 +0100, Jon Skeet [C# MVP]
<sk***@pobox.com> wrote: ozbear <oz****@no.bigpond.spam.com> wrote: The documentation does seem to be incorrect. I am using the 1.1
framework, if that matters, and given the declaration:
enum answer {yes, no maybe};
i can declare a variable of type -answer- and use the C# OR
operator...
answer test = answer.yes | answer.no;
According to the doco, I need the [Flags] attribute applied to my
-answer- enumeration, yet the C# compiler accepts the above test =
assignment without complaint. In other words...the presence or
absence of [Flags] makes no difference to the /assignment/.
I accept that it will affect other things like ToString(), etc.
It should work as per the above according to sectino 14.10.2 of the
ECMA spec.
The documentation you were talking about is the FlagsAttribute remarks,
presumably? If so, it's quite an interesting case - it's up to a
language to decide what it allows, so I don't think the FlagAttribute
documentation should really be talking about that at all. What it
could/should be talking about is that when [Flags] is applied, bitwise
operations are *expected* to give useful results (whereas they may not
otherwise). A language *could* decide to only allow bitwise operations
on enumerations which are marked with the [Flags] attribute, of course.
--
Jon,
Yes, it was in the FlagsAttribute section of the documentation.
I haven't located anything specifically for [Flags]. I also note
that the doco uses the word "OR" rather than the C# "|" operator so
perhaps its remarks are Visual Basic oriented. I don't do VB so
I haven't tried.
Regards, Oz
> I also note that the doco uses the word "OR" rather than the C# "|" operator so
perhaps its remarks are Visual Basic oriented. I don't do VB so
I haven't tried.
LOL:))) You made my day:)))))))))) This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Michele Simionato |
last post by:
I often feel the need to extend the string method ".endswith" to tuple
arguments, in such a way to automatically check for multiple endings.
For instance, here is a typical use case:
if...
|
by: Michele Simionato |
last post by:
I have read with interest the recent thread about closures. The funny
thing is that the authors are arguing one against the other but I
actually agree with all of them and I have a proposal that...
|
by: Raymond Hettinger |
last post by:
Proposal
--------
I am gathering data to evaluate a request for an alternate version of
itertools.izip() with a None fill-in feature like that for the built-in
map() function:
>>> map(None,...
|
by: Raymond Hettinger |
last post by:
I am evaluating a request for an alternate version of itertools.izip()
that has a None fill-in feature like the built-in map function:
>>> map(None, 'abc', '12345') # demonstrate map's None...
|
by: ThunderMusic |
last post by:
Hi,
Is there a way we can send a feature request for Visual Studio? When using
'Refactor-->Encapsulate Field', I'd like to have an option for the
references not to be updated anywhere in the...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
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: 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...
| |
