473,883 Members | 1,750 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

ANSI C compliance

Just to make a tangential point here, in case anyone new to C doesn't
understand what all these flame wars are about.

Shorthand title: "My boss would fire me if I wrote 100% ANSI C code"

We are discussing whether this newsgroup should focus on 100% ANSI C or
simply topics related to the C language in the real world. There is a C
standard which is defined by an international committee. People who write
compilers refer to this in order to make sure their compilers follow the
standard -- that they actually compile C. However, they also add extensions
to the C language to make your life easier, and of course there are bugs in
the compilers and such.

So for various reasons, C you write which runs and works as expected on one
platform might not work on another platform. The C standard is there to
alleviate this -- to decide which compiler is wrong if they differ in
behavior.

What percent of non-trivial programs are completely ANSI C (i.e. they work
as intended on all platforms for which you have an ANSI C compiler, modulo
compiler bugs)? I would suspect somewhere near 0%, just like about 0% of
non-trivial programs are completely bug free. Even taking this into
account, I would suspect less than 5% of non-trivial C programs written are
intended to be, or actually are, standard C. It simply isn't necessary
engineering practice, although there are certainly exceptions. For example,
one job I once interviewed for was writing standard ANSI C implementions of
licensed technology, that were meant to be ported (by hand) to assembly on
DSPs by the licensees. That is, the idea was to write something for other
people to read and compile, not something to actually go in a real product.

Now, on to my point. Writing truly standard C as valued by the "regulars"
in this newsgroup is time-consuming if you're not experienced. And it takes
time to accumulate the knowledge necessary to do so. Thus, in the business
world, it is not considered good practice, since time = money.

There is a field of study you might call "software development", which is
the study of how real teams build real software products. There is a notion
called "speculativ e generality" (from one of Steve McConnell's books I
think, don't
remember which one, see also Martin Fowler). This is basically when you
write code that speculates on what you may need to write need in the future.
Instead of writing code that does exactly what you need to do, you write
something that does more than that, potentially. This is shorthand for
overengineering -- architecting a general system when a specific one will
do.

Writing 100% ANSI C when you are not in a special circumstance (like the one
I listed above) is considered speculative generality. Portability is a
feature of code. Thinking about portability to machine with 9 bit bytes or
2 stacks or no stack or 6 stacks is a waste of time (at least business time,
your personal time is free to be spent however you like), when you have no
forseeable need for it. Because this time could be spent working on
features that actually are required, ones that actually generate money.
Even if you DO have a forseeable need for it, it is considered good practice
to solve _only the problem at hand_. Business requirements are extremely
volatile. Executives are fickle.

An example. Our game started out on PS2. A couple years ago we ported it
to the GameCube and XBox. Did we have completely portable code at first?
No, we wrote a game for PS2. Would it have been easier to port if we had?
Sure, a little. But it wasn't a big deal to fix all the problems as they
came up, as compiled with *real* compilers. And so we did so, in a
straightforward manner.

Do we have standard C code now that we ported it? No. Do we need to? Not
really, the products sold more than 1.5 million copies and generated
millions of dollars in profits.

Now we are investigating porting it to PSP (Playstation portable). Would
it be easier if we have standard C code? Sure, a little. But what if we
never had to port to PSP? Then our effort writing standard C would have
been wasted. What if the PSP compiler has a bad bug that makes it
incompatible with ANSI C? (Not unlikely, since there is only one compiler
for these machines at first, generally).

In software development, *incur the development cost* of a feature *when you
need it*. Not any sooner.

So, the bottom line is, if I was working on making some old nasty code that
works ANSI C compliant, instead of implementing a feature on my schedule
(ANSI C compliance would be laughed off the schedule), my boss would be
PISSED. You don't do that. There is a very real risk of creating bugs in
already working code, which of course is much worse than that code not being
ANSI C.

That said, you should learn the basic rules of the language (to a reasonable
point, there is definitely a point of diminishing returns). Far too many
programmers hack blindly, just trying to shut the compiler warnings up.
(Believe it or not, I am actually the one on the team that adheres most
strictly to standards, e.g. I am the one who hates it when people use enum
as integers, even though that is standard, etc.. My co-workers would have a
good laugh at this, and wonder if this newsgroup is from another planet.)

