Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #15611 > unrolled thread

Writing "absolutely" portable code

Back to article view | Back to comp.lang.c

Contents

  Writing "absolutely" portable code ArifulHossain tuhin <etothepowerpi@gmail.com> - 2012-01-09 02:26 -0800
    Re: Writing "absolutely" portable code ec429 <ec429@cam.ac.uk> - 2012-01-09 11:47 +0000
      Re: Writing "absolutely" portable code Jens Gustedt <jens.gustedt@loria.fr> - 2012-01-09 13:56 +0100
      Re: Writing "absolutely" portable code ArifulHossain tuhin <etothepowerpi@gmail.com> - 2012-01-09 05:45 -0800
        Re: Writing "absolutely" portable code ec429 <ec429@cam.ac.uk> - 2012-01-09 14:46 +0000
          Re: Writing "absolutely" portable code ArifulHossain tuhin <etothepowerpi@gmail.com> - 2012-01-10 01:11 -0800
      Re: Writing "absolutely" portable code Rui Maciel <rui.maciel@gmail.com> - 2012-01-09 15:58 +0000
      Re: Writing "absolutely" portable code falk@rahul.net (Edward A. Falk) - 2012-01-09 18:41 +0000
    Re: Writing "absolutely" portable code Rui Maciel <rui.maciel@gmail.com> - 2012-01-09 12:23 +0000
      Re: Writing "absolutely" portable code Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-01-09 08:45 -0500
        Re: Writing "absolutely" portable code superpollo <superpollo@tznvy.pbz> - 2012-01-09 15:02 +0100
          Re: Writing "absolutely" portable code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-09 16:11 +0000
      Re: Writing "absolutely" portable code ArifulHossain tuhin <etothepowerpi@gmail.com> - 2012-01-09 05:56 -0800
        Re: Writing "absolutely" portable code Rui Maciel <rui.maciel@gmail.com> - 2012-01-09 15:07 +0000
          Re: Writing "absolutely" portable code ArifulHossain tuhin <etothepowerpi@gmail.com> - 2012-01-10 01:21 -0800
            Re: Writing "absolutely" portable code Stephen Sprunk <stephen@sprunk.org> - 2012-01-10 13:20 -0600
              Re: Writing "absolutely" portable code ArifulHossain tuhin <etothepowerpi@gmail.com> - 2012-01-11 06:57 -0800
            Re: Writing "absolutely" portable code Rui Maciel <rui.maciel@gmail.com> - 2012-01-11 09:23 +0000
    Re: Writing "absolutely" portable code jacob navia <jacob@spamsink.net> - 2012-01-09 13:48 +0100
      Re: Writing "absolutely" portable code ec429 <ec429@cam.ac.uk> - 2012-01-09 13:11 +0000
        Re: Writing "absolutely" portable code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-09 05:27 -0800
          Re: Writing "absolutely" portable code ec429 <ec429@cam.ac.uk> - 2012-01-09 13:41 +0000
            Re: Writing "absolutely" portable code ArifulHossain tuhin <etothepowerpi@gmail.com> - 2012-01-09 06:09 -0800
        Re: Writing "absolutely" portable code jacob navia <jacob@spamsink.net> - 2012-01-09 14:35 +0100
          Re: Writing "absolutely" portable code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-09 13:44 +0000
            Re: Writing "absolutely" portable code ArifulHossain tuhin <etothepowerpi@gmail.com> - 2012-01-09 06:18 -0800
            Re: Writing "absolutely" portable code jacob navia <jacob@spamsink.net> - 2012-01-09 18:59 +0100
            Re: Writing "absolutely" portable code jacob navia <jacob@spamsink.net> - 2012-01-09 19:01 +0100
              Re: Writing "absolutely" portable code ec429 <ec429@cam.ac.uk> - 2012-01-09 19:21 +0000
                Re: Writing "absolutely" portable code Richard <rgrdev_@gmail.com> - 2012-01-10 20:48 +0100
                  Re: Writing "absolutely" portable code David Dyer-Bennet <dd-b@dd-b.net> - 2012-01-10 14:26 -0600
                    Re: Writing "absolutely" portable code Richard <rgrdev_@gmail.com> - 2012-01-10 21:44 +0100
                      Re: Writing "absolutely" portable code David Dyer-Bennet <dd-b@dd-b.net> - 2012-01-10 15:45 -0600
                  Re: Writing "absolutely" portable code Rui Maciel <rui.maciel@gmail.com> - 2012-01-11 09:12 +0000
                  Re: Writing "absolutely" portable code ec429 <ec429@cam.ac.uk> - 2012-01-11 11:10 +0000
                    Re: Writing "absolutely" portable code James Kuyper <jameskuyper@verizon.net> - 2012-01-11 11:52 -0500
                      Re: Writing "absolutely" portable code ec429 <ec429@cam.ac.uk> - 2012-01-11 17:01 +0000
                        Re: Writing "absolutely" portable code James Kuyper <jameskuyper@verizon.net> - 2012-01-11 12:11 -0500
                Re: Writing "absolutely" portable code Rui Maciel <rui.maciel@gmail.com> - 2012-01-11 09:08 +0000
              Re: Writing "absolutely" portable code Rui Maciel <rui.maciel@gmail.com> - 2012-01-11 08:22 +0000
              Re: Writing "absolutely" portable code Rui Maciel <rui.maciel@gmail.com> - 2012-01-11 08:54 +0000
          Re: Writing "absolutely" portable code ec429 <ec429@cam.ac.uk> - 2012-01-09 13:57 +0000
            Re: Writing "absolutely" portable code Seebs <usenet-nospam@seebs.net> - 2012-01-09 19:21 +0000
              Re: Writing "absolutely" portable code ec429 <ec429@cam.ac.uk> - 2012-01-09 19:52 +0000
                Re: Writing "absolutely" portable code Seebs <usenet-nospam@seebs.net> - 2012-01-09 20:20 +0000
          Re: Writing "absolutely" portable code ArifulHossain tuhin <etothepowerpi@gmail.com> - 2012-01-09 06:16 -0800
      Re: Writing "absolutely" portable code ArifulHossain tuhin <etothepowerpi@gmail.com> - 2012-01-09 06:02 -0800
    Re: Writing "absolutely" portable code Keith Thompson <kst-u@mib.org> - 2012-01-09 14:50 -0800
      Re: Writing "absolutely" portable code Kaz Kylheku <kaz@kylheku.com> - 2012-01-09 23:20 +0000
        Re: Writing "absolutely" portable code Rui Maciel <rui.maciel@gmail.com> - 2012-01-10 00:23 +0000
      Re: Writing "absolutely" portable code Dirk Zabel <zabel@riccius-sohn.eu> - 2012-01-10 17:44 +0100
        Re: Writing "absolutely" portable code ArifulHossain tuhin <etothepowerpi@gmail.com> - 2012-01-11 07:13 -0800
        Re: Writing "absolutely" portable code Nick Bowler <nbowler@draconx.ca> - 2012-01-17 20:36 +0000
          Re: Writing "absolutely" portable code ec429 <ec429@cam.ac.uk> - 2012-01-17 23:06 +0000
            Re: Writing "absolutely" portable code blp@cs.stanford.edu (Ben Pfaff) - 2012-01-17 15:32 -0800
              Re: Writing "absolutely" portable code Kaz Kylheku <kaz@kylheku.com> - 2012-01-18 00:40 +0000
                Re: Writing "absolutely" portable code Seebs <usenet-nospam@seebs.net> - 2012-01-18 18:35 +0000
                  Re: Writing "absolutely" portable code Kaz Kylheku <kaz@kylheku.com> - 2012-01-18 19:15 +0000
                    Re: Writing "absolutely" portable code Seebs <usenet-nospam@seebs.net> - 2012-01-21 21:32 +0000
              Re: Writing "absolutely" portable code "io_x" <a@b.c.invalid> - 2012-01-18 07:26 +0100
                Re: Writing "absolutely" portable code "Joachim Schmitz" <nospam.jojo@schmitz-digital.de> - 2012-01-18 11:07 +0100
                  Re: Writing "absolutely" portable code Seebs <usenet-nospam@seebs.net> - 2012-01-21 21:32 +0000
                    Re: Writing "absolutely" portable code Ian Collins <ian-news@hotmail.com> - 2012-01-22 10:42 +1300
                    Re: Writing "absolutely" portable code "io_x" <a@b.c.invalid> - 2012-01-22 18:53 +0100
                      Re: Writing "absolutely" portable code "io_x" <a@b.c.invalid> - 2012-01-22 19:00 +0100
                        Re: Writing "absolutely" portable code "io_x" <a@b.c.invalid> - 2012-01-23 19:28 +0100
                Re: Writing "absolutely" portable code Stephen Sprunk <stephen@sprunk.org> - 2012-01-18 08:44 -0600
                Re: Writing "absolutely" portable code James Dow Allen <jdallen2000@yahoo.com> - 2012-01-18 07:09 -0800
                  Re: Writing "absolutely" portable code "io_x" <a@b.c.invalid> - 2012-01-18 17:44 +0100
          Re: Writing "absolutely" portable code Seebs <usenet-nospam@seebs.net> - 2012-01-18 07:58 +0000

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#15621

