473,836 Members | 1,537 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Initializing constants

The code block below initialized a r/w variable (usually .bss) to the
value of pi. One, of many, problem is any linked compilation unit may
change the global variable. Adjusting

// rodata
const long double const_pi=0.0;

lines to

// rodata
const long double const_pi=init_l dbl_pi();

would add additional protections, but is not legal C, and, rightly so,
fails on GCC/i386.

Do any C standards define a means to initalize constants to values
obtained from hardware, or does the total number of constants and/or
cross-compiling prohibit it completely (although, when cross-compiling,
the compiler could create a value using the resources available i.e.
emulation)?

I'm hoping something like this is possible...

// rodata
const long double const_pi= LDBL_PI;

When compiling on i386 systems for i386 targets and using the
coprocessor, LDBL_PI evaluates to the 80bit value of fldpi instruction,
and when compiling on non i386 systems for i386 targets, an emulation
value is calculated from available resources.

BEGIN CODE
#include <stdio.h>

// prototype
long double init_ldbl_pi();

// rodata
const long double const_pi=0.0;

// global function
long double init_ldbl_pi() {
long double ldbl=3.14;

#if (defined __GNUC__) && (defined __i386__)
asm("fldpi":::" st");
asm("fstpt %0":"=m" (ldbl)::"st");
#endif
return ldbl;
}

// main function
int main() {
long double ldbl_pi=init_ld bl_pi();
printf("%Le\n", ldbl_pi);
return 0;
}
END CODE

Aug 31 '06 #1
34 3398
"newsposter0123 " <ne************ @yahoo.comwrite s:
I'm hoping something like this is possible...

// rodata
const long double const_pi= LDBL_PI;

When compiling on i386 systems for i386 targets and using the
coprocessor, LDBL_PI evaluates to the 80bit value of fldpi instruction,
and when compiling on non i386 systems for i386 targets, an emulation
value is calculated from available resources.
What's the value in getting pi from an i386 instruction? I would
suggest just writing out enough digits of pi to cover the desired
level of significance.
--
"What is appropriate for the master is not appropriate for the novice.
You must understand the Tao before transcending structure."
--The Tao of Programming
Aug 31 '06 #2

Ben Pfaff wrote:
When compiling on i386 systems for i386 targets and using the
coprocessor, LDBL_PI evaluates to the 80bit value of fldpi instruction,
and when compiling on non i386 systems for i386 targets, an emulation
value is calculated from available resources.

What's the value in getting pi from an i386 instruction? I would
suggest just writing out enough digits of pi to cover the desired
level of significance.
Hardware generally provides constants other than pi.

For one, when converting numbers. Ideally you would like to get the
original number back. Especially when adjusting bases. But that debate
rages elsewhere.

Provided the precision of the measurements device was known in advance,
then the number of significant digits could be predetermined. If a
device with greater precision were used, then the constant would be
require adjustment (and no longer be a constant).

In general, constants imply unrestricted usage, not limited to a
specific application, or limiting the number of significant digits in a
calculation. Otherwise, why spend $$$ on precision equipment?

Aug 31 '06 #3
"newsposter0123 " <ne************ @yahoo.comwrite s:
Ben Pfaff wrote:
When compiling on i386 systems for i386 targets and using the
coprocessor, LDBL_PI evaluates to the 80bit value of fldpi instruction,
and when compiling on non i386 systems for i386 targets, an emulation
value is calculated from available resources.

What's the value in getting pi from an i386 instruction? I would
suggest just writing out enough digits of pi to cover the desired
level of significance.

Hardware generally provides constants other than pi.

For one, when converting numbers. Ideally you would like to get the
original number back. Especially when adjusting bases. But that debate
rages elsewhere.

