473,581 Members | 2,751 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

VB Conversion Keywords And .NET Conversion Routines

Hi,

Just wanted to know if there is any speed difference between

VB conversion Keywords like CInt, Clng, CStr, CDbl, CBool etc.
..NETs Convert.To<...> methods.

And which is better to be used and why ?

Thanx
rawCoder


Nov 21 '05 #1
47 2845
Personally I use the generic .NET methods like Convert.ToInt32 () instead of
CInt(), etc. This makes your programs more congruent with other .NET
languages, including C#. Some of the VB legacy conversion methods have
backward compatibility baggage. I don't recall the specifics, but it's best
to make direct calls into the CLR so you know exactly what you're getting,
when writing new code. When converting legacy VB6 code, that's when you'd
use the VB versions, at least in early iterations of the conversion.

The best you can hope for, it seems to me, is that CInt() does nothing more
than call Convert.ToInt32 (); at minimum, that's an extra call. I'd just as
soon avoid that.

Another oft-overlooked issue is that when writing new code it's better to
use AndAlso / OrElse rather than And/Or, so that you get rid of one of VB's
most annoying features: lack of short-circuit evaluation. Again, you'd
stick with And / Or when trying to get a clean conversion of legacy VB6
code, or on those rare occasions when you actually don't want short-circuit
evaluation.

--Bob

"rawCoder" <ra******@hotma il.com> wrote in message
news:eh******** *****@TK2MSFTNG P15.phx.gbl...
Hi,

Just wanted to know if there is any speed difference between

VB conversion Keywords like CInt, Clng, CStr, CDbl, CBool etc.
.NETs Convert.To<...> methods.

And which is better to be used and why ?

Thanx
rawCoder

Nov 21 '05 #2
Personally I use the generic .NET methods like Convert.ToInt32 () instead of
CInt(), etc. This makes your programs more congruent with other .NET
languages, including C#. Some of the VB legacy conversion methods have
backward compatibility baggage. I don't recall the specifics, but it's best
to make direct calls into the CLR so you know exactly what you're getting,
when writing new code. When converting legacy VB6 code, that's when you'd
use the VB versions, at least in early iterations of the conversion.

The best you can hope for, it seems to me, is that CInt() does nothing more
than call Convert.ToInt32 (); at minimum, that's an extra call. I'd just as
soon avoid that.

Another oft-overlooked issue is that when writing new code it's better to
use AndAlso / OrElse rather than And/Or, so that you get rid of one of VB's
most annoying features: lack of short-circuit evaluation. Again, you'd
stick with And / Or when trying to get a clean conversion of legacy VB6
code, or on those rare occasions when you actually don't want short-circuit
evaluation.

--Bob

"rawCoder" <ra******@hotma il.com> wrote in message
news:eh******** *****@TK2MSFTNG P15.phx.gbl...
Hi,

Just wanted to know if there is any speed difference between

VB conversion Keywords like CInt, Clng, CStr, CDbl, CBool etc.
.NETs Convert.To<...> methods.

And which is better to be used and why ?

Thanx
rawCoder

Nov 21 '05 #3
Bob,
Personally I use the generic .NET methods like Convert.ToInt32 () instead
of CInt(), etc. This makes your programs more congruent with other .NET
languages, including C#.
What is the advantage from this, in my idea can you than better write it
direct in C
Some of the VB legacy conversion methods have backward compatibility
baggage.


What are VB legacy conversion methods. C#, C++, J++, JavaScript and Java and
what ever from C derived languages have a lot of legacy C stuff. (With what
in my opinion is almost nothing wrong by the way)

Cor
Nov 21 '05 #4
Bob,
Personally I use the generic .NET methods like Convert.ToInt32 () instead
of CInt(), etc. This makes your programs more congruent with other .NET
languages, including C#.
What is the advantage from this, in my idea can you than better write it
direct in C
Some of the VB legacy conversion methods have backward compatibility
baggage.


What are VB legacy conversion methods. C#, C++, J++, JavaScript and Java and
what ever from C derived languages have a lot of legacy C stuff. (With what
in my opinion is almost nothing wrong by the way)

