Hi, i have newbie qestion,
when i write
#include <somthing.h>
the precompiler subtitue that line with the lines from "somthing.h"
header file.
when, where and how the compiler insert the lines in "somthing.c"
implementation file into my source code?
thanks
amit
15  2250  am******@gmail.com wrote:
Hi, i have newbie qestion,
when i write
#include <somthing.h>
the precompiler subtitue that line with the lines from "somthing.h"
header file.
when, where and how the compiler insert the lines in "somthing.c"
implementation file into my source code?
In a typical implementation, the preprocessor generates an intermediate
file or data stream with header's content included inline and passes
this to the compiler.
--
Ian Collins.
On 16 Sep 2006 14:56:36 -0700, in comp.lang.c , am******@gmail.com
wrote:
>Hi, i have newbie qestion,
when i write
#include <somthing.h>
the precompiler subtitue that line with the lines from "somthing.h"
header file.
when, where and how the compiler insert the lines in "somthing.c"
implementation file into my source code?
It doesn't.
If "something" is a library, the build process will try to link with
that library to extract the machine code needed to provide the
functions. If "something" is another source file, you will need to
tell the compiler to compile it too, and then tell the linker to link
it.
--
Mark McIntyre
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan am******@gmail.com wrote:
>
when i write
#include <somthing.h>
the precompiler subtitue that line with the lines from "somthing.h"
header file.
when, where and how the compiler insert the lines in "somthing.c"
implementation file into my source code?
On the fly, during reading of the source file. It need not insert
anything, it just has to act as if it did so.
--
"The most amazing achievement of the computer software industry
is its continuing cancellation of the steady and staggering
gains made by the computer hardware industry..." - Petroski
--
Posted via a free Usenet account from http://www.teranews.com
"""
It doesn't.
If "something" is a library, the build process will try to link with
that library to extract the machine code needed to provide the
functions. If "something" is another source file, you will need to
tell the compiler to compile it too, and then tell the linker to link
it.
"""
how can it know if it is a library?
does it convert somthing.h into somthing.o and look up for it?
amit
ho
CBFalconer wrote:
am******@gmail.com wrote:
when i write
#include <somthing.h>
the precompiler subtitue that line with the lines from "somthing.h"
header file.
when, where and how the compiler insert the lines in "somthing.c"
implementation file into my source code?
On the fly, during reading of the source file. It need not insert
anything, it just has to act as if it did so.
--
"The most amazing achievement of the computer software industry
is its continuing cancellation of the steady and staggering
gains made by the computer hardware industry..." - Petroski
--
Posted via a free Usenet account from http://www.teranews.com
On 17 Sep 2006 03:27:17 -0700, am******@gmail.com wrote:
>CBFalconer wrote:
>am******@gmail.com wrote:
>
when i write
#include <somthing.h>
the precompiler subtitue that line with the lines from "somthing.h"
header file.
when, where and how the compiler insert the lines in "somthing.c"
implementation file into my source code?
On the fly, during reading of the source file. It need not insert
anything, it just has to act as if it did so.
--
"The most amazing achievement of the computer software industry
is its continuing cancellation of the steady and staggering
gains made by the computer hardware industry..." - Petroski
Top posting fixed. Please place your response after (or interspersed
with) the text you are responding to.
>"""
It doesn't.
It doesn't what? What is "it" that doesn't? What does "it" refer to?
What process should "it" be performing.
>
If "something" is a library, the build process will try to link with
If "something" is a library, it cannot be the object of a #include
directive. Libraries contain object code which will be processed by
the linker. #include works during preprocessing and deals only with
text that will become part of the source to be processed by the
compiler.
>that library to extract the machine code needed to provide the
functions. If "something" is another source file, you will need to
tell the compiler to compile it too, and then tell the linker to link
it.
You do not tell the linker to link source.
When you #include "something", the preprocessor forces the compiler,
in a system specific manner, to process the contents of "something" at
the point in your source where the #include directive was encountered.
One common method of achieving this is to copy your source into a
temporary file line by line, substituting all the lines of "something"
instead of copying the #include line. Thus, the compiler never really
processes the #include or the file it refers to. It sees only the
single file resulting from the preprocessing.
It is fairly common for headers to not include object definitions or
executable statements. They usually consist entirely of type and
object declarations, function prototypes, and macro definitions. In
this case, the result of compiling this text does not produce anything
the linker cares about.
Even if "something" does contain executable code or object
definitions, the result of compiling its text is part of the object
code built from your source file. The linker know to process this
additional object code the same way it knows to process any of your
object code.
>"""
how can it know if it is a library?
The compiler never sees a library. The #include directive does not
refer to a library. Libraries are processed at link time. How the
linker knows which libraries need to be searched for external
functions your code references is system specific.
>does it convert somthing.h into somthing.o and look up for it?
The text from "somthing" is processed as part of your source and any
resulting object code is part of your object file. somthing.o is a
system specific result of processing somthing.c, not somthing.h. In
this case, somthing.c must be the translation unit and not a #include
file. If you compile x.c and #include "somthing.c", the resulting
object file will be called x.o.
Not all systems use the .o naming convention. Mine doesn't even use
the .c convention.
Remove del for email
i think my question is misunderstood.
suppose i declare a function in "myLib.h". that function has an
implementation - lets say
that that implementation is in "myLib.c"
now if i put the line #include "myLib.h" into some code, i can use the
function of "myLib" in that code. i understand where its get the
function declaration (it's copy the lines of myLib.h into my source
code, in one way or another).
what i dont understand is where it's getting the actual function
implementation.
thanks
amit
all
Barry Schwarz wrote:
On 17 Sep 2006 03:27:17 -0700, am******@gmail.com wrote:
CBFalconer wrote:
am******@gmail.com wrote:
when i write
#include <somthing.h>
the precompiler subtitue that line with the lines from "somthing.h"
header file.
when, where and how the compiler insert the lines in "somthing.c"
implementation file into my source code?
On the fly, during reading of the source file. It need not insert
anything, it just has to act as if it did so.
--
"The most amazing achievement of the computer software industry
is its continuing cancellation of the steady and staggering
gains made by the computer hardware industry..." - Petroski
Top posting fixed. Please place your response after (or interspersed
with) the text you are responding to.
"""
It doesn't.
It doesn't what? What is "it" that doesn't? What does "it" refer to?
What process should "it" be performing.
If "something" is a library, the build process will try to link with
If "something" is a library, it cannot be the object of a #include
directive. Libraries contain object code which will be processed by
the linker. #include works during preprocessing and deals only with
text that will become part of the source to be processed by the
compiler.
that library to extract the machine code needed to provide the
functions. If "something" is another source file, you will need to
tell the compiler to compile it too, and then tell the linker to link
it.
You do not tell the linker to link source.
When you #include "something", the preprocessor forces the compiler,
in a system specific manner, to process the contents of "something" at
the point in your source where the #include directive was encountered.
One common method of achieving this is to copy your source into a
temporary file line by line, substituting all the lines of "something"
instead of copying the #include line. Thus, the compiler never really
processes the #include or the file it refers to. It sees only the
single file resulting from the preprocessing.
It is fairly common for headers to not include object definitions or
executable statements. They usually consist entirely of type and
object declarations, function prototypes, and macro definitions. In
this case, the result of compiling this text does not produce anything
the linker cares about.
Even if "something" does contain executable code or object
definitions, the result of compiling its text is part of the object
code built from your source file. The linker know to process this
additional object code the same way it knows to process any of your
object code.
"""
how can it know if it is a library?
The compiler never sees a library. The #include directive does not
refer to a library. Libraries are processed at link time. How the
linker knows which libraries need to be searched for external
functions your code references is system specific.
does it convert somthing.h into somthing.o and look up for it?
The text from "somthing" is processed as part of your source and any
resulting object code is part of your object file. somthing.o is a
system specific result of processing somthing.c, not somthing.h. In
this case, somthing.c must be the translation unit and not a #include
file. If you compile x.c and #include "somthing.c", the resulting
object file will be called x.o.
Not all systems use the .o naming convention. Mine doesn't even use
the .c convention.
Remove del for email
In article <11*********************@m7g2000cwm.googlegroups.c om>,
<am******@gmail.comwrote:
>i think my question is misunderstood.
>suppose i declare a function in "myLib.h". that function has an
implementation - lets say
that that implementation is in "myLib.c"
>now if i put the line #include "myLib.h" into some code, i can use the
function of "myLib" in that code. i understand where its get the
function declaration (it's copy the lines of myLib.h into my source
code, in one way or another).
what i dont understand is where it's getting the actual function
implementation.
The language itself doesn't answer this question: the standards
just say that external linkage -exists-, and gives very minimal properties
for it, but does not say anything about how it works.
In the past, there have been C implementations for which it was
necessary to name all the source files on the compiler command line and
which interpreted all of the lines of code as necessary, so everything
had to be named at once..
In every system that I have actually used, the C compiler provided
a way to compile source seperately to some intermediate binary state,
and the implimentation provided a mechanism to merge ("link") (possibly
transforming greatly) the intermediate binary forms into a single
executable. The intermediate forms have not always been machine code
suitable for the target: sometimes they are in an assembler-style
language that the linker rewrites into machine code.
The answer to "where does it find the implementation of a function" then
becomes "where-ever you tell the implementation's linker to look
for the the intermediate file produced by the C compiler."
It is fairly common with modern implementations that if you name
a series of source files on a single compiler command line, that
the compiler will automatically convert each of them to intermediate
form and then automatically link them together to an executable.
--
I was very young in those days, but I was also rather dim.
-- Christopher Priest
On 17 Sep 2006 03:27:17 -0700, in comp.lang.c , am******@gmail.com
wrote:
>"""
It doesn't.
If "something" is a library, the build process will try to link with
that library to extract the machine code needed to provide the
functions. If "something" is another source file, you will need to
tell the compiler to compile it too, and then tell the linker to link
it.
"""
how can it know if it is a library?
Because thats how it was provided to you.
The header by itself is useless. It has to have a library or source
file or object or something to contain the actual code.
>does it convert somthing.h into somthing.o and look up for it?
No.
--
Mark McIntyre
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
On Sun, 17 Sep 2006 08:22:02 -0700, in comp.lang.c , Barry Schwarz
<sc******@doezl.netwrote:
>Top posting fixed. Please place your response after (or interspersed
with) the text you are responding to.
>>"""
It doesn't.
It doesn't what? What is "it" that doesn't? What does "it" refer to?
What process should "it" be performing.
Amit didn't say that, I did, immediately below the line where he asked
>>when, where and how the compiler insert the lines in "somthing.c"
implementation file into my source code?
... and thus in a context where "it" was utterly clear.
Your "fixing" of top-posting in fact merely screwed the post up so
that you had no idea who said what, and in relation to what.
I suggest you start again !
>>If "something" is a library, the build process will try to link with
If "something" is a library, it cannot be the object of a #include
directive.
Have you got a clue what you're commenting on at this point? Stop,
wander back, and read the thread again.
>>that library to extract the machine code needed to provide the
functions. If "something" is another source file, you will need to
tell the compiler to compile it too, and then tell the linker to link
it.
You do not tell the linker to link source.
And you seem to be unable to read for sense..... (though I admit I
used 'it' a bit too much. I could have more longwindedly said 'to link
the results of that second compilation')
>When you #include "something", the preprocessor forces the compiler,
in a system specific manner, to process the contents of "something" at
the point in your source where the #include directive was encountered.
Sure, but Amit's question was - where does the compiler get the actual
defintions of the functions from, since he _is well aware_ that
they're not in the header.
--
Mark McIntyre
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
On Sun, 17 Sep 2006 17:49:12 +0100, Mark McIntyre
<ma**********@spamcop.netwrote:
>On Sun, 17 Sep 2006 08:22:02 -0700, in comp.lang.c , Barry Schwarz
<sc******@doezl.netwrote:
>>Top posting fixed. Please place your response after (or interspersed
with) the text you are responding to.
>>>"""
It doesn't.
It doesn't what? What is "it" that doesn't? What does "it" refer to?
What process should "it" be performing.
Amit didn't say that, I did, immediately below the line where he asked
Here is the beginning portion of the text of the message from amit I
was responding to quoted from Google
<quote>
"""
It doesn't.
If "something" is a library, the build process will try to link with
that library to extract the machine code needed to provide the
functions. If "something" is another source file, you will need to
tell the compiler to compile it too, and then tell the linker to link
it.
"""
how can it know if it is a library?
does it convert somthing.h into somthing.o and look up for it?
amit
ho
- Hide quoted text -
- Show quoted text -
CBFalconer wrote:
amit....@gmail.com wrote:
when i write
#include <somthing.h>
</quote>
The line you claim he didn't write is the first line in his message.
Maybe he didn't write it and you did. But there is nothing in his
message to indicate it came from you and not him.
>>>when, where and how the compiler insert the lines in "somthing.c"
implementation file into my source code?
.. and thus in a context where "it" was utterly clear.
Your "fixing" of top-posting in fact merely screwed the post up so
that you had no idea who said what, and in relation to what.
I did not move any text he attributed to you. Furthermore, I did not
remove any attributions in his message. In fact, the only thing I
moved was his top posting down to his first attribution. If there are
any misattributions, they were already in his message. Nor did I
comment on any text attributed to you.
>
I suggest you start again !
Start again from what? Text clearly marked in the original as amit's
you claim is yours. If this is true, then my only comment is GIGO.
>
>>>If "something" is a library, the build process will try to link with
If "something" is a library, it cannot be the object of a #include
directive.
Have you got a clue what you're commenting on at this point? Stop,
wander back, and read the thread again.
>>>that library to extract the machine code needed to provide the
functions. If "something" is another source file, you will need to
tell the compiler to compile it too, and then tell the linker to link
it.
You do not tell the linker to link source.
And you seem to be unable to read for sense..... (though I admit I
used 'it' a bit too much. I could have more longwindedly said 'to link
the results of that second compilation')
amit's question appears to have been answered so I see no point in
continuing. Since your assertions regarding authorship are
inconsistent with the text of the message I was responding to, you're
welcome to respond with additional ad hominems if you feel the need to
get the last word in.
Remove del for email
thank you all,
i found this link that togther with your comments, set it right for me. http://www.linuxjournal.com/article/6463
cheers
amit
Barry Schwarz wrote:
On Sun, 17 Sep 2006 17:49:12 +0100, Mark McIntyre
<ma**********@spamcop.netwrote:
On Sun, 17 Sep 2006 08:22:02 -0700, in comp.lang.c , Barry Schwarz
<sc******@doezl.netwrote:
>Top posting fixed. Please place your response after (or interspersed
with) the text you are responding to.
"""
It doesn't.
It doesn't what? What is "it" that doesn't? What does "it" refer to?
What process should "it" be performing.
Amit didn't say that, I did, immediately below the line where he asked
Here is the beginning portion of the text of the message from amit I
was responding to quoted from Google
<quote>
"""
It doesn't.
If "something" is a library, the build process will try to link with
that library to extract the machine code needed to provide the
functions. If "something" is another source file, you will need to
tell the compiler to compile it too, and then tell the linker to link
it.
"""
how can it know if it is a library?
does it convert somthing.h into somthing.o and look up for it?
amit
ho
- Hide quoted text -
- Show quoted text -
CBFalconer wrote:
amit....@gmail.com wrote:
when i write
#include <somthing.h>
</quote>
The line you claim he didn't write is the first line in his message.
Maybe he didn't write it and you did. But there is nothing in his
message to indicate it came from you and not him.
>>when, where and how the compiler insert the lines in "somthing.c"
implementation file into my source code?
.. and thus in a context where "it" was utterly clear.
Your "fixing" of top-posting in fact merely screwed the post up so
that you had no idea who said what, and in relation to what.
I did not move any text he attributed to you. Furthermore, I did not
remove any attributions in his message. In fact, the only thing I
moved was his top posting down to his first attribution. If there are
any misattributions, they were already in his message. Nor did I
comment on any text attributed to you.
I suggest you start again !
Start again from what? Text clearly marked in the original as amit's
you claim is yours. If this is true, then my only comment is GIGO.
>>If "something" is a library, the build process will try to link with
If "something" is a library, it cannot be the object of a #include
directive.
Have you got a clue what you're commenting on at this point? Stop,
wander back, and read the thread again.
>>that library to extract the machine code needed to provide the
functions. If "something" is another source file, you will need to
tell the compiler to compile it too, and then tell the linker to link
it.
You do not tell the linker to link source.
And you seem to be unable to read for sense..... (though I admit I
used 'it' a bit too much. I could have more longwindedly said 'to link
the results of that second compilation')
amit's question appears to have been answered so I see no point in
continuing. Since your assertions regarding authorship are
inconsistent with the text of the message I was responding to, you're
welcome to respond with additional ad hominems if you feel the need to
get the last word in.
Remove del for email
am******@gmail.com writes:
thank you all,
i found this link that togther with your comments, set it right for me.
http://www.linuxjournal.com/article/6463
Great.
If you have any more questions, please remember not to top-post.
Read <http://www.caliburn.nl/topposting.html>.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this. am******@gmail.com wrote:
i think my question is misunderstood.
If you can't be bothered to pay attention to simple instructions, like
this:
Top posting fixed. Please place your response after (or
interspersed with) the text you are responding to.
Then why should we pay attention to you?
Brian
On 17 Sep 2006 09:21:14 -0700, in comp.lang.c , am******@gmail.com
wrote:
>i think my question is misunderstood.
suppose i declare a function in "myLib.h". that function has an
implementation - lets say
that that implementation is in "myLib.c"
now if i put the line #include "myLib.h" into some code, i can use the
function of "myLib" in that code. i understand where its get the
function declaration (it's copy the lines of myLib.h into my source
code, in one way or another).
what i dont understand is where it's getting the actual function
implementation.
This is the second part of my original answer.
You have to tell the compiler to compile both files, and then tell the
linker to link the results together to make the executable.
How you do this is compiler-specific. With most compilers you can
chain the filenames together eg
$ cc file1.c file2.c
--
Mark McIntyre
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
<am******@gmail.comwrote in message
news:11*********************@m7g2000cwm.googlegrou ps.com...
i think my question is misunderstood.
suppose i declare a function in "myLib.h". that function has an
implementation - lets say
that that implementation is in "myLib.c"
This matching of names is pure convention. For this to occur "myLib.h" must
define a sub routine name thats also in "MyLib.c".
now if i put the line #include "myLib.h" into some code, i can use the
function of "myLib" in that code. i understand where its get the
function declaration (it's copy the lines of myLib.h into my source
code, in one way or another).
what i dont understand is where it's getting the actual function
implementation.
It gets that at the end. The source lines don't get included, the loader
pulls the compiled modules together at the end
thanks
amit
all
Barry Schwarz wrote:
On 17 Sep 2006 03:27:17 -0700, am******@gmail.com wrote:
>CBFalconer wrote:
>am******@gmail.com wrote:
>
when i write
>
#include <somthing.h>
>
the precompiler subtitue that line with the lines from "somthing.h"
header file.
when, where and how the compiler insert the lines in "somthing.c"
implementation file into my source code?
>>
>On the fly, during reading of the source file. It need not insert
>anything, it just has to act as if it did so.
>>
>--
>"The most amazing achievement of the computer software industry
> is its continuing cancellation of the steady and staggering
> gains made by the computer hardware industry..." - Petroski
>>
Top posting fixed. Please place your response after (or interspersed
with) the text you are responding to.
>"""
>It doesn't.
It doesn't what? What is "it" that doesn't? What does "it" refer to?
What process should "it" be performing.
>
>If "something" is a library, the build process will try to link with
If "something" is a library, it cannot be the object of a #include
directive. Libraries contain object code which will be processed by
the linker. #include works during preprocessing and deals only with
text that will become part of the source to be processed by the
compiler.
>that library to extract the machine code needed to provide the
>functions. If "something" is another source file, you will need to
>tell the compiler to compile it too, and then tell the linker to link
>it.
You do not tell the linker to link source.
When you #include "something", the preprocessor forces the compiler,
in a system specific manner, to process the contents of "something" at
the point in your source where the #include directive was encountered.
One common method of achieving this is to copy your source into a
temporary file line by line, substituting all the lines of "something"
instead of copying the #include line. Thus, the compiler never really
processes the #include or the file it refers to. It sees only the
single file resulting from the preprocessing.
It is fairly common for headers to not include object definitions or
executable statements. They usually consist entirely of type and
object declarations, function prototypes, and macro definitions. In
this case, the result of compiling this text does not produce anything
the linker cares about.
Even if "something" does contain executable code or object
definitions, the result of compiling its text is part of the object
code built from your source file. The linker know to process this
additional object code the same way it knows to process any of your
object code.
>"""
>
>how can it know if it is a library?
The compiler never sees a library. The #include directive does not
refer to a library. Libraries are processed at link time. How the
linker knows which libraries need to be searched for external
functions your code references is system specific.
>does it convert somthing.h into somthing.o and look up for it?
The text from "somthing" is processed as part of your source and any
resulting object code is part of your object file. somthing.o is a
system specific result of processing somthing.c, not somthing.h. In
this case, somthing.c must be the translation unit and not a #include
file. If you compile x.c and #include "somthing.c", the resulting
object file will be called x.o.
Not all systems use the .o naming convention. Mine doesn't even use
the .c convention.
Remove del for email
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: patrick.m.lahey |
last post by:
Newbie here...
Ok, the following code:
class Base:
_count = 0
def __init__(self):
self.__class__._count += 1
print dir(self)
|
by: google |
last post by:
The DBA duties at my company have gotten to the point where I am unable
to complete them all on my own so we decided to hire a new DBA. After
weeks of searching and interviewing we are coming up...
|
by: sachin |
last post by:
When we view any document in print preview dialog, where does it save the document? such that when me move to next/previous page where it reads the information from . If a heavy document like RTF...
|
by: noleander |
last post by:
Hi. I've got a C++ program written in Visual C++ 2003. The program is
trivial, created with the Program-creation wizard: used the .NET "Form"
template. The program has a trivial...
|
by: Phil |
last post by:
My regional setting (on Win2000) is:
(General Tab)Locale = English (US)
(Date Tab), short date = MM/dd/yy
When I ask .Net DateFormat.ShortDatePattern,
I get MM/dd/yyyy
Now, where does the...
|
by: Daniel |
last post by:
where does Microsoft.Xml.Xquery live?
where does Microsoft.Xml.Xquery live? all i can find is a copy of it in the
sample project:...
|
by: DanielJohnson |
last post by:
I am wondering where does the value returned by main goes. Suppoes
main returns some number say 42, where is it stored.
Supposed a shell script call a C program and the program returns the
value...
|
by: AAaron123 |
last post by:
Where does the "Extreme database" come from?
During a solution conversion, VS told me it needed to install the "Crystal
Reports" so I inserted the disk and during the installation or conversion I...
|
by: sanchaita |
last post by:
I wanted to know where does the WPHOST.db file corresponding to the post office in a novell groupwise gets stored.
Does it get stored in our local disc. If yes, then where?. And where does the...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: 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...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
| |