Provided the precision of the measurements device was known in advance,
then the number of significant digits could be predetermined. If a
device with greater precision were used, then the constant would be
require adjustment (and no longer be a constant).
But the i386 floating-point architecture also has a fixed
precision. When you obtain your device with greater precision,
you will have to change the code anyhow. So I don't see the
benefit.
--
int main(void){char p[]="ABCDEFGHIJKLM NOPQRSTUVWXYZab cdefghijklmnopq rstuvwxyz.\
\n",*q="kl BIcNBFr.NKEzjwC IxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+= strchr(p,*q++)-p;if(i>=(int)si zeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}
Aug 31 '06 #4

Ben Pfaff wrote:
"newsposter0123 " <ne************ @yahoo.comwrite s:
Ben Pfaff wrote:
Provided the precision of the measurements device was known in advance,
then the number of significant digits could be predetermined. If a
device with greater precision were used, then the constant would be
require adjustment (and no longer be a constant).

But the i386 floating-point architecture also has a fixed
precision.
Yep. Some hardware provides an 128bit long double.
When you obtain your device with greater precision,
you will have to change the code anyhow.
Depending on how the application was implemented, maybe. If the
calculations could be completed using the long double type, then no.
But the library/ api providing and/or using the constant would not
require adjustment.
>So I don't see the
benefit.
Much easier for the programmer to implement.

BTW, this is off topic, but if a measurment device (micrometer) is
graduated in thousands of an inch and has range 0-2 inch, would the
measurement .053 contain 3 or 4 significant digits and be written as
5.300e-2 or 5.30e-2? I'm pretty sure the measurement 1.053 would have
4.

Aug 31 '06 #5
"newsposter0123 " <ne************ @yahoo.comwrite s:
Ben Pfaff wrote:
>"newsposter012 3" <ne************ @yahoo.comwrite s:
Provided the precision of the measurements device was known in advance,
then the number of significant digits could be predetermined. If a
device with greater precision were used, then the constant would be
require adjustment (and no longer be a constant).

But the i386 floating-point architecture also has a fixed
precision.
Yep. Some hardware provides an 128bit long double.
>When you obtain your device with greater precision,
you will have to change the code anyhow.

Depending on how the application was implemented, maybe. If the
calculations could be completed using the long double type, then no.
But the library/ api providing and/or using the constant would not
require adjustment.
You said, in the article that I originally replied to, that you
wanted to use an i386-specific instruction to obtain the value of
pi. You can't use that to obtain more than 80 bits of precision,
and you can't use it except on an i386 machine. Now you're
telling me that this will allow you to obtain greater precision
on a new device without adjusting the library or API.
>>So I don't see the
benefit.
Much easier for the programmer to implement.
I don't see how it's easier to use an i386-specific instruction
to obtain 80 bits of pi that to write a floating-point constant
that contains 80 bits of pi, and I certainly don't see how it
makes the code more extensible to better precision.
BTW, this is off topic, but if a measurment device (micrometer) is
graduated in thousands of an inch and has range 0-2 inch, would the
measurement .053 contain 3 or 4 significant digits and be written as
5.300e-2 or 5.30e-2? I'm pretty sure the measurement 1.053 would have
4.
Sounds like a trick question to me. I would think that .053 has
2 significant digits.
--
int main(void){char p[]="ABCDEFGHIJKLM NOPQRSTUVWXYZab cdefghijklmnopq rstuvwxyz.\
\n",*q="kl BIcNBFr.NKEzjwC IxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+= strchr(p,*q++)-p;if(i>=(int)si zeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}
Aug 31 '06 #6
Ben Pfaff wrote:
>Ben Pfaff wrote:
>>"newsposter01 23" <ne************ @yahoo.comwrite s:
You said, in the article that I originally replied to
Appreciate your reply.
that you
wanted to use an i386-specific instruction to obtain the value of
pi.
The specific example I used was for gcc running on i386, creating i386
targets. Generally, I was interested in how the C standards would view
such an method for initializing readonly (.rodata) constants.
You can't use that to obtain more than 80 bits of precision,
and you can't use it except on an i386 machine.
Exactly.
Now you're
telling me that this will allow you to obtain greater precision
on a new device without adjusting the library or API.
I don't have to adjust the constant pi in my calculator every time I
evaluate a new equation. I certainly would not want applications to
adjust the value of a library exported "constant" every time it was
used, which, if it were a read only constant would be illegal C.
I don't see how it's easier to use an i386-specific instruction
to obtain 80 bits of pi that to write a floating-point constant
that contains 80 bits of pi and I certainly don't see how it
makes the code more extensible to better precision.
I think it would be easier to write LDBL_PI then to write "3.14...." to
25 or 30 digits of accuracy (or whatever it takes to get the most
accurate value of the constant for the arch dependent implementation of
long double). Plus, assuming the compiler uses the maximum precision
available for the long double type at compile time (either from
hardware or emulation), I doubt it could calculate (due to chopping,
rounding, etc.), based on a "3.14...." string, a value of pi more
accurate than a hardware value of pi. This would probably be true for
any other hardware supplied constant.
Sounds like a trick question to me. I would think that .053 has
2 significant digits.
Hmmm. I guess the tenths 0 must be used to position the decimal point,
and is, therefore ,not significant.

Aug 31 '06 #7
newsposter0123 wrote:
The code block below initialized a r/w variable (usually .bss) to the
value of pi. One, of many, problem is any linked compilation unit may
change the global variable.
Well, don't do that then.

Lame answer? Sure. You can't have your cake and eat it too, though -- being
accessible from anywhere is why global variables are used and shouldn't be.
Adjusting

// rodata
const long double const_pi=0.0;

lines to

// rodata
const long double const_pi=init_l dbl_pi();

would add additional protections, but is not legal C, and, rightly so,
fails on GCC/i386.
It's more correct to say that it's not strictly conforming C. It's legal for
an implementation to compile this, however, since an implementation may
allow additional forms of constant expressions.

Obviously, most won't, certainly not arbitrary functions.
Do any C standards define a means to initalize constants to values
obtained from hardware
What do you mean by "C standards"? If the latest standard doesn't have it,
the earlier ones probably won't, either. If you just mean "any standard
written that involves the C language", a la POSIX, that's a different story.

Obviously, "values obtained from hardware" would have a hard time getting
standardized by anything.
or does the total number of constants and/or cross-compiling prohibit it
completely (although, when cross-compiling, the compiler could create a
value using the resources available i.e. emulation)?
No idea what you're getting at, here.
I'm hoping something like this is possible...

// rodata
const long double const_pi= LDBL_PI;

When compiling on i386 systems for i386 targets and using the
coprocessor, LDBL_PI evaluates to the 80bit value of fldpi instruction,
and when compiling on non i386 systems for i386 targets, an emulation
value is calculated from available resources.
You don't really want a constant expression (which has a very specific
meaning in C), but a read-only value. C does not directly implement such
semantics. Many platforms will allow you to implement this one way or the
other (with linker directives or virtual memory protection) but otherwise
nothing but good discipline will help.

If you *do* really want a compile-time constant expression based on some
arbitrary platform-specific calculation, you're basically asking your
compiler for magic. It's not wise to expect that.

If you really, really want this, use code generation and put the constant in
a separate header. Of course, platform-specific code generation has its own
problems -- the main one here being that you have to implement and run a
separate utility just to get the actual program to compile. This basically
means you're extending the implementation itself to give you what you want,
a powerful but difficult-to-maintain and easily abused technique.

S.
Aug 31 '06 #8
Skarmander wrote:
newsposter0123 wrote:
>The code block below initialized a r/w variable (usually .bss) to the
value of pi. One, of many, problem is any linked compilation unit may
change the global variable.

Well, don't do that then.
I am trying hard to avoid it.
>would add additional protections, but is not legal C, and, rightly so,
fails on GCC/i386.
It's more correct to say that it's not strictly conforming C. It's legal
for an implementation to compile this, however, since an implementation
may allow additional forms of constant expressions.
Yes, I'm assuming that the implementation places all constants in a
separate section (Probably ELF/COFF specific here) protected from
writes at runtime that could not be adjusted up during initialization
at runtime.
>
Obviously, most won't, certainly not arbitrary functions.
Maybe using "hooks?"
>
>Do any C standards define a means to initalize constants to values
obtained from hardware

What do you mean by "C standards"?
Who knows? They all have lots of sections, and numerous
interpretations .
If the latest standard doesn't have
it, the earlier ones probably won't, either.
Allowed usage may be implemented at any time I guess.
If you just mean "any
standard written that involves the C language", a la POSIX, that's a
different story.
Correct.
Obviously, "values obtained from hardware" would have a hard time
getting standardized by anything.
Yes, more competent persons would have to write the exact wording,
assuming the standard does not currently allow it.
>or does the total number of constants and/or cross-compiling prohibit it
completely (although, when cross-compiling, the compiler could create a
value using the resources available i.e. emulation)?
No idea what you're getting at, here.
When cross compiling the hardware running the compiler and the compiler
that compiled the compiler (is that straight?) may use a different
implementation for long double and/or the constant. Ex Microsoft just
uses double as long doubles and therefore may not be able to create a
"most accurate" constant.
>
>I'm hoping something like this is possible...

// rodata
const long double const_pi= LDBL_PI;

When compiling on i386 systems for i386 targets and using the
coprocessor, LDBL_PI evaluates to the 80bit value of fldpi instruction,
and when compiling on non i386 systems for i386 targets, an emulation
value is calculated from available resources.
You don't really want a constant expression (which has a very specific
meaning in C), but a read-only value.
Correct.
C does not directly implement such
semantics.
So it would have to be "added". An arduous process at best.
Many platforms will allow you to implement this one way or
the other (with linker directives or virtual memory protection) but
otherwise nothing but good discipline will help.
Right, but nothing portable, unfortunately.
If you *do* really want a compile-time constant expression based on some
arbitrary platform-specific calculation, you're basically asking your
compiler for magic. It's not wise to expect that.
I'm just happy with their current magic. But, bells and whistles, no
matter how minute, can make a big difference.
If you really, really want this, use code generation and put the
constant in a separate header. Of course, platform-specific code
generation has its own problems -- the main one here being that you have
to implement and run a separate utility just to get the actual program
to compile. This basically means you're extending the implementation
itself to give you what you want, a powerful but difficult-to-maintain
and easily abused technique.
So far, for specific platforms, I'm initializing an array of
sizeof(long double) bytes with the byte codes obtained from the
hardware instruction. This makes way to many assumptions to be
implemented in a portable way. Just with GCC, the -m96bit-long-double
and -m128bit-long-double options complicate things for i386 (although
the extra zeros in the 128bit shouldn't interfere with the 96bit
value).