So, the second bottom line is, that this is C programming in the real world,
which the overwhelming majority of people are interested in doing. As
opposed to whacking off in a newsgroup about their ANSI C knowledge as an
end in itself. That is why CLC is a terrible place to discuss ONLY ANSI C,
as there is already perfectly good place (CLC.moderated) . This is where
people new to C tend to come (as mentioned, alt.comp.lang.l earn-c-c++ is a
joke by its very title), and CLC.moderated would reject many of their posts
as off topic. Since they don't KNOW what standard C is yet, they don't know
what's on-topic.

Good day. If you have a reasoned response to this, I'd be interested in
your opinions.

(But alas, let the flames from the "regulars" begin...)

Roose
Nov 13 '05
100 7046
Jack Klein wrote:
There happen to be quite a few compilers for embedded systems which
come under the category of free-standing implementations . It is not
uncommon for such implementations to specify that the user-written
start-up function signature should be "void main()", generally "void
main(void)", as there are never anything like command line arguments
in such environments.


This newsgroup tends to assume "hosted" unless otherwise stated.
In free-standing implementations ,
the main function, can be called anything.
I've worked on embedded, where the main function was called
"start_main _"

--
pete
Nov 13 '05 #51
On 5 Nov 2003 01:56:01 GMT, sc*@eskimo.com (Steve Summit) wrote:
There is a notion called "speculativ e generality"... This is
basically when you write code that speculates on what you may...
need in the future. Instead of writing code that does exactly
what you need to do, you write something that does more than that,
potentially.


Generalization does not always take extra time. In fact, I have found
that generalizing a problem often leads to a solution which is not
only extensible, but easier and cleaner to implement in the first
place.

--
Al Balmer
Balmer Consulting
re************* ***********@att .net
Nov 13 '05 #52
On Wed, 05 Nov 2003 08:57:29 GMT, "Roose" <no****@nospam. nospam>
wrote:
I am very doubtful of the methodology of preventing bugs a priori by using
ANSI C, as contrasted with spending the resources on proper QA, which many
organization s fail to do. Indeed, I would suspect that you asked
programmers of airliners and medical equipment, they would say their
_quality bottleneck_ is in QA and unit testing, rather than in ANSI C
conformance.


Sorry, wrong. Quality comes in the production of the product, not the
testing. I've not programmed for airliners, but I have programmed for
medical equipment, and I have done a great deal of programming for
mission- and life-critical process control. There's an excellent
chance that you are within reach of a plastic product produced in part
with my software, and to my knowledge, a PVC reactor hasn't exploded
for years.

It's a common saying that quality cannot be legislated by QA or tested
into a product by QC. Testing can show the presence of errors, but
cannot show the absence of errors.

ANSI/ISO C is not the be-all and end-all of quality programming, but
it's a valuable aid. While most programs in my world must use some
facilities that are outside the scope of the standard, it's no
problem, and no extra work, to write proper code for the 95% which can
be standard C. In fact, most of that other 5% is standardized as well,
conforming to POSIX, which has relatively high portability. I really
don't understand your contention that writing standard C where
possible costs more. In fact, for products with a reasonably long
lifetime, it's cheaper. In your limited world of game programming,
perhaps you just replace obsolete code. Most of us don't have that
luxury, and have to consider maintenance as part of the life-cycle
cost.

This is anecdotal, but I have done a great deal of C maintenance
programming, ever since the standard was approved (and written much
code we called C before that :-). and while doing that I have made a
lot of legacy code standard-conforming. Nearly every time I've done
that, I've uncovered bugs which would have been caught by a pedantic
compiler if the program had been written in standard C originally.
(Aside - it's amazing how customers will live with bugs for years and
how ingeniously they sometimes work around them. We've got 'em
trained.)

Bottom line is that this newsgroup discusses Standard C. That's what
we do here. It doesn't mean there aren't other things to discuss, it
just means that other things should be discussed in other places. If
you try that, you'll find than many of the folks here you've accused
of being narrow-minded and not knowing about the outside world also
participate in those other groups.

Have you looked at comp.programmin g, for example? They discuss much
wider issues than comp.lang.c.

--
Al Balmer
Balmer Consulting
re************* ***********@att .net
Nov 13 '05 #53
On Wed, 05 Nov 2003 08:57:29 GMT, "Roose" <no****@nospam. nospam>
wrote:
and suggest that there should be a group called comp.lang.ansi-c or
whatever,


