Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > About -lm switch used for linking math.h

Reply
Thread Tools

About -lm switch used for linking math.h

 
 
Joshua Maurice
Guest
Posts: n/a
 
      02-02-2012
On Jan 28, 2:39*pm, Ian Collins <(E-Mail Removed)> wrote:
> On 01/29/12 10:25 AM, Stephen Sprunk wrote:
> > Unfortunately, if you pack an array of _Bool like that, that causes all
> > sorts of problems when you try to take the address of one of the members
> > of the array.

>
> > Also, it would make accessing the members a lot more expensive than it
> > appears, which could well overshadow any performance benefit to packing
> > them.

>
> Which is one reason why C++ has specialised containers for bool. *In
> some ways bool sits better in C++ than in C (it has always been part of
> the language), but then again just about every C project I've worked on
> has some form of boolean type defined. *So adding _Bool to the language
> does follow the standardisation mantra of standardising existing practice..


Really? I thought this was considered a headache in C++, and there was
talk of deprecating the template specialization of std::vector<bool>
due to its various headaches. It really would have been much better to
introduce a specific type like std::bit_vector instead of specializing
and thereby changing the semantics of std::vector<bool>.
 
Reply With Quote
 
 
 
 
Joe keane
Guest
Posts: n/a
 
      02-02-2012
In article <(E-Mail Removed)>,
Ian Collins <(E-Mail Removed)> wrote:
>Which is one reason why C++ has specialised containers for bool.


Which is more of a headache than useful.

A bit is not an object, it doesn't have an address.

Just make 'bitstring' and done-with-it.
 
Reply With Quote
 
 
 
 
Jorgen Grahn
Guest
Posts: n/a
 
      02-03-2012
On Sun, 2012-01-29, Nick Keighley wrote:
> On Jan 28, 10:39*pm, Ian Collins <(E-Mail Removed)> wrote:
>
>> [...] but then again just about every C project I've worked on
>> has some form of boolean type defined.

>
> I even knew of a project that had four different boolean types. One of
> which had TRUE, FALSE and MAYBE.


Seen that many times (not the MAYBE). Sometimes they are designed so
that 'if(my_boolean)' doesn't work as expected.

Add to that various status code/return code types/defines and the
various conventions for using int return codes (e.g. 0 is success and
-1 failure; OK and ERROR are defined in various ways), and you have
great opportunities for broken error handling

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 
Reply With Quote
 
Phil Carmody
Guest
Posts: n/a
 
      02-14-2012
Kleuske <(E-Mail Removed)> writes:
> On Fri, 27 Jan 2012 09:48:22 +0000, Kenny McCormack saw fit to publish the
> following:
>
> > In article <(E-Mail Removed)>, Joe Pfeiffer
> > <(E-Mail Removed)> wrote: ...
> >>If you're on a Unix-based system (including Linux and BSD), the man page
> >>for a function will tell you both what .h file you need to #include to
> >>compile it, and what library you need to use to link it. So, for
> >>instance, the man page for the sin function says:

> >
> > This isn't necessarily true (and, in true CLC fashion, I'm going to go
> > to great pains to explain why your statement isn't true in absolute
> > generality). All versions of MS/PC DOS/Windows, since DOS 2.0, are
> > Unix-based, yet, when I type "man {anything}" on my Windows Server 2008
> > R2 Home Premium Super Deluxe (*), all I get is some dumb error message.
> >
> > (*) With wheels and a sandwich...

>
> In what universe is MS-DOS "unix-based?".


Holy moley. If his posts are going to be that hilariously stupid,
I might consider pulling him out of the killfile. Or is tha above
just a one-off, in which case thanks for responding to it so we
could all have a laugh at the pseudonymous twerp's expense?

Phil
--
Unix is simple. It just takes a genius to understand its simplicity
-- Dennis Ritchie (1941-2011), Unix Co-Creator
 
Reply With Quote
 
Phil Carmody
Guest
Posts: n/a
 
      02-14-2012
Ike Naar <(E-Mail Removed)> writes:
> On 2012-01-30, Keith Thompson <(E-Mail Removed)> wrote:
> > Stephen Sprunk <(E-Mail Removed)> writes:
> >> I'll note, though, that "if (ok!=false)" works just fine, even for
> >> uncommon values of truth.

