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

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

C newb - third party libs and using and testing suite

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

Contents

  C newb - third party libs and using and testing suite S390 <s390@tampascanner.info> - 2016-11-27 01:05 +0000
    Re: C newb - third party libs and using and testing suite Richard Heathfield <rjh@cpax.org.uk> - 2016-11-27 01:41 +0000
      Re: C newb - third party libs and using and testing suite Richard Heathfield <rjh@cpax.org.uk> - 2016-11-27 13:21 +0000
        Re: C newb - third party libs and using and testing suite S390 <s390@tampascanner.info> - 2016-11-28 03:35 +0000
          Re: C newb - third party libs and using and testing suite Richard Heathfield <rjh@cpax.org.uk> - 2016-11-28 10:19 +0000
            Re: C newb - third party libs and using and testing suite S390 <s390@tampascanner.info> - 2016-12-02 19:25 +0000
              Re: C newb - third party libs and using and testing suite "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-02 14:44 -0500
              Re: C newb - third party libs and using and testing suite BartC <bc@freeuk.com> - 2016-12-02 19:49 +0000
                Re: C newb - third party libs and using and testing suite S390 <s390@tampascanner.info> - 2016-12-04 13:27 +0000
            Re: C newb - third party libs and using and testing suite S390 <s390@tampascanner.info> - 2016-12-02 20:35 +0000
          Re: C newb - third party libs and using and testing suite James Kuyper <jameskuyper@verizon.net> - 2016-11-28 09:27 -0500
            Re: C newb - third party libs and using and testing suite S390 <s390@tampascanner.info> - 2016-12-02 20:43 +0000
              Re: C newb - third party libs and using and testing suite "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-02 16:35 -0500
                Re: C newb - third party libs and using and testing suite S390 <s390@tampascanner.info> - 2016-12-05 14:50 +0000
                  Re: C newb - third party libs and using and testing suite James Kuyper <jameskuyper@verizon.net> - 2016-12-05 23:48 -0500
                    Re: C newb - third party libs and using and testing suite S390 <s390@tampascanner.info> - 2016-12-09 22:12 +0000
                      Re: C newb - third party libs and using and testing suite "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-09 18:38 -0500
                        Re: C newb - third party libs and using and testing suite Keith Thompson <kst-u@mib.org> - 2016-12-09 16:34 -0800
                      Re: C newb - third party libs and using and testing suite Keith Thompson <kst-u@mib.org> - 2016-12-09 15:54 -0800
                        Re: C newb - third party libs and using and testing suite BartC <bc@freeuk.com> - 2016-12-10 00:09 +0000
                          Re: C newb - third party libs and using and testing suite jameskuyper@verizon.net - 2016-12-09 16:37 -0800
                            Re: C newb - third party libs and using and testing suite BartC <bc@freeuk.com> - 2016-12-10 01:09 +0000
                              Re: C newb - third party libs and using and testing suite jameskuyper@verizon.net - 2016-12-09 17:32 -0800
                              Re: C newb - third party libs and using and testing suite Keith Thompson <kst-u@mib.org> - 2016-12-09 17:36 -0800
    Re: C newb - third party libs and using and testing suite "James R. Kuyper" <jameskuyper@verizon.net> - 2016-11-26 21:14 -0500
      Re: C newb - third party libs and using and testing suite Richard Heathfield <rjh@cpax.org.uk> - 2016-11-27 09:21 +0000
        Re: C newb - third party libs and using and testing suite "James R. Kuyper" <jameskuyper@verizon.net> - 2016-11-27 10:36 -0500
    Re: Part II - C newb - third party libs and using and testing suite S390 <s390@tampascanner.info> - 2016-12-02 21:20 +0000
      Re: Part II - C newb - third party libs and using and testing suite "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-02 16:55 -0500
        Re: Part II - C newb - third party libs and using and testing suite Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-02 17:14 -0800
          Re: Part II - C newb - third party libs and using and testing suite BartC <bc@freeuk.com> - 2016-12-03 13:39 +0000
        Re: Part II - C newb - third party libs and using and testing suite BartC <bc@freeuk.com> - 2016-12-03 02:11 +0000