Nope. C *is* ANSI-C. The standard is the very definition of C To me,
comp.lang means just that - discussions about the *language.* Not its
applications, not extensions to it, not libraries for it or algorithms
coded in it, but the language itself and its proper use. No confusion
there.

I think what you want is a group named comp.programmin g.c, and that
might actually be a good idea, though I wonder if the traffic would
justify subsetting comp.programmin g. You could work toward creating
such a group, and in the meantime, participate in its parent,
comp.programmin g (where you'll also find some of the c.l.c regulars,
being less pedantic ;-)

What you are *not* going to be able to do is hijack this newsgroup and
redefine it as what you want it to be. It is what it is.

--
Al Balmer
Balmer Consulting
re************* ***********@att .net
Nov 13 '05 #54
On Wed, 05 Nov 2003 10:34:19 +0000, Joona I Palaste wrote:
Keith Thompson <ks*@cts.com> scribbled the following:
"Roose" <no****@nospam. nospam> writes:

Again I claim if I went through my
code looking for %ul and replacing it with %lu, it would not be looked upon
highly.

Why not? Don't you believe in fixing bugs?

Are you assuming that "%ul" happens to work as a format for unsigned
long on most implementations , and converting it to the more
standard-compliant "%lu" would be a waste of time?

In fact, "%ul\n" is a valid printf format; the "%u" converts an
unsigned int, and the "l" is a literal lower case letter L.
The statement

printf("%ul\n", l);

if l is equal to 42, will print "42l" followed by a newline. The bug
might even be missed in testing if it's misread as 421.

I'm just making a guess about what you were assuming; if I was
mistaken, can you clarify your point?


If Roose's boss thinks there's no difference between "42l" and "42" (as
output strings), then good for him, but I don't want to work in that
company.


No you misunderstand. Roose's boss wants bugs. That's the problem.
If Roose bothered to write correct code, then the development group
wouldn't fulfill their bug quota, and without a full bug quota the
testers wouldn't have anything do to, and the company might have to
release a product on time.
Nov 13 '05 #55
> Why not? Don't you believe in fixing bugs?

Are you assuming that "%ul" happens to work as a format for unsigned
long on most implementations , and converting it to the more
standard-compliant "%lu" would be a waste of time?


Yes, that's what I was assuming, and I stand corrected. You mean you guys
don't test your code before posting it? : ) I will look for another
example of such a thing.

Roose
Nov 13 '05 #56
On Wed, 05 Nov 2003 07:43:49 GMT
"Roose" <no****@nospam. nospam> wrote:
Let me thank you first for making a reasoned argument. My time is not
unlimited, so let me ignore the vast majority of responses and focus
on the ones such as this that rely logical argument -- AND acknowledge
the existence of life outside the newsgroup.

"Steve Summit" <sc*@eskimo.com > wrote in message
news:bo******** **@eskinews.esk imo.com...
Roose wrote:
I'm not talking about "you" or "I". I'm talking about a real
development team, that makes a real product. On such a team, _as
a fact_, you will encounter old code, code written by someone
other than yourself. Old code
that is likely not written in ANSI C.
Sure, but none of us -- you, I, or Ian -- is talking to or about
that earlier programmer. We're talking about us -- you, me, and
anyone else who happens to be listening, who we'd like to convince
to do better than the earlier programmer.


OK, I think the real point was lost somewhere there, but my contention
is that ANSI C being "better" is dependent on the situation, and not
an absolute fact.


Such instances are few and far between in my experience. Equally, my
experience is that writing code to be as portable as possible can often
save you time *BEFORE* you reach the deadline.

A REAL example:
Writing a significant chunk of embedded code. Since the code was as
portable as possible I ended up porting it to a Silicon Graphics
workstation and debugging it there because there were far better tools
available including the ability to read some aircraft attitude data and
the digitised video and overlay a line of the video indicating where my
software believed the horizon was. This saved a significant amount of
time on that particular project.
Again, I'm not talking about "you". I'm talking about the average
programmer who you might be working with. If you were a project
manager, if such a programmer was not very familiar with ANSI C --
what would you do?
Would you schedule extra time for him to make his code ANSI
compliant, or
would you schedule just enough time for him to get it into a nice
readable state, suitable for further modification?


If I cared about the long-term maintainability of the company's
code base, and if my programmers were insufficiently competent to
so maintain it, I might schedule some time for those programmers
to learn the necessary skills.


