473,882 Members | 1,646 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Header include order

It seems like, in every C source file I've ever seen, there has been a
very definite include order, as follows:

- include system headers
- include application headers
- include the header associated with this source file

For example, in a file hello.c:

#include <stdio.h>
#include "utils.h"
#include "hello.h"

(Incidentally I think that a source file which doesn't include the header
file which exports its symbols is _very_ bad, as this is a good way to
check for inconsistencies for free.)

I would argue that the standard order of header including is wrong,
and that the correct order is the reverse. Consider this scenario:

hello.c:
#include <stdlib.h>
#include "hello.h"

hello.h:
struct blah {
size_t size;
};

hello2.c
#include "hello.h"

Inexplicably (from the perspective of the person doing the including)
the file hello.h will cause compiler errors in hello2.c but not in hello.c.
If hello.c were written first, and then the include file used elsewhere,
the error would appear to be "new", and not be caught by those who wrote
hello.c, implementing the functionality exported by hello.h.

If this include order is used, this problem is averted:

- include the header associated with this source file
- include application headers
- include system headers

This is good for two reasons:
1. All headers must now include any system headers they need, and will
fail immediately if they don't.
2. Every header will be included in at least ONE source file before
anything else (the source file associated with that header), allowing
any intra-application dependencies to be caught.

Does anyone have a reasonable justification for the standard include
order that I haven't thought of? Thanks.

--
Derrick Coetzee
Nov 13 '05
60 8334
E. Robert Tisdale <E.************ **@jpl.nasa.gov > wrote:
Alex wrote:
E. Robert Tisdale wrote:
Alex wrote:

$ cat test.c
#define _SIZE_T
#include <stdlib.h>

size_t size = 32;

$ gcc -W -Wall -ansi -pedantic test.c

Evidently, this is *not* the Sun C compiler for Solaris 2.6
but some version of the GNU C compiler.


No, but the headers being used, to the best of my knowledge,
*are* from the Sun C compiler:

/*
* Copyright (c) 1996, by Sun Microsystems, Inc.
* All Rights reserved.
*/ Perhaps, but not likely. Type gcc -v -W -Wall -ansi -pedantic test.c
I don't need to. From the output I posted earlier

/usr/include/stdlib.h:106: warning: parameter names <...>

....you can clearly see the path. This is indeed the file
with the Sun copyright you see above.
The stdlib.h distributed with gcc version 3.2
includes stddef.h to define size_t. I get
That's nice. It doesn't have to. Did I say differently?
Yes. I said:
Where is the definition for size_t?
You said:
In a header file included by stdlib.h

It doesn't have to be. It *could* be defined in stdlib.h.
Which, I thought, was pretty obvious. However, you went
out on a tangent, trying to make me prove that there is
indeed an implementation where size_t is defined in
stdlib.h. Such proof is inherently irrelevant!
For a change of pace. Please prove that all past, present,
and future implementations have/do/will always include another
header within stdlib.h in order to define size_t.
I *never* claimed that all past or future implementations
must include another header file in stdlib.h to define size_t.
All I asked you to do is show us *one* implementation that does not.
If you are aware of the fact that there *can* be an
implementation where size_t is defined in stdlib.h, why
are you arguing? Are you going to write code to depend
on that fact (I wonder how...) until I find you an
implementation where it would fail? Which I did.

Until such time, if you are interested in specific implementations ,
please refer to the appropriate newsgroups.
As far as this newsgroup is concerned, your assertion is baseless.

You're the one who claims that your implementation defines size_t
in stdlib.h itself.
You claimed that stdlib.h includes another header to
define size_t. I pointed out that it was speculation
on your part, since the standard does not define it.
The point is that the ANSI/ISO C standards are very carefully written
to avoid specifying any unnecessary details about the implementation.
You need to be very careful when making statements about implementations
based upon your interpretation of the standards.


That is *my* point. Again, you said that stdlib.h
includes a header to define size_t. I pointed out
that it doesn't have to, according to the standard.

Can it be any simpler than that? Are you trolling?