Aug 31 '06 #9
newsposter0123 wrote:
Skarmander wrote:
>newsposter01 23 wrote:
>>The code block below initialized a r/w variable (usually .bss) to the
value of pi. One, of many, problem is any linked compilation unit may
change the global variable.
Well, don't do that then.

I am trying hard to avoid it.
>>would add additional protections, but is not legal C, and, rightly so,
fails on GCC/i386.
It's more correct to say that it's not strictly conforming C. It's legal
for an implementation to compile this, however, since an implementation
may allow additional forms of constant expressions.

Yes, I'm assuming that the implementation places all constants in a
separate section (Probably ELF/COFF specific here) protected from
writes at runtime that could not be adjusted up during initialization
at runtime.
That's not enough, I'm afraid. The implementation would also have to fix up
any evaluations involving the not-so-constant expression as if they took
place at compile time. "A constant expression can be evaluated during
translation rather than runtime, and accordingly may be used in any place
that a constant may be." This is what "constant" actually means in C: an
expression that can be evaluated at translation time.

This is why it's impossible for a compiler to allow
const long x = foo();
with foo() an arbitrary function, because to solve this in general, the
compiler would have to be capable of deferring translation of the entire
program! A C *interpreter* could do it, but that's probably not what you're
looking for.
>Obviously, most won't, certainly not arbitrary functions.
Maybe using "hooks?"
Not for what C calls a constant expression, per the above. But you're
talking about a read-only expression, which could conceivably be done.
>>Do any C standards define a means to initalize constants to values
obtained from hardware
What do you mean by "C standards"?
Who knows? They all have lots of sections, and numerous
interpretations .
The intent is for the number of implementations to be unlimited, but the
number of interpretations to be quite limited. Preferably to one. The draft
copy of the C99 standard I have does a pretty good job.
>If the latest standard doesn't have
it, the earlier ones probably won't, either.
Allowed usage may be implemented at any time I guess.
C has very few "optional" parts, and those are mostly restricted to being
"implementa tion-defined" (so the actual behavior needs to be documented) or
they don't actually guarantee something useful will happen (because a
platform may not support it at all). Either is useless for your purpose.