Cor
Nov 21 '05 #5
"Cor Ligthert" <no************ @planet.nl> wrote in message
news:uQ******** ******@TK2MSFTN GP09.phx.gbl...
Bob,
Personally I use the generic .NET methods like Convert.ToInt32 () instead
of CInt(), etc. This makes your programs more congruent with other .NET
languages, including C#.
What is the advantage from this, in my idea can you than better write it
direct in C


All I'm saying is that the CLR provides virtually all the classes and
methods you need for conversions. .NET-hosted languages that have legacy
syntax for doing the same things as the CLR methods will either implement
compiler syntax sugar that substitutes CLR calls for the legacy syntax, or
they will provide a library that implements the legacy syntax / behaviors.
VB.NET does primarily the latter, but with a little bit of syntax sugar --
the namespace / library where the compatibility methods exist is always
automatically referenced without the VB.NET developer having to do anything.

In the best case, if you call the legacy VB function CInt(), it's just going
to forward it to Convert.ToInt32 () anyway. Why not avoid that extra call?
In the worst case, CInt() is going to implement some legacy behavior that
might be even more expensive. For example it might take Nothing as zero,
which would involve another test or perhaps a try/catch. I don't recall
offhand -- but I remember finding that some of the legacy conversion
functions do jump through extra hoops to behave exactly like legacy VB.

I'm not passing judgment on this as good, bad or indifferent -- it's just
the way it is. I'm sure that some future version of C# will have similar
issues. The initial release of C# didn't have to cope with legacy issues
since it was a brand-new language, but over time, it will. I also assume
that COBOL.NET, S#, Eiffel.NET, etc., have similar kludges to help legacy
code run somewhat as-is.
What are VB legacy conversion methods. C#, C++, J++, JavaScript and Java
and what ever from C derived languages have a lot of legacy C stuff. (With
what in my opinion is almost nothing wrong by the way)


I'm not referring to language characteristics or conventions that descend
from predecessor languages. I'm referring to keywords / functions /
commands that are obsoleted by the provided .NET classes and which exist
only so that code written for previous, non .NET versions of those languages
will come as close as feasible to running unchanged.

I don't think anyone seriously recommends using, for example, PRINT#
statements in VB.NET. They're obsolete. CInt() / CDbl(), etc., are, too.
People use them to ease the incorporation of legacy code into .NET apps, or
out of habit; I'm simply advocating that they be treated like deprecated
HTML tags, which is to say, they will probably not be supported someday and
there are arguably better ways of doing the same things.

The parallel to deprecated HTML tags also cuts the other way. <B> is
deprecated, for example, but so many people continue to use it that it
probably will continue to be supported just from sheer inertia. That
probably means it's simple and abbreviated enough that it is useful and
appealing despite the fact it's obsolete. One could argue that CInt() is
more concise than Convert.ToInt32 () and maybe on that basis plus the fact
that probably most VB.NET developers started out with VB6, CInt() will
remain enshrined in the language forever. Personally though I prefer to
take the larger view that you want VB.NET to participate as an equal partner
with other .NET languages and it should play in the sandbox the same way so
that programmers can move between VB.NET and other .NET languages with a
minimum of quirky exceptions to how things are done from one language to the
next.

--Bob
Nov 21 '05 #6
"Cor Ligthert" <no************ @planet.nl> wrote in message
news:uQ******** ******@TK2MSFTN GP09.phx.gbl...
Bob,
Personally I use the generic .NET methods like Convert.ToInt32 () instead
of CInt(), etc. This makes your programs more congruent with other .NET
languages, including C#.
What is the advantage from this, in my idea can you than better write it
direct in C


All I'm saying is that the CLR provides virtually all the classes and
methods you need for conversions. .NET-hosted languages that have legacy
syntax for doing the same things as the CLR methods will either implement
compiler syntax sugar that substitutes CLR calls for the legacy syntax, or
they will provide a library that implements the legacy syntax / behaviors.
VB.NET does primarily the latter, but with a little bit of syntax sugar --
the namespace / library where the compatibility methods exist is always
automatically referenced without the VB.NET developer having to do anything.

In the best case, if you call the legacy VB function CInt(), it's just going
to forward it to Convert.ToInt32 () anyway. Why not avoid that extra call?
In the worst case, CInt() is going to implement some legacy behavior that
might be even more expensive. For example it might take Nothing as zero,
which would involve another test or perhaps a try/catch. I don't recall
offhand -- but I remember finding that some of the legacy conversion
functions do jump through extra hoops to behave exactly like legacy VB.

