Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Writing "absolutely" portable code

Reply
Thread Tools

Writing "absolutely" portable code

 
 
Rui Maciel
Guest
Posts: n/a
 
      01-11-2012
jacob navia wrote:

> Linux people are very conservative, and their version of Unix is frozen
> around 1980. Apple did a better Unix. And I am not speaking about the
> wonderful and intuitive user interface, the great LOOKS, the package
> management system that has hundreths of public domain applications
> ported to Apple Unix, etc etc.


I don't know what you mean by "Linux people". As you know, linux itself is
only an OS kernel. From there, there is a considerable number of people and
organizations who, independently, put together operating systems which are
based on the linux kernel. Some of those projects don't even rely
exclusively on the linux kernel, as they also provide essentially the same
operating system with kernels other than the linux one.

Anyway, there isn't a concerted effort dictated by a centralized authority
intended to steer the technical direction of those projects. Well, at least
beyond the scope of each individual project.

Therefore, until a meaningful definition for "linux people" is provided,
your assertion is meaningless. And even if one is provided, I seriously
doubt your initial assertion will hold.


> I am really satisfied with my Mac, sorry. It is EXACTLY what linux
> could have been if they would have worked in making a BETTER Unix
> instead of producing several dozens of different window management
> systems (equally bad and equally awful) and several dozens of equally
> bad IDEs.


This assertion is absurd. There is no centralized authority wasting
resources on redundant projects. There are multiple, independent people
investing their time developing a set of projects independently.
Criticizing someone for, in his spare time, having put together a window
manager isn't a reasonable thing to do, particularly if the only complain
which is being made is that there are already competing projects out there.
For example, the same criticism that you are directing at the "several dozen
different window management systems" can also be used to complain about
jacob navia's compiler. Do you also believe that you should have worked in
making a better anything instead of producing one of the several dozen
different compilers already available, each equally bad and equally awful?


> They never think about the USER EXPERIENCE when designing their programs
> (just look at gdb), something Apple has always had in mind.


What's wrong with gdb?


Rui Maciel
 
Reply With Quote
 
 
 
 
Rui Maciel
Guest
Posts: n/a
 
      01-11-2012
ec429 wrote:

> The WMs are not "awful"; neither GNOME nor KDE is perfect, but that's
> largely because they erred in the direction of imitating MacOS Classic.
> Xfce, LXDE, fvwm2 and several others are clean, unobtrusive, and
> lightweight.


I don't see how KDE tried to imitate any of Apple's DEs. KDE tens to be
accused of trying to imitate Windows' DEs, which is also a silly claim. For
example, I remember some people claiming that KDE4 tried to rip off
Windows7, eventhough KDE4 was released over a year and a half before
Windows7.


Rui Maciel
 
Reply With Quote
 
 
 
 
Rui Maciel
Guest
Posts: n/a
 
      01-11-2012
Richard wrote:

> Wrong. Invariably its because people dont like change. Debug using
> eclipse or VS and compare it to using the god awful gdb with ddd or
> something equally as half arsed, ugly and unreliable.


Do you realize that Eclipse uses gdb to debug C and C++ code?


Rui Maciel
 
Reply With Quote
 
Rui Maciel
Guest
Posts: n/a
 
      01-11-2012
ArifulHossain tuhin wrote:

> Our team was(and still is) little inexperienced dealing with Gnu Build
> system. Lot of them used to develop in java/c# or visual studio. Our
> organization is trying to train us, hopefully we won't be new in coming
> months. But still i believe a moderate sized project can be done by
> handwritten makefiles because the similarity in POSIX systems. Yes they
> require tweaks and won't be "automated". But autotools are no different.
> Most of the time, they need tweaks too. The problem is the "tweak"s are
> not very understandable because of the complexity associated with
> Autotools. Whereas makefiles are rather straight forward.


In my opinion, the main flaw which affects the GNU Build System is its sub-
par documentation, which needlessly contributes to its steep learning curve.
Maybe it's even responsible for it. Nonetheless, once someone gets the hang
of it, things tend to work well. It's just a matter of reading the right
documentation and checking how others have set up their own projects.