Page 2 of 2 — ← Prev page 1 [2]

#98635

On Friday, December 9, 2016 at 7:09:25 PM UTC-5, Bart wrote:
> On 09/12/2016 23:54, Keith Thompson wrote:
> > S390 <s390@tampascanner.info> writes:
> 
> >> looks for /lib/<string>.a I get from that thing I was reading it needs
> >> appends .a, but where is this prepending of "lib" coming from????
> >
> > It's documented in the GNU ld manual, among other places (ld is part of
> > the "binutils" package).  If you're using a linker other than the GNU
> > binutils version, it should be documented in that linker's manual.
> >
> > Quoting https://sourceware.org/binutils/docs-2.27/ld/Options.html :
> >
> >     -l namespec
> >     --library=namespec
> >
> >         Add the archive or object file specified by namespec to the
> >         list of files to link. This option may be used any number of
> >         times. If namespec is of the form :filename, ld will search
> >         the library path for a file called filename, otherwise it
> >         will search the library path for a file called libnamespec.a.
> >
> >         On systems which support shared libraries, ld may also
> >         search for files other than libnamespec.a. Specifically,
> >         on ELF and SunOS systems, ld will search a directory for a
> >         library called libnamespec.so before searching for one called
> >         libnamespec.a. (By convention, a .so extension indicates a
> >         shared library.) Note that this behavior does not apply to
> >         :filename, which always specifies a file called filename.
> >
> > Note that if you want to specify an exact file name, you can do so.
> 
> With -L, I've never managed to make it work when there's a problem 
> finding object files. I've just tested it, put one of two .obj files I 
> need in library C:\X, specified both .obj files with no path but 
> followed or preceded by -LC:\X\ (-LC:/X/ or -LC:/x etc), and it can't 
> find the file that is in X.

How is your test relevant to the behavior of the -L option? That option controls where it looks for library files, not object files.

Windows may work differently, for all I know, but on unix-like systems there would be no need to use -L/C/x/,  It would be sufficient to use -L/C/x. Using an extra '/' at the end is permitted, but often causes messages that refer to /C/x//something, rather than /C/x/something.

> So I always specify a full path on each file to avoid problems.
> 
> (I've no idea how -l workd except that on Linux I sometimes have to use 
> -lm and -ldl to link my programs.)

It's been a long time since I've built code on anything other than a unix-like system, so I wouldn't be surprised if some of the following statements are unix-specific. However, I seem to remember that there's a lot of similarity between windows and unix compiler options of this kind (other options can be VERY different).

-L and -l work together. There's a default ordered set of locations that your
compiler searches for any needed library files. It searches that set in that
order, stopping as soon as it finds a library file with a matching name. Each
-L option adds the specified directory to the end of the search list, but only
for searches that occur after the -L option in the command line.
On unix-like systems, -lname specifies that the library file you want it to
find is named libname.a. I wouldn't be surprised if it implements a different
naming convention on Windows machines. However, whatever naming convention
applies, it starts looking for a file with the specified name somewhere in the
directories that make the up the library search path list, in the specified\order.

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

#98641

On 10/12/2016 00:37, jameskuyper@verizon.net wrote:
> On Friday, December 9, 2016 at 7:09:25 PM UTC-5, Bart wrote:

>> With -L, I've never managed to make it work when there's a problem
>> finding object files. I've just tested it, put one of two .obj files I
>> need in library C:\X, specified both .obj files with no path but
>> followed or preceded by -LC:\X\ (-LC:/X/ or -LC:/x etc), and it can't
>> find the file that is in X.
>
> How is your test relevant to the behavior of the -L option? That option controls where it looks for library files, not object files.

That might explain it then! (Although I may well have had problems with 
it finding .a files too.)

I'll have to bail out here but I'm not completely sure what .a files 
are; I've certainly never created them.

(These days I use .so or .dll files as their format is not tied to a 
compiler and the content can be accessed from any language. Although it 
it was necessary, I might be able to turn a .a file into .so/.dll.)

-- 
Bartc

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

#98642

