On Tue, 04 Nov 2008 16:43:49 -0500, Eric Sosman
<Er*********@su n.comwrote:
>Richard Harter wrote:
>Suppose we are writing a program in C and that we have a
particular kind of object (in the sense of OO programming) that I
will call bobbles. Being well disciplined programmers (Ha!) we
create a module to package our bobble related functions together.
If we were using an OO based language there would be machinery in
place, constructors, destructors, and such like, to handle the
details of our module, but in C we have to roll our own.
One of the things we need to do is to create functions that will
serve as constructors and destructors. There are two things that
we have to take care of, specifying the interface, and writing
the function internals. My concern is with specifying the
interface.
I am going to throw in one curve ball. Our program will contain
references to created bobbles; we won't know where these are so
they can go stale when we delete bobbles. The code will need to
be able to detect that a reference has gone stale and deal with
it appropriately.
As far as I can see, the curve is orthogonal to the rest of
the discussion, so I'll ignore it. Your issues appear to deal with
representati on hiding and validity checking, not with garbage
collection.
I may address the rest of your comments later (for which, thank
you very much) but this seems to be a serious point of confusion
so let me expand. What we can have is the following sequence of
events:
At time A we create bobble X. Space will be allocated for X as
needed, including a struct bobble_s.
At time B we schedule operation zeta to be performed on X at time
E. Don't assume that X 'knows' that about the scheduled
operation.
At time C we delete bobble X. All space is deallocated.
At time D we allocate bobble Y. As it chances, Y has the same
address as X.
At time E the program attempts to peform the scheduled operation
on X. It has to be able to detect that X is no longer there even
though there is a bobble around with X's address.
Simply hashing the address into an integer won't work because the
addresses are the same. Likewise using an opaque pointer doesn't
work. That's the point of the "unique id" - it is different for
different bobbles even though they have the same address.
Of course you can use sequence numbers as keys in a hash table or
some kind of search tree, but that is relatively computationally
expensive compared to the descriptor/locator paired structs.
Richard Harter, cr*@tiac.net http://home.tiac.net/~cri, http://www.varinoma.com
Save the Earth now!!
It's the only planet with chocolate. 17  3397 
In comp.lang.c Richard Harter <cr*@tiac.netwr ote:
[ ... ]
At time A we create bobble X. Space will be allocated for X as
needed, including a struct bobble_s.
Put a unique "serial number" in each bobble. At creation time,
initialize the serial number from an incremented global counter.
Before deletion, set it to zero. Don't free() your deleted bobbles,
put them on a free list and get new storage from that list before
you fall back on malloc(). This is to ensure that serial numbers
are either zero or unique, and never garbage.
At time B we schedule operation zeta to be performed on X at time
E. Don't assume that X 'knows' that about the scheduled
operation.
In your queued request, store a copy of the serial number as well as
a pointer to X.
At time C we delete bobble X. All space is deallocated.
At time D we allocate bobble Y. As it chances, Y has the same
address as X.
Y gets a brand new serial number.
At time E the program attempts to peform the scheduled operation
on X. It has to be able to detect that X is no longer there even
though there is a bobble around with X's address.
Check that the serial number matches the copy on the request.
If not, well only you know what to do. Cancel the request
or report an error, whatever applies to your situation.
Don't let the global counter overflow. Follow your creation
and destruction discipline meticulously. This is C, the language
won't call destructors for you.
--
pa at panix dot com
Richard Harter wrote:
On Tue, 04 Nov 2008 16:43:49 -0500, Eric Sosman
<Er*********@su n.comwrote:
>Richard Harter wrote:
>>>[...]
I am going to throw in one curve ball. Our program will contain
references to created bobbles; we won't know where these are so
they can go stale when we delete bobbles. The code will need to
be able to detect that a reference has gone stale and deal with
it appropriately.
As far as I can see, the curve is orthogonal to the rest of
the discussion, so I'll ignore it. Your issues appear to deal with
representati on hiding and validity checking, not with garbage
collection.
I may address the rest of your comments later (for which, thank
you very much) but this seems to be a serious point of confusion
so let me expand. What we can have is the following sequence of
events:
At time A we create bobble X. Space will be allocated for X as
needed, including a struct bobble_s.
At time B we schedule operation zeta to be performed on X at time
E. Don't assume that X 'knows' that about the scheduled
operation.
At time C we delete bobble X. All space is deallocated.
If zeta is still armed and dangerous, this seems to me to
be an error in the program and not something a bobblefeature
should be expected to deal with. You're asking a destroyed
bobble to "remember" its former existence somehow, so it can
still respond in some way to an attempt to do something with
its non-existent self ... It doesn't seem to me that a robust
programming discipline should rely on spirit messages from the
afterlife.
If you're like me, your feet have occasionally taken one
more step than there were stairs. I've never thought that it
was the stairway's job to detect my misstep and protect me
somehow (by deploying a padded cell, perhaps?), especially
if the stairway itself has been demolished.
Or, as an instructor once told me, "Don't Do That."
--
Eric Sosman es*****@ieee-dot-org.invalid
On Wed, 5 Nov 2008 02:55:29 +0000 (UTC), pa@see.signatur e.invalid
(Pierre Asselin) wrote:
>In comp.lang.c Richard Harter <cr*@tiac.netwr ote:
>[ ... ]
At time A we create bobble X. Space will be allocated for X as
needed, including a struct bobble_s.
Put a unique "serial number" in each bobble. At creation time,
initialize the serial number from an incremented global counter.
Before deletion, set it to zero. Don't free() your deleted bobbles,
put them on a free list and get new storage from that list before
you fall back on malloc(). This is to ensure that serial numbers
are either zero or unique, and never garbage.
>At time B we schedule operation zeta to be performed on X at time
E. Don't assume that X 'knows' that about the scheduled
operation.
In your queued request, store a copy of the serial number as well as
a pointer to X.
>At time C we delete bobble X. All space is deallocated.
>At time D we allocate bobble Y. As it chances, Y has the same
address as X.
Y gets a brand new serial number.
>At time E the program attempts to peform the scheduled operation
on X. It has to be able to detect that X is no longer there even
though there is a bobble around with X's address.
Check that the serial number matches the copy on the request.
If not, well only you know what to do. Cancel the request
or report an error, whatever applies to your situation.
Don't let the global counter overflow. Follow your creation
and destruction discipline meticulously. This is C, the language
won't call destructors for you.
Er, the serial number approach was part of the original proposal.
Richard Harter, cr*@tiac.net http://home.tiac.net/~cri, http://www.varinoma.com
Save the Earth now!!
It's the only planet with chocolate.
On Tue, 04 Nov 2008 22:34:53 -0500, Eric Sosman
<es*****@ieee-dot-org.invalidwrot e:
>Richard Harter wrote:
>On Tue, 04 Nov 2008 16:43:49 -0500, Eric Sosman
<Er*********@s un.comwrote:
>>Richard Harter wrote:
[...]
I am going to throw in one curve ball. Our program will contain
references to created bobbles; we won't know where these are so
they can go stale when we delete bobbles. The code will need to
be able to detect that a reference has gone stale and deal with
it appropriately.
As far as I can see, the curve is orthogonal to the rest of
the discussion, so I'll ignore it. Your issues appear to deal with
representatio n hiding and validity checking, not with garbage
collection.
I may address the rest of your comments later (for which, thank
you very much) but this seems to be a serious point of confusion
so let me expand. What we can have is the following sequence of
events:
At time A we create bobble X. Space will be allocated for X as
needed, including a struct bobble_s.
At time B we schedule operation zeta to be performed on X at time
E. Don't assume that X 'knows' that about the scheduled
operation.
At time C we delete bobble X. All space is deallocated.
If zeta is still armed and dangerous, this seems to me to
be an error in the program, and not something a bobblefeature
should be expected to deal with. You're asking a destroyed
bobble to "remember" its former existence somehow, so it can
still respond in some way to an attempt to do something with
its non-existent self ... It doesn't seem to me that a robust
programming discipline should rely on spirit messages from the
afterlife.
If you're like me, your feet have occasionally taken one
more step than there were stairs. I've never thought that it
was the stairway's job to detect my misstep and protect me
somehow (by deploying a padded cell, perhaps?), especially
if the stairway itself has been demolished.
Or, as an instructor once told me, "Don't Do That."
You're misreading the situation. I'm not asking the destroyed
bobble to "remember" anything. How can it, when it no longer
exists? What I proposed was that zeta be able to detect the
non-existence of X when its time came. The technique I proposed
does require that the "locator" struct remain in existence; zeta
detects the non-existence of X by the mismatch of serial numbers.
However I don't see that as an onerous requirement.
Perhaps more importantly, I completely disagree with your view
that "If zeta is still armed and dangerous, this seems to me to
be an error in the program." Au contraire, in the situations I
am interested in it is an essential capability. As an example
think about a printer and the printer software. The printer
software is supposed to be able to deal with the fact that the
printer may be off line.
Richard Harter, cr*@tiac.net http://home.tiac.net/~cri, http://www.varinoma.com
Save the Earth now!!
It's the only planet with chocolate.
"Richard Harter" <cr*@tiac.net ha scritto nel messaggio
news:49******** ********@news.s btc.net...
On Tue, 04 Nov 2008 16:43:49 -0500, Eric Sosman
<Er*********@su n.comwrote:
At time A we create bobble X. Space will be allocated for X as
needed, including a struct bobble_s.
if *X=={u32, u32, u32}
we create a name string X@Point@32@32@3 2 a pointer allocated
and the memory space
X is
{u32* pointer=Space== 32*3 bits /* space to point
u32* name ="X@Point@32@32 @32" /* type to point
}
evalutation X return X->pointer
evalutation type use return X->"Point@32@32@3 2"
evalutation name X->"X"
At time B we schedule operation zeta to be performed on X at time
E. Don't assume that X 'knows' that about the scheduled
operation.
At time C we delete bobble X. All space is deallocated.
X is
{u32* pointer=0
u32* name ="X@Point@0"
}
At time D we allocate bobble Y. As it chances, Y has the same
address as X.
Y is
{u32* pointer=Space== 32*3 bits
u32* name ="Y@Point@32@32 @32"
}
At time E the program attempts to peform the scheduled operation
on X. It has to be able to detect that X is no longer there even
though there is a bobble around with X's address.
see the actual X
X is
{u32* pointer->0
u32* name ->X@Point@0
}
Simply hashing the address into an integer won't work because the
addresses are the same. Likewise using an opaque pointer doesn't
work. That's the point of the "unique id" - it is different for
different bobbles even though they have the same address.
Of course you can use sequence numbers as keys in a hash table or
some kind of search tree, but that is relatively computationally
expensive compared to the descriptor/locator paired structs.
Richard Harter, cr*@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
Save the Earth now!!
It's the only planet with chocolate.
On 5 Nov, 00:22, c...@tiac.net (Richard Harter) wrote:
On Tue, 04 Nov 2008 16:43:49 -0500, Eric Sosman
<Eric.Sos...@su n.comwrote:
Richard Harter wrote:
Suppose we are writing a program in C and that we have a
particular kind of object (in the sense of OO programming) that I
will call bobbles. *Being well disciplined programmers (Ha!) we
create a module to package our bobble related functions together.
If we were using an OO based language there would be machinery in
place, constructors, destructors, and such like, to handle the
details of our module, but in C we have to roll our own.
One of the things we need to do is to create functions that will
serve as constructors and destructors. *There are two things that
we have to take care of, specifying the interface, and writing
the function internals. *My concern is with specifying the
interface.
I am going to throw in one curve ball. *Our program will contain
references to created bobbles; we won't know where these are so
they can go stale when we delete bobbles. *The code will need to
be able to detect that a reference has gone stale and deal with
it appropriately.
* * As far as I can see, the curve is orthogonal to the rest of
the discussion, so I'll ignore it. *Your issues appear to deal with
representation hiding and validity checking, not with garbage
collection.
I may address the rest of your comments later (for which, thank
you very much) but this seems to be a serious point of confusion
so let me expand. *What we can have is the following sequence of
events:
At time A we create bobble X. *Space will be allocated for X as
needed, including a struct bobble_s.
what's the difference between a bobble and a bobble_s?
At time B we schedule operation zeta to be performed on X at time
E. *Don't assume that X 'knows' that about the scheduled
operation.
At time C we delete bobble X. *All space is deallocated.
I'm not sure that'sa good idea. I think you need some sort
of collection of valid Bobbles (the last big OO project I
looked at called these Repositories). Operation zeta would be
given an identifier for X and not a reference to the actual X.
At time D we allocate bobble Y. *As it chances, Y has the same
address as X.
but a different identity.
At time E the program attempts to peform the scheduled operation
on X. *It has to be able to detect that X is no longer there even
though there is a bobble around with X's address.
it asks the repository for X and provides the identifier.
The repository fails to find X and signals an error.
Simply hashing the address into an integer won't work because the
addresses are the same. *Likewise using an opaque pointer doesn't
work. *That's the point of the "unique id" - it is different for
different bobbles even though they have the same address.
apart from your solution looks slightly too complicated
don't you actaully *have* a solution?
You either ban the complete deletion of objects. Or objects
have well known places they live and unique identity. Some
OO books gone on quite a bit about identity.
Of course you can use sequence numbers as keys in a hash table or
some kind of search tree, but that is relatively computationally
expensive compared to the descriptor/locator paired structs.
I think if things can disappear behind your back then you're
going to have to live with the full horror of GUIDs.
--
Nick Keighley
The rabbit snarled and hefted his submachine gun angrily.
Ears back and teeth visible, he hissed at the cyborg.
Charles Stross "Singularit y Sky"
Richard Harter wrote:
On Tue, 04 Nov 2008 22:34:53 -0500, Eric Sosman
<es*****@ieee-dot-org.invalidwrot e:
>Richard Harter wrote:
>>On Tue, 04 Nov 2008 16:43:49 -0500, Eric Sosman
<Er*********@ sun.comwrote:
Richard Harter wrote:
[...]
I am going to throw in one curve ball. Our program will contain
reference s to created bobbles; we won't know where these are so
they can go stale when we delete bobbles. The code will need to
be able to detect that a reference has gone stale and deal with
it appropriately.
As far as I can see, the curve is orthogonal to the rest of
the discussion, so I'll ignore it. Your issues appear to deal with
representati on hiding and validity checking, not with garbage
collection .
I may address the rest of your comments later (for which, thank
you very much) but this seems to be a serious point of confusion
so let me expand. What we can have is the following sequence of
events:
At time A we create bobble X. Space will be allocated for X as
needed, including a struct bobble_s.
At time B we schedule operation zeta to be performed on X at time
E. Don't assume that X 'knows' that about the scheduled
operation.
At time C we delete bobble X. All space is deallocated.
If zeta is still armed and dangerous, this seems to me to
be an error in the program, and not something a bobblefeature
should be expected to deal with. You're asking a destroyed
bobble to "remember" its former existence somehow, so it can
still respond in some way to an attempt to do something with
its non-existent self ... It doesn't seem to me that a robust
programming discipline should rely on spirit messages from the
afterlife.
You're misreading the situation. I'm not asking the destroyed
bobble to "remember" anything. How can it, when it no longer
exists? What I proposed was that zeta be able to detect the
non-existence of X when its time came. The technique I proposed
does require that the "locator" struct remain in existence; zeta
detects the non-existence of X by the mismatch of serial numbers.
However I don't see that as an onerous requirement.
Then "all space is deallocated" seems an overstatement.
If a bobble happens to consist of two, ten, or a hundred
separately-allocated memory areas, all of them are part of
the bobble even if only one happens to be a struct bobble_s.
Delete "all space," and there is nowhere left to record the
fact that "Kilroy was a bobble."
Retaining a bobble-fragment (a bobblet?) may be tenable.
The scheme as originally outlined, though, is not: If you
follow a pointer (or whatever) from a bobble locator to a
bobble that has been freed and try to inspect the freed bobble's
data, you are a gone goose. There's no telling what you might
find at the other end of a pointer to freed memory, if you in
fact find anything at all.
You could put the ex-bobble in a pool of "currently unused
bobble-sized blocks" and thus retain the ability to look at
its memory, and even to recycle the memory to hold a newer
bobble. But that's a far cry from "all space is deallocated."
Perhaps more importantly, I completely disagree with your view
that "If zeta is still armed and dangerous, this seems to me to
be an error in the program." Au contraire, in the situations I
am interested in it is an essential capability. As an example
think about a printer and the printer software. The printer
software is supposed to be able to deal with the fact that the
printer may be off line.
There's something about your analogy I find unconvincing:
Surely there's a difference between "The printer is off-line"
and "Printer? What printer? I don't see any printer here."
I suspect this means I haven't understood you; sorry.
--
Eric Sosman es*****@ieee-dot-org.invalid cr*@tiac.net (Richard Harter) writes:
On Tue, 04 Nov 2008 16:43:49 -0500, Eric Sosman
<Er*********@su n.comwrote:
>>Richard Harter wrote:
>>Suppose we are writing a program in C and that we have a
particular kind of object (in the sense of OO programming) that I
will call bobbles. Being well disciplined programmers (Ha!) we
create a module to package our bobble related functions together.
If we were using an OO based language there would be machinery in
place, constructors, destructors, and such like, to handle the
details of our module, but in C we have to roll our own.
One of the things we need to do is to create functions that will
serve as constructors and destructors. There are two things that
we have to take care of, specifying the interface, and writing
the function internals. My concern is with specifying the
interface.
I am going to throw in one curve ball. Our program will contain
references to created bobbles; we won't know where these are so
they can go stale when we delete bobbles. The code will need to
be able to detect that a reference has gone stale and deal with
it appropriately.
As far as I can see, the curve is orthogonal to the rest of
the discussion, so I'll ignore it. Your issues appear to deal with
representatio n hiding and validity checking, not with garbage
collection.
I may address the rest of your comments later (for which, thank
you very much) but this seems to be a serious point of confusion
so let me expand. What we can have is the following sequence of
events:
At time A we create bobble X. Space will be allocated for X as
needed, including a struct bobble_s.
This is reasonable, we need to create objects.
At time B we schedule operation zeta to be performed on X at time
E. Don't assume that X 'knows' that about the scheduled
operation.
This is reasonable, we need to be able to send messages to our
objects. But note that to be able to do so, we need to have a
reference to the recipient object.
At time C we delete bobble X. All space is deallocated.
This is the weak link.
At time D we allocate bobble Y. As it chances, Y has the same
address as X.
This is reasonable, we don't have infinite memory. But either X still
exists (and therefore Y shouldn't be allocated in the same memory
space) or X doesn't exist anymore, and therefore there's no "same
address" since X doesn't exist anymore.
"an object do exist" means "there are some references to the object".
At time E the program attempts to peform the scheduled operation
on X. It has to be able to detect that X is no longer there even
though there is a bobble around with X's address.
There's no point. Either there is a reference to the object X, and
therefore X is still there, or there's no reference to X, and
therefore it doesn't matter if an object Y takes its place, and is
refered to with the same pointer.
It is clear that what's wrong in your hypotheses is "At time C we
delete bobble X. All space is deallocated." Just don't delete
objects. Once you've lost all references to an objects, your memory
management module is free to reuse the space, but not before. Yes, it
means:
Use a Garbage Collector!
If it's good enough for Apple, it should be good enough for you! http://developer.apple.com/search.ph...lt_collection&
And by the way, are you sure there are not already enough Object
Systems implemented for/over C? Isn't Objective-C good enough for you?
Also have a look at: http://ldeniau.web.cern.ch/ldeniau/html/oopc.html
--
__Pascal Bourguignon__
On Wed, 05 Nov 2008 00:22:54 GMT, cr*@tiac.net (Richard Harter)
wrote:
>On Tue, 04 Nov 2008 16:43:49 -0500, Eric Sosman
<Er*********@s un.comwrote:
>I may address the rest of your comments later (for which, thank
you very much) but this seems to be a serious point of confusion
so let me expand. What we can have is the following sequence of
events:
At time A we create bobble X. Space will be allocated for X as
needed, including a struct bobble_s.
At time B we schedule operation zeta to be performed on X at time
E. Don't assume that X 'knows' that about the scheduled
operation.
At time C we delete bobble X. All space is deallocated.
At time D we allocate bobble Y. As it chances, Y has the same
address as X.
At time E the program attempts to peform the scheduled operation
on X. It has to be able to detect that X is no longer there even
though there is a bobble around with X's address.
Quite clearly the casual phrase "all space is deallocated" led to
all sorts of interesting interpretations . I suppose it won't do
to say "all of the space used in X is deallocated" - the same
sort of confusion will arise, because people will inevitably
assume that allocate means malloc and deallocate means free. So:
Assume that we are using memory management tools that exist as a
layer over malloc/free. Assume that "allocate" means "get valid
storage objects from the memory management tools for the entity
being created". Assume that "deallocate " means return the
entity's storage objects to the memory management tools.
How the memory management tools do this is, I hope, not relevant.
Okay?
Richard Harter, cr*@tiac.net http://home.tiac.net/~cri, http://www.varinoma.com
Save the Earth now!!
It's the only planet with chocolate. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: christopher diggins |
last post by:
I have written an article on how to do Aspect Oriented Programming in
vanilla C++ (i.e. without language extensions or other tools such as
AspectC++). The article is available at
http://www.heron-language.com/aspect-cpp.html. I would appreciate some
feedback on the article, and also I would like to know whether I am
repeating some prior work.
Thanks in advance!
--
|
by: Roger Smythe |
last post by:
A means for the progressive decomposition a problem space into increasingly simpler component parts
such that these component parts represent higher levels of conceptual abstraction, and are
completely independent of each other except for their well-defined interfaces.
This was an attempt to explain the gist of OOP to programmers accustomed to the
structured programming paradigm. I tried to explain OOP in terms of ideals that can
be...
|
by: Tony Johansson |
last post by:
Hello Experts!
I reading a book called programming with design pattern revealed
by Tomasz Muldner and here I read something that I don't understand
completely.
It says
"A garbarage collector, such as the one used in Java, maintains a record of
whether or not
an object is currentlys being used. An unused object is tagged as garbage,
|
by: ROSY |
last post by:
hello experts plz answer following questions::: thanks in advance.
1. Out of fgets() and gets() which function is safe to use and why?
2. What is a far pointer? where we use it?
3. What does the error 'Null Pointer Assignment' mean and what causes
this error?
4. What is near, far and huge pointers? How many bytes are occupied by
them?
5. How would you obtain segment and offset addresses from a far
address of a memory location?
|
by: EMW |
last post by:
Hi,
When I use
Response.Write "something"
it is placed at the top op de html document above the <HTML> tag.
I need it to be put in the BODY part.
How can I do this?
rg,
| | |
by: SStory |
last post by:
3rd time trying to post this but never see it in the list:
===================================
In VB.NET, am doing the following with my MDI app..
Please advise if I am going about this wrong or there is a better way.
I thought, well, the main form needs to be able to ask the child form if it
can save
|
by: Ivan Weiss |
last post by:
I am designing a class to represent an item in a database (containing
model's of products). I need to display a listing of all of these items
in a listview to be displayed to the user (so they can select, edit, or
delete the item). To follow the right way cause I am new and learning
OOP should I create a function within the class to return all items or
in a module or in the calling form itself? I figured it shouldnt go in
the class...
|
by: AndyW |
last post by:
Hey folks.
I am trying to get a soap wsdl service working and have a bit of a
noob php programming question for it. I'm using PHP 5.x btw.
I have written a soap server that contains a single method in the
form:
SayHelloWorld( $name ) { return "Hello " .$name; };
|
by: JoeC |
last post by:
I have a question about designing objects and programming. What is the
best way to design objects? Create objects debug them and later if you
need some new features just use inhereitance. Often times when I
program, I will create objects for a specific purpose for a program and
if I need to add to it I just add the code.
|
by: Ben Bacarisse |
last post by:
cri@tiac.net (Richard Harter) writes:
<snip>
I too was going to mention the technique until I saw Eric's reply
because in your sketch you said:
| we have definitions like
|
| struct bobble_s {...};
|
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...
| | |
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,...
|
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...
|
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...
|
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 into image.
Globals.ThisAddIn.Application.ActiveDocument.Select();...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
|
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
| | |
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
|
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...
| |