In any case, what is contained in the standard and what is provided by
implementations are conceptually different things. If the standard doesn't
have it, it can't be done portably; if the standard has it, it may be done
portably. In this case the standard doesn't have it.
>Obviously, "values obtained from hardware" would have a hard time
getting standardized by anything.
Yes, more competent persons would have to write the exact wording,
assuming the standard does not currently allow it.
What I meant was that not all the competence in the world could condense
this into something usable. The concept is much too broad.
>>or does the total number of constants and/or cross-compiling prohibit it
completely (although, when cross-compiling, the compiler could create a
value using the resources available i.e. emulation)?
No idea what you're getting at, here.

When cross compiling the hardware running the compiler and the compiler
that compiled the compiler (is that straight?) may use a different
implementation for long double and/or the constant. Ex Microsoft just
uses double as long doubles and therefore may not be able to create a
"most accurate" constant.
I now have some idea what you're getting at, but it just illustrates why
what you want is impractical.

Implementations do support implementation-specific constant expressions,
namely exactly those required by the standard. For example, INT_MAX (from
<limits.h>) must be the maximum value that can be stored in an int; it has
to be a constant expression.

That's quite reasonable, but how reasonable is "the value of pi calculated
to as many digits as this implementation supports"? This idea clearly does
not generalize.