On Jan 9, 1:11 pm, ec429 <ec...@cam.ac.uk> wrote:

> Then again, if iPhone is as painfully locked down as jacob suggests, it
> might be better to just not support it - a platform that closed is not
> going to thrive anyway.

hence Apples current poor performance...

[toc] | [prev] | [next] | [standalone]

#15623

On 09/01/12 13:27, Nick Keighley wrote:
> On Jan 9, 1:11 pm, ec429<ec...@cam.ac.uk>  wrote:
>
>> Then again, if iPhone is as painfully locked down as jacob suggests, it
>> might be better to just not support it - a platform that closed is not
>> going to thrive anyway.
>
> hence Apples current poor performance...
I'm not sure if this is sarcasm or not, but on the off-chance that it 
is, /me points at esr.ibiblio.org
And yes, I am a terrible ESR fanboi.
-e
-- 
'sane', adj.: see 'unimaginative'
   on the web - http://jttlov.no-ip.org

[toc] | [prev] | [next] | [standalone]

#15637

On Monday, January 9, 2012 7:41:39 PM UTC+6, ec429 wrote:
> On 09/01/12 13:27, Nick Keighley wrote:
> > On Jan 9, 1:11 pm, ec429<ec...@cam.ac.uk>  wrote:
> >
> >> Then again, if iPhone is as painfully locked down as jacob suggests, it
> >> might be better to just not support it - a platform that closed is not
> >> going to thrive anyway.
> >
> > hence Apples current poor performance...
> I'm not sure if this is sarcasm or not, but on the off-chance that it 
> is, /me points at esr.ibiblio.org
> And yes, I am a terrible ESR fanboi.
I like him a lot. But i feel sometimes he goes kind of "overboard".
> -e
> -- 
> 'sane', adj.: see 'unimaginative'
>    on the web - http://jttlov.no-ip.org