Alex
Nov 13 '05 #51
Alex wrote:
E. Robert Tisdale wrote:
Alex wrote:
E. Robert Tisdale wrote:

Alex wrote:

>$ cat test.c
>#define _SIZE_T
>#include <stdlib.h>
>
>size_t size = 32;
>
>$ gcc -W -Wall -ansi -pedantic test.c

Evidently , this is *not* the Sun C compiler for Solaris 2.6
but some version of the GNU C compiler.

No, but the headers being used, to the best of my knowledge,
*are* from the Sun C compiler:

/*
* Copyright (c) 1996, by Sun Microsystems, Inc.
* All Rights reserved.
*/
Perhaps, but not likely. Type

gcc -v -W -Wall -ansi -pedantic test.c


I don't need to. From the output I posted earlier

/usr/include/stdlib.h:106: warning: parameter names <...>

...you can clearly see the path.
This is indeed the file with the Sun copyright you see above.


I found this same copyright notice in 88 header files
in the implementation distributed with version 3.2 of gcc.
Regardless of origin, your stdlib.h header file
is almost certainly part of the GNU C implementation
distributed with gcc.

The stdlib.h distributed with gcc version 3.2
includes stddef.h to define size_t. I get

That's nice. It doesn't have to.
Did I say differently?
Yes. I said:
Where is the definition for size_t?
You said:
In a header file included by stdlib.h
It doesn't have to be. It *could* be defined in stdlib.h.


I never said differently.
But the fact that size_t *could* be defined in stdlib.h itself
does *not* mean that size_t *is* defined in stdlib.h itself.
Which, I thought, was pretty obvious. However,
you went out on a tangent, trying to make me prove that
there is indeed an implementation
where size_t is defined in stdlib.h.
Such proof is inherently irrelevant!
It is *not* irrelevant to your claim
that you have found an implementation
where size_t is actually defined in stdlib.h itself.
Are you prepared to concede that you were wrong?
For a change of pace. Please prove that all past, present,
and future implementations have/do/will always include another
header within stdlib.h in order to define size_t.
I *never* claimed that all past or future implementations
must include another header file in stdlib.h to define size_t.
All I asked you to do is show us *one* implementation that does not.


If you are aware of the fact that there *can* be an implementation
where size_t is defined in stdlib.h, why are you arguing?


I assume that you agree that since the ANSI/ISO C standards
do not specify that size_t is defined in stdlib.h itself
and not in any included header file, all implementations
*could* define size_t in a header file included by stdlib.h.
My assertion is simply that, in fact, all implementations
*do* define size_t in a header file included by stdlib.h.
All you need to do to disprove my assertion is to provide
one example of an implementation that actually defines size_t
in stdlib.h itself.
Are you going to write code to depend on that fact (I wonder how...)
until I find you an implementation where it would fail? Which I did.


No. You haven't demonstrated that
size_t is actually defined in stdlib.h itself.
Until such time, if you are interested in specific implementations ,
please refer to the appropriate newsgroups.
As far as this newsgroup is concerned, your assertion is baseless.
You're the one who claims that your implementation defines size_t
in stdlib.h itself.


You claimed that stdlib.h includes another header to define size_t.
I pointed out that it was speculation on your part
since the standard does not define it.


And I have pointed out that the ANSI/ISO C standards are irrelevant
to the question of whether or not size_t is defined in a header file
included by stdlib.h.
You are just ignorant of all the other considerations,
besides the standard, that go into an implementation.
For example, size_t is useful at a much lower level than stdlib.h
in most implementations so it is *always* defined
in a lower level header file included in stdlib.h.
The point is that the ANSI/ISO C standards are very carefully written
to avoid specifying any unnecessary details about the implementation.
You need to be very careful when making statements about implementations
based upon your interpretation of the standards.


That is *my* point. Again, you said that stdlib.h
includes a header to define size_t. I pointed out
that it doesn't have to, according to the standard.


And I never argued this point. I only asserted that
size_t was actually defined in a header file included by stdlib.h.
The absence of even one contradictory example supports my assertion.