> >
> > Yes, but "if (!ok)" is clearer and, IMHO, better.

>
> (ok) is still clearer and still better.


Except when it isn't. For example the commonly adopted coding style
for the linux kernel is to have desirable operation flow uninterupted
down a function, and for failures to jump away from that flow (be that
goto, break, return, whatever).

Phil
--
Unix is simple. It just takes a genius to understand its simplicity
-- Dennis Ritchie (1941-2011), Unix Co-Creator
 
Reply With Quote
 
Ike Naar
Guest
Posts: n/a
 
      02-14-2012
On 2012-02-14, Phil Carmody <(E-Mail Removed)> wrote:
> Ike Naar <(E-Mail Removed)> writes:
>> On 2012-01-30, Keith Thompson <(E-Mail Removed)> wrote:
>> > Stephen Sprunk <(E-Mail Removed)> writes:
>> >> I'll note, though, that "if (ok!=false)" works just fine, even for
>> >> uncommon values of truth.
>> >
>> > Yes, but "if (!ok)" is clearer and, IMHO, better.

>>
>> (ok) is still clearer and still better.

>
> Except when it isn't. For example the commonly adopted coding style
> for the linux kernel is to have desirable operation flow uninterupted
> down a function, and for failures to jump away from that flow (be that
> goto, break, return, whatever).


Even under such a coding style, "!ok" means the opposite of "ok!=false".
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      02-15-2012
Ike Naar <(E-Mail Removed)> writes:
> On 2012-02-14, Phil Carmody <(E-Mail Removed)> wrote:
>> Ike Naar <(E-Mail Removed)> writes:
>>> On 2012-01-30, Keith Thompson <(E-Mail Removed)> wrote:
>>> > Stephen Sprunk <(E-Mail Removed)> writes:
>>> >> I'll note, though, that "if (ok!=false)" works just fine, even for
>>> >> uncommon values of truth.
>>> >
>>> > Yes, but "if (!ok)" is clearer and, IMHO, better.
>>>
>>> (ok) is still clearer and still better.

>>
>> Except when it isn't. For example the commonly adopted coding style
>> for the linux kernel is to have desirable operation flow uninterupted
>> down a function, and for failures to jump away from that flow (be that
>> goto, break, return, whatever).

>
> Even under such a coding style, "!ok" means the opposite of "ok!=false".


Yes, that was my mistake, which I acknowleged when it was first pointed out.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Phil Carmody
Guest
Posts: n/a
 
      02-22-2012
Ike Naar <(E-Mail Removed)> writes:

> On 2012-02-14, Phil Carmody <(E-Mail Removed)> wrote:
> > Ike Naar <(E-Mail Removed)> writes:
> >> On 2012-01-30, Keith Thompson <(E-Mail Removed)> wrote:
> >> > Stephen Sprunk <(E-Mail Removed)> writes:
> >> >> I'll note, though, that "if (ok!=false)" works just fine, even for
> >> >> uncommon values of truth.
> >> >
> >> > Yes, but "if (!ok)" is clearer and, IMHO, better.
> >>
> >> (ok) is still clearer and still better.

> >
> > Except when it isn't. For example the commonly adopted coding style
> > for the linux kernel is to have desirable operation flow uninterupted
> > down a function, and for failures to jump away from that flow (be that
> > goto, break, return, whatever).

>
> Even under such a coding style, "!ok" means the opposite of "ok!=false".


Ack. I only read context if the new material doesn't make sense -
my key-hole approach gave me an inappropriate context. Apologies.

Phil
--
> I'd argue that there is much evidence for the existence of a God.

Pics or it didn't happen.
-- Tom (/. uid 822)
 
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
linking 2 VLANs on one switch rezalas Hardware 3 05-17-2008 04:23 AM
Switch/Switch problem fibre gigbit ethernet hartmut.albers@gmail.com Cisco 2 09-06-2005 04:59 PM
Is a frame switch and an ISDN switch really needed? owmanstubbedmytoe Cisco 2 12-05-2004 07:15 AM
bridge / layer 2 switch / layer 3 switch Joel M. Baldwin Cisco 2 11-06-2003 11:19 PM
difference b/w layer 2 switch and layer 3 switch praveen Cisco 1 10-22-2003 07:19 AM



Advertisments