I'm not passing judgment on this as good, bad or indifferent -- it's just
the way it is. I'm sure that some future version of C# will have similar
issues. The initial release of C# didn't have to cope with legacy issues
since it was a brand-new language, but over time, it will. I also assume
that COBOL.NET, S#, Eiffel.NET, etc., have similar kludges to help legacy
code run somewhat as-is.
What are VB legacy conversion methods. C#, C++, J++, JavaScript and Java
and what ever from C derived languages have a lot of legacy C stuff. (With
what in my opinion is almost nothing wrong by the way)


I'm not referring to language characteristics or conventions that descend
from predecessor languages. I'm referring to keywords / functions /
commands that are obsoleted by the provided .NET classes and which exist
only so that code written for previous, non .NET versions of those languages
will come as close as feasible to running unchanged.

I don't think anyone seriously recommends using, for example, PRINT#
statements in VB.NET. They're obsolete. CInt() / CDbl(), etc., are, too.
People use them to ease the incorporation of legacy code into .NET apps, or
out of habit; I'm simply advocating that they be treated like deprecated
HTML tags, which is to say, they will probably not be supported someday and
there are arguably better ways of doing the same things.

The parallel to deprecated HTML tags also cuts the other way. <B> is
deprecated, for example, but so many people continue to use it that it
probably will continue to be supported just from sheer inertia. That
probably means it's simple and abbreviated enough that it is useful and
appealing despite the fact it's obsolete. One could argue that CInt() is
more concise than Convert.ToInt32 () and maybe on that basis plus the fact
that probably most VB.NET developers started out with VB6, CInt() will
remain enshrined in the language forever. Personally though I prefer to
take the larger view that you want VB.NET to participate as an equal partner
with other .NET languages and it should play in the sandbox the same way so
that programmers can move between VB.NET and other .NET languages with a
minimum of quirky exceptions to how things are done from one language to the
next.

--Bob
Nov 21 '05 #7
Bob,
The initial release of C# didn't have to cope with legacy issues since it
was a brand-new language, What do you consider "(int)" in C#?

I hope you realize that "(int)" in C# is the same as CInt in a number of
cases.

The "nice" thing about CInt is it is more powerful, then either "(int)" or
Convert.ToInt32 , as it combines both, plus.
I don't think anyone seriously recommends using, for example, PRINT# The PRINT# keyword is not even available in VB.NET, so why would any one
even consider recommending it?

The Print# keyword has been replaced with the
Microsoft.Visua lBasic.FileSyst em.Print function in the VB.NET runtime. The
VB.NET runtime is an integral part of the VB.NET language.
statements in VB.NET. They're obsolete. CInt() / CDbl(), etc., are, too. CInt & CDbl are no where near obsolete, they are keywords which are an
integral part of the VB.NET language, just as are If, Sub, Property, and
every other keyword in VB.NET. Not to be confused with VB6 keywords that are
retained in VB.NET and not actually used, such as GOSUB.

If you have not yet read Paul Vick's article on CInt & such, I strongly
suggest you do:

http://www.panopticoncentral.net/arc...6/07/1200.aspx

Unfortunately I don't have access to my VS.NET 2005 partition right now, I
understand that CInt, CDbl, etc have expanded usage in VB.NET 2005! In that
they honor overloaded operators:

http://www.panopticoncentral.net/arc...7/01/1338.aspx
http://msdn.microsoft.com/vbasic/whi...verloading.asp

Hope this helps
Jay

"Bob Grommes" <bo*@bobgrommes .com> wrote in message
news:e3******** ******@TK2MSFTN GP09.phx.gbl... "Cor Ligthert" <no************ @planet.nl> wrote in message
news:uQ******** ******@TK2MSFTN GP09.phx.gbl...
Bob,
Personally I use the generic .NET methods like Convert.ToInt32 () instead
of CInt(), etc. This makes your programs more congruent with other .NET
languages, including C#.


What is the advantage from this, in my idea can you than better write it
direct in C