[toc] | [prev] | [next] | [standalone]

#15622

Le 09/01/12 14:11, ec429 a écrit :
> OTOH note that the OP said he was developing a library, so probably
> isn't going to be writing any UI code anyway. The networking part is
> going to have some "and the rest" in it, but if you have BSD sockets
> then you're fine.
> Then again, if iPhone is as painfully locked down as jacob suggests, it
> might be better to just not support it - a platform that closed is not
> going to thrive anyway.
> -e

It is not as bad as it looks.

If you have no interaction with the iphone UI, you do not need Objective 
C, and you can compile from the command line using
a normal makefile. The problem is that you will need to debug
your code and THAT needs XCode and the iphone connection.

I have ported and worked in a QT port to the iphone, and I
worked exclusively with the make environment of QT and their
source code using the command line in my Mac.

Since I was producing a library, I just included the library
into the user interface of my app. The library could be
debugged using the XCode debugger (that is actually just
a hacked version of gdb by Apple).

Having a Mac is not that of a big deal: a "mini" mac starts at around
600 euros in the apple store, not a big deal. And, I am very happy with
it:

I have come to the best Unix that I know of: nice, good looking,
easy to use, everything works, powerful, etc :-) It is a
nice change after all those years under windows.

This closed environment is a god thing in many ways since there are less
security problems: virus writers have MORE problems than with the
android platform that is so open that viruses are present in many
applications in their store.