For the specific example I mentioned, some implementations define a constant
M_PI which evaluates to a double representing some approximation of pi. I
don't know if it's governed by any standard (not the C standard, in any
case), and even if it is that may not guarantee that the maximum precision
be used, and even if it *does* it may not be practical to provide such a
definition, since it's impossible to implement portably. (Many C library
implementations are at least semi-portable.)
>>I'm hoping something like this is possible...

// rodata
const long double const_pi= LDBL_PI;

When compiling on i386 systems for i386 targets and using the
coprocessor , LDBL_PI evaluates to the 80bit value of fldpi instruction,
and when compiling on non i386 systems for i386 targets, an emulation
value is calculated from available resources.
You don't really want a constant expression (which has a very specific
meaning in C), but a read-only value.
Correct.
>C does not directly implement such
semantics.
So it would have to be "added". An arduous process at best.
I don't know. C++ did it. Is using C++ an option for you?

C++ has different semantics, where code like

int foo(void);
const int x = foo();

is allowed. (Note that "foo()" is still not a constant expression here, nor
is "x"; the value of x is just read-only after initialization. )
>Many platforms will allow you to implement this one way or
the other (with linker directives or virtual memory protection) but
otherwise nothing but good discipline will help.
Right, but nothing portable, unfortunately.
If you're satisfied with a read-only runtime value, then it's easy enough to
implement in C: just write a function that returns the value, or have a
doubly-const pointer to it (the latter can be subverted by people who really
want to, of course, but not silently).

static double const_pi_intern ;
const double * const const_pi = &const_pi_inter n;

void initialize_cons t_pi() {
/* ... */
}

or

double const_pi() {
static double const_pi_intern = 0.0;
if (const_pi_inter n == 0.0) {
/* Initialize */
}
return const_pi_intern ;
}

Neither solution gives you a compile-time constant and both may involve some
runtime overhead (which the compiler may be able to optimize away), so then
the question becomes: what's more important?
>If you really, really want this, use code generation and put the
constant in a separate header. Of course, platform-specific code
generation has its own problems -- the main one here being that you have
to implement and run a separate utility just to get the actual program
to compile. This basically means you're extending the implementation
itself to give you what you want, a powerful but difficult-to-maintain
and easily abused technique.