All I'm saying is that the CLR provides virtually all the classes and
methods you need for conversions. .NET-hosted languages that have legacy
syntax for doing the same things as the CLR methods will either implement
compiler syntax sugar that substitutes CLR calls for the legacy syntax, or
they will provide a library that implements the legacy syntax / behaviors.
VB.NET does primarily the latter, but with a little bit of syntax sugar --
the namespace / library where the compatibility methods exist is always
automatically referenced without the VB.NET developer having to do
anything.

In the best case, if you call the legacy VB function CInt(), it's just
going to forward it to Convert.ToInt32 () anyway. Why not avoid that extra
call? In the worst case, CInt() is going to implement some legacy behavior
that might be even more expensive. For example it might take Nothing as
zero, which would involve another test or perhaps a try/catch. I don't
recall offhand -- but I remember finding that some of the legacy
conversion functions do jump through extra hoops to behave exactly like
legacy VB.

I'm not passing judgment on this as good, bad or indifferent -- it's just
the way it is. I'm sure that some future version of C# will have similar
issues. The initial release of C# didn't have to cope with legacy issues
since it was a brand-new language, but over time, it will. I also assume
that COBOL.NET, S#, Eiffel.NET, etc., have similar kludges to help legacy
code run somewhat as-is.
What are VB legacy conversion methods. C#, C++, J++, JavaScript and Java
and what ever from C derived languages have a lot of legacy C stuff.
(With what in my opinion is almost nothing wrong by the way)


I'm not referring to language characteristics or conventions that descend
from predecessor languages. I'm referring to keywords / functions /
commands that are obsoleted by the provided .NET classes and which exist
only so that code written for previous, non .NET versions of those
languages will come as close as feasible to running unchanged.

I don't think anyone seriously recommends using, for example, PRINT#
statements in VB.NET. They're obsolete. CInt() / CDbl(), etc., are, too.
People use them to ease the incorporation of legacy code into .NET apps,
or out of habit; I'm simply advocating that they be treated like
deprecated HTML tags, which is to say, they will probably not be supported
someday and there are arguably better ways of doing the same things.

The parallel to deprecated HTML tags also cuts the other way. <B> is
deprecated, for example, but so many people continue to use it that it
probably will continue to be supported just from sheer inertia. That
probably means it's simple and abbreviated enough that it is useful and
appealing despite the fact it's obsolete. One could argue that CInt() is
more concise than Convert.ToInt32 () and maybe on that basis plus the fact
that probably most VB.NET developers started out with VB6, CInt() will
remain enshrined in the language forever. Personally though I prefer to
take the larger view that you want VB.NET to participate as an equal
partner with other .NET languages and it should play in the sandbox the
same way so that programmers can move between VB.NET and other .NET
languages with a minimum of quirky exceptions to how things are done from
one language to the next.

--Bob

Nov 21 '05 #8
Bob,
The initial release of C# didn't have to cope with legacy issues since it
was a brand-new language, What do you consider "(int)" in C#?

I hope you realize that "(int)" in C# is the same as CInt in a number of
cases.

The "nice" thing about CInt is it is more powerful, then either "(int)" or
Convert.ToInt32 , as it combines both, plus.
I don't think anyone seriously recommends using, for example, PRINT# The PRINT# keyword is not even available in VB.NET, so why would any one
even consider recommending it?

The Print# keyword has been replaced with the
Microsoft.Visua lBasic.FileSyst em.Print function in the VB.NET runtime. The
VB.NET runtime is an integral part of the VB.NET language.
statements in VB.NET. They're obsolete. CInt() / CDbl(), etc., are, too. CInt & CDbl are no where near obsolete, they are keywords which are an
integral part of the VB.NET language, just as are If, Sub, Property, and
every other keyword in VB.NET. Not to be confused with VB6 keywords that are
retained in VB.NET and not actually used, such as GOSUB.

If you have not yet read Paul Vick's article on CInt & such, I strongly
suggest you do:

http://www.panopticoncentral.net/arc...6/07/1200.aspx

Unfortunately I don't have access to my VS.NET 2005 partition right now, I
understand that CInt, CDbl, etc have expanded usage in VB.NET 2005! In that
they honor overloaded operators:

http://www.panopticoncentral.net/arc...7/01/1338.aspx
http://msdn.microsoft.com/vbasic/whi...verloading.asp