Anyway all I say here is my personal opinion of course, and I like
Apple, be warned.

jacob

[toc] | [prev] | [next] | [standalone]

#15624

jacob navia <jacob@spamsink.net> writes:

> Le 09/01/12 14:11, ec429 a écrit :
>> Then again, if iPhone is as painfully locked down as jacob suggests, it
>> might be better to just not support it
<snip>
> This closed environment is a god thing

Some typos just get to the heart of the matter in a way that no other
writing can.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#15633

On Monday, January 9, 2012 7:44:21 PM UTC+6, Ben Bacarisse wrote:
> jacob navia <ja...@spamsink.net> writes:
> 
> > Le 09/01/12 14:11, ec429 a écrit :
> >> Then again, if iPhone is as painfully locked down as jacob suggests, it
> >> might be better to just not support it
> <snip>
> > This closed environment is a god thing
> 
> Some typos just get to the heart of the matter in a way that no other
> writing can.

I scared a intern in my office by laughing so loudly. Very "witty" stuff dude.
> 
> -- 
> Ben.

[toc] | [prev] | [next] | [standalone]

#15648

Le 09/01/12 14:44, Ben Bacarisse a écrit :
> jacob navia<jacob@spamsink.net>  writes:
>
>> Le 09/01/12 14:11, ec429 a écrit :
>>> Then again, if iPhone is as painfully locked down as jacob suggests, it
>>> might be better to just not support it
> <snip>
>> This closed environment is a god thing
>
> Some typos just get to the heart of the matter in a way that no other
> writing can.
>

Look Ben, I am agnostic ok? :-)

But Apple's machines are *nice* to use. I would love that linux
machines were like that but no, they are never like that.

For instance,

$ man gcc

works, you do NOT get a warning telling you that GNU doesn't like man 
pages. The documentation is entirely rewritten.

And then ALL the details: makefiles do not require tabs and will accept
tabs or spaces... and you know what impressed me the most?

$ cat foo.c
#include <math.h>
#include <stdio.h>

int main(int argc,char *argv[]) { printf("%g\n",sin(argc)); }

$ gcc foo.c
$ ./a.out 1
0.909297
$

NO NEED FOR -lm!!!!!!! The libraries are included BY DEFAULT!!!!!!!!

How many times we have discussed that here?
And I was told by the linux people that "THAT IS THE WAY IT IS..."

Apple did it.

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 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.

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

[toc] | [prev] | [next] | [standalone]

#15649

Le 09/01/12 14:44, Ben Bacarisse a écrit :
> jacob navia<jacob@spamsink.net>  writes:
>
>> Le 09/01/12 14:11, ec429 a écrit :
>>> Then again, if iPhone is as painfully locked down as jacob suggests, it
>>> might be better to just not support it
> <snip>
>> This closed environment is a god thing
>
> Some typos just get to the heart of the matter in a way that no other
> writing can.
>

Look Ben, I am agnostic ok? :-)

But Apple's machines are *nice* to use. I would love that linux
machines were like that but no, they are never like that.

For instance,

$ man gcc

works, you do NOT get a warning telling you that GNU doesn't like man 
pages. The documentation is entirely rewritten.

And then ALL the details: makefiles do not require tabs and will accept
tabs or spaces... and you know what impressed me the most?

$ cat foo.c
#include <math.h>
#include <stdio.h>

int main(int argc,char *argv[]) { printf("%g\n",sin(argc)); }

$ gcc foo.c
$ ./a.out 1
0.909297
$

NO NEED FOR -lm!!!!!!! The libraries are included BY DEFAULT!!!!!!!!

How many times we have discussed that here?
And I was told by the linux people that "THAT IS THE WAY IT IS..."

Apple did it.

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 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.

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

[toc] | [prev] | [next] | [standalone]

