Is C really portable? And, apologies, but this is possibly a little OT?
In c.l.c we often see 'not portable' comments, but I wonder just how
portable C apps really are.
I don't write portable C code - *not only* because, in a 'C sense', I
probably do things that aren't portable - but because for the last x years,
I've written code to run on a number of different platforms. Those apps
have had to make use of system calls, use threads, present nice UIs, .
Premise: any decently complex modern application cannot be entirely written
in standard C [meaning, the language without compiler added 'extensions',
and only using the standard libraries]. Or, if it is written in standard C,
then it is 'sub optimal' [and certainly doesn't have a nice UI!].
Conclusion: Whilst the language is portable, applications are not. And
that's why we also often see 'go and ask elsewhere' comments appearing here
[totally reasonable they are too of course].
Anyway, just a thought, and I wonder if anyone can come up with a counter to
it?
131  5986 
pemo said: Is C really portable?
C isn't portable.
C programs aren't terribly portable - a bit, that's all.
C libraries can be *astoundingly* portable, if done properly.
C the language isn't any more or less portable than English.
Useful C programs can be written which will work in many environments, and
indeed I have written many such myself.
But where C really scores is in the fact that you can write a whole bundle
of stuff that will be useful on any platform whatsoever, and call it a
"library".
In c.l.c we often see 'not portable' comments, but I wonder just how
portable C apps really are.
If carefully written to abstract any non-portable parts of their
functionality into separate modules, C applications can be extraordinarily
portable. Take 500,000 lines of carefully written code, 5,000 of which are
carefully isolated platform-related stuff, and the rest of which is
straight ISO C. Rewrite those 5,000 every time you hit a new platform.
Takes about four man-weeks to port, instead of eight man-years. Hey presto,
portable Web browser. (Hi Borris.)
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
pemo wrote: Is C really portable? And, apologies, but this is possibly a little OT?
C is very portable.
In c.l.c we often see 'not portable' comments, but I wonder just how
portable C apps really are.
90%[1] of most apps can be written in portable C leaving only 10% you
have to actually tailor for the target.
I don't write portable C code - *not only* because, in a 'C sense', I
probably do things that aren't portable - but because for the last x years,
I've written code to run on a number of different platforms. Those apps
have had to make use of system calls, use threads, present nice UIs, .
So you isolate those pieces of code in a system specific module.
Premise: any decently complex modern application cannot be entirely written
in standard C [meaning, the language without compiler added 'extensions',
and only using the standard libraries]. Or, if it is written in standard C,
then it is 'sub optimal' [and certainly doesn't have a nice UI!].
Certainly the bulk of applications have non-standard components, but
that does not mean the bulk of the code has to be non-standard.
Conclusion: Whilst the language is portable, applications are not. And
that's why we also often see 'go and ask elsewhere' comments appearing here
[totally reasonable they are too of course].
Many applications are very portable, requiring just a small amount of
tailoring for specific targets. This can be assisted by using libraries
that are available on multiple targets for the system specific stuff
(e.g. QT or GTK+).
I've written C for an embedded system that I then debugged on a silicon
graphics workstation (with some wrapper code) and some of the code was
then used on another completely different platform.
The code I'm currently working on is destined to run on Windows, Linux
and AIX (not in that order), and the application has previously run on
other systems.
Anyway, just a thought, and I wonder if anyone can come up with a counter to
it?
See above. Many of us here work on software that is required to run on
multiple platforms, and we use techniques that have been around since
before I started programming to do it. Things like modularisation and
keeping all the system specific stuff out of the bulk of the modules.
[1] 75% of all statistics are made up on the spot
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.
pemo wrote: Premise: any decently complex modern application cannot be entirely written
in standard C [meaning, the language without compiler added 'extensions',
and only using the standard libraries]. Or, if it is written in standard C,
then it is 'sub optimal' [and certainly doesn't have a nice UI!].
Well... yes since you often have to interact with the OS and
environment. But I don't re-write programs monolithically every time I
start a new project. I "drag&drop" libraries I've written over the
years and just write a new main file for the program.
Conclusion: Whilst the language is portable, applications are not.
And that's why we also often see 'go and ask elsewhere' comments appearing here
[totally reasonable they are too of course].
Anyway, just a thought, and I wonder if anyone can come up with a counter to
it?
This is going to be a long(ish) story...
At my previous company, I've fought hard against people who think like
this. Our products run on a wide variety of different environment, all
with different OSes (some with none), all different CPU families and
all different compilers.
The products range from small 8bit PICs to medium 8bit Z80s to large
16bit 68000 to 486 all the way up to a modern 200Mhz ARM9. But they all
tend to have to do the same jobs - getting data over a serial line,
process and route the data and transmitting the data over serial lines
where necessary. Needless to say, this environment encouraged people to
keep re-inventing the wheel. And my bosses, engineers from the 70s,
thought this was the 'natural' way of doing things.
I believed in the portability of C and was appalled at this set-up.
Especially the re-inventing the wheel part. So I started writing
portable code for 'simple' stuff like CRC16 and base64 encoding etc.
using #ifdefs to select the appropriate implementations for resource
starved systems (PICs on average only have 20 bytes of ram). Then I
moved on to more complex stuff like a Modbus protocol engine.
Then the real struggle began - trying to convince people that this is
the way to go. I've already won converts among my team members since
they find it nice to be able to simply browse through my shared folder
of libraries to get what they needed. Slowly people started to
appreciate the effect of fixing a bug in a file fixes it for all
platforms.
The change in attitude towards writing code resulted in a huge library
of re-usable code. This allowed us to concentrate on adding new
features as well as freed us from being dependent on a single
CPU/platform. When our competitors shifted from 68000's to PPCs we were
able to do the same. When ARM became all the rage in embedded devices
we were able to move our product to it as well.
So, I've written code to work all the way from 4MHz, 8bit CPUs with 20
bytes of ram to 200MHz, 32bit CPUs with 128MB of ram and a hard disk.
The complete programs are obviously not portable since you can't expect
a 1MB program to fit on 1kB of EEPROM. But the code I've written, by
themselves, are portable. main() should ideally be the only
non-portable part of your code.
pemo wrote: Premise: any decently complex modern application cannot be entirely written
in standard C [meaning, the language without compiler added 'extensions',
and only using the standard libraries]. Or, if it is written in standard C,
then it is 'sub optimal' [and certainly doesn't have a nice UI!].
Well... yes since you often have to interact with the OS and
environment. But I don't re-write programs monolithically every time I
start a new project. I "drag&drop" libraries I've written over the
years and just write a new main file for the program.
Conclusion: Whilst the language is portable, applications are not.
And that's why we also often see 'go and ask elsewhere' comments appearing here
[totally reasonable they are too of course].
Anyway, just a thought, and I wonder if anyone can come up with a counter to
it?
This is going to be a long(ish) story...
At my previous company, I've fought hard against people who think like
this. Our products run on a wide variety of different environment, all
with different OSes (some with none), all different CPU families and
all different compilers.
The products range from small 8bit PICs to medium 8bit Z80s to large
16bit 68000 to 486 all the way up to a modern 200Mhz ARM9. But they all
tend to have to do the same jobs - getting data over a serial line,
process and route the data and transmitting the data over serial lines
where necessary. Needless to say, this environment encouraged people to
keep re-inventing the wheel. And my bosses, engineers from the 70s,
thought this was the 'natural' way of doing things.
I believed in the portability of C and was appalled at this set-up.
Especially the re-inventing the wheel part. So I started writing
portable code for 'simple' stuff like CRC16 and base64 encoding etc.
using #ifdefs to select the appropriate implementations for resource
starved systems (PICs on average only have 20 bytes of ram). Then I
moved on to more complex stuff like a Modbus protocol engine.
Then the real struggle began - trying to convince people that this is
the way to go. I've already won converts among my team members since
they find it nice to be able to simply browse through my shared folder
of libraries to get what they needed. Slowly people started to
appreciate the effect of fixing a bug in a file fixes it for all
platforms.
The change in attitude towards writing code resulted in a huge library
of re-usable code. This allowed us to concentrate on adding new
features as well as freed us from being dependent on a single
CPU/platform. When our competitors shifted from 68000's to PPCs we were
able to do the same. When ARM became all the rage in embedded devices
we were able to move our product to it as well.
So, I've written code to work all the way from 4MHz, 8bit CPUs with 20
bytes of ram to 200MHz, 32bit CPUs with 128MB of ram and a hard disk.
The complete programs are obviously not portable since you can't expect
a 1MB program to fit on 1kB of EEPROM. But the code I've written, by
themselves, are portable. main() should ideally be the only
non-portable part of your code. sl*******@yahoo.com wrote:
<snip portability discusion> themselves, are portable. main() should ideally be the only
non-portable part of your code.
No, IMHO main should be portable, the non-portable bits should be in a
platform specific library.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.
pemo wrote: Is C really portable? [...]
"Portable" is not a Boolean attribute. Worse, it's not
a one-dimensional attribute. Worst of all, its components
aren't all measurable.
"Portability" comes down to economy: How much time, money,
skull sweat, and caffeine will it take to get your program
working on a machine that hasn't hosted it before? Along with
the effort estimate goes another: How strong is the desire to
have the program work on some particular target system? It's
likely that your tic-tac-toe program would be difficult to get
running on your car's engine control computer, but the chances
that you'd want to do such a thing seem pretty remote.
"Portability" cannot even be assessed entirely from a
study of the code. For example, a program written to the
strictest coding standards and impeccably implemented might
still be "non-portable" to a system with less than 256MB of
memory. (The well-behaved program will, of course, fail
cleanly with a polite message -- but if the program cannot
carry out its intended function, it hasn't been "ported,"
has it?)
So: When we say that something is "portable" we're really
using a sort of shorthand for a whole big bag of imponderables.
"Non-portable" is similarly inexact. In c.l.c. usage, all of
these have been tagged as "non-portable;" I've tried to arrange
them in an approximate order from venial sins to deadly:
- Code that assumes two's complement integers
- Code that assumes a particular character encoding
- Code that assumes a particular endianness
- Code that assumes `int i; int j;' allocates the two
variables in adjacent memory locations
.... and, of course, many more. Clearly there are "portability
threats" of different kinds and magnitudes in such examples;
because c.l.c. is sort of rabid we tend to lose the differences
and tar them all with the same "non-portable" brush.
The really interesting thing, I think, is that it often
turns out that the restrictions on "portable" code are less
stringent than may appear at first. One reason I hang around
c.l.c. is that people keep coming up with more-portable ways
of doing things I'd been using less-portable code for; I usually
don't go back and retrofit my old code, but I say "Aha! Neat!"
and stash the technique in my toolbox for future use.
--
Eric Sosman es*****@acm-dot-org.invalid
"pemo" <us***********@gmail.com> wrote: Is C really portable? And, apologies, but this is possibly a little OT?
...snip...
Others have already given good replies. I would
like to add that "portability" depends more on
the developer's knowledge and goals than on a
particular programming language.
C programs can be portable, when written by
knowledgeable and experienced people with
the intention of making them portable.
When the intent, knowledge (1) or experience
are not there, portability will most likely
also be missing.
One of the best examples of portable code I
ever saw, was a set of cross-development
tools for 8080 processors. (Assembler,
linker & simulator.)
The programs were written in a subset of
Fortran, using only the features know to
be common across several Fortran dialects.
The character set encoding was "discovered"
at run time, translation tables were set
up so that the program could run unchanged
in machines using any character encoding:
ASCII, EIBIC, CDC (forget the name), etc.
Hollerith (character) strings were limited
to one character and arrays used for anything
else.
All the input/output functionality was
encapsulated in a couple of functions, so
any environment dependency that forced a
change here would not affect the rest of
the system.
These and similar techniques can be used in
any language to produce portable code.
-----------
(1) A colleague of mine came to me recently
telling he found a bug in GCC. A code segment
behaved differently in our target system,
(Linux on PPC + GCC) than in his test
environment (Windows + Visual C++).
A few questions revealed that he had just
discovered the amazing fact that the plain C
"char" data type can be signed or unsigned
depending on the implementation.
He has been programming in C & C++ for years,
and carries a business card with the title
"Senior Software Engineer".
I would not expect this gentleman to produce
any portable C code, even if his life depended
on that ...
-----------
Roberto Waltman
[ Please reply to the group, ]
[ return address is invalid. ]
Flash Gordon wrote: sl*******@yahoo.com wrote:
<snip portability discusion>
themselves, are portable. main() should ideally be the only
non-portable part of your code.
No, IMHO main should be portable, the non-portable bits should be in a
platform specific library.
That's only true if you want the whole program to be protable. As I've
described, that's not my case. The main must often do things that are
not 100% portable, like start threads, initialise libraries etc. For
what I'm doing, it's better to write portable libraries/functions and
be able to re-use them on any platform. Main tend to be very small
anyway, all it usually does is call other libraries, so it's not an
issue to re-write it. But that may not be how others write code, that's
just how I do it.
pemo wrote: Is C really portable?
No. The standard embodies a portable syntax which exists as subset of
any compliant compiler, but that's exactly as meaningless as you might
suspect it is. For example, I don't believe there exists any pair of C
compilers from different vendors that have exact source space
compatibility.
[...] And, apologies, but this is possibly a little OT?
Well C.L.C. is a group about ANSI standard C. I don't know why, but if
you wish to discuss the actual practice of programming in C you will
have to find some other newsgroup to post in.
In c.l.c we often see 'not portable' comments, but I wonder just how
portable C apps really are.
They're not. Amongst languages in common use today, C is just like
Visual Basic in that there just really isn't any real expectation of
portability on any real world application code. Nearly every other
language in common use today is far more portable than C.
I don't write portable C code [...]
(well practically nobody does so ...)
[...] - *not only* because, in a 'C sense', I
probably do things that aren't portable - but because for the last x years,
I've written code to run on a number of different platforms. Those apps
have had to make use of system calls, use threads, present nice UIs, .
Well, its not just that. The standard says integer overflow is
undefined, right shift is not deterministic, you can't assume 2s
complement math, you can't assume ASCII characters, you can't assume
IEEE 754 floating point, wide-characters are specifically specified
*not* to represent anything deterministic, no code can be considered
re-enterable, parameter computation order is not specified, etc.
Even avoiding system calls, user interfaces and threading, its still
very hard to write portable code in C.
Premise: any decently complex modern application cannot be entirely written
in standard C [meaning, the language without compiler added 'extensions',
and only using the standard libraries]. Or, if it is written in standard C,
then it is 'sub optimal' [and certainly doesn't have a nice UI!].
Yes, but this only addresses system and library function calls. Try
writing a reasonable performing crypto-library in pure C that is
completely portable.
Conclusion: Whilst the language is portable, applications are not.
A subset of the *syntax* is portable. Nothing more.
[...] And
that's why we also often see 'go and ask elsewhere' comments appearing here
[totally reasonable they are too of course].
Of course. This group is incorrectly named (or equivalently has been
taken over by people who have ideas for this group that don't
correspond to the name of it). It should be called comp.lang.c.ansi.
This group does not discuss the practice of C programming.
The exception, of course, is the tremendous leniancy given to people
asking questions about gcc, and giving answers that are specific to
gcc.
--
Paul Hsieh http://www.pobox.com/~qed/ http://bstring.sf.net/
<we******@gmail.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com... pemo wrote: Is C really portable?
No. The standard embodies a portable syntax which exists as subset of
any compliant compiler, but that's exactly as meaningless as you might
suspect it is. For example, I don't believe there exists any pair of C
compilers from different vendors that have exact source space
compatibility.
Probably true, but not terribly important. Having been in and
around the validation business for several decades, I can testify
that Standard C has way more implementations than any other
language; and many of them score nearly perfect on two or more
nontrivial validation suites. Put another way, I've sold C code
intended to be portable also for several decades and I've *never*
had to worry about whether that code will compile, and execute
correctly, on a multitude of platforms. (With C++, I *always*
worry.)
Before C came along, I was doing similar things with Fortran,
and with reasonable success. And I've used about half a dozen
other popular languages with lesser success. So, IM(extensive)E
C portability is far from meaningless to me. YM(obviously)V. In c.l.c we often see 'not portable' comments, but I wonder just how
portable C apps really are.
They're not. Amongst languages in common use today, C is just like
Visual Basic in that there just really isn't any real expectation of
portability on any real world application code. Nearly every other
language in common use today is far more portable than C.
Does your planet have an oxygen atomsphere? Just curious. [...] And
that's why we also often see 'go and ask elsewhere' comments appearing
here
[totally reasonable they are too of course].
Of course. This group is incorrectly named (or equivalently has been
taken over by people who have ideas for this group that don't
correspond to the name of it). It should be called comp.lang.c.ansi.
This group does not discuss the practice of C programming.
The exception, of course, is the tremendous leniancy given to people
asking questions about gcc, and giving answers that are specific to
gcc.
If you weren't in such a sour mood, and if I weren't trying to
hold onto my recent good mood, I'd be tempted to agree with you,
at least to some extent.
P.J. Plauger
Dinkumware, Ltd. http://www.dinkumware.com
pemo wrote: Premise: any decently complex modern application cannot be entirely written
in standard C [meaning, the language without compiler added 'extensions',
and only using the standard libraries]. Or, if it is written in standard C,
then it is 'sub optimal' [and certainly doesn't have a nice UI!].
Conclusion: Whilst the language is portable, applications are not. And
that's why we also often see 'go and ask elsewhere' comments appearing here
[totally reasonable they are too of course].
Anyway, just a thought, and I wonder if anyone can come up with a counter to
it?
Well, even if the application can't be completely written in standard
C, it pays to be as close to portable as possible. Here's a list of
mostly portable, very non-trivial code in the real world where
portability is a major reason for their success:
1. Linux Kernel - now usually the first OS to be ported to a new CPU
2. BSD Kernel
3. Tcl interpreter - almost always the first scripting language to be
ported to a new OS or CPU
4. Tk GUI toolkit/library
5. gcc
6. Apache web server.
7. Adobe's postscript engine.
There are many others. Some assumes POSIX for portability. A few, like
the Tcl interpreter, don't even assume this. Tcl runs perfectly on a
386 in DOS.
P.J. Plauger wrote: <we******@gmail.com> wrote in message pemo wrote: Is C really portable?
No. The standard embodies a portable syntax which exists as subset of
any compliant compiler, but that's exactly as meaningless as you might
suspect it is. For example, I don't believe there exists any pair of C
compilers from different vendors that have exact source space
compatibility.
Probably true, but not terribly important. Having been in and
around the validation business for several decades, I can testify
that Standard C has way more implementations than any other
language;
Thats nice, but not the question OP was asking. Please crack open a
dictionary: Availability != Portability.
[...] and many of them score nearly perfect on two or more
nontrivial validation suites. Put another way, I've sold C code
intended to be portable also for several decades and I've *never*
had to worry about whether that code will compile, and execute
correctly, on a multitude of platforms. (With C++, I *always*
worry.)
Before C came along, I was doing similar things with Fortran,
and with reasonable success.
Well yeah, and you could do the same thing with Visual Basic, and the
various Basic interpretors available for UNIXs, and so on. If you push
the entire job of portability up to the actual developer of the code,
well then in fact *MOST* languages are portable. If fact, did you know
its fact possible to be portable *BETWEEN* many languages? When you
put the onus onto the programmer, you can claim all sorts of
capabilities for your language.
There is a subtle difference between a language begin portable, and
software which has been painstakingly ported.
[...] And I've used about half a dozen
other popular languages with lesser success. So, IM(extensive)E
C portability is far from meaningless to me. YM(obviously)V.
In c.l.c we often see 'not portable' comments, but I wonder just how
portable C apps really are.
They're not. Amongst languages in common use today, C is just like
Visual Basic in that there just really isn't any real expectation of
portability on any real world application code. Nearly every other
language in common use today is far more portable than C.
Does your planet have an oxygen atomsphere? Just curious.
Well my planet has Lua, Java, Python, Perl, TCL, and bizarre new
languages like Haskel, Scheme, etc. They are all portable.
Oh and BTW, my planet actually has mostly a Nitrogen atmosphere, though
it does includes a smaller proportion of oxygen, CO_2 and other
elements.
--
Paul Hsieh http://www.pobox.com/~qed/ http://bstring.sf.net/
In article <11*********************@f14g2000cwb.googlegroups. com>,
<we******@gmail.com> wrote: Well my planet has Lua, Java, Python, Perl, TCL, and bizarre new
languages like Haskel, Scheme, etc. They are all portable.
perl has horrible portability. Every time I want to do a non-trivial
perl update, whether it be a rev update or just bringing in a bunch
of new modules, it takes me pretty much a working day.
Indeed, I've been doing a module update today, and 22 of the modules
won't compile or won't test properly.
Last I checked, if you compile perl without threading then multiple
signals are not handled properly... and if you do compile with
threading then various other things break. :(
--
If you lie to the compiler, it will get its revenge. -- Henry Spencer
On 9 Dec 2005 17:27:08 -0800, in comp.lang.c , we******@gmail.com
wrote: pemo wrote: In c.l.c we often see 'not portable' comments, but I wonder just how
portable C apps really are.
They're not. Amongst languages in common use today, C is just like
Visual Basic in that there just really isn't any real expectation of
portability on any real world application code.
This is complete nonsense. Find me a Visual Basic compiler for Atari
ST, or Palm pilot, or IBM mainframe.
Nearly every other
language in common use today is far more portable than C.
You're fuller of sh*t than a midden.
Even avoiding system calls, user interfaces and threading, its still
very hard to write portable code in C.
and clueless.
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==---- http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
On 9 Dec 2005 19:43:44 -0800, in comp.lang.c , we******@gmail.com
wrote: P.J. Plauger wrote: <we******@gmail.com> wrote in message
(of writing portable code)
Before C came along, I was doing similar things with Fortran,
and with reasonable success.
Well yeah, and you could do the same thing with Visual Basic,
go on then, port some VB to Apple Mac, IBM Mainframe, Solaris, and Vax
11/780. And Blackberry.
Does your planet have an oxygen atomsphere? Just curious.
Well my planet has Lua, Java, Python, Perl, TCL, and bizarre new
languages like Haskel, Scheme, etc. They are all portable.
Fascinating but not relevant to the question.
Oh and BTW, my planet actually has mostly a Nitrogen atmosphere, though
it does includes a smaller proportion of oxygen, CO_2 and other
elements.
Sounds habitable. One sun or two? I'm guessing one, but its possible
its two, apparently habitable planets can form round binary systems.
Can you send me the plans for your FTL transmitter by the way, its
very effective.
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==---- http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
"Eric Sosman" <es*****@acm-dot-org.invalid> wrote "Portability" cannot even be assessed entirely from a
study of the code. For example, a program written to the
strictest coding standards and impeccably implemented might
still be "non-portable" to a system with less than 256MB of
memory. (The well-behaved program will, of course, fail
cleanly with a polite message -- but if the program cannot
carry out its intended function, it hasn't been "ported,"
has it?)
Particularly when it could have produced the output, but slower, or less
accurately, or (here's the crucher) with less readable source code, on the
256MB machine.
"Non-portable" is similarly inexact. In c.l.c. usage, all of
these have been tagged as "non-portable;" I've tried to arrange
them in an approximate order from venial sins to deadly:
- Code that assumes two's complement integers
- Code that assumes a particular character encoding
- Code that assumes a particular endianness
- Code that assumes `int i; int j;' allocates the two
variables in adjacent memory locations
... and, of course, many more. Clearly there are "portability
threats" of different kinds and magnitudes in such examples;
because c.l.c. is sort of rabid we tend to lose the differences
and tar them all with the same "non-portable" brush.
"Good enough" portability is a huge problem.
For instance, if you are pasing an IFF file, most of the file is binary and
the clc regular will of course load in all the big-endian integers using a
big-endian read and the little-endian ones using a little-endian read.
Unfortunately the segment tags are ASCII, and it is very tempting to
hardcode 'A' 'I' 'F' 'F' (the tag for a sound file). This will work fine on
any ASCII system, and suddenly go wrong when the portable code is ported to
non-ASCII.
<we******@gmail.com> wrote They're not. Amongst languages in common use today, C is just like
Visual Basic in that there just really isn't any real expectation of
portability on any real world application code. Nearly every other
language in common use today is far more portable than C.
C is probably the most portable for command-line type apps.
Nothing is very portable for GUIs. Java tries to be, but the original
library had to be abandoned because it didn't work. Also, lots of PCs don't
have Java Virtual Machines installed.
The exception, of course, is the tremendous leniancy given to people
asking questions about gcc, and giving answers that are specific to
gcc.
Unix people are morally superior to those who use and program Windows.
Didn't you realsie this?
Walter Roberson wrote: In article <11*********************@f14g2000cwb.googlegroups. com>,
<we******@gmail.com> wrote:Well my planet has Lua, Java, Python, Perl, TCL, and bizarre new
languages like Haskel, Scheme, etc. They are all portable.
perl has horrible portability. Every time I want to do a non-trivial
perl update, whether it be a rev update or just bringing in a bunch
of new modules, it takes me pretty much a working day.
Indeed, I've been doing a module update today, and 22 of the modules
won't compile or won't test properly.
Last I checked, if you compile perl without threading then multiple
signals are not handled properly... and if you do compile with
threading then various other things break. :(
So you mean, its not easy to *INSTALL* right?
--
Paul Hsieh http://www.pobox.com/~qed/ http://bstring.sf.net/
Mark McIntyre wrote: On 9 Dec 2005 17:27:08 -0800, in comp.lang.c , we******@gmail.com
wrote:pemo wrote: In c.l.c we often see 'not portable' comments, but I wonder just how
portable C apps really are.
They're not. Amongst languages in common use today, C is just like
Visual Basic in that there just really isn't any real expectation of
portability on any real world application code.
This is complete nonsense. Find me a Visual Basic compiler for Atari
ST, or Palm pilot, or IBM mainframe.
Uhh ... no, they have *other* basic interpretors and compilers. I'm
sure they all can run the following:
10 PRINT "HELLO"
20 END
Which is the same situation as C.
--
Paul Hsieh http://www.pobox.com/~qed/ http://bstring.sf.net/
<we******@gmail.com> wrote in message
news:11*********************@f14g2000cwb.googlegro ups.com... P.J. Plauger wrote: <we******@gmail.com> wrote in message > pemo wrote:
>> Is C really portable?
>
> No. The standard embodies a portable syntax which exists as subset of
> any compliant compiler, but that's exactly as meaningless as you might
> suspect it is. For example, I don't believe there exists any pair of C
> compilers from different vendors that have exact source space
> compatibility.
Probably true, but not terribly important. Having been in and
around the validation business for several decades, I can testify
that Standard C has way more implementations than any other
language;
Thats nice, but not the question OP was asking. Please crack open a
dictionary: Availability != Portability.
No, but it's part of a complete breakfast. Portability is a
measure of the relative cost of moving software between
platforms vs. rewriting it; it's not a Boolean. Availability
is thus an important factor in improving portability.
[...] and many of them score nearly perfect on two or more
nontrivial validation suites. Put another way, I've sold C code
intended to be portable also for several decades and I've *never*
had to worry about whether that code will compile, and execute
correctly, on a multitude of platforms. (With C++, I *always*
worry.)
Before C came along, I was doing similar things with Fortran,
and with reasonable success.
Well yeah, and you could do the same thing with Visual Basic, and the
various Basic interpretors available for UNIXs, and so on.
Please don't translate my qualitative measure into a Boolean.
Turn your contrast knob down a bit. My point was that you could
achieve rather high portability using the Pfort subset of Fortran.
(See Kernighan & Plauger, "Software Tools".) You could do not
quite as well with Pascal, even though that language was allegedly
more portable than Fortran. (See Kernighan & Plauger, "Software
Tools in Pascal".) But you can write *way* more powerful code
that's portable in C.
If you push
the entire job of portability up to the actual developer of the code,
well then in fact *MOST* languages are portable.
Your contrast knob is set too high again. The developer always
has *some* responsibility in writing portable code; the question
is what reward you get for your effort. I maintain that Standard
C has a pretty high reward for remarkably low effort, particularly
given that C is such a powerful (read: low level) language. But
it's never a question of putting all the responsibility either
on the programmer or on the language. So to say that most
languages are portable is to once again treat portability as a
Boolean, when it's not.
If fact, did you know
its fact possible to be portable *BETWEEN* many languages? When you
put the onus onto the programmer, you can claim all sorts of
capabilities for your language.
No, you can claim all sorts of capabilities for the programmer.
But if you're rewriting the code, you've left the above
definition of portability in the dust.
There is a subtle difference between a language begin portable, and
software which has been painstakingly ported.
Only if you think in black and white. We informally say that
a language is portable if it lowers the cost of writing
programs that are portable (cheaper to move than to completely
rewrite). If you take too much pain in porting the code,
somewhere along the line the cost of a complete rewrite
proves to be lower and the code is "not portable". (You
sometimes find that out too late.) [...] And I've used about half a dozen
other popular languages with lesser success. So, IM(extensive)E
C portability is far from meaningless to me. YM(obviously)V.
>> In c.l.c we often see 'not portable' comments, but I wonder just how
>> portable C apps really are.
>
> They're not. Amongst languages in common use today, C is just like
> Visual Basic in that there just really isn't any real expectation of
> portability on any real world application code. Nearly every other
> language in common use today is far more portable than C.
Does your planet have an oxygen atomsphere? Just curious.
Well my planet has Lua, Java, Python, Perl, TCL, and bizarre new
languages like Haskel, Scheme, etc. They are all portable.
I wonder what language their compilers were written in. I'm
sure *some* of them were written in languages other than C.
P.J. Plauger
Dinkumware, Ltd. http://www.dinkumware.com
On 10 Dec 2005 05:07:36 -0800, in comp.lang.c , we******@gmail.com
wrote: Mark McIntyre wrote: On 9 Dec 2005 17:27:08 -0800, in comp.lang.c , we******@gmail.com
wrote: >
>They're not. Amongst languages in common use today, C is just like
>Visual Basic in that there just really isn't any real expectation of
>portability on any real world application code.
This is complete nonsense. Find me a Visual Basic compiler for Atari
ST, or Palm pilot, or IBM mainframe.
Uhh ... no, they have *other* basic interpretors and compilers.
True, but irrelevant. Egregious misdirection won't help you in CLC
,the pedants are too pedantic. In this instance I refer you to your
own remark "C is just like Visual Basic" and a later one "Visual Basic
is more portable" you made in the same thread.
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==---- http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Is a program just using printf portable?
For instance this one:
#include <stdio.h>
int main(void)
{
int r=printf("hello world\n");
}
Is not portable.
Why?
The result of printf is negative if there was an error,
but the exact values are implementation specific and
will change from this implementation of printf to the
next one. This makes impossible any error analysis
of that function call in a portable way.
The standard makes NO error analysis, not even a summary
error analysis where it could have said some ranges of
values for specific problems, and indicate some common
behavior in the case of an error. For instance an input
output error (disk full, device not ready, whatever)
could have been a single value, specified by the standard
but it isn't.
MANY things in the standard (specially error handling) are
handled in such a sloppy manner that any reasonable
usage of them is impossible and I do not just mean
gets()...
"Portability" is like "code reuse", or "good design principles".
Things everyone will tell you "Of course I want it"
but when you look underneath the covers you see that the
practice is completely different.
Yes, C is very portable and encourages code reuse, but
lisp is as portable as C, and fortran is quite portable too.
You have to limit yourself to the language subset that
will run in several platforms, that's all.
"jacob navia" <ja***@jacob.remcomp.fr> wrote #include <stdio.h>
int main(void)
{
int r=printf("hello world\n");
}
Is not portable.
Why?
The result of printf is negative if there was an error,
but the exact values are implementation specific and
will change from this implementation of printf to the
next one. This makes impossible any error analysis
of that function call in a portable way.
The standard makes NO error analysis, not even a summary
error analysis where it could have said some ranges of
values for specific problems, and indicate some common
behavior in the case of an error. For instance an input
output error (disk full, device not ready, whatever)
could have been a single value, specified by the standard
but it isn't.
MANY things in the standard (specially error handling) are
handled in such a sloppy manner that any reasonable
usage of them is impossible and I do not just mean
gets()...
"Portability" is like "code reuse", or "good design principles".
Things everyone will tell you "Of course I want it"
but when you look underneath the covers you see that the
practice is completely different.
Yes, C is very portable and encourages code reuse, but
lisp is as portable as C, and fortran is quite portable too.
You have to limit yourself to the language subset that
will run in several platforms, that's all.
But the reality is that printf() hardly ever fails, and if it does fail
getting your program's standardoutput is probably not going to be very high
on the user's list of priorities.
A worse problem is that many C installations don't have a stdout.
jacob navia <ja***@jacob.remcomp.fr> writes: Is a program just using printf portable?
For instance this one:
#include <stdio.h>
int main(void)
{
int r=printf("hello world\n");
}
Is not portable.
Why?
Um, because it doesn't return a value from the main program? (That's
valid for C99, but not for C90.) Adding a "return 0;" would fix that.
But I don't think that's what you had in mind.
The result of printf is negative if there was an error,
but the exact values are implementation specific and
will change from this implementation of printf to the
next one. This makes impossible any error analysis
of that function call in a portable way.
No, it just means you can tell that an error occurred if r<0.
You can't portably tell what error occurred (if any). But since the
program doesn't attempt to do so, in what sense is the program itself
non-portable?
(Did you intend to do something with the value of r? Some compilers
would complain about it being set but not used.)
[...]
You have to limit yourself to the language subset that
will run in several platforms, that's all.
And that "subset" is defined by the standard.
--
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.
jacob navia wrote: Is a program just using printf portable?
For instance this one:
#include <stdio.h>
int main(void)
{
int r=printf("hello world\n");
}
Is not portable.
Perfectly portable to any C99-conforming system.
(Under C90 rules it's erroneous, hence not portable.)
Why?
The result of printf is negative if there was an error,
but the exact values are implementation specific and
will change from this implementation of printf to the
next one. This makes impossible any error analysis
of that function call in a portable way.
Nonsense. <stdio.h> defines a macro named EOF, and
the expansion of that macro is the negative value you
mention. You can portably compare `r' to EOF and make
decisions based on equality or inequality. In this case
you can even forego EOF altogether and just test `r<0'
to see whether an error has occurred.
The standard makes NO error analysis, not even a summary
error analysis where it could have said some ranges of
values for specific problems, and indicate some common
behavior in the case of an error. For instance an input
output error (disk full, device not ready, whatever)
could have been a single value, specified by the standard
but it isn't.
"Analysis" is a peculiar word to use here, so I'm not
entirely sure I know what Jacob is talking about. However,
the Standard certainly does prescribe specific behaviors
for some abuses of some functions. For example, acos(42.0)
and strtod("foo", NULL) are required to detect the erroneous
inputs and react in specific ways. True, some functions are
not so tightly specified; the behavior of free("beer") is
undefined. And for other functions the Standard requires
failures to be reported in a specific way, but does not try
to enumerate all the possible causes of failure. For example,
malloc(1) is required to return NULL if it fails, but the
Standard doesn't try to list all the possible failure modes
of all the possible malloc() implementations in the Universe.
The second sentence is simply nonsense. Jacob complains
that the Standard could have used a single value to report
I/O errors but does not -- well, what does he think EOF is?
(I refuse to be fazed by the fact that some functions return
NULL instead of EOF to report an error: Each function has a
known and predictable way of reporting errors, which means
the programmer has a portable way of detecting them.)
MANY things in the standard (specially error handling) are
handled in such a sloppy manner that any reasonable
usage of them is impossible and I do not just mean
gets()...
Reasonable error handling may be beyond Jacob's powers,
but other programmers have found it tractable.
[...]
You have to limit yourself to the language subset that
will run in several platforms, that's all.
In particular, this means you must not use Jacob's
Private Language, the one he claims is C but so clearly is
no such thing. (Perhaps Jacob's opinion of C's portability
stems from his mistaken belief that JPL is C. Since JPL is
not portable, Jacob concludes that C is not portable -- but
really, that's only speculation on my part. More likely,
he's just trolling again.)
--
Eric Sosman es*****@acm-dot-org.invalid
On Sat, 10 Dec 2005 21:04:04 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.fr> wrote: Is a program just using printf portable?
For instance this one:
#include <stdio.h>
int main(void)
{
int r=printf("hello world\n");
}
Is not portable.
You're wrong, and your reasoning is flawed. The programme is 100%
portable, it will work on any platform.
The result of printf is negative if there was an error,
but the exact values are implementation specific and
will change from this implementation of printf to the
next one. This makes impossible any error analysis
of that function call in a portable way.
Nonsense. You yourself note the error analysis you can do - negative
values indicate an error. This is fully portable, and very useful.
MANY things in the standard (specially error handling) are
handled in such a sloppy manner that any reasonable
usage of them is impossible
Perhaps, just perhaps, the people on the committee know a little bit
more than you do? Perhaps there;s a slim chance theres a good reason
why error handling isn't specified as you;d like? Maybe something to
do with different platforms supporting different types of errors, or
not reporting some errors, or not allowing some to occur at all? Or do
you think its more likely that your knowledge is greater than theirs?
Given your apparent exposure to exactly one platform?
"Portability" is like "code reuse", or "good design principles".
Things everyone will tell you "Of course I want it"
but when you look underneath the covers you see that the
practice is completely different.
YMMV but in my experience that view is quite incorrect. I've said this
before, but you seem to have had a very very sheltered exposure to
real world programming.
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==---- http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Keith Thompson a écrit : jacob navia <ja***@jacob.remcomp.fr> writes:
Is a program just using printf portable?
For instance this one:
#include <stdio.h>
int main(void)
{
int r=printf("hello world\n");
}
Is not portable.
Why?
Um, because it doesn't return a value from the main program? (That's
valid for C99, but not for C90.) Adding a "return 0;" would fix that.
But I don't think that's what you had in mind.
Correct. I am using standard C, not some old standard
no longer valid.
The result of printf is negative if there was an error,
but the exact values are implementation specific and
will change from this implementation of printf to the
next one. This makes impossible any error analysis
of that function call in a portable way.
No, it just means you can tell that an error occurred if r<0.
WHAT error? That is my point!
You can't portably tell what error occurred (if any).
That is what I was saying!
But since the
program doesn't attempt to do so, in what sense is the program itself
non-portable?
I didn't write that part because it is not portable.
If there is an i/o error, a sensible value *could* be
EOF, but not even that is specified.
(Did you intend to do something with the value of r? Some compilers
would complain about it being set but not used.)
This is just polemic. My message was clear: the error analysis of
a printf call is not portable.
printf ("%07L\n",23.78);
how do I detect the format error in my program without
tying me to a specific printf implementation???
Eric Sosman <es*****@acm-dot-org.invalid> writes: jacob navia wrote:
[...] The result of printf is negative if there was an error,
but the exact values are implementation specific and
will change from this implementation of printf to the
next one. This makes impossible any error analysis
of that function call in a portable way.
Nonsense. <stdio.h> defines a macro named EOF, and
the expansion of that macro is the negative value you
mention. You can portably compare `r' to EOF and make
decisions based on equality or inequality. In this case
you can even forego EOF altogether and just test `r<0'
to see whether an error has occurred.
No, the standard says:
The fprintf function returns the number of characters transmitted,
or a negative value if an output or encoding error occurred.
There's no implication that the negative value is the same as EOF.
If EOF happens to be -1 (which is common), and printf() happens to
return -1 on error (which is probably also common), then testing
against EOF might happen to work, but the only think you can depend on
is that the result is less than 0 on error.
An implementation could use the return value to indicate what kind of
error occurs, but again, any program depending on this is
non-portable.
--
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.
Mark McIntyre a écrit : On Sat, 10 Dec 2005 21:04:04 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.fr> wrote:
Is a program just using printf portable?
For instance this one:
#include <stdio.h>
int main(void)
{
int r=printf("hello world\n");
}
Is not portable.
You're wrong, and your reasoning is flawed. The programme is 100%
portable, it will work on any platform.
The result of printf is negative if there was an error,
but the exact values are implementation specific and
will change from this implementation of printf to the
next one. This makes impossible any error analysis
of that function call in a portable way.
Nonsense. You yourself note the error analysis you can do - negative
values indicate an error. This is fully portable, and very useful.
"There was an error"
If you are satisfied with such an error analysis OK.
It *could* be that you need to know MORE isn't it?
WHAT type of error?
Input output error? (disk full, i/o whatever)
Format error? (incorrect specifications of the
arguments to printf, illegal format specs, missing argument)
Memory error? (printf attempted to allocate memory for some
internal buffers and failed due to low memory conditions)
MANY things in the standard (specially error handling) are
handled in such a sloppy manner that any reasonable
usage of them is impossible
Perhaps, just perhaps, the people on the committee know a little bit
more than you do? Perhaps there;s a slim chance theres a good reason
why error handling isn't specified as you;d like? Maybe something to
do with different platforms supporting different types of errors, or
not reporting some errors, or not allowing some to occur at all? Or do
you think its more likely that your knowledge is greater than theirs?
Given your apparent exposure to exactly one platform?
I will ignore your sarcastic tone, since I do not care
a lot about your opinion of me. Staying at the level
of a discussion about C, it is obvious that some
care could have produced a more detailed specification of
the error report of printf isn't it?
Specifying a series of error range values could have been done
I do not see why a spec like this would not be feasible:
EOF: i/o error. Device full, device not ready, etc
-100 <= error <=-10 Format error. Incorrectly specified format string
-1000 <= error <= -101 Internal printf error
-1001 > error Non standard specified error type.
etc.
This would have allowed to make portable programs
that test for the return value of printf and can do a more
reasonable error analysis than
AN ERROR HAPPENED...
"Portability" is like "code reuse", or "good design principles".
Things everyone will tell you "Of course I want it"
but when you look underneath the covers you see that the
practice is completely different.
YMMV but in my experience that view is quite incorrect. I've said this
before, but you seem to have had a very very sheltered exposure to
real world programming.
Basically that sentence says:
"I do not like you."
You have NO idea who am I, what do I do, etc.
But you know that I have a "sheltered" ???
exposure to real world programming.
Well, OK. You are correct. I do not care.
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Keith Thompson a écrit : An implementation could use the return value to indicate what kind of
error occurs, but again, any program depending on this is
non-portable.
This is my point. The error analysis of printf is not portable.
And this is a pity, since that function is extremely portable
and with just a bit of effort the error analysis *could*
have been better specified. For instance:
1) EOF: i/o error. Device full, device not ready, etc
2) -100 <= error <=-10 Format error. Incorrectly specified format string
3) -1000 <= error <= -101 Internal printf error: memory low for internal
buffers, synchronization problems in a multi-threaded
context, whatever.
4) -1001 > error Non standard specified error type.
So, for the two most likely problems that occur, we
could now write portable programs that could
do a reasonable error analysis!
Error when output to the device (disk or
terminal), and format spec error.
Specially the second, would be nice to have since if
you write:
printf("%07L\n", 2776.8);
there is now no way to know what happened and why
it doesn't work!
Please understand that I am NOT arguing against portability
but pointing to the fact that even in the most simple
programs, standard C leaves an essential part of
software construction: error analysis, completely out
of the picture!
jacob
Malcolm a écrit : But the reality is that printf() hardly ever fails,
Never had a "Disk full" report?
fprintf can well fail...
And the error analysis there is the same...
Mark McIntyre a écrit : On 10 Dec 2005 05:07:36 -0800, in comp.lang.c , we******@gmail.com
wrote:
Mark McIntyre wrote:
On 9 Dec 2005 17:27:08 -0800, in comp.lang.c , we******@gmail.com
wrote:
They're not. Amongst languages in common use today, C is just like
Visual Basic in that there just really isn't any real expectation of
portability on any real world application code.
Excuse me but maybe you know that VB 6 is no longer
supported by Microsoft and you are supposed to rewrite
your software into VB .NET now.
This has been a catastrophe for many small software
companies that bet on VB and now find themselves
forced to rewrite thousands of lines of complicated
applications in VB .Net...
Happily this is not going to happen with C. It is not
owned by a single company.
On Sat, 10 Dec 2005 23:55:42 +0100, jacob navia wrote:
[...] printf ("%07L\n",23.78);
how do I detect the format error in my program without
tying me to a specific printf implementation???
By using a compiler or other tool that warns about it. Why use a runtime
check for something that can be checked prior?
-- http://members.dodo.com.au/~netocrat
Netocrat a écrit : On Sat, 10 Dec 2005 23:55:42 +0100, jacob navia wrote:
[...]
printf ("%07L\n",23.78);
how do I detect the format error in my program without
tying me to a specific printf implementation???
By using a compiler or other tool that warns about it. Why use a runtime
check for something that can be checked prior?
Lcc-win32 does that kind of analysis but this is not the
point, since the format string could be an argument
or a variable passed from another function, etc.
jacob navia <ja***@jacob.remcomp.fr> writes: Keith Thompson a écrit : jacob navia <ja***@jacob.remcomp.fr> writes:
Is a program just using printf portable?
For instance this one:
#include <stdio.h>
int main(void)
{
int r=printf("hello world\n");
}
Is not portable.
Why?
Um, because it doesn't return a value from the main program? (That's
valid for C99, but not for C90.) Adding a "return 0;" would fix that.
But I don't think that's what you had in mind.
Correct. I am using standard C, not some old standard
no longer valid.
Fine, but you should be aware that there are still plenty of
implementations that don't (yet) support the current standard.
If you're concerned about portability, you have to take that into
account. Adding a "return 0;" at the end of main() is harmless in
any case. The result of printf is negative if there was an error,
but the exact values are implementation specific and
will change from this implementation of printf to the
next one. This makes impossible any error analysis
of that function call in a portable way.
No, it just means you can tell that an error occurred if r<0.
WHAT error? That is my point!
You can't portably tell what error occurred; I grant you that. You can't portably tell what error occurred (if any).
That is what I was saying!
Ok. > But since the
program doesn't attempt to do so, in what sense is the program itself
non-portable?
I didn't write that part because it is not portable.
If there is an i/o error, a sensible value *could* be
EOF, but not even that is specified.
You claimed that the program you posted is non-portable. In fact,
it's quite portable. The part of it you didn't write might be
non-portable, but we're not mind-readers. If you want to make a
point, I suggest you post code that actually illustrates the point
you're trying to make.
There are things you can do portably in C. There are other things you
can't do portably in C. Is that your point? It's true of any
language. (Did you intend to do something with the value of r? Some compilers
would complain about it being set but not used.)
This is just polemic. My message was clear: the error analysis of
a printf call is not portable.
printf ("%07L\n",23.78);
how do I detect the format error in my program without
tying me to a specific printf implementation???
You can't.
The error analysis is merely limited to determining whether or not an
error occurred. I fail to see what that has to do with the
portability of the language.
--
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.
Keith Thompson a écrit : printf ("%07L\n",23.78);
how do I detect the format error in my program without
tying me to a specific printf implementation???
You can't.
The error analysis is merely limited to determining whether or not an
error occurred. I fail to see what that has to do with the
portability of the language.
Well, of course the language is very portable. But when you
dig a bit deeper you find that things like error failure modes
and error analysis is completely left out of the picture or
treated as an afterthought. ("An error occured")
My point is that this is a flaw that hinders the portability
of C, even in small programs like the example I gave.
Is this code snippet portable?
int a,b,c;
....
a = b+c;
No, it is not, since the overflow behavior is not specified...
(See the discussion we had a few days ago)
In general C programs port well, but serious improvements to
the portability of the language could be done if the
far too numerous "dark zones" (UB) would be correctly
specified.
On Sun, 11 Dec 2005 00:07:25 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.fr> wrote: If you are satisfied with such an error analysis OK.
It *could* be that you need to know MORE isn't it?
WHAT type of error?
And how could such error analysis be portable?
Input output error? (disk full, i/o whatever)
Lets go on: Which sort of IO error? What caused it? Who was running
the programme at the time? How much memory was in use? How many
diskdrives were busy? Which horse running in the 3:30 at Kempton? You
see my point?
it is obvious
Then perhaps you'd care to show how.
that some
care could have produced a more detailed specification of
the error report of printf isn't it?
Please produce a DR, submit it to the committee, and remember, it has
to work on all platforms supported by C. If its workable, I'm quite
sure they'll consider it. Remember, it mustn't break any existing
implementations, nor produce any meaningless errors.
Specifying a series of error range values could have been done
I do not see why a spec like this would not be feasible:
Of course its feasible, But many of them have no meaning and in fact
may even be impossible on many implementations. I mean, would you
really want to provide an "out of red ink" error code for a screen
device? Or a "please rewind the tape" error for a keyboard?
Basically that sentence says:
"I do not like you."
No. That sentence says "you write stuff here based on apparent
experience of one platform, and assume that your experience is
typical. You persist in this even when shown to be wrong by
counterexample. "
You have NO idea who am I, what do I do, etc.
I know a fair amount as it happens. I know you're probably french, I
know you write a compiler. I know you use webhosting services of the
university of Virginia. I know you have a hook-in with a German
software company based near Karlsruhe, and that the town has a
brewery.
I also know you write incorrect stuff in CLC, and I know that from
time to time you write correct stuff. If you could stick to the
latter, you'd find yourself flamed less.
I do not care.
Thats evident. And here's a thought: people who are unrepentant in the
face of their obvious errors, especially ones who are agressive in
defending those errors, often find they're unpopular with their peers.
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==---- http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
On Sat, 10 Dec 2005 23:55:42 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.fr> wrote: printf ("%07L\n",23.78);
how do I detect the format error in my program without
tying me to a specific printf implementation???
By using a compiler, or simlar tool, that warns about such errors. Why
rely on runtime checks for stuff you should be checking at compile
time.
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==---- http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
jacob navia <ja***@jacob.remcomp.fr> writes:
[snip] In general C programs port well, but serious improvements to
the portability of the language could be done if the
far too numerous "dark zones" (UB) would be correctly
specified.
Nailing down the details of those "dark zones" could also make the
language more difficult to implement on some platforms, hindering
portability.
C does place a heavier burden on the programmer than many other
languages. It assumes you know what you're doing, and often isn't
very helpful when that assumption turns out to be incorrect. This is
a deliberate decision, part of what's often referred to as the "spirit
of C".
It's perfectly reasonable to design a language similar to C, but with
better defined behavior on errors -- especially if you happen to have
your own compiler and a newsgroup in which to discuss it.
It's also perfectly reasonable to advocate changing C; comp.std.c is
the appropriate newsgroup for this. Being able to point to an
existing implementation is likely to help your case, especially if you
can demonstrate that a feature can be implemented on a wide variety of
platforms.
--
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.
On Sun, 11 Dec 2005 00:16:26 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.fr> wrote: Keith Thompson a écrit : An implementation could use the return value to indicate what kind of
error occurs, but again, any program depending on this is
non-portable.
This is my point. The error analysis of printf is not portable.
No, no no. Are you dense? AS SPECIFIED, its completely portable. Any
zero or greater value means success. Any negative value means failure.
This is completely portable.
To be sure, more detailed analysis is not portable. I should imagine
this is why it was excluded from the standard, wouldn't you?
Please understand that I am NOT arguing against portability
but pointing to the fact that even in the most simple
programs, standard C leaves an essential part of
software construction: error analysis, completely out
of the picture!
Only if the programmer is bad.
I'm sorry, but really you asked for that.
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==---- http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
On Sun, 11 Dec 2005 00:35:40 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.fr> wrote: Mark McIntyre a écrit :
(actually websnarf wrote this tripe)
>They're not. Amongst languages in common use today, C is just like
>Visual Basic in that there just really isn't any real expectation of
>portability on any real world application code.
I didn't make the original remark. If you /must/ reply to a deeply
nested comment, please get the immediate attributions rght. I don't
want anyone who can't read chevrons to think I wrote that patent
nonsense.
Excuse me but maybe you know that VB 6 is no longer
supported by Microsoft and you are supposed to rewrite
your software into VB .NET now.
This has been a catastrophe for many small software
I totally agree with you. Anyone saying that VB is portable is a fool
or a knave.
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==---- http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
On Sun, 11 Dec 2005 01:11:18 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.fr> wrote: Well, of course the language is very portable. But when you
dig a bit deeper you find that things like error failure modes
and error analysis is completely left out of the picture or
treated as an afterthought. ("An error occured")
My point is that this is a flaw that hinders the portability
of C, even in small programs like the example I gave.
For goodness' sake, no it does NOT. It hinders teh portability of a
programme that depends on platform-specificextensions to C, but no
more.
It in fact AIDS portability, since it prevents the use of non-portable
error codes.
Is this code snippet portable?
(snip example of potential integer overflow).
No, it is not, since the overflow behavior is not specified...
I disagree. Its portable, but requires care. YMMV.
In general C programs port well, but serious improvements to
the portability of the language could be done if the
far too numerous "dark zones" (UB) would be correctly
specified.
But they can't be, don't you understand? How would you specify the
above, on a chip which didn't support detection of integer overflow?
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==---- http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Mark McIntyre a écrit : Specifying a series of error range values could have been done
I do not see why a spec like this would not be feasible:
Of course its feasible, But many of them have no meaning and in fact
may even be impossible on many implementations.
Who cares? Those implementations are not FORCED to issue that
kind of errors!!!!
They have only to respect the ranges for the errors
they do issue.
The nice thing of such an implementation is that offers
portability at no cost for anybody.
Assigning a range of values for different types of
errors allows the calling program to check for in a
portable way the type of error (for instance i/o error)
r = fprintf(... );
if (r == EOF) {
printf("Disk full. Please erase some files\n");
}
But it DOESN'T constrain the implementations in any way.
It just constrains the range of error codes so that they can
be portably tested!
I mean, would you
really want to provide an "out of red ink" error code for a screen
device? Or a "please rewind the tape" error for a keyboard?
Those codes would be in some portable range, of values. That way
all those errors could be tested in a portable way without knowing
anything specific about the printer/output device, but
KEEEPING the possibility of a more specific error handling
if desired.
jacob
Mark McIntyre a écrit : On Sun, 11 Dec 2005 00:16:26 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.fr> wrote:Please understand that I am NOT arguing against portability
but pointing to the fact that even in the most simple
programs, standard C leaves an essential part of
software construction: error analysis, completely out
of the picture!
Only if the programmer is bad.
I'm sorry, but really you asked for that.
Please Mark suppose this program:
fprintf(outfile, ... etc);
Are you going to say to me that if fprintf fails,
this is the programmer's fault ???
No, it is that the disk is FULL, period.
What I am trying to say is that the programmer has no
PORTABLE way to test for that condition...
Normally you would ASSUME that if (r < 0) the disk
is full, but it could be actually completely another
thing: File opened for reading only, no access to the
device etc.
This kind of analysis is called ERROR ANALYSIS and it is
an essential part of software construction. And, by
the way, the good programmers are the ones that always
have this issues in mind.
Mark McIntyre a écrit : In general C programs port well, but serious improvements to
the portability of the language could be done if the
far too numerous "dark zones" (UB) would be correctly
specified.
But they can't be, don't you understand? How would you specify the
above, on a chip which didn't support detection of integer overflow?
Well what happens with the fesetenv, fegetenv and all floating point
environment functions in a machine that doesn't have floating point?
There could be always provisions that allow certain parts of the
standard to be optional!
But WHY do we have to use always the LOWEST common denominator???
MANY CPU support the overflow flag please.
jacob
Mark McIntyre a écrit : On Sun, 11 Dec 2005 00:35:40 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.fr> wrote:
Mark McIntyre a écrit :
(actually websnarf wrote this tripe)
>>They're not. Amongst languages in common use today, C is just like
>>Visual Basic in that there just really isn't any real expectation of
>>portability on any real world application code.
>
I didn't make the original remark. If you /must/ reply to a deeply
nested comment, please get the immediate attributions rght. I don't
want anyone who can't read chevrons to think I wrote that patent
nonsense.
You are right. Excuse me.
P.J. Plauger wrote: <we******@gmail.com> wrote in message P.J. Plauger wrote: <we******@gmail.com> wrote in message
> pemo wrote:
>> Is C really portable?
>
> No. The standard embodies a portable syntax which exists as subset of
> any compliant compiler, but that's exactly as meaningless as you might
> suspect it is. For example, I don't believe there exists any pair of C
> compilers from different vendors that have exact source space
> compatibility.
Probably true, but not terribly important. Having been in and
around the validation business for several decades, I can testify
that Standard C has way more implementations than any other
language;
Thats nice, but not the question OP was asking. Please crack open a
dictionary: Availability != Portability.
No, but it's part of a complete breakfast. Portability is a
measure of the relative cost of moving software between
platforms vs. rewriting it;
Incorrect. If what you said was true then "portability cost" would be
a redundant phrase that had no meaning. Of course, that's not the
case. So you are attempting to claim that the definition of
"portability" is really the definition of "portability cost".
Portability describes a *CHARACTERISTIC* of the degree of
transportability of source code. By itself, its not a measure of cost.
[...] it's not a Boolean. Availability is thus an important factor in improving portability.
No. Availability affects where you can port to. The nature of a given
source code's portability is always taken against the set of platforms
that have a compiler for that platform.
One can see this more clearly when one realizes that Java was a
portable language *BEFORE* any compilers were available for it.
Because that's the nature of the language itself. Availability, just
provided proof.
[...] and many of them score nearly perfect on two or more
nontrivial validation suites. Put another way, I've sold C code
intended to be portable also for several decades and I've *never*
had to worry about whether that code will compile, and execute
correctly, on a multitude of platforms. (With C++, I *always*
worry.)
Before C came along, I was doing similar things with Fortran,
and with reasonable success.
Well yeah, and you could do the same thing with Visual Basic, and the
various Basic interpretors available for UNIXs, and so on.
Please don't translate my qualitative measure into a Boolean.
Turn your contrast knob down a bit. My point was that you could
achieve rather high portability using the Pfort subset of Fortran.
Right, but the same true of other languages including C, and is
actually not in support of your point.
(See Kernighan & Plauger, "Software Tools".) You could do not
quite as well with Pascal, even though that language was allegedly
more portable than Fortran. (See Kernighan & Plauger, "Software
Tools in Pascal".) But you can write *way* more powerful code
that's portable in C.
But you can write code far more powerful *still* in other languages,
like Perl, Python, Java, etc. C may compare very well to extremely
obsolete languages that are only in marginal use today, but I do
believe I said "modern languages in common use". You're caught in a
time warp here -- you've seen that C is more portable than Pascal, but
somehow cannot see that modern languages are again more portable than
C.
If you push
the entire job of portability up to the actual developer of the code,
well then in fact *MOST* languages are portable.
Your contrast knob is set too high again. The developer always
has *some* responsibility in writing portable code; the question
is what reward you get for your effort. I maintain that Standard
C has a pretty high reward for remarkably low effort,
Right, because performance doesn't matter to you, and things like
cryptography just have no meaning to you. And of course, for whatever
reason you are not actually comparing it to other contemporary
languages.
[...] particularly
given that C is such a powerful (read: low level) language. But
it's never a question of putting all the responsibility either
on the programmer or on the language. So to say that most
languages are portable is to once again treat portability as a
Boolean, when it's not.
If fact, did you know
its fact possible to be portable *BETWEEN* many languages? When you
put the onus onto the programmer, you can claim all sorts of
capabilities for your language.
No, you can claim all sorts of capabilities for the programmer.
But if you're rewriting the code, you've left the above
definition of portability in the dust.
I don't know what definition you are talking about, but I think you
missed my point. See: http://www.nyx.net/~gthompso/self_mult.htm
There is a subtle difference between a language begin portable, and
software which has been painstakingly ported.
Only if you think in black and white. We informally say that
a language is portable if it lowers the cost of writing
programs that are portable (cheaper to move than to completely
rewrite).
Well no, *you* informally say that, because you have little respect for
precise language. Its a good thing you aren't on any committee that
manages a international standard. Oh wait ...
http://www.m-w.com/dictionary/portable
http://www.thefreedictionary.com/portable
http://dictionary.reference.com/search?q=portable
There's nothing about cost in any of those definitions. Also notice
that the definitions include the "two or more platforms" in them.
Meaning that "portability" is not related to the number of platforms
your code is portable, but rather the degree to which the software
itself is inherently portable.
[...] If you take too much pain in porting the code,
somewhere along the line the cost of a complete rewrite
proves to be lower and the code is "not portable". (You
sometimes find that out too late.)
Now tell me who's being black and white? [...] And I've used about half a dozen
other popular languages with lesser success. So, IM(extensive)E
C portability is far from meaningless to me. YM(obviously)V.
>> In c.l.c we often see 'not portable' comments, but I wonder just how
>> portable C apps really are.
>
> They're not. Amongst languages in common use today, C is just like
> Visual Basic in that there just really isn't any real expectation of
> portability on any real world application code. Nearly every other
> language in common use today is far more portable than C.
Does your planet have an oxygen atomsphere? Just curious.
Well my planet has Lua, Java, Python, Perl, TCL, and bizarre new
languages like Haskel, Scheme, etc. They are all portable.
I wonder what language their compilers were written in. I'm
sure *some* of them were written in languages other than C.
I think all of them were. So let us see what happens when we follow
this to its logical conclusion. Since they were written in C,
presumably that makes C more portable than any one of them right? Ok,
but what language is C written in? When a platform is first
constructed, the pattern usually is that they make an assembler, which
is then used to bootstrap a small C compiler, after which a real C
compiler is ported to that, or something similar. So by this reasoning
we can conclude, then, that assembly is more portable than C.
Each of those languages was *painstakingly ported*. As posted by
Walter Robinson in this thread, apparently the Perl source code (which
is in C) is a horrendous mess to port to each platform. I.e., even
*after having been ported* its a pain in the ass to use, because of
platform compatibility problems. But these are not problems of the
Perl *language*, but rather the implementation, which of course, is
mostly related to poor portability of C itself.
--
Paul Hsieh http://www.pobox.com/~qed/ http://bstring.sf.net/
Mark McIntyre wrote: On 9 Dec 2005 19:43:44 -0800, in comp.lang.c , we******@gmail.com
wrote:P.J. Plauger wrote: Does your planet have an oxygen atomsphere? Just curious. [...]
Oh and BTW, my planet actually has mostly a Nitrogen atmosphere, though
it does includes a smaller proportion of oxygen, CO_2 and other
elements.
Sounds habitable. One sun or two? I'm guessing one, but its possible
its two, apparently habitable planets can form round binary systems.
Can you send me the plans for your FTL transmitter by the way, its
very effective.
Remind me. You're the one that said empty strings are illegal right?
--
Paul Hsieh http://www.pobox.com/~qed/ http://bstring.sf.net/
<we******@gmail.com> wrote in message
news:11**********************@f14g2000cwb.googlegr oups.com... > Thats nice, but not the question OP was asking. Please crack open a
> dictionary: Availability != Portability.
No, but it's part of a complete breakfast. Portability is a
measure of the relative cost of moving software between
platforms vs. rewriting it;
Incorrect. If what you said was true then "portability cost" would be
a redundant phrase that had no meaning. Of course, that's not the
case. So you are attempting to claim that the definition of
"portability" is really the definition of "portability cost".
Call it a claim if you will. I think of it as an observation.
If you reread your earlier diatribes, you'll find nearly as many
potential meanings for "portability" as occurrences of that word.
I'm simply coming from a coherent worldview that seems to fit
with what rational people seem to mean when they use that word.
I've been promulgating this "definition" for decades, and I've
repeatedly been told that it makes sense. You seem to be working
backwards from a syllogism that ends in "Ergo, C is not really
portable." As Adlai Stevenson famously summarized a political
opponent's argument, "These are the opinions on which I base my
facts."
Portability describes a *CHARACTERISTIC* of the degree of
transportability of source code. By itself, its not a measure of cost.
Fine, pick your adjective. But once you say "degree" you've given
up on using portability as a Boolean. (And what happens when your
boss tells you that one degree costs $12,873.17?)
[...] it's not a Boolean. Availability is thus an important factor in
improving portability.
No. Availability affects where you can port to. The nature of a given
source code's portability is always taken against the set of platforms
that have a compiler for that platform.
And the fewer the platforms, the higher the probable cost of
porting -- I mean, the lower the degree of portability.
One can see this more clearly when one realizes that Java was a
portable language *BEFORE* any compilers were available for it.
Because that's the nature of the language itself. Availability, just
provided proof.
Uh, no. My brother worked a couple of years at making Java programs
really portable. He began by throwing away all multithreading code
and simplifying all GUI calls, so that he could then focus on all
the really sneaky portability problems. FWIW, he's one of the best
programmers I know, and it wasn't easy work for him. (Gosling
began by eliminating all the things from C that he *knew* were
portability problems, thus freeing himself up to get in *real*
trouble.)
Please don't translate my qualitative measure into a Boolean.
Turn your contrast knob down a bit. My point was that you could
achieve rather high portability using the Pfort subset of Fortran.
Right, but the same true of other languages including C, and is
actually not in support of your point.
Back to the complete breakfast again. That "characteristic" you
call portability has a number of components. Among them are
availability, uniformity, and power. C rates high on all these
measures, making it IME the best candidate in many cases for
writing code intended to be portable.
(See Kernighan & Plauger, "Software Tools".) You could do not
quite as well with Pascal, even though that language was allegedly
more portable than Fortran. (See Kernighan & Plauger, "Software
Tools in Pascal".) But you can write *way* more powerful code
that's portable in C.
But you can write code far more powerful *still* in other languages,
like Perl, Python, Java, etc.
And that's where we part company. If by powerful you mean you can
perform certain large scale operations with an economy of expression,
then I agree. I write Maplesoft scripts to do things in minutes that
would be impractical in C. But if by powerful you mean that there
are few limitations on what you can manage, then C wins hands down.
I wouldn't program a coffee pot in Maplesoft, but I do perform
quite a bit of mathematics in C.
C may compare very well to extremely
obsolete languages that are only in marginal use today, but I do
believe I said "modern languages in common use". You're caught in a
time warp here -- you've seen that C is more portable than Pascal, but
somehow cannot see that modern languages are again more portable than
C.
I admit that I'm an old fart, but I'm also quite accustomed to being
declared obsolete on a regular basis. IIRC, the first time someone
told me my days as a programmer were numbered was in 1964. Then
there were the Pascal zealots, then Ada, then C++, then Java,
then...
> If you push
> the entire job of portability up to the actual developer of the code,
> well then in fact *MOST* languages are portable.
Your contrast knob is set too high again. The developer always
has *some* responsibility in writing portable code; the question
is what reward you get for your effort. I maintain that Standard
C has a pretty high reward for remarkably low effort,
Right, because performance doesn't matter to you, and things like
cryptography just have no meaning to you.
Where the hell did that come from? And who the hell are you to tell
me what matters to me or what has meaning to me? Get stuffed.
And of course, for whatever
reason you are not actually comparing it to other contemporary
languages.
Funny, I thought I was.
> There is a subtle difference between a language begin portable, and
> software which has been painstakingly ported.
Only if you think in black and white. We informally say that
a language is portable if it lowers the cost of writing
programs that are portable (cheaper to move than to completely
rewrite).
Well no, *you* informally say that, because you have little respect for
precise language. Its a good thing you aren't on any committee that
manages a international standard. Oh wait ...
You have now crossed the line from being simply irrational and
parochial into being actively insulting. I think this conversation
is nearing its end.
[...] If you take too much pain in porting the code,
somewhere along the line the cost of a complete rewrite
proves to be lower and the code is "not portable". (You
sometimes find that out too late.)
Now tell me who's being black and white?
If the cost is $17,000, that's a "degree". If the question is
"Is cost less than $17,000?" that's a Boolean. Black and white.
> Well my planet has Lua, Java, Python, Perl, TCL, and bizarre new
> languages like Haskel, Scheme, etc. They are all portable.
I wonder what language their compilers were written in. I'm
sure *some* of them were written in languages other than C.
I think all of them were. So let us see what happens when we follow
this to its logical conclusion. Since they were written in C,
presumably that makes C more portable than any one of them right? Ok,
but what language is C written in?
C.
When a platform is first
constructed, the pattern usually is that they make an assembler, which
is then used to bootstrap a small C compiler, after which a real C
compiler is ported to that, or something similar.
No, you take an existing C compiler, written in C, and rewrite the
back end to make a cross compiler. You do the same with an assembler,
also written in C. Some of us have been doing that for a third of
a century. Truth to tell, I used to have to write about 100 lines
of assembly language to support each new machine architecture.
For the past decade or so, I even write that as non-portable C.
And these days you can write a self-compiling translator in C++
as well -- with a few thousand lines of C code under the hood.
I'll even confess that I once wrote a relocating linker as one
giant QED edit script, but I didn't do my employer any favors in
doing so. The fact is that C is still the only language that is
both portable and almost completely self supporting, OS and all.
C++ comes close, but whatever is third is way back there.
So by this reasoning
we can conclude, then, that assembly is more portable than C.
A syllogism stands or falls on the truth of its assumptions.
Each of those languages was *painstakingly ported*. As posted by
Walter Robinson in this thread, apparently the Perl source code (which
is in C) is a horrendous mess to port to each platform.
Shows what happens when you believe more in Perl than in C, I'd say.
I.e., even
*after having been ported* its a pain in the ass to use, because of
platform compatibility problems. But these are not problems of the
Perl *language*, but rather the implementation, which of course, is
mostly related to poor portability of C itself.
Hold onto that warm thought. Winter is coming.
P.J. Plauger
Dinkumware, Ltd. http://www.dinkumware.com This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Martin Marcher |
last post by:
Hi,
I've read several questions and often the answer was
'C knows nothing about .'
So if C knows that little as some people say, what are the benefits, I
mean do other languages know more...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
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: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
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: 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,...
| | |