On Friday, December 9, 2016 at 8:09:45 PM UTC-5, Bart wrote:
...
> I'll have to bail out here but I'm not completely sure what .a files 
> are; I've certainly never created them.
> 
> (These days I use .so or .dll files as their format is not tied to a 
> compiler and the content can be accessed from any language. Although it 
> it was necessary, I might be able to turn a .a file into .so/.dll.)

The 'a' in the file extension indicates that *.a files are archives which
contain a bunch of object files in a format that the linker knows about, so it
can extract them from those archives. .so files are also used on unix-like
systems, and I'd expect them to be similar in purpose (if not in format) to the
Windows ones you're more familiar with.

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

#98643

BartC <bc@freeuk.com> writes:
> On 10/12/2016 00:37, jameskuyper@verizon.net wrote:
>> On Friday, December 9, 2016 at 7:09:25 PM UTC-5, Bart wrote:
>
>>> With -L, I've never managed to make it work when there's a problem
>>> finding object files. I've just tested it, put one of two .obj files I
>>> need in library C:\X, specified both .obj files with no path but
>>> followed or preceded by -LC:\X\ (-LC:/X/ or -LC:/x etc), and it can't
>>> find the file that is in X.
>>
>> How is your test relevant to the behavior of the -L option? That
>> option controls where it looks for library files, not object files.
>
> That might explain it then! (Although I may well have had problems with 
> it finding .a files too.)
>
> I'll have to bail out here but I'm not completely sure what .a files 
> are; I've certainly never created them.
>
> (These days I use .so or .dll files as their format is not tied to a 
> compiler and the content can be accessed from any language. Although it 
> it was necessary, I might be able to turn a .a file into .so/.dll.)

That shouldn't be necessary.

A ".a" file is an archive file, a fairly simple container for a
collection of object (".o") files.  They're used for static linking.

A ".so" file is a dynamic library.

At least for GNU binutils ld, if you specify "-lfoo", it will search
for either "libfoo.a" or "libfoo.so".  I think the latter normally
takes precedence.  If it finds "libfoo.so", it will generate
instructions that will cause it to be loaded when you execute
the program (there can also be an appended version number); the
"ldd" command shows you what dynamic libraries a given executable
depends on.  If it finds "libfoo.a", it will link any needed code
from the archive directly into the generated executable.

And, as explained, above, "-L" takes a directory argument and appends
that directory name to the search path used by "-l".

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#97553

On 11/26/2016 08:05 PM, S390 wrote:
>
> I am not a C person for normal things... tweak and edit or fix a few
> things, etc. to C programs... but I've come up against a program which
> needs more than my normal tweaking...
>
> For most of what I do I take little things and build them to little
> blocks and then combine all the blocks after having rigorously tested
> them outside of each other.
>
> In this case that definitely is a plus since I didn't write the original
> program, and deciphering some of its workings is little difficult to
> follow at times.
>
> What I am trying to do is use this library: JAMLib
>
> https://sourceforge.net/projects/jamlib/
>
> Trying to follow the doc in this and use the "examples" is not getting me
> any traction due to my C lack of knowledge...
>
> Example:
>
> #include <~/jamtest/jamlib/jam.h>
> #include <~/jamtest/jamlib/structrw.h>
>
> void main()
>         {
>           int Result_I;
> 	  struct Base_PS;
>
>           Result_I = JAM_OpenMB( "TEST", &Base_PS );
>           if ( Result_I )
>             printf("JAM_OpenMB returned %d.\n", Result_I );
>         }
>
>
> leads to:
>
> ~/jamtest $ gcc jamtest.c -l~/jamtest/jamlib/jamlib.a
> jamtest.c: In function ‘main’:
> jamtest.c:9: error: ‘Base_PS’ undeclared (first use in this function)

The following line:

     struct Base_PS;

declares that Base_PS is a struct tag for a struct type - but it doesn't 
actually define that struct type. This is NOT what you wanted to do. 
Note that structure tags can only appear immediately after a 'struct' 
keyword. If the same identifier appears anywhere else, it is not a 
struct tag, and there is no conflict between that other use of the same 
identifier, and it's use as a struct tag.
Therefore the expression &Base_PS pays no attention to your struct 
declaration, and looks for something else named (NOT tagged) Base_PS.
However, as this message correctly indicates, Base_PS (rather than 
struct Base_PS) isn't declared anywhere in your code.