Nov 13 '05 #52
E. Robert Tisdale <E.************ **@jpl.nasa.gov > wrote:
Alex wrote:
E. Robert Tisdale wrote:
The point is that the ANSI/ISO C standards are very carefully written
to avoid specifying any unnecessary details about the implementation.
You need to be very careful when making statements about implementations
based upon your interpretation of the standards.
That is *my* point. Again, you said that stdlib.h
includes a header to define size_t. I pointed out
that it doesn't have to, according to the standard.

And I never argued this point. I only asserted that
size_t was actually defined in a header file included by stdlib.h.
The absence of even one contradictory example supports my assertion.


You are obviously trolling. I resign from this discussion.

Alex
Nov 13 '05 #53
Alex wrote:
I have lost this argument so you're a troll.


Nov 13 '05 #54
On Mon, 24 Nov 2003 14:13:56 -0800
"E. Robert Tisdale" <E.************ **@jpl.nasa.gov > wrote:
Alex wrote:
E. Robert Tisdale wrote:
Alex wrote:
E. Robert Tisdale wrote:

>Alex wrote:
>
>>$ cat test.c
>>#define _SIZE_T
>>#include <stdlib.h>
>>
>>size_t size = 32;
>>
>>$ gcc -W -Wall -ansi -pedantic test.c
>
>Evidently , this is *not* the Sun C compiler for Solaris 2.6
>but some version of the GNU C compiler.

No, but the headers being used, to the best of my knowledge,
*are* from the Sun C compiler:

/*
* Copyright (c) 1996, by Sun Microsystems, Inc.
* All Rights reserved.
*/

Perhaps, but not likely. Type

gcc -v -W -Wall -ansi -pedantic test.c


I don't need to. From the output I posted earlier

/usr/include/stdlib.h:106: warning: parameter names <...>

...you can clearly see the path.
This is indeed the file with the Sun copyright you see above.


I found this same copyright notice in 88 header files
in the implementation distributed with version 3.2 of gcc.
Regardless of origin, your stdlib.h header file
is almost certainly part of the GNU C implementation
distributed with gcc.


Since according to you the GCC headers are copyright Sun, perhaps you
will accept a header copyright IBM that was distributed with either AIC
or the AIX compiler?

/* IBM_PROLOG_BEGI N_TAG */
/* This is an automatically generated prolog. */
/* */
/* bos43V src/bos/usr/include/stdlib.h 1.31.6.2 */
/* */
/* Licensed Materials - Property of IBM */
/* */
/* (C) COPYRIGHT International Business Machines Corp. 1985,1995 */

....
#ifndef _H_STANDARDS
#include <standards.h>
#endif

The above is the only file included by this header, and is does not
define SIZE_T not does it include anything else

#ifndef _SIZE_T
#define _SIZE_T
typedef unsigned long size_t;
#endif

So with the version of CC and headers that IBM provide size_t IS defined
in stdlib.h and NOT in a file included by it.

Obviously I can't post the include files in there entirety since they
are copyright, so you can either believe me, buy a copy of AIX and it's
development system, or call me a lier.
>The stdlib.h distributed with gcc version 3.2
>includes stddef.h to define size_t. I get

That's nice. It doesn't have to.

Did I say differently?


Yes. I said:
>>Where is the definition for size_t?


You said:
>In a header file included by stdlib.h


It doesn't have to be. It *could* be defined in stdlib.h.


I never said differently.
But the fact that size_t *could* be defined in stdlib.h itself
does *not* mean that size_t *is* defined in stdlib.h itself.


You said "In a header included by stdlib.h" not "Possibly in a header
included by stdlib.h" so you have definitely been proved wrong. since on
AIX 4.3 it IS defined in stdlib.h and NOT in any headers included by
stdlib.h.
Which, I thought, was pretty obvious. However,
you went out on a tangent, trying to make me prove that
there is indeed an implementation
where size_t is defined in stdlib.h.
Such proof is inherently irrelevant!