#15653

On 09/01/12 18:01, jacob navia wrote:
> And then ALL the details: makefiles do not require tabs and will accept
> tabs or spaces...
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.

> 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 pisses off library developers when it links against the 
old version instead of the new one they've just built.

> 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.
Linux and GNU follow (largely) the POSIX standards.  Standards are a 
_good 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 (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.

> 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.
GNU did make a "better Unix".  Have you read The Unix Haters' Handbook? 
  1980s-vintage Unix had some serious issues, most the result of 
vendors' attempts at product differentiation for competitive advantage. 
  Maintaining source-level compatibility with the post-divestiture 
clusterf**k guaranteed that compromises would have to be made.  As older 
software has been replaced with newer, portable code, GNU and Linux have 
evolved to discard as much of that baggage as they dare.
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.
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 - 
that's all the environment you need, and 'integration' is pointless when 
everything is a stream of text (a powerful abstraction that Macs, with 
their "resource fork", break).

> They never think about the USER EXPERIENCE when designing their programs
> (just look at gdb), something Apple has always had in mind.
Looking at gdb, my impression is that its UX is actually very good. 
It's exactly the right way to build a debugger - its interface is 
essentially a scripting language with a REPL, allowing you to control 
your program and query its state in as natural a way as is possible for 
compiled programs.  Compare, incidentally, the debugging cycles of 
interpreted languages: for instance, the Python debugger is the Python 
interpreter; most JS debuggers are JS interpreters.

Summary: Steve Jobs is not, in fact, god.  He was just a competent marketer.

-e
-- 
'sane', adj.: see 'unimaginative'
   on the web - http://jttlov.no-ip.org

[toc] | [prev] | [next] | [standalone]

#15698

ec429 <ec429@cam.ac.uk> writes:

> On 09/01/12 18:01, jacob navia wrote:
>> And then ALL the details: makefiles do not require tabs and will accept
>> tabs or spaces...
> 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.

>
>> 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 pisses 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.

>
>> 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.
> Linux and GNU follow (largely) the POSIX standards.  Standards are a
> _good

Rubbish.

> 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.

> (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 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.
> GNU did make a "better Unix".  Have you read The Unix Haters' Handbook?
> 1980s-vintage Unix had some serious issues, most the result of vendors' attempts
> at product differentiation for competitive advantage. Maintaining source-level
> compatibility with the post-divestiture clusterf**k guaranteed that compromises
> would have to be made.  As older software has been replaced with newer, portable
> code, GNU and Linux have evolved to discard as much of that baggage as they
> dare.
> 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?

> Xfce, LXDE, fvwm2 and several others are clean, unobtrusive, and
> lightweight.

Ugly and horrible too.

> 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.

[toc] | [prev] | [next] | [standalone]

#15700

Richard <rgrdev_@gmail.com> writes:

> 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.

In theory, an IDE could be a good thing -- though it tends to lock  you
into a set of tools rather than letting you choose individually, which
is a big problem.  

I've never actually used one that was better than the non-IDE
environments I've programmed in, though.  Visual Studio in particular is
a total disaster, especially for C and C++ code.  We get random build
failures, crashes, it fails to find things it should find, Tool Tips
don't work, it misses breakpoints, and so forth -- and not just for me
(the non-Windows guy); the experts have the same problems and can't tell
me how to get around them.

I've worked on some fairly big projects, including a 5-million-line
thing while I was at Sun (it used Linux and GCC, in fact it had a custom
Linux distribution rolled into it).  
-- 
David Dyer-Bennet, dd-b@dd-b.net; http://dd-b.net/
Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/
Photos: http://dd-b.net/photography/gallery/
Dragaera: http://dragaera.info

[toc] | [prev] | [next] | [standalone]

#15702

David Dyer-Bennet <dd-b@dd-b.net> writes:

> Richard <rgrdev_@gmail.com> writes:
>
>> 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.
>
> In theory, an IDE could be a good thing -- though it tends to lock  you
> into a set of tools rather than letting you choose individually, which
> is a big problem.  

Not if it can be configured to use external tools.
>
> I've never actually used one that was better than the non-IDE
> environments I've programmed in, though.  Visual Studio in particular is
> a total disaster, especially for C and C++ code.  We get random build

I think thats down to your set up. VS can be intrusive but millions use
it daily with a lot of success.

And jut look at Apple and their IDE and the satisfaction ratings.

I am NOT saying discrete tools are a bad thing but bringing them all
together in an INTEGRATED UI can be a good thing.

I use emacs as and IDE and its benefits outweigh the disadvantages : but
I dont try to convince myself its good at debugging, completion, context
help etc, Its not. 

[toc] | [prev] | [next] | [standalone]

#15706

Richard <rgrdev_@gmail.com> writes:

> David Dyer-Bennet <dd-b@dd-b.net> writes:
>
>> Richard <rgrdev_@gmail.com> writes:
>>
>>> 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.
>>
>> In theory, an IDE could be a good thing -- though it tends to lock  you
>> into a set of tools rather than letting you choose individually, which
>> is a big problem.  
>
> Not if it can be configured to use external tools.

Yes.  In theory, it could be a good thing.  But I've never actually
encountered one that actualized that possibility.

>> I've never actually used one that was better than the non-IDE
>> environments I've programmed in, though.  Visual Studio in particular is
>> a total disaster, especially for C and C++ code.  We get random build
>
> I think thats down to your set up. VS can be intrusive but millions use
> it daily with a lot of success.

Nearly always for very small projects. 

> And jut look at Apple and their IDE and the satisfaction ratings.

Never seen it, I've heard serious complaints about the lack of
alternatives. 

> I am NOT saying discrete tools are a bad thing but bringing them all
> together in an INTEGRATED UI can be a good thing.
>
> I use emacs as and IDE and its benefits outweigh the disadvantages : but
> I dont try to convince myself its good at debugging, completion, context
> help etc, Its not. 

The editor is the most important tool, so that's where I live, yes.  But
the gdb integration IS pretty useful in my experience.  Doesn't do class
browsing, that's the bit that looked hopeful in VS -- but it doesn't
deliver, it just doesn't work in C++.  (Works pretty well for C#
though.) 
-- 
David Dyer-Bennet, dd-b@dd-b.net; http://dd-b.net/
Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/
Photos: http://dd-b.net/photography/gallery/
Dragaera: http://dragaera.info

[toc] | [prev] | [next] | [standalone]

#15735

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

[toc] | [prev] | [next] | [standalone]

#15742

On 10/01/12 19:48, Richard wrote:
> ec429<ec429@cam.ac.uk>  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 pisses 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 :grin:), 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