The declaration for JAM_OpenMB given by jam.h is:

int JAM_OpenMB          ( uchar*                Basename_PC,
                           s_JamBase**           NewArea_PPS );

so what you need to declare is an object of the type s_JamBase*, and 
then pass the address of that object to JAM_OpenMB. The code that makes 
up this project makes frequent use of variables named Base_PS for that 
purpose (which is presumably where you got the name from), so I'll keep 
that name:

     s_JamBase *Base_PS;
     Result_I = JAM_OpenMB( "TEST", &Base_PS );

JAM_OpenMB() creates a new s_JamBase object, it sets the pointer whose 
address you give it, to point at that new object. You pass that pointer 
around to various other JAM functions, and then when you're done you get 
rid of the s_JamBase object by calling JAM_CloseMB().

> jamtest.c:9: error: (Each undeclared identifier is reported only once
> jamtest.c:9: error: for each function it appears in.)
>
> This "Base_PS" needs to be some sort of "structure" which well, for me
> doesn't compute...

It needs to be s_JamBase*, where s_JamBase is declared in jam.h as a 
typedef for an tagless struct type.

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

#97555

On 27/11/16 02:14, James R. Kuyper wrote:
> On 11/26/2016 08:05 PM, S390 wrote:
>>
>> I am not a C person for normal things... tweak and edit or fix a few
>> things, etc. to C programs... but I've come up against a program which
>> needs more than my normal tweaking...
>>
>> For most of what I do I take little things and build them to little
>> blocks and then combine all the blocks after having rigorously tested
>> them outside of each other.
>>
>> In this case that definitely is a plus since I didn't write the original
>> program, and deciphering some of its workings is little difficult to
>> follow at times.
>>
>> What I am trying to do is use this library: JAMLib
>>
>> https://sourceforge.net/projects/jamlib/
>>
>> Trying to follow the doc in this and use the "examples" is not getting me
>> any traction due to my C lack of knowledge...
>>
>> Example:
>>
>> #include <~/jamtest/jamlib/jam.h>
>> #include <~/jamtest/jamlib/structrw.h>
>>
>> void main()
>>         {
>>           int Result_I;
>>       struct Base_PS;
>>
>>           Result_I = JAM_OpenMB( "TEST", &Base_PS );
>>           if ( Result_I )
>>             printf("JAM_OpenMB returned %d.\n", Result_I );
>>         }
>>
>>
>> leads to:
>>
>> ~/jamtest $ gcc jamtest.c -l~/jamtest/jamlib/jamlib.a
>> jamtest.c: In function ‘main’:
>> jamtest.c:9: error: ‘Base_PS’ undeclared (first use in this function)
>
> The following line:
>
>     struct Base_PS;
>
> declares that Base_PS is a struct tag for a struct type - but it doesn't
> actually define that struct type. This is NOT what you wanted to do.
> Note that structure tags can only appear immediately after a 'struct'
> keyword. If the same identifier appears anywhere else, it is not a
> struct tag, and there is no conflict between that other use of the same
> identifier, and it's use as a struct tag.
> Therefore the expression &Base_PS pays no attention to your struct
> declaration, and looks for something else named (NOT tagged) Base_PS.
> However, as this message correctly indicates, Base_PS (rather than
> struct Base_PS) isn't declared anywhere in your code.
>
> The declaration for JAM_OpenMB given by jam.h is:
>
> int JAM_OpenMB          ( uchar*                Basename_PC,
>                           s_JamBase**           NewArea_PPS );

The documentation he posted mentioned t_JamBase, not s_JamBase. Did he 
misquote it?

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#97572

On 11/27/2016 04:21 AM, Richard Heathfield wrote:
> On 27/11/16 02:14, James R. Kuyper wrote:
...
>> The declaration for JAM_OpenMB given by jam.h is:
>>
>> int JAM_OpenMB          ( uchar*                Basename_PC,
>>                           s_JamBase**           NewArea_PPS );
>
> The documentation he posted mentioned t_JamBase, not s_JamBase. Did he
> misquote it?