Right, let me suggest that if you were a manager -- with limited
budget as always -- that training programmers to write ANSI C and
converting old code to ANSI C would often be on your cut list. Also,


Converting pre-ANSI code to ISO C is not required to write any
modifications in ISO C. By making such changes as you deal with the
relevant parts of the code you can gradually ease the burden of
maintenance without a significant bad effect on your immediate
timescales and budgets. I know this through personal experience just as
I know that gradually making the change can expose problems that only
occasionally cause the application to misbehave and allow you to fix
them.
if you were a hiring manager, I would suggest that it is often the
case that one programmer who does not "care" about ANSI C would often
suit your purposes better than another that does.
I would expect and good C programmer to be able to cope with pre-ANSI
code on a legacy project. I know this because I *AM* working on such a
project. I also know that the head of my SW department would far prefer
people who understand and care about standards compliant software than
those who don't care about it.
Point taken, but I still contend that portability is a feature.
It costs extra to make code ANSI compliant.


The same can be said about any feature, meaning that the way to
save the most money is presumably not to try to write the code at
all.


Also correct, but my contention is that other features fair better in
a cost/benefit analysis than (often speculative) portablity. Other
features cost money as well, but they also generate money. Writing
ANSI C for a single device does not, in general, generate any money.


If you know how to write portable code then my experience is that in
most cases it does not cost more than writing non-portable software.
If the short-term costs of coding portably truly don't promise
any long-term benefits, or if you're trapped by deadline
pressures under which you don't have time to do things right
(though you might have time to do them again), you might decide
you can't afford the portability.


I think this decision is made fairly often in the business world. But
if you have experience that demonstrates otherwise, I'd be interested
to hear about it.


See my comments above. All are based on real personal experience in the
defence and commercial worlds.
But for those of us who are used to doing it, the short-term cost
of the kinds of portability we're talking about here is zero.


What percentage of programmers do you think are used to doing it?
(Honestly, I am not sure of the answer).


Anyone in the defence industry will have their code peer reviewed so it
only takes a few people for the word to slowly spread. Outside the
defence industry things are different.

Personally I learnt most of my C from K&R2 referring to the manuals for
the compiler when I needed to do something HW specific and *knowing*
that the HW specific stuff I was doing was specific to the
implementation as it was documented as such. This does not mean that I
did not introduce non-portable constructs by mistake in code I
considered to be portable, but it did bring things a long way towards
it.
If you were a hiring
manager, wouldn't this unnecessarily limit your pool of applicants if
you were to insist on it?
As with everything, when recruiting you weigh the cost/benefit. If
someone is good enough and prepared to learn but does not know enough
about portable coding one might consider them just as one would reject
someone who could only write simple portable programs and was not
willing to learn.
The nicely portable code flows out of our fingers as easily
as the nonportable code, that you seem to be trying to condone,
fumbles out of the fingers of those hypothetical earlier
programmers. The question is -- which kind of programming are
we trying to encourage? And if we constantly give everyone carte
blanche to write code which falls down on the various software
virtues -- portability, maintainability , correctness, repeatability,
predictability, efficiency -- if every day we let them get away
with that which is merely expedient, when will we collectively
ever learn to do better?


I would say that the last 4 virtues you mention are _absolute_
virtues, while the former is a business decision. I completely agree
that we should strive to do better -- but our time is limited, and
focusing on one thing comes at the expense of others. I would much
rather (and my boss would much rather me) learn a new rendering
technique, rather than study the ANSI C standard. I would much rather
write a unit test than make my code ANSI compliant.


Making your code ISO compliant can remove bugs you are not aware of and
your compiler can probably provide a lot of help in doing this and if
not you may be able to run it through gcc with maximal warnings to see
the issues. So you should at least try to see how close you are and
whether there is anything immediately critical that you can resolve as
*part* of your testing. Potentially you look through the optional
warnings s your compiler can generate and enable ones that are most
likely to show up real problems, such as -Wsequence-point on gcc.

You don't have to spend a lot of time/money in one go, 5 minutes per
day would be a start and could remove unexplained crashes that you
can't track down.
The expediency you seem to be condoning is responsible for many
of the ills in software development. I understand that you're
willing to make tradeoffs in favor of expediency at the expense
of other virtues, but what always puzzles me is why you and so
many posters before you keep coming in here and insisting that
the rest of us are wrong for making, or advocating, a different
set of tradeoffs.