Hope this helps
Jay

"Bob Grommes" <bo*@bobgrommes .com> wrote in message
news:e3******** ******@TK2MSFTN GP09.phx.gbl... "Cor Ligthert" <no************ @planet.nl> wrote in message
news:uQ******** ******@TK2MSFTN GP09.phx.gbl...
Bob,
Personally I use the generic .NET methods like Convert.ToInt32 () instead
of CInt(), etc. This makes your programs more congruent with other .NET
languages, including C#.


What is the advantage from this, in my idea can you than better write it
direct in C


All I'm saying is that the CLR provides virtually all the classes and
methods you need for conversions. .NET-hosted languages that have legacy
syntax for doing the same things as the CLR methods will either implement
compiler syntax sugar that substitutes CLR calls for the legacy syntax, or
they will provide a library that implements the legacy syntax / behaviors.
VB.NET does primarily the latter, but with a little bit of syntax sugar --
the namespace / library where the compatibility methods exist is always
automatically referenced without the VB.NET developer having to do
anything.

In the best case, if you call the legacy VB function CInt(), it's just
going to forward it to Convert.ToInt32 () anyway. Why not avoid that extra
call? In the worst case, CInt() is going to implement some legacy behavior
that might be even more expensive. For example it might take Nothing as
zero, which would involve another test or perhaps a try/catch. I don't
recall offhand -- but I remember finding that some of the legacy
conversion functions do jump through extra hoops to behave exactly like
legacy VB.

I'm not passing judgment on this as good, bad or indifferent -- it's just
the way it is. I'm sure that some future version of C# will have similar
issues. The initial release of C# didn't have to cope with legacy issues
since it was a brand-new language, but over time, it will. I also assume
that COBOL.NET, S#, Eiffel.NET, etc., have similar kludges to help legacy
code run somewhat as-is.
What are VB legacy conversion methods. C#, C++, J++, JavaScript and Java
and what ever from C derived languages have a lot of legacy C stuff.
(With what in my opinion is almost nothing wrong by the way)


I'm not referring to language characteristics or conventions that descend
from predecessor languages. I'm referring to keywords / functions /
commands that are obsoleted by the provided .NET classes and which exist
only so that code written for previous, non .NET versions of those
languages will come as close as feasible to running unchanged.

I don't think anyone seriously recommends using, for example, PRINT#
statements in VB.NET. They're obsolete. CInt() / CDbl(), etc., are, too.
People use them to ease the incorporation of legacy code into .NET apps,
or out of habit; I'm simply advocating that they be treated like
deprecated HTML tags, which is to say, they will probably not be supported
someday and there are arguably better ways of doing the same things.

The parallel to deprecated HTML tags also cuts the other way. <B> is
deprecated, for example, but so many people continue to use it that it
probably will continue to be supported just from sheer inertia. That
probably means it's simple and abbreviated enough that it is useful and
appealing despite the fact it's obsolete. One could argue that CInt() is
more concise than Convert.ToInt32 () and maybe on that basis plus the fact
that probably most VB.NET developers started out with VB6, CInt() will
remain enshrined in the language forever. Personally though I prefer to
take the larger view that you want VB.NET to participate as an equal
partner with other .NET languages and it should play in the sandbox the
same way so that programmers can move between VB.NET and other .NET
languages with a minimum of quirky exceptions to how things are done from
one language to the next.

--Bob

Nov 21 '05 #9
Don't you think that the compiler compiles Cint function to basically the
same as Convert.ToInteg er32? I really wonder if Cint function calls
convert.ToInteg er32. Are you positive about this?

"Bob Grommes" wrote:
"Cor Ligthert" <no************ @planet.nl> wrote in message
news:uQ******** ******@TK2MSFTN GP09.phx.gbl...
Bob,
Personally I use the generic .NET methods like Convert.ToInt32 () instead
of CInt(), etc. This makes your programs more congruent with other .NET
languages, including C#.


What is the advantage from this, in my idea can you than better write it
direct in C