No. jamlib.doc mentions s_JamBase 19 times, and t_JamBase only twice - 
it was just bad luck that he chose one of those two places for his 
quote. All of the source code, and all of the other documentation, only 
refers to s_JamBase.

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

#97906 — Re: Part II - C newb - third party libs and using and testing suite

On Sun, 27 Nov 2016 01:05:30 +0000, S390 wrote:

Thanks for the input... Richard and James!

@fidodev:~/jamtest$ cat jamtest.c 
#include </home/me/jamtest/jamlib/jam.h>
#include </home/me/jamtest/jamlib/structrw.h>
#include <stdlib.h> 

int main(void)
        {
          int Result_I;
          s_JamBase *Base_PS = NULL;
        printf("going to call the function!\n");
          Result_I = JAM_OpenMB( "/home/me/jamtest/TESTJ", &Base_PS );
        printf("called the function!\n");
        printf("function returned %d \n", Result_I );
          if ( Result_I )
            printf("JAM_OpenMB returned %d.\n", Result_I );
          free(Base_PS); 
        printf("something to see!\n");
        }


Yes, theres cruft in there to follow this going through its motions....

This works... 

@fidodev:~/jamtest$ gcc -m32 jamtest.c /home/me/jamtest/jamlib/jamlib.a -
o jamtest

0@fidodev:~/jamtest$ ./jamtest 
going to call the function!
called the function!
function returned 2 
JAM_OpenMB returned 2.
something to see!

Which is correct, that file doesn't exist so...


The issue with the types is that I have too many things open at the same 
time... this lib needs to be compiled in 32b mode and used in 32b mode on 
subsequent programs when on 64b systems...hence the -m32 option... Its an 
issue with the way I connected, and the editor not being connected to the 
right system...

The bigger picture and problem is my total lack of understanding of 
"structures" that doesn't exist for me in what I do/have done... again C 
is not my choice of programming...

What I need is something that outlines in total complete idiot mode, what 
these things are...and how to use them.. because the next thing I am 
going to do is read something from this/these files, and its going to 
return a "structure" for it which means I don't know how to read it break 
it down, or some "pointer" to it etc...  And that stuff is starting to 
sound a lot like "object" oriented stuff I avoided because it just starts 
to sound like "wah awahaha wahhhawah wahhahh" 

Variables are variables, strings, arrays, integers, what not, etc.. not 
pointers to memory.... of something..that probably has to do with using 
interpreted languages versus something compiled, outside assembler.

ie where I am headed is to dump out the header of these files, look at a 
value, do somethings, and move on... 


JAM_ReadMBHeader - Read message base header
===========================================
Syntax
int JAM_ReadMBHeader( s_JamBase* Base_PS,
s_JamBaseHeader* Header_PS );
Description
Reads the message base header from the start of the JAM header
file.
Parameters
Base_PS The message base to use
Header_PS A pointer to a base header structure where the base
header will be stored.
Returns
0 if successful
JAM_BAD_PARAM if Base_PS or Header_PS is NULL
JAM_IO_ERROR if an I/O error occured. see JAM_Errno()
Example
{
s_JamBaseHeader BaseHeader_S;
int Result_I;
Result_I = JAM_ReadMBHeader( Base_PS, &BaseHeader_S );
if ( Result_I )
printf("JAM_ReadMBHeader returned %d.\n", Result_I );
}

So what I am headed to and this is untested.....


int main(void)
        {
          int Result_I;
          s_JamBase *Base_PS = NULL;
          s_JamBaseHeader BaseHeader_S;

          Result_I = JAM_OpenMB( "/home/me/jamtest/TESTJ", &Base_PS );

          if ( Result_I )

            printf("JAM_OpenMB returned %d.\n", Result_I );

	  else // no error in opening so read the header

	   Result_I = JAM_ReadMBHeader( Base_PS, &BaseHeader_S );
		if ( Result_I )
		// if an error like didn't read it  this prints out
		printf("JAM_ReadMBHeader returned %d.\n", Result_I );

		else //ok read the header to get the data needed...

		do my stuff here with the data of the structure...
		example stuff is
		dateOfCreation = JAM_HeaderCreationDate
		 tests on dateOfCreation


			}
 	
          free(Base_PS); 

        }