I'm not saying you're wrong, but rather I'm objecting to the extremely
narrow focus demonstrated in this newsgroup.


This group is about programming in C and not about implementation
specifics. If you don't like it then use another group. There are plenty
of places for discussing the specifics of any given implementation
where you will find a lot more expertise on that specific
implementation.
The posts come at the
expense of the larger question -- in recent threads the larger
questions being answering an interview question (so as to demonstrate
knowledge), and also helping a newbie learn C.
A lot of helpful information was posted and people I know who *have*
been interviewers would have liked many of the answers.
Many people have
already stated that newbies are welcomed here. In that case, it would
be prudent to address them in a manner that they can understand,
rather than turning them off to the C language with nitpicking.
Accurate answers are given (and inaccurate ones corrected) and if
someone asks for further explanation it will be provided. Many people
*try* to pitch their answers at the apparent level of knowledge of the
person asking the question whilst still doing this.
I
would also contend that learning strict ANSI C is not the first step
for a beginning C programmer. There is enough challenge in getting a
working program together.
It is far easier to get a working program together if you set the
warning level on your compiler as high as possible and try to understand
and *resolve* the warnings (not just cast them away) than if you don't
do this. Such a method also leads you naturally in to producing ISO C
programs.

Also, trying to use libraries outside of those provided by the C
standard means you have *more* to learn and so makes the job harder.
However, we (or I at least) don't object to people new to see using the
simpler external libraries, it is just that we will direct them else
where for help with those libraries.
Software engineering is still a pretty flimsy discipline.
For the most part, we're all slogging along through the mud,
often waist deep, often falling on our faces in it. Yet when one
of the sloggers dares to suggest that we invent paved roads, and
wheeled vehicles to move swiftly and easily on them, someone else
derides this vision as an ivory-tower fantasy, ungrounded in the
real world. 'Tis sad.


Completely agree. However, I would say that the line-by-line
deficiencies in code (e.g. non-ANSI code) are completely and utterly
overshadowed by the lack of design knowledge by the average
programmer.


When I started my career I was not expected to do the design. Instead I
would be presented with the design (if there was any significant
complexity) and be asked to code it. Thus I was exposed to good design
at any given level before I was expected to do it, and when doing design
work or coding others would look at my work and provide help and advise
as required. IMHO this is a correct way to tackle the issue and allows
the learning of both good coding in ISO C and good design at the same
time.

I have also been in the position of mentoring fresh graduates and I
would gradually build up the complexity of what they were required to do
making sure they were heading in the right direction before letting them
loose.
Attack the worst of the ills first. And the one that has
the most effect on maintainability and understandabili ty of code is
the fact that your average codebase is filled with faulty
abstractions, or, sadly, none at all.


However, those ills are for other groups such as comp.unix.progr ammer,
although people do point out design flaws when reviewing code that is
posted here in order to move people in the right direction. Asking for
such help here is off topic, but providing it *whilst* dealing with the
C issues is considered acceptable based on what I've seen.
--
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 #57
Roose wrote:
Why not? Don't you believe in fixing bugs?

Are you assuming that "%ul" happens to work as a format for unsigned
long on most implementations , and converting it to the more
standard-compliant "%lu" would be a waste of time?
Yes, that's what I was assuming, and I stand corrected.


Could you tell us about even one implementation on which %ul works as a
format for unsigned long? Or does your "I stand corrected" mean that you no
longer believe that /any/ implementations do this?

I ask merely for information.
You mean you guys
don't test your code before posting it? : ) I will look for another
example of such a thing.


If you find a bug in code posted here, and no correction for that bug has
been posted, please do post a correction. You may be surprised by the
reaction. In fact, I urge you to look for bugs in code that I myself have
posted, partly for your own satisfaction, but also so that you can see the
kind of reaction that one can expect when posting a correction in this
newsgroup.

Part of the immense value of this newsgroup is the extraordinary attention
to detail displayed by its nit-pickers.

--
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 #58
Roose wrote:

<snip>
Not sure what the point of the fortran example is exactly, but I'm talking
about people who, at the expense of answering anyone's _real_ question,
ignore anything not related strictly to ANSI C, and instead inundate them
with irrelevant details about ANSI C.
The details are far from irrelevant in a C newsgroup. They might well be
considered irrelevant in a group such as comp.programmin g or sci.crypt.
Again my claim is that --
regardless of whether they are right to come here -- a lot of newbies do,
and get
turned off to the C language.
Doubtless you have independent and compelling statistical evidence to
support this assertion. Where is it?