It is *not* irrelevant to your claim
that you have found an implementation
where size_t is actually defined in stdlib.h itself.
Are you prepared to concede that you were wrong?


Why should he when he is correct?
For a change of pace. Please prove that all past, present,
and future implementations have/do/will always include another
header within stdlib.h in order to define size_t.

I *never* claimed that all past or future implementations
must include another header file in stdlib.h to define size_t.
All I asked you to do is show us *one* implementation that does not.


If you are aware of the fact that there *can* be an implementation
where size_t is defined in stdlib.h, why are you arguing?


I assume that you agree that since the ANSI/ISO C standards
do not specify that size_t is defined in stdlib.h itself
and not in any included header file, all implementations
*could* define size_t in a header file included by stdlib.h.
My assertion is simply that, in fact, all implementations
*do* define size_t in a header file included by stdlib.h.


You are wrong, see above.
All you need to do to disprove my assertion is to provide
one example of an implementation that actually defines size_t
in stdlib.h itself.
Done. Although it looks to me like you already had an example.
Are you going to write code to depend on that fact (I wonder how...)
until I find you an implementation where it would fail? Which I
did.


No. You haven't demonstrated that
size_t is actually defined in stdlib.h itself.


It looked like it was defined there to me, it just had protection
against duplicate definitions so you could include all the headers that
define it which the standard allows you to do.
Until such time, if you are interested in specific implementations ,
please refer to the appropriate newsgroups.
As far as this newsgroup is concerned, your assertion is baseless.

You're the one who claims that your implementation defines size_t
in stdlib.h itself.


You claimed that stdlib.h includes another header to define size_t.
I pointed out that it was speculation on your part
since the standard does not define it.


And I have pointed out that the ANSI/ISO C standards are irrelevant
to the question of whether or not size_t is defined in a header file
included by stdlib.h.
You are just ignorant of all the other considerations,
besides the standard, that go into an implementation.
For example, size_t is useful at a much lower level than stdlib.h
in most implementations so it is *always* defined
in a lower level header file included in stdlib.h.


WRONG
The point is that the ANSI/ISO C standards are very carefully
written to avoid specifying any unnecessary details about the
implementatio n. You need to be very careful when making statements
about implementations based upon your interpretation of the
standards.


That is *my* point. Again, you said that stdlib.h
includes a header to define size_t. I pointed out
that it doesn't have to, according to the standard.


And I never argued this point. I only asserted that
size_t was actually defined in a header file included by stdlib.h.


You actually stated that it IS defined in a header included by stdlib.h
and you have done so even more clearly and explicitly in the post.
The absence of even one contradictory example supports my assertion.


Absence of proof is not proof of absence. Anyway, your original
assertion and fallacious statement of fact are disproved by the IBM
implementation.
--
Mark Gordon
Paid to be a Geek & a Senior Software Developer
Although my email address says spamtrap, it is real and I read it.
Nov 13 '05 #55
Mark Gordon wrote:
On Mon, 24 Nov 2003 14:13:56 -0800
"E. Robert Tisdale" <E.************ **@jpl.nasa.gov > wrote:

Alex wrote:

E. Robert Tisdale wrote:
Alex wrote:

>E. Robert Tisdale wrote:
>
>
>>Alex wrote:
>>
>>
>>>$ cat test.c
>>>#defin e _SIZE_T
>>>#inclu de <stdlib.h>
>>>
>>>size_t size = 32;
>>>
>>>$ gcc -W -Wall -ansi -pedantic test.c
>>
>>Evidently , this is *not* the Sun C compiler for Solaris 2.6
>>but some version of the GNU C compiler.
>
>No, but the headers being used, to the best of my knowledge,
>*are* from the Sun C compiler:
>
> /*
> * Copyright (c) 1996, by Sun Microsystems, Inc.
> * All Rights reserved.
> */

Perhaps, but not likely. Type

gcc -v -W -Wall -ansi -pedantic test.c

I don't need to. From the output I posted earlier

/usr/include/stdlib.h:106: warning: parameter names <...>