Rui Maciel
 
Reply With Quote
 
ec429
Guest
Posts: n/a
 
      01-11-2012
On 10/01/12 19:48, Richard wrote:
> ec429<(E-Mail Removed)> writes:
>> Meaning that your developer on an Apple system writes non-conforming makefiles
>> and can't understand why no-one on other Unices ever seems to use his software.
>> The pitfalls of Postel's prescription, as HTML demonstrated.

> They dont care.

Not caring that they're wrong doesn't make them right. The lessons of
the old Unix Wars about the danger of differentiation still ring true.
>>> NO NEED FOR -lm!!!!!!! The libraries are included BY DEFAULT!!!!!!!!

>> Inherently brittle as it won't canonically know about all libraries, also I bet
>> it ****es off library developers when it links against the old version instead
>> of the new one they've just built.

> Every heard of overwriting defaults. Methins you squawk/protest too
> much.

My point is that the feature isn't useful because it trivially can't be
robust. If you learn to rely on it, you will get headaches. Is " -lm"
really so much to type?
The squawking (which I interpret to refer to the ALL CAPS SHOUTING!!!!)
was in the post I was replying to.
>> Linux and GNU follow (largely) the POSIX standards. Standards are a
>> _good

> Rubbish.

Where Linux and GNU fail to follow POSIX, they usually have a
POSIXLY_CORRECT switch (or a POSIX_ME_HARDER ), and it's usually
because of some brain-damaged thing a Unix vendor invented in order to
differentiate their product, which then got used in too much software to
excise it. Or were you disputing that standards are a good thing? If
so, you're beyond help.
>> thing_. While every improvement is necessarily a change, not every change is
>> necessarily an improvement. When Linux does things the 1980 way, it's because
>> the 1980 way is the Right Thing (tm). When the 1980 way is the Wrong
>> Thing

> Wrong. Invariably its because people dont like change. Debug using
> eclipse or VS and compare it to using the god awful gdb with ddd or
> something equally as half arsed, ugly and unreliable.

You have a problem with gdb? The problem is you. gdb is very powerful,
it has a well-designed CLI, and in my experience it's reliable (from
what I've heard, VS is very much /not/ reliable).
Anecdote: When Phil Kendall was designing the debugger for FUSE (the
Free Unix Spectrum Emulator, not Filesystem in USErspace), did he base
it on Eclipse? Of course not. VS? Surely you jest. No, he chose a
stripped-down gdb interface (somewhat modified to deal with z80 assembly
rather than C binaries with debugging symbols).
What, exactly, don't you like about gdb? Does it not hold your hand
enough, poor ickle child? Are there not enough pictures to engage your
attention?
>> (tm), Linux changes it where compatibility permits. (Interestingly, several of
>> the Right Things turn out to have come from Plan 9)
>> Package management? .deb; end of.

> Which particular packahame management? There are about 60 at the last
> count. Too many chiefs, not enough indians.

I said which package management: Debian's system. If you meant which
package /manager/, there's really only one (apt). There are plenty of
interfaces, but that's a matter of choice; since they're all apt,
they're all compatible, so it wouldn't matter if every single user had
their own, they'd still all be using apt and sharing .deb packages. The
joy of standards, you see
>> The WMs are not "awful"; neither GNOME nor KDE is perfect, but that's largely
>> because they erred in the direction of imitating MacOS Classic.

> And you based that on what? How did they err?