Again, the above is just rough spitballed... 


So something that outlines HOWTO use this stuff, would be great... I 
never go into that whole "object" stuff for exactly this reason.. my mind 
don't work that way! x=1, something ="This string!" or x[1]="Somevalue" x
[2]="Some other value" etc.. this ThebigBox->something TILT! ERRORR!

-- 
I MADE America Great Again! President Trump! I put a stake in that bitch 
for good!

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

#97910 — Re: Part II - C newb - third party libs and using and testing suite

On 12/02/2016 04:20 PM, S390 wrote:
...
> it down, or some "pointer" to it etc...  And that stuff is starting to
> sound a lot like "object" oriented stuff I avoided because it just starts
> to sound like "wah awahaha wahhhawah wahhahh"

You can write object-oriented C code, and structures play a key role in 
making that possible. However, C was not designed with object 
orientation in mind, the way that C++ or java was. If you don't want the 
advantages that come from using object-oriented design principles, you 
don't have to use them in C (or in C++, for that matter).

> Variables are variables, strings, arrays, integers, what not, etc.. not
> pointers to memory.... of something..that probably has to do with using
> interpreted languages versus something compiled, outside assembler.

Structures are nothing more than a related group of variables that all 
get stored together for ease of use. They're tremendously useful for 
organizing your programs for the same reason that storage boxes, 
closets, and drawers are useful for organizing your house. Of course, 
they only get easy to use once you're familiar with them.

I'm afraid I can't recommend a good "HowTo" for C programming. I can 
offer some advice, however: if you're going to use C, take the time 
needed to learn all the basics (including structures). If you don't have 
time to do so, don't use C - there are other languages that are easier 
to use with little study.

Take a look at BartC's messages on this newsgroup. The way that C is 
designed is radically incompatible with the way he thinks languages 
should be designed. There's nothing wrong with that - he should just 
choose some other language that's a better fit to the way he thinks. If 
he thinks he can create a better language, he should try to do so, and 
that's precisely what he's doing. However, he has also decided to use C 
as the development language for the compiler for his own language, even 
though his philosophical objections to the way C is designed make it 
impossible for him to correctly understand how C works. That way leads 
to insanity, and he seems to be headed there (if he hasn't already arrived).

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

#97916 — Re: Part II - C newb - third party libs and using and testing suite

On Friday, December 2, 2016 at 9:55:26 PM UTC, James R. Kuyper wrote:
>
> You can write object-oriented C code, and structures play a key role in 
> making that possible. However, C was not designed with object 
> orientation in mind, the way that C++ or java was. If you don't want the 
> advantages that come from using object-oriented design principles, you 
> don't have to use them in C (or in C++, for that matter).
> 
You make it sound like no rational person would ever use any design
methodology other than object-orientation. It's one way of organising
programs, and it maps naturally to a reasonably large and important 
subset of programs. But that's all. It's losing popularity as the 
disadvantages become more widely recognised. 
>
> Structures are nothing more than a related group of variables that all 
> get stored together for ease of use. They're tremendously useful for 
> organizing your programs for the same reason that storage boxes, 
> closets, and drawers are useful for organizing your house. Of course, 
> they only get easy to use once you're familiar with them.
> 
The question is whether a list of employees should be represented as

Bloggs, Fred
1234567890
$32,000 

Sixpack, Joe
2345678901
$29,0000


or

Bloggs, Fred; Sixpack, Joe
1234567890, 2345678901
$32,000, $29,0000

C structures encourage the first but don't insist on it. But in
many ways the second is more flexible, if we wish to take  average
salary, for example
>
> I'm afraid I can't recommend a good "HowTo" for C programming. I can 
> offer some advice, however: if you're going to use C, take the time 
> needed to learn all the basics (including structures). If you don't have 
> time to do so, don't use C - there are other languages that are easier 
> to use with little study.
>
Not really. Javascript is superficially easier because it's not
immediately obvious how an employee list is laid out in memory.
But beyond the very first few hurdles, that actually makes it harder
to write and understand Javascript programs.  
> 
> Take a look at BartC's messages on this newsgroup. The way that C is 
> designed is radically incompatible with the way he thinks languages 
> should be designed. There's nothing wrong with that - he should just 
> choose some other language that's a better fit to the way he thinks. If 
> he thinks he can create a better language, he should try to do so, and 
> that's precisely what he's doing. However, he has also decided to use C 
> as the development language for the compiler for his own language, even 
> though his philosophical objections to the way C is designed make it 
> impossible for him to correctly understand how C works. That way leads 
> to insanity, and he seems to be headed there (if he hasn't already 
> arrived).
>
Bart's got a perfectly adequate understanding of C. He exaggerates
some of the problems for the purpose of promoting his own non-C
language, but that's a natural thing to do. There's another poster
who obviously has a very good knowledge of C and identifies many
deep and subtle problems with the language. I've got to say that
I've never been "bitten" by any of the weaknesses raised by this
second poster. But Bart's complaints often match my own experience
- code that pulls in half a library just to get a boolean definition,
for example.

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

#97938 — Re: Part II - C newb - third party libs and using and testing suite

On 03/12/2016 01:14, Malcolm McLean wrote:
> On Friday, December 2, 2016 at 9:55:26 PM UTC, James R. Kuyper wrote:

>> Take a look at BartC's messages on this newsgroup. The way that C is
>> designed is radically incompatible with the way he thinks languages
>> should be designed.

> Bart's got a perfectly adequate understanding of C. He exaggerates
> some of the problems for the purpose of promoting his own non-C
> language, but that's a natural thing to do.

I'm not promoting it. I very rarely give links to the project (and the 
implementation is not mature or stable enough anyway; it's also not my 
primary language).