<snip>
if you were a hiring manager, would
you limit your applicant pool in such a way, when it is clear that people
who are not completely familiar with strict ANSI C would be capable of
meeting the business objectives?
I would consider hiring a person not familiar with C (which is my term for
what you call "strict ANSI C"), provided that they made up for this
deficiency in other relevant areas and provided that they were able to
demonstrate willingness to learn C.

<snip>
I am very doubtful of the methodology of preventing bugs a priori by using
ANSI C, as contrasted with spending the resources on proper QA, which many
organizations fail to do.
Correct use of the C language sure beats the hell out of its incorrect use
when it comes to preventing bugs. And correct use of C is pretty much what
we discuss here.

<snip>
ANSI C is a limited part of C in the real world,
Sure, if by "C in the real world" you mean "C together with a bunch of
libraries and extensions", but it's the core, the vital part of the
language, and it's essential to understand that core if one is to be an
effective C programmer.
and thus the name comp.lang.c is misleading,


comp - computing
lang - language
C - C

I don't see anything misleading here. The key point is that C is defined by
an international standard, not by the misunderstandin gs and
platform-specific experiences of anyone who happens to drop into clc one
cold November evening when there's nothing good on television.
<snip>

--
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 #59
Mark Gordon wrote:
On Wed, 05 Nov 2003 07:43:49 GMT
"Roose" <no****@nospam. nospam> wrote:

Let me thank you first for making a reasoned argument. My time is not
unlimited, so let me ignore the vast majority of responses and focus
on the ones such as this that rely logical argument -- AND acknowledge
the existence of life outside the newsgroup.

"Steve Summit" <sc*@eskimo.com > wrote in message
news:bo****** ****@eskinews.e skimo.com...
Roose wrote:

Such instances are few and far between in my experience. Equally, my
experience is that writing code to be as portable as possible can often
save you time *BEFORE* you reach the deadline.

A REAL example:
Writing a significant chunk of embedded code. Since the code was as
portable as possible I ended up porting it to a Silicon Graphics
workstation and debugging it there because there were far better tools
available including the ability to read some aircraft attitude data and
the digitised video and overlay a line of the video indicating where my
software believed the horizon was. This saved a significant amount of
time on that particular project.


In support, another Real World example:
I was working on code for an embedded laser printer. The task was
page control (sequencing, and resource aquisition). The code was
based on data input. Since resources were tight (i.e. 5 people shared
the same printer to work on), writing in ANSI C code allowed me to
debug the code on the PC using a debugger to single step through
the code (and setting appropriate variables). This debugging
process was often faster than trying to debug using the proprietary
debugger after waiting many hours for free time on a printer.

One note: Many of the real world programs have code that is platform
dependent. However, those portions can be confined to their own
modules and replaced by "stubs" for other platforms. In my case,
I used some stubs for platform specific functionality.

--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.l earn.c-c++ faq:
http://www.raos.demon.uk/acllc-c++/faq.html
Other sites:
http://www.josuttis.com -- C++ STL Library book

Nov 13 '05 #60

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

Similar topics

5
2837
by: Acacia | last post by:
a) Does the C++ language never change? I was recommended to upgrade my MSVC v1.5 to a newer compiler - yet I thought that ANSI C++ was a standardised language and never changed - so why would i need to upgrade my compiler? More features? b) How good is C++? Would it be worth learning for a computer, and possibly programming, enthusiast? Has it got a long life ahead of it or is it likely to die out soon replaced by newer languages?
3
5940
by: Jack | last post by:
Hi I am just trying to get a feel for what oracle SQL syntax there is that would not be covered at all in anyway from a functionality perspective in the standard ANSI SQL.. Any input is appreciated.. Thank you, Jack
83
11666
by: sunny | last post by:
Hi All What is C99 Standard is all about. is it portable, i mean i saw -std=C99 option in GCC but there is no such thing in VC++.? which one is better ANSI C / C99? can i know the major difference between C99 & ANSI C standards?
0
9797
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
0
10762
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
10863
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
10422
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
0
9586
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...
1
7977
isladogs
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 presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
0
7136
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
6005
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
1
4622
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 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.