All I'm saying is that the CLR provides virtually all the classes and
methods you need for conversions. .NET-hosted languages that have legacy
syntax for doing the same things as the CLR methods will either implement
compiler syntax sugar that substitutes CLR calls for the legacy syntax, or
they will provide a library that implements the legacy syntax / behaviors.
VB.NET does primarily the latter, but with a little bit of syntax sugar --
the namespace / library where the compatibility methods exist is always
automatically referenced without the VB.NET developer having to do anything.

In the best case, if you call the legacy VB function CInt(), it's just going
to forward it to Convert.ToInt32 () anyway. Why not avoid that extra call?
In the worst case, CInt() is going to implement some legacy behavior that
might be even more expensive. For example it might take Nothing as zero,
which would involve another test or perhaps a try/catch. I don't recall
offhand -- but I remember finding that some of the legacy conversion
functions do jump through extra hoops to behave exactly like legacy VB.

I'm not passing judgment on this as good, bad or indifferent -- it's just
the way it is. I'm sure that some future version of C# will have similar
issues. The initial release of C# didn't have to cope with legacy issues
since it was a brand-new language, but over time, it will. I also assume
that COBOL.NET, S#, Eiffel.NET, etc., have similar kludges to help legacy
code run somewhat as-is.
What are VB legacy conversion methods. C#, C++, J++, JavaScript and Java
and what ever from C derived languages have a lot of legacy C stuff. (With
what in my opinion is almost nothing wrong by the way)


I'm not referring to language characteristics or conventions that descend
from predecessor languages. I'm referring to keywords / functions /
commands that are obsoleted by the provided .NET classes and which exist
only so that code written for previous, non .NET versions of those languages
will come as close as feasible to running unchanged.

I don't think anyone seriously recommends using, for example, PRINT#
statements in VB.NET. They're obsolete. CInt() / CDbl(), etc., are, too.
People use them to ease the incorporation of legacy code into .NET apps, or
out of habit; I'm simply advocating that they be treated like deprecated
HTML tags, which is to say, they will probably not be supported someday and
there are arguably better ways of doing the same things.

The parallel to deprecated HTML tags also cuts the other way. <B> is
deprecated, for example, but so many people continue to use it that it
probably will continue to be supported just from sheer inertia. That
probably means it's simple and abbreviated enough that it is useful and
appealing despite the fact it's obsolete. One could argue that CInt() is
more concise than Convert.ToInt32 () and maybe on that basis plus the fact
that probably most VB.NET developers started out with VB6, CInt() will
remain enshrined in the language forever. Personally though I prefer to
take the larger view that you want VB.NET to participate as an equal partner
with other .NET languages and it should play in the sandbox the same way so
that programmers can move between VB.NET and other .NET languages with a
minimum of quirky exceptions to how things are done from one language to the
next.

--Bob

Nov 21 '05 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

2
1670
by: archy | last post by:
If I want to use index keywords for a (simple) database of quotations, do I need to set each word up in a separate field, or can I list multiple words in a single field? Or is this the wrong question? TIA -- archy "we only live, only suspire, consumed by either fire or fire" (T.S. Eliot)
16
5110
by: TTroy | last post by:
Hello, I'm relatively new to C and have gone through more than 4 books on it. None mentioned anything about integral promotion, arithmetic conversion, value preserving and unsigned preserving. And K&R2 mentions "signed extension" everywhere. Reading some old clc posts, I've beginning to realize that these books are over-generalizing the...
0
260
by: rawCoder | last post by:
Hi, Just wanted to know if there is any speed difference between VB conversion Keywords like CInt, Clng, CStr, CDbl, CBool etc. ..NETs Convert.To<...> methods. And which is better to be used and why ? Thanx
9
6015
by: arunmib | last post by:
hi all, How can I convert an Integer (int data type) and an unsigned char data type to a quadword? I want to know the conversion mechanism.... Advance thanks for the help.
21
2430
by: REH | last post by:
It it permissible to use the constructor style cast with primitives such as "unsigned long"? One of my compilers accepts this syntax, the other does not. The failing one chokes on the fact that the type is not a single identifier or keyword. Which one is correct? For example: unsigned long x = unsigned long(y); REH
0
7788
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 effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language...
0
8137
Oralloy
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, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. ...
0
8299
jinu1996
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 tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that...
1
7890
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For...
0
6545
agi2029
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, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then...
0
5355
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert...
0
3799
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in...
1
2297
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
0
1127
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.