[toc] | [prev] | [next] | [standalone]

#15755

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.

[toc] | [prev] | [next] | [standalone]

#15756

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

[toc] | [prev] | [next] | [standalone]

#15757

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.

[toc] | [prev] | [next] | [standalone]

#15733

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

[toc] | [prev] | [next] | [standalone]

#15731

jacob navia wrote:

> and you know what impressed me the most?
> 
> $ cat foo.c
> #include <math.h>
> #include <stdio.h>
> 
> int main(int argc,char *argv[]) { printf("%g\n",sin(argc)); }
> 
> $ gcc foo.c
> $ ./a.out 1
> 0.909297
> $
> 
> NO NEED FOR -lm!!!!!!! The libraries are included BY DEFAULT!!!!!!!!
> 
> How many times we have discussed that here?
> And I was told by the linux people that "THAT IS THE WAY IT IS..."

I've tested your example in Kubuntu 11.10, with GCC 4.6.1.

<test>
rui@Kubuntu:tmp$ cat main.c 
#include <math.h>
#include <stdio.h>

int main(int argc,char *argv[]) { printf("%g\n",sin(argc)); }
rui@Kubuntu:tmp$ gcc main.c
/tmp/ccpoalMn.o: In function `main':
main.c:(.text+0x15): undefined reference to `sin'
collect2: ld returned 1 exit status
rui@Kubuntu:tmp$ gcc main.c -lm
rui@Kubuntu:tmp$ 
</test>


Rui Maciel

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | comp.lang.c

csiph-web