...you can clearly see the path.
This is indeed the file with the Sun copyright you see above.


I found this same copyright notice in 88 header files
in the implementation distributed with version 3.2 of gcc.
Regardless of origin, your stdlib.h header file
is almost certainly part of the GNU C implementation
distributed with gcc.

Since according to you the GCC headers are copyright Sun, perhaps you
will accept a header copyright IBM that was distributed with either AIC
or the AIX compiler?

/* IBM_PROLOG_BEGI N_TAG */
/* This is an automatically generated prolog. */
/* */
/* bos43V src/bos/usr/include/stdlib.h 1.31.6.2 */
/* */
/* Licensed Materials - Property of IBM */
/* */
/* (C) COPYRIGHT International Business Machines Corp. 1985,1995 */

...
#ifndef _H_STANDARDS
#include <standards.h>
#endif

The above is the only file included by this header, and is does not
define SIZE_T not does it include anything else

#ifndef _SIZE_T
#define _SIZE_T
typedef unsigned long size_t;
#endif

So with the version of CC and headers that IBM provide size_t IS defined
in stdlib.h and NOT in a file included by it.

Obviously I can't post the include files in there entirety since they
are copyright, so you can either believe me, buy a copy of AIX and it's
development system, or call me a lier.

>>The stdlib.h distributed with gcc version 3.2
>>include s stddef.h to define size_t. I get
>
>That's nice. It doesn't have to.

Did I say differently?

Yes. I said:
>>>Where is the definition for size_t?
>>
You said:
>>In a header file included by stdlib.h
>
It doesn't have to be. It *could* be defined in stdlib.h.


I never said differently.
But the fact that size_t *could* be defined in stdlib.h itself
does *not* mean that size_t *is* defined in stdlib.h itself.

You said "In a header included by stdlib.h" not "Possibly in a header
included by stdlib.h" so you have definitely been proved wrong. since on
AIX 4.3 it IS defined in stdlib.h and NOT in any headers included by
stdlib.h.


I stand corrected. I ammend my assertion to
"size_t is defined in a header file included by stdlib.h
except for the IBM AIC or AIX compiler."

Nov 13 '05 #56
E. Robert Tisdale wrote:
CBFalconer wrote:
<troll banners>
Evidently, your definition of a troll is anyone who disagrees with you.
No. I have disagreed with Chuck on many occasions, and yet he has never
called me a troll. Therefore, your statement is incorrect.
For you, it's just another epithet that you hurl at an opponent.
No. He just hurls it at trolls.
You resort to ad hominem attacks
Loads of people have tried reasoning with you. It never works, because you
blithely ignore almost every criticism people make. So in the end, lots of
people stopped bothering.

Now that we know you respond to cartoons, expect more cartoons.
when you have lost an argument
and have no valid argument to contribute to the discussion.
Oh, we have plenty of valid arguments, stretching back many years. When are
you planning to deal with those arguments?
The use of such an obviously fallacious argument shows contempt
for subscribers if you really expect to sway them with it.
It was a cartoon, not an argument. We've done the arguments already.
Or do you honestly believe that you are making a valid argument?


We've made loads. Google for almost any comp.lang.c thread containing the
word "Tisdale" for a whole bunch of reasons why you are wrong.

--
Richard Heathfield : bi****@eton.pow ernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 13 '05 #57
On Mon, 24 Nov 2003 17:49:25 -0800
"E. Robert Tisdale" <E.************ **@jpl.nasa.gov > wrote:
Mark Gordon wrote:
<snip>
Since according to you the GCC headers are copyright Sun, perhaps
you will accept a header copyright IBM that was distributed with
either AIC or the AIX compiler?

^^^ AIX

<snip>
I stand corrected. I ammend my assertion to
"size_t is defined in a header file included by stdlib.h
except for the IBM AIC or AIX compiler."


How do you know there is no other implementation where size_t is not
defined in stdlib.h?