What I do promote however is an alternate approach to many aspects of C, 
and might use my own working language as an example or to back up arguments.

If I think it's better. But if my approach isn't better or has 
drawbacks, then I will often mention those as well.

> But Bart's complaints often match my own experience
> - code that pulls in half a library just to get a boolean definition,
> for example.

What about when you need to build an open source project, and the first 
thing you encounter is a 10, 20 or 30,000-line 'configure' file? And 
you're on Windows! (And if you do try and download all the things 
necessary to try and build it, something always goes wrong.)

There are enough problems in just getting 100% C code to compile and 
build without involving all this other junk. So I might also use my 
project as an example of how to distribute C source code that can be 
built with little hassle.

-- 
Bartc

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

#97919 — Re: Part II - C newb - third party libs and using and testing suite

On 02/12/2016 21:55, James R. Kuyper wrote:

> If
> he thinks he can create a better language, he should try to do so, and
> that's precisely what he's doing.

Actually I did that long ago. And they were implemented in themselves; 
there was no C involvement at all. But now there is some ...

> However, he has also decided to use C
> as the development language for the compiler for his own language, even
> though his philosophical objections to the way C is designed make it
> impossible for him to correctly understand how C works. That way leads
> to insanity, and he seems to be headed there (if he hasn't already
> arrived).

The 'better than C' language I use is called 'M'. The compiler for M is 
written in another, interpreted language called 'Q'. The interpreter for 
Q is written in M (so there are circular dependencies).

So far, there is no C involvement: the output of the 'M' compiler is 
usually x64 assembly.

*But* I can also get it to generate C intermediate code. Then things 
become more portable. (However there is a lot more to portability across 
OSes than this, as I'm now discovering.)

So the direct involvement of C is optional provided I stick to one 
platform (or create more code generators; there is only x86 and ARM 
really so that is a possibility).

As for becoming insane, there are two dangers: one from the circular 
dependencies I mentioned (if someone is thinking of implementing a 
language, for God's sake use someone else's language to implement it, 
not itself. Until it is stable anyway).

The other danger is from trying to integrate with or to talk to a 
gazillion third party libraries and interfaces all defined in C and 
expecting you to use C and a C compiler. And with a dozen conflicting 
examples of how to do anything, most of which don't actually work when 
you try them.

-- 
Bartc

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web