They (well, GNOME at least; I haven't used KDE) tried to copy the
'persistent desktop' metaphor; gnome-session-save is a shonky piece of
crap, and session management generally is a bit broken in gdm. I intend
to ditch it and install something simpler and lighter-weight, but I
haven't come to a decision yet.
>> Xfce, LXDE, fvwm2 and several others are clean, unobtrusive, and
>> lightweight.

> Ugly and horrible too.

Actually I think fvwm is quite nice-looking. What really sells it,
though, is that it decouples the desktop shell from the processes under
it. I was ssh-ing into linux.pwf.cam.ac.uk one day, running a fvwm
session by the magic of Xnest, when my ssh tunnel fell over. When I
connected back up, there were all my terminals, still running fine,
unaware that fvwm had ever exit. If only GNOME could detach like that
*sigh*. (Note, by the way, that this is /old/ technology; WMs generally
have been somewhat slow in taking up ideas from each other - but that's
because they've been responding to market pressure to "Look shiny! Like
Apple does!")
>> IDEs are simply not necessary; if nano were mouse-aware I wouldn't even use a
>> GUI editor. Text editor, compiler, make, debugger, shell tools -

> IDEs, well done, are a real boon. I can only assume you never used one
> or worked with any considerably sized code base that allows context
> help, auto class completions, refactoring, JIT debugging etc etc.

I've used IDEs, and hated them. "Auto class completions"? Sorry, I
don't do OO. Refactoring? I do that by hand and it isn't that hard;
having it done automatically sounds like a great way to introduce subtle
bugs if there's a global or a static around. I don't need context help:
C is small, and I choose libraries whose interfaces are similarly small.
If you find yourself needing context help in order to use a tool, the
tool is badly designed (or your brain is; I'm not sure which).
On the charge of codebase size, I guess I plead guilty: my largest
project is about 10,000 lines. However, that's largely because I design
small combineable tools in the Unix tradition, rather than the monster
monoliths that are popular in other parts of the computing landscape.
If you need an IDE to handle your project, your project is wrong - that
doesn't make the IDE right.
(I have worked with larger codebases; this summer I was working on a web
frontend to the NetFPGA toolchain, thousands of LOC in several
languages. I handled C, Perl, Python, PHP, Javascript, and Verilog. No
IDE, no problem.)
The shell is my DE; when I want help, there's 'man'; when I want build
control, there's 'make'; when I want debugging, there's 'gdb'; when I
want source control, there's 'git'. The fact that these are separate
tools designed by different people doesn't stop them interoperating
nicely; Unix tradition produces much better integration than
"Integration" ever can, and it leaves me free to pick and choose my
tools at will (don't like make? there's always CMake. Don't like git?
Try svn or bzr or hg.)
In summary, Integrated Development Environments Considered Harmful.

fisk me, I fisk back -e
--
'sane', adj.: see 'unimaginative'
on the web - http://jttlov.no-ip.org
 
Reply With Quote
 
ArifulHossain tuhin
Guest
Posts: n/a
 
      01-11-2012
On Wednesday, January 11, 2012 1:20:10 AM UTC+6, Stephen Sprunk wrote:
> On 10-Jan-12 03:21, ArifulHossain tuhin wrote:
> > On Monday, January 9, 2012 9:07:23 PM UTC+6, Rui Maciel wrote:
> >> ArifulHossain tuhin wrote:
> >>> One example, there was a small project i was involved, which was modifying
> >>> a tiny "media realy" software. The project has only 20 10-15 c files. we
> >>> need to add some of our own. because of the hideous build systems. And it
> >>> was not necessary to maintain this small project with autotools. we ended
> >>> up writing custom makefiles for the project.
> >>
> >> That is strange. Were those files C source code files? And did anyone in
> >> that team had any experience with the GNU build system, or was everyone
> >> cutting their teeth on it?

> >
> > Our team was(and still is) little inexperienced dealing with Gnu Build
> > system. Lot of them used to develop in java/c# or visual studio. Our
> > organization is trying to train us, hopefully we won't be new in coming
> > months.

>
> Hopefully that training is coming from someone with significant
> experience. It can be a pretty steep learning curve.
>


Training is not coming from a expert. In our country we do not have a lot guys working on linux/unix programming these days. Most of Linux/Unix guyz we have are admins. They know little about build systems in depth.

> > But still i believe a moderate sized project can be done by handwritten
> > makefiles because the similarity in POSIX systems. Yes they require
> > tweaks and won't be "automated".

>
> That's the major feature of autotools: to not need to tweak makefiles
> for each target platform.
>
> For in-house apps that only have a few targets, learning autotools is
> probably not worth the effort; for open-source apps that have to run on
> dozens of targets, each with varying libraries and other apps installed,
> and which may be cross-compiled or installed in different locations,
> it's well worth it.
>


Its going to be deployed on customer's infrastructures.


> > But autotools are no different. Most of the time, they need tweaks too.

>
> If so, you're (probably) doing it wrong.
>


Maybe, because i do not have a lot of experience regarding autotools. I'm also a admin turned developer. my bad


> > The problem is the "tweak"s are not very understandable because of the
> > complexity associated with Autotools. Whereas makefiles are rather
> > straight forward.

>
> That's just a matter of what you're used to. If I learned the autotools
> system first, I'd probably find that easier than makefiles. The build
> systems in the MS tools are baffling to me, but if that's what you
> learned first, that's probably easier for you than makefiles.
>
> S
>
> --
> Stephen Sprunk "God does not play dice." --Albert Einstein
> CCIE #3723 "God is an inveterate gambler, and He throws the
> K5SSS dice at every possible opportunity." --Stephen Hawking


 
Reply With Quote
 
ArifulHossain tuhin
Guest
Posts: n/a
 
      01-11-2012
On Tuesday, January 10, 2012 10:44:07 PM UTC+6, Dirk Zabel wrote:
> Unfortunately, this step very often does not work for me. I am regularly
> trying to cross-compile for an embedded, ppc-based linux system, which
> in theory should be possible with the configure-parameter
>
> --host=ppc-XXX-linux
>
> Very often I have to work long until configure works. And if it works,
> there is no guarantee that the next step, i.e. "make" works. And if that
> works, there might be subtle errors which show up later when the program
> runs on the target platform. Sometimes I don't get configure to work
> anyway or decide, that it's not worth the time. For example, I once
> tried to build apache for my target platform without success. Finally, I
> decided to use another webserver (lighttpd), which might be more
> appropriate anyway, but I wanted to give apache a try.
> Just now I am in the process to cross-compile php for my target. The
> first issue was that the target has MSB byte-order, which the configure
> script did not care about. The actual sources had #ifdefs to take
> byte-order into account, so after patching the byte-order information
> into configure, I could solve this. But I have yet to solve further
> problems. Often the configure-script tries to compile and run short
> test-programs in order to find something out. This of course always
> fails if you try to cross-compile. Than I have first to see what
> information the configure script tried to aquire and how I can provide
> this information manually. No, I don't like this.
>
> So from this experiences, I would greatly prefer a manually written,
> clean makefile together with some pre-written config.h where the
> system-dependent definitions are visible. Btw I don't think, a manually
> written script configuration script would be better, I think it could be
> even worse.
>
> Regards
> Dirk


Excellent explanation. That's exactly what happens to me, and i'm guessing many others. Sometimes it takes hours to fix the ./configure stage. In which time a custom makefile can be written if someone has some understanding.
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      01-11-2012
On 01/11/2012 06:10 AM, ec429 wrote:
,,,
> What, exactly, don't you like about gdb? Does it not hold your hand
> enough, poor ickle child? Are there not enough pictures to engage your
> attention?



The main things I don't like about gdb might actually be features of
gcc. The only thing I can say for certain is that the two tools don't
communicate with each other properly Even when I compile with
optimization turned (supposedly) completely off, I often face the
problems like the following:

* A variable, whose value I want to check, has been optimized out of
existence.

* I will advance though the program one step at a time. gdb will display
line 34, line 35, line 34, line 35, line 34, etc, which would be fine if
they were parts of loop, but is very disconcerting when one of those
lines is a comment and the other is a declaration. Eventually it stops
cycling between those line numbers, and jumps to line 39, and by
examination of the values of various variables, I conclude that what
it's actually been doing was executing the loop on lines 36 and 37.

* I will single-step through a line of code that supposedly changes the
value of a variable, examining the value of that variable before and
after execution of the statement, and see the value unchanged. It
eventually gets changed, but during what is supposed to be the execution
of some other line of code much farther down in the code.

I can't be sure whether these problems are the fault of gdb or gcc.
However, I only ran into similar problems using the IRIX MIPS-Pro
compiler and dbx if I chose optimization levels higher than the lowest
possible one. That is why I usually debug with all optimizations turned
off - unless turning optimization off makes the bug disappear.

I have other problems with gdb as well, but they're just due to lack of
experience with the program, I presume. I've been using dbx for more
than two decades, possibly three.
 
Reply With Quote
 
ec429
Guest
Posts: n/a
 
      01-11-2012
On 11/01/12 16:52, James Kuyper wrote:
> * A variable, whose value I want to check, has been optimized out of
> existence.

If that's happening with optimisation turned off, it's probably a bug,
which you should probably report.
> * I will advance though the program one step at a time. gdb will display
> line 34, line 35, line 34, line 35, line 34, etc, which would be fine if
> they were parts of loop, but is very disconcerting when one of those
> lines is a comment and the other is a declaration. Eventually it stops
> cycling between those line numbers, and jumps to line 39, and by
> examination of the values of various variables, I conclude that what
> it's actually been doing was executing the loop on lines 36 and 37.

That sounds strongly like your source file is more recent than
executable. gdb doesn't like it when the sources you have don't match
the binary you're debugging.
> * I will single-step through a line of code that supposedly changes the
> value of a variable, examining the value of that variable before and
> after execution of the statement, and see the value unchanged. It
> eventually gets changed, but during what is supposed to be the execution
> of some other line of code much farther down in the code.

Same as above, source/binary mismatch.

-e
--
'sane', adj.: see 'unimaginative'
on the web - http://jttlov.no-ip.org
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      01-11-2012
On 01/11/2012 12:01 PM, ec429 wrote:
> On 11/01/12 16:52, James Kuyper wrote:
>> * A variable, whose value I want to check, has been optimized out of
>> existence.

> If that's happening with optimisation turned off, it's probably a bug,
> which you should probably report.


I hadn't thought about that - I'll try to remember to do so the next
time it happens.

>> * I will advance though the program one step at a time. gdb will display
>> line 34, line 35, line 34, line 35, line 34, etc, which would be fine if
>> they were parts of loop, but is very disconcerting when one of those
>> lines is a comment and the other is a declaration. Eventually it stops
>> cycling between those line numbers, and jumps to line 39, and by
>> examination of the values of various variables, I conclude that what
>> it's actually been doing was executing the loop on lines 36 and 37.

> That sounds strongly like your source file is more recent than
> executable. gdb doesn't like it when the sources you have don't match
> the binary you're debugging.
>> * I will single-step through a line of code that supposedly changes the
>> value of a variable, examining the value of that variable before and
>> after execution of the statement, and see the value unchanged. It
>> eventually gets changed, but during what is supposed to be the execution
>> of some other line of code much farther down in the code.

> Same as above, source/binary mismatch.


I agree, that is the most reasonable conclusion. That is why my first
step was to erase all object, library, and executable files created by
my build process, and rebuild from scratch. I continued to observe the
same behavior. This has happened in many different contexts.

I'm pretty good at writing platform-agnostic code; even my bugs are
usually platform-agnostic, so testing on our Irix machines generally was
just as good as testing on our Linux ones. Since we shut down our Irix
machines I've frequently had to fall back on debugging printf()s in
order to get sensible (i.e. corrected to make it appear as if no
optimizations were occurring) dumps of the program state.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Writing portable code... jacob navia C Programming 7 09-03-2007 10:29 PM
Portable Python - free portable development environment ! perica.zivkovic@gmail.com Python 7 01-13-2007 11:19 AM
Writing portable code in Visual Studio C++ Richard Giuly C++ 5 07-31-2006 03:49 PM
portable (VHDL) vs. non-portable (altera LPM) approaches to signed computations Eli Bendersky VHDL 1 03-01-2006 02:43 PM
Writing portable software Jason Curl C Programming 10 03-15-2005 10:29 PM



Advertisments