Just accept that you were wrong in your assertion
and that you are wrong to claim to know what every single
implementation of C does.
--
Mark Gordon
Paid to be a Geek & a Senior Software Developer
Although my email address says spamtrap, it is real and I read it.
Nov 13 '05 #58
Mark Gordon wrote:
How do you know that there is no other implementation
where size_t is not defined in stdlib.h?


How do you know that there *is* another implementation
where size_t is not defined in stdlib.h?

Nov 13 '05 #59
E. Robert Tisdale wrote:
Mark Gordon wrote:
How do you know that there is no other implementation
where size_t is not defined in stdlib.h?


How do you know that there *is* another implementation
where size_t is not defined in stdlib.h?


And this kind of silly argument is /precisely/ why we go by What The
Standard Says.

The Standard, in this case, requires stdlib.h to declare the size_t type,
but neither forbids it from doing so, nor requires it to do so,
specifically by including some other header. Therefore, it is foolish for
us to write C code that relies either on the inclusion, or on the
non-inclusion, by stdlib.h of some other header for that declaration.

--
Richard Heathfield : bi****@eton.pow ernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 13 '05 #60

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

Similar topics

8
6434
by: qazmlp | last post by:
I need to include a list of - C++ headers - headers of other modules - headers of my module - implementation specific ie.OS headers In what order, they should be included in my .CPP file? What is the best followed approach?
7
2098
by: header_question | last post by:
Is it best to place all #include files in one header file seperate from all the other files in a project? What is the logic that determines the order of the #include files, does it depend on the order of function calls in main?
11
2767
by: Steven T. Hatton | last post by:
In the past there have been lengthy discussiions regarding the role of header files in C++. People have been very adamat about header files serving as in interface to the implementation. I do understand the objective. This example may represent an interface in need of a bit of refactoring, but it goes to demonstrate the basic idea as I understand it. http://developer.kde.org/documentation/library/cvs-api/kdevelop/html/ast_8h-source.html...
3
3106
by: pooja | last post by:
Suppose i have created a class c1 with f1()in c1.cpp and included this c1.cpp in file1.cpp file , which is also having main() by giving the statement #include "c1.cpp". the same i can do by using header file. i can create a class c1 with f1() in c1.h and include this c1.h in file1.cpp by giving the statement #include "c1.h" tell me that what exactly is the difference between c1.h and c1.cpp? Since they both are doing the same things.
8
3059
by: nrhayyal | last post by:
Hi c++ Gurus, Need your blessing. while testing few aspects with respect to header file inclusions, i observed few things which i would like to share with you. i have a file sqlca.h in which a structure sqlca is declared. i included this file as a soft link in /usr/include. the soft link is as follows: sqlca.h -> /usr/opt/db2_08_01/include64/sqlca.h
3
2755
by: fc2004 | last post by:
Hi, Is there any tools that could report where cyclic header dependency happens? this would be useful when working with a large project where tens or hundreds of headers files may form complex inclusion relationships. Another question I have is how to solve this dependency when "typedef" is used. usually we can use forward declaration like "struc A; " to solve references like "struct A* p". But in many places we have
12
2108
by: Ben | last post by:
I'm kind of new to creating templates. I've made some small class and function templates in the past and I have used quite of bit of the STL, but I am having problems tyring to create templates. I'm trying to make class templates in seperate header files with pointers to each other, and I am getting strange errors. Is it possible to do?
1
1754
by: Marco Spatz | last post by:
Hi, I used PCLint to check my code yesterday and got some warnings about "Repeated include files" and "Redundant declaration for symbol 'CLASSNAME'". I know the reasons for these warnings and I think they are not a problem. But all this made me think about the order in which header files are include. Think about a 4 layered architecture with
11
2816
by: Gary Wessle | last post by:
Hi is it right to have a line like #include <path/to/header.hfor a library on my system, in my header file and use some functions provided by this library in the implementation file (file.cpp) inside a class with out declaring those functions in the class declaration in the header file? thanks
0
9931
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
10725
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
10830
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
9557
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
7113
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();...
0
5781
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...
0
5978
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
1
4601
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
3
3226
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.