So far, for specific platforms, I'm initializing an array of
sizeof(long double) bytes with the byte codes obtained from the
hardware instruction. This makes way to many assumptions to be
implemented in a portable way. Just with GCC, the -m96bit-long-double
and -m128bit-long-double options complicate things for i386 (although
the extra zeros in the 128bit shouldn't interfere with the 96bit
value).
Just mark the function that has to initialize the value as non-portable and
requiring a separate implementation on each platform; you can fill the value
with a nonsense constant and barf on startup if the initialization function
isn't implemented.

You seem to be trying to solve the problem of "how to implement something
that cannot be done portably in a portable way". You don't; you isolate it,
flag it as a requirement and move on.

In this case, simply requiring that a particular macro expand to the
constant pi with a particular platform-dependent precision doesn't seem too
much of a burden on would-be porters.

S.
Aug 31 '06 #10

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

Similar topics

16
7227
by: Emanuel Ziegler | last post by:
Hi, I am using the vector class from the STL. Normally, I initialize values element by element, which is very uncomfortable and sometimes impossible (e.g. when passing a constant vector to an inherited constructor, since I cannot create a temporary vector before calling). Is there a possibility to assign a vector in one line, like it is possible for arrays?
1
2550
by: Steven T. Hatton | last post by:
Is there a way to initialize an member array of user defined objects that is declared static const? For example: const vec3f I(1,0,0); const vec3f j(0,1,0); class corner_functor {
3
3514
by: anonymous | last post by:
hello, i am attempting to initialize a constant in my .h file. it would be terrific if i could also assign the constant, but i continue to get compile problems. this is what i'm trying to do: (in myfile.h) const std::string MY_CONSTANT = "permanent value"; but my compiler (gcc version 3.2.1) tells me:
7
2442
by: masood.iqbal | last post by:
I am having lots of trouble getting a simple program that initializs a dynamically allocated 2D array to work. My 2D array is not getting initialized properly, and additionally I am getting a "Null pointer assignment" error. Kindly help. Also, eventually I intend to move this logic to a separate function. For that, I believe, that I will need to pass a pointer-to-pointer-to-pointer type as an arguent. Please confirm.
2
3591
by: Drew McCormack | last post by:
I am getting an error in g++ 4.0.0 that I did not get in g++ 3.4. I have a header with the following const variables with namespace scope: namespace Periphery { extern const double ProtonMassInAtomicUnits = 1836.152755656068; } I try to use these in another header to initialize static const member
7
6159
by: vikky | last post by:
hi all, Out of sheer curosity, I decided to initialize an integer with a number bigger than INT_MAX, however I still am not able to justify its output. Here is the program : #include<stdio.h> int main(void) { int t=0xFFFFFFFFFFFFFFFFDABC;
4
6023
by: ccdrbrg | last post by:
I am trying to initialize an arrary of pointers to structs with constants. Sample code: struct mystruct { char *text; int number; };
10
10529
by: Russell Shaw | last post by:
Hi, gcc-3.4 complains about non-integers in: enum {IDENTIFIER = "<identifier>", WIDGETDEF = "widgetdef"}; even if i cast the strings to integers.
13
2344
by: WaterWalk | last post by:
Hello. When I consult the ISO C++ standard, I notice that in paragraph 3.6.2.1, the standard states: "Objects with static storage duration shall be zero-initialized before any other initialization takes place." Does this mean all non-local objects will be zero-initialized before they are initialized by their initializers(if they have)? For example: int g_var = 3; int main() {}
0
9825
marktang
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, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look ! Part I. Meaning of...
0
10560
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 captivates audiences and drives business growth. The Art of Business Website Design Your website is...
1
10602
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 most users, this new feature is actually very convenient. If you want to control the update process,...
0
10260
tracyyun
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 protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
0
9388
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 launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
0
5653
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 the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
1
4463
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
2
4023
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
3
3116
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 effective websites that not only look great but also perform exceptionally well. In this comprehensive...

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.