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

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

va_start without the first argument?

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

Contents

  va_start without the first argument? Thiago Adams <thiago.adams@gmail.com> - 2017-03-10 11:57 -0800
    Re: va_start without the first argument? Thiago Adams <thiago.adams@gmail.com> - 2017-03-10 12:04 -0800
    Re: va_start without the first argument? Keith Thompson <kst-u@mib.org> - 2017-03-10 12:32 -0800
      Re: va_start without the first argument? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-03-10 15:51 -0500
      Re: va_start without the first argument? Thiago Adams <thiago.adams@gmail.com> - 2017-03-10 14:36 -0800
        Re: va_start without the first argument? Thiago Adams <thiago.adams@gmail.com> - 2017-03-10 14:53 -0800
          Re: va_start without the first argument? Robert Wessel <robertwessel2@yahoo.com> - 2017-03-10 17:14 -0600
            Re: va_start without the first argument? Thiago Adams <thiago.adams@gmail.com> - 2017-03-10 15:37 -0800
              Re: va_start without the first argument? Robert Wessel <robertwessel2@yahoo.com> - 2017-03-10 23:12 -0600
                Re: va_start without the first argument? Thiago Adams <thiago.adams@gmail.com> - 2017-03-13 10:29 -0700
                  Re: va_start without the first argument? Thiago Adams <thiago.adams@gmail.com> - 2017-03-13 11:31 -0700
                    Re: va_start without the first argument? scott@slp53.sl.home (Scott Lurndal) - 2017-03-13 18:40 +0000
                      Re: va_start without the first argument? Thiago Adams <thiago.adams@gmail.com> - 2017-03-13 12:31 -0700
              Re: va_start without the first argument? jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-11 19:53 +0100
                Re: va_start without the first argument? BartC <bc@freeuk.com> - 2017-03-11 19:05 +0000
                  Re: va_start without the first argument? Keith Thompson <kst-u@mib.org> - 2017-03-11 11:56 -0800
                Re: va_start without the first argument? antispam@math.uni.wroc.pl - 2017-03-12 05:41 +0000
                Re: va_start without the first argument? David Brown <david.brown@hesbynett.no> - 2017-03-12 13:52 +0100
                  Re: va_start without the first argument? BartC <bc@freeuk.com> - 2017-03-12 14:40 +0000
                    Re: va_start without the first argument? David Brown <david.brown@hesbynett.no> - 2017-03-12 18:13 +0100
                      Re: va_start without the first argument? BartC <bc@freeuk.com> - 2017-03-12 18:04 +0000
                        Re: va_start without the first argument? David Brown <david.brown@hesbynett.no> - 2017-03-12 21:04 +0100
                          Re: va_start without the first argument? BartC <bc@freeuk.com> - 2017-03-12 21:02 +0000
                            Re: va_start without the first argument? David Brown <david.brown@hesbynett.no> - 2017-03-12 22:40 +0100
                              Re: va_start without the first argument? supercat@casperkitty.com - 2017-03-12 15:51 -0700
                                Re: va_start without the first argument? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-03-12 16:52 -0700
                                Re: va_start without the first argument? David Brown <david.brown@hesbynett.no> - 2017-03-13 00:56 +0100
                                  Re: va_start without the first argument? supercat@casperkitty.com - 2017-03-13 09:17 -0700
                                    Re: va_start without the first argument? BartC <bc@freeuk.com> - 2017-03-13 17:54 +0000
                                      Re: va_start without the first argument? David Brown <david.brown@hesbynett.no> - 2017-03-13 22:12 +0100
                                        Re: va_start without the first argument? BartC <bc@freeuk.com> - 2017-03-13 22:48 +0000
                                          Re: va_start without the first argument? David Brown <david.brown@hesbynett.no> - 2017-03-14 13:46 +0100
                                            Re: va_start without the first argument? BartC <bc@freeuk.com> - 2017-03-14 13:37 +0000
                                              Re: va_start without the first argument? David Brown <david.brown@hesbynett.no> - 2017-03-14 15:24 +0100
                                                Re: va_start without the first argument? supercat@casperkitty.com - 2017-03-14 08:25 -0700
                                                  Re: va_start without the first argument? David Brown <david.brown@hesbynett.no> - 2017-03-14 17:02 +0100
                                                    Re: va_start without the first argument? supercat@casperkitty.com - 2017-03-14 09:45 -0700
                                              Re: va_start without the first argument? Keith Thompson <kst-u@mib.org> - 2017-03-14 09:15 -0700
                                                Re: va_start without the first argument? supercat@casperkitty.com - 2017-03-14 10:02 -0700
                                                Re: va_start without the first argument? jt@toerring.de (Jens Thoms Toerring) - 2017-03-14 20:32 +0000
                                        Re: va_start without the first argument? raltbos@xs4all.nl (Richard Bos) - 2017-03-14 07:44 +0000
                                          Re: va_start without the first argument? David Brown <david.brown@hesbynett.no> - 2017-03-14 13:38 +0100
                                          Re: va_start without the first argument? Keith Thompson <kst-u@mib.org> - 2017-03-14 08:57 -0700
                                    Re: va_start without the first argument? Keith Thompson <kst-u@mib.org> - 2017-03-13 11:21 -0700
                                      Re: va_start without the first argument? scott@slp53.sl.home (Scott Lurndal) - 2017-03-13 18:33 +0000
                                        Re: va_start without the first argument? David Brown <david.brown@hesbynett.no> - 2017-03-13 22:08 +0100
                                          Re: va_start without the first argument? supercat@casperkitty.com - 2017-03-13 15:23 -0700
                                            Re: va_start without the first argument? David Brown <david.brown@hesbynett.no> - 2017-03-14 13:58 +0100
                                              Re: va_start without the first argument? Keith Thompson <kst-u@mib.org> - 2017-03-14 09:18 -0700
                                                Re: va_start without the first argument? scott@slp53.sl.home (Scott Lurndal) - 2017-03-14 16:52 +0000
                                                  Re: va_start without the first argument? Keith Thompson <kst-u@mib.org> - 2017-03-14 11:34 -0700
                                                    Re: va_start without the first argument? scott@slp53.sl.home (Scott Lurndal) - 2017-03-14 18:54 +0000
                                                    Re: va_start without the first argument? supercat@casperkitty.com - 2017-03-14 13:30 -0700
                                                      Re: va_start without the first argument? Ike Naar <ike@iceland.freeshell.org> - 2017-03-15 21:55 +0000
                                                        Re: va_start without the first argument? supercat@casperkitty.com - 2017-03-15 15:16 -0700
                                                        Re: va_start without the first argument? Philip Lantz <prl@canterey.us> - 2017-03-23 21:04 -0700
                                                Re: va_start without the first argument? David Brown <david.brown@hesbynett.no> - 2017-03-14 21:48 +0100
                                            Re: va_start without the first argument? scott@slp53.sl.home (Scott Lurndal) - 2017-03-14 14:01 +0000
                                              Re: va_start without the first argument? supercat@casperkitty.com - 2017-03-14 07:42 -0700
                                          Re: va_start without the first argument? scott@slp53.sl.home (Scott Lurndal) - 2017-03-14 12:38 +0000
                                Re: va_start without the first argument? jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-13 01:11 +0100
                                  Re: va_start without the first argument? Ian Collins <ian-news@hotmail.com> - 2017-03-13 15:43 +1300
                                    Re: va_start without the first argument? BartC <bc@freeuk.com> - 2017-03-13 10:36 +0000
                                      Re: va_start without the first argument? Ian Collins <ian-news@hotmail.com> - 2017-03-14 07:33 +1300
                                        Re: va_start without the first argument? BartC <bc@freeuk.com> - 2017-03-13 19:00 +0000
                                          Re: va_start without the first argument? Ian Collins <ian-news@hotmail.com> - 2017-03-14 08:05 +1300
                                            Re: va_start without the first argument? BartC <bc@freeuk.com> - 2017-03-13 23:10 +0000
                                              Re: va_start without the first argument? Ian Collins <ian-news@hotmail.com> - 2017-03-14 17:38 +1300
                                                Re: va_start without the first argument? Thiago Adams <thiago.adams@gmail.com> - 2017-03-14 05:48 -0700
                                          Re: va_start without the first argument? Thiago Adams <thiago.adams@gmail.com> - 2017-03-13 12:12 -0700
                  Re: va_start without the first argument? jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-12 19:39 +0100
    Re: va_start without the first argument? jt@toerring.de (Jens Thoms Toerring) - 2017-03-10 20:49 +0000
      Re: va_start without the first argument? Thiago Adams <thiago.adams@gmail.com> - 2017-03-10 14:41 -0800
        Re: va_start without the first argument? John Bode <jfbode1029@gmail.com> - 2017-03-10 16:05 -0800
          Re: va_start without the first argument? jacob navia <jacob@jacob.remcomp.fr> - 2017-03-11 21:47 +0100
            Re: va_start without the first argument? supercat@casperkitty.com - 2017-03-11 13:07 -0800
              Re: va_start without the first argument? jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-11 22:24 +0100
                Re: va_start without the first argument? Thiago Adams <thiago.adams@gmail.com> - 2017-03-13 05:44 -0700
                  Re: va_start without the first argument? Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-13 08:59 -0400
                    Re: va_start without the first argument? Thiago Adams <thiago.adams@gmail.com> - 2017-03-13 06:17 -0700
                      Re: va_start without the first argument? Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-13 13:27 -0400
                        Re: va_start without the first argument? Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-13 13:30 -0400
                          Re: va_start without the first argument? Thiago Adams <thiago.adams@gmail.com> - 2017-03-13 11:00 -0700
                        Re: va_start without the first argument? Thiago Adams <thiago.adams@gmail.com> - 2017-03-13 10:34 -0700
            Re: va_start without the first argument? antispam@math.uni.wroc.pl - 2017-03-12 06:00 +0000
            Re: va_start without the first argument? gordonb.gas5o@burditt.org (Gordon Burditt) - 2017-03-17 09:46 -0500
              Re: va_start without the first argument? supercat@casperkitty.com - 2017-03-17 09:07 -0700
          Re: va_start without the first argument? Thiago Adams <thiago.adams@gmail.com> - 2017-03-13 05:39 -0700
            Re: va_start without the first argument? John Bode <jfbode1029@gmail.com> - 2017-03-13 11:40 -0700
              Re: va_start without the first argument? Thiago Adams <thiago.adams@gmail.com> - 2017-03-13 12:01 -0700
                Re: va_start without the first argument? jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-13 23:17 +0100
                  Re: va_start without the first argument? Thiago Adams <thiago.adams@gmail.com> - 2017-03-13 16:15 -0700
                    Re: va_start without the first argument? jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-14 00:26 +0100
                      Re: va_start without the first argument? kikiins@gmail.com - 2017-03-13 16:51 -0700
                        Re: va_start without the first argument? jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-14 01:12 +0100
                          Re: va_start without the first argument? Thiago Adams <thiago.adams@gmail.com> - 2017-03-13 18:24 -0700
                            Re: va_start without the first argument? Thiago Adams <thiago.adams@gmail.com> - 2017-03-13 18:57 -0700
                    Re: va_start without the first argument? raltbos@xs4all.nl (Richard Bos) - 2017-03-14 07:59 +0000
                      Re: va_start without the first argument? Thiago Adams <thiago.adams@gmail.com> - 2017-03-14 06:45 -0700
                  Re: va_start without the first argument? Robert Wessel <robertwessel2@yahoo.com> - 2017-03-13 18:20 -0500
                    Re: va_start without the first argument? jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-14 00:31 +0100
      Re: va_start without the first argument? raltbos@xs4all.nl (Richard Bos) - 2017-03-13 16:51 +0000
    Re: va_start without the first argument? jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-11 19:29 +0100
    Re: va_start without the first argument? Siri Cruise <chine.bleu@yahoo.com> - 2017-03-11 12:12 -0800
    Re: va_start without the first argument? luser droog <luser.droog@gmail.com> - 2017-03-13 05:37 -0700
      Re: va_start without the first argument? luser droog <luser.droog@gmail.com> - 2017-03-15 11:45 -0700
        Re: va_start without the first argument? Thiago Adams <thiago.adams@gmail.com> - 2017-03-15 13:39 -0700

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

#105898

Le 12/03/2017 à 23:51, supercat@casperkitty.com a écrit :
> Writing unnecessary code and hoping a compiler will eliminate it
> doesn't seem like a very robust approach, compared with writing code which
> only does what's actually necssary.

Like anything, engineering is about compromises. In principle you are 
right, the machine should do only what is necessary.

Now comes the programming language. It may take a runtime cost, for 
instance, instead of using the input data at the actual locations they 
are, input data is copied into temporary storage, passing it by value. 
We ensure then, that the called procedure can't change the original data.

This run tilme cost of the programming language can be eliminated when 
you write directly the processor instructions. When you call procedure 
A, that procedure knows by construction where the arguments are and no 
copy is done. You spare a few cycles.

But there are limits of course. The more of this linkage between 
procedures is done, the more the code becomes tangled and unmodifiable. 
High level languages like C accept the run time cost to easy the 
programming for humans. Humans make mistakes and the bigger the exposure 
of a programmer (or a team) to direct assembly language with all the 
tricks ON, produces code that is relatively fast but unmaintenable.

OK. Programming languages easy the effort to input machine instructions. 
You program in PHP and deal with high level objects, etc. The machine 
itself compiles or interprets C or PHP or whatever, and expands the set 
of actions described in the language into actual machine actions that 
are executed.

This way an addition of two numbers can take more than 1 cycle (what 
actually should take in any modern processor) but thousands of 
instructions to lookup for overloaded additions, or the class hierarchy 
for those two numbers or whatever.

And in many applications those thousand of instructions do not take 
almost any time (some micro-seconds maybe) and is perfectly acceptable.

Everything depends on the actual usage of the code, and the human effort 
done to realize the set of instructions that somebody has decided the 
machine should do.

Here is the center of the problem. Is each operation necessary? Couldn't 
another algorithm speed up the processing? Are those convoluted class 
hierarchies really necessary? Couldn't we simplify a bit?

I think many people have lost the motivation for doing minimal programs 
since machines have become so powerful. Who cares?

We have enough RAM and CPU.

But there are hidden costs that everyone pays for doing bloated 
software, that is also unmaintainable because of its sheer size!

Simplifying is not a luxury, it is necessary. In this time when everyone 
is going in the wrong direction it would be better to stop and reflect 
if all that complexity is really necessary.

For instance Thiago wanted a new syntax for lambdas recently. I objected 
that the new syntax complexifies C and doesn't really bring something 
imperatively new. You can do function pointer calls in C, and all 
computers I have used had a call instruction where the address of the 
call is in a register.

Can you write a data base server in assembly?

Yes, if you want. It would run very fast but it would cost a huge amount 
of effort to write.

Compiled languages have the advantage that they pre-process the 
language, generating an executable that has already all calculations 
needed at run time by the language resolved (addresses, temporaries, 
etc). Interpreted languages must pay that when they do the interpretation.

But conceptual abstractions, like parameter passing, cost cpu time, that 
is a fact. And many people pay that time since they program in C and not 
in assembly directly.

But then C++ adds some trillions of complexity into the mix. It is still 
a compiled language but there are already several problems:

1) Exception handling. A run time interpreter is generated, that will 
walk the stack frames executing destructors if there is an exception.

Well, here the performance is not important since it is an exception, so 
that path is not taken very often.

Or is it?

If you start programming using that too often you will end up with a 
slow program.

2)
Another problem for C++ is the hidden constructors/destructors calls 
when building temporary objects, what sometimes could mean unnecessary 
heap usage. That has been reduced by the heroic efforts of the 
optimizing compilers, that everyone takes for granted. C++ has sometimes 
a good speed because a huge and complex machinery has been built, to 
deduce when the code could be optimized by proving that the action 
specified by the language is unnecessary.

3) Code bloat.
Another problem with C++ is the "inline" statement. This tends to bloat 
the generated code in a big way, saving the effort of constructing a 
stack frame and making a function call, but at the cost of swamping the 
code caches and slowing down the CPU to read more code from memory. 
Templates add their contribution to code bloat also. Templates allow the 
easy generation of specialized functions but they replicate code also, 
making that approach resposible for a LOT of code duplication. Could 
they be replaced by simpler stuff like passing a code for the argument 
type and specifying as templates a small subset of the generated function?

Note that the code duplication makes it possible to write a single piece 
of code for very different types, what simplifies maintenance.

Everything in engineering is a compromise.

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

#105901

On 03/13/17 01:11 PM, jacobnavia wrote:

<snip>

> Here is the center of the problem. Is each operation necessary? Couldn't
> another algorithm speed up the processing? Are those convoluted class
> hierarchies really necessary? Couldn't we simplify a bit?
>
> I think many people have lost the motivation for doing minimal programs
> since machines have become so powerful. Who cares?
>
> We have enough RAM and CPU.

That my apply to desktop and server applications (why else would people 
use Java!), but it definitely isn't the case for embedded and kernel 
space developers.

> But there are hidden costs that everyone pays for doing bloated
> software, that is also unmaintainable because of its sheer size!

Size doesn't make code unmaintainable, poor software engineering does. 
I have to work in the Linux and Illumos kernels from time to time: Both 
are large and neither is unmaintainable.

> Simplifying is not a luxury, it is necessary. In this time when everyone
> is going in the wrong direction it would be better to stop and reflect
> if all that complexity is really necessary.

Indeed, simplicity is one of the cornerstones of agile development. 
Most over complex code I have had the dubious pleasure of maintaining 
got into a mess because successive developers added more functionality 
without taking the time to refactor the code.  Often they were unable to 
do this because the code lacked adequate tests so there was too much 
risk associated with changing it.

> For instance Thiago wanted a new syntax for lambdas recently. I objected
> that the new syntax complexifies C and doesn't really bring something
> imperatively new. You can do function pointer calls in C, and all
> computers I have used had a call instruction where the address of the
> call is in a register.

I think most here though likewise.  There is a much greater benefit from 
lambdas in C++ that there is in C.

<snip>

Here we go.. the hoary old chestnut FUD roaster is out...

> But then C++ adds some trillions of complexity into the mix. It is still
> a compiled language but there are already several problems:
>
> 1) Exception handling. A run time interpreter is generated, that will
> walk the stack frames executing destructors if there is an exception.
>
> Well, here the performance is not important since it is an exception, so
> that path is not taken very often.
>
> Or is it?
>
> If you start programming using that too often you will end up with a
> slow program.

So don't!

> 2)
> Another problem for C++ is the hidden constructors/destructors calls
> when building temporary objects, what sometimes could mean unnecessary
> heap usage. That has been reduced by the heroic efforts of the
> optimizing compilers, that everyone takes for granted. C++ has sometimes
> a good speed because a huge and complex machinery has been built, to
> deduce when the code could be optimized by proving that the action
> specified by the language is unnecessary.

Constructors and destructors are only there is someone has written them 
and they are only written if they have a job to do!

> 3) Code bloat.
> Another problem with C++ is the "inline" statement. This tends to bloat
> the generated code in a big way, saving the effort of constructing a
> stack frame and making a function call, but at the cost of swamping the
> code caches and slowing down the CPU to read more code from memory.

Well that's no different to C.  Most compilers probably use the same 
back end to perform inlining in C and C++.

> Templates add their contribution to code bloat also. Templates allow the
> easy generation of specialized functions but they replicate code also,
> making that approach resposible for a LOT of code duplication. Could
> they be replaced by simpler stuff like passing a code for the argument
> type and specifying as templates a small subset of the generated function?

That is often done.  Don't forget that templates are often used in C++ 
where macros would be used in C and the compiler can choose whether or 
not to inline a template function instantiation, but it can't choose not 
to inline a macro...

> Note that the code duplication makes it possible to write a single piece
> of code for very different types, what simplifies maintenance.
>
> Everything in engineering is a compromise.

Indeed.

-- 
Ian

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

#105903

On 13/03/2017 02:43, Ian Collins wrote:
> On 03/13/17 01:11 PM, jacobnavia wrote:

>> Simplifying is not a luxury, it is necessary. In this time when everyone
>> is going in the wrong direction it would be better to stop and reflect
>> if all that complexity is really necessary.
>
> Indeed, simplicity is one of the cornerstones of agile development. Most
> over complex code I have had the dubious pleasure of maintaining got
> into a mess because successive developers added more functionality
> without taking the time to refactor the code.

But the same doesn't seem to apply to programming languages themselves?

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

#105928

On 03/13/17 11:36 PM, BartC wrote:
> On 13/03/2017 02:43, Ian Collins wrote:
>> On 03/13/17 01:11 PM, jacobnavia wrote:
>
>>> Simplifying is not a luxury, it is necessary. In this time when everyone
>>> is going in the wrong direction it would be better to stop and reflect
>>> if all that complexity is really necessary.
>>
>> Indeed, simplicity is one of the cornerstones of agile development. Most
>> over complex code I have had the dubious pleasure of maintaining got
>> into a mess because successive developers added more functionality
>> without taking the time to refactor the code.
>
> But the same doesn't seem to apply to programming languages themselves?

Complexity has to go somewhere.  That somewhere is usually the user's 
code or the programming language.  A good example is a typical bit of 
driver code I often encounter or have to write:

Get resource A
Get resource B
Get resource C
Get resource D

Do something with them.

Would you rather see the code written pretty much as above, or have the 
steps lost in a tangle of ifs, gotos and clean up code?

-- 
Ian

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

#105931

On 13/03/2017 18:33, Ian Collins wrote:
> On 03/13/17 11:36 PM, BartC wrote:
>> On 13/03/2017 02:43, Ian Collins wrote:
>>> On 03/13/17 01:11 PM, jacobnavia wrote:
>>
>>>> Simplifying is not a luxury, it is necessary. In this time when
>>>> everyone
>>>> is going in the wrong direction it would be better to stop and reflect
>>>> if all that complexity is really necessary.
>>>
>>> Indeed, simplicity is one of the cornerstones of agile development. Most
>>> over complex code I have had the dubious pleasure of maintaining got
>>> into a mess because successive developers added more functionality
>>> without taking the time to refactor the code.
>>
>> But the same doesn't seem to apply to programming languages themselves?
>
> Complexity has to go somewhere.  That somewhere is usually the user's
> code or the programming language.

That's not the only option. Sometimes a system grows over time and 
becomes so complex and with so many ad hoc, bolted-on features that it 
is better to start afresh. Then the result, based on experience of the 
old system, really can be smaller, simpler, more reliable, easier to 
understand and less work to maintain. It might even be faster.

> A good example is a typical bit of
> driver code I often encounter or have to write:
>
> Get resource A
> Get resource B
> Get resource C
> Get resource D

> Do something with them.
>
> Would you rather see the code written pretty much as above, or have the
> steps lost in a tangle of ifs, gotos and clean up code?

A lot of stuff that people say C++ makes simpler, can already be done by 
any scripting language (even one of mine).

And it is genuinely simpler and much, much cleaner in appearance; you 
don't need to try and pick out fragments of the actual code from amongst 
the punctuation, types and syntax.

The only problem with such languages is speed. Yet, probably, most of a 
typical application with a user interface could run at scripting speed 
without anyone noticing.

-- 
Bartc

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

#105933

On 03/14/17 08:00 AM, BartC wrote:
> On 13/03/2017 18:33, Ian Collins wrote:
>> On 03/13/17 11:36 PM, BartC wrote:
>>> On 13/03/2017 02:43, Ian Collins wrote:
>>>> On 03/13/17 01:11 PM, jacobnavia wrote:
>>>
>>>>> Simplifying is not a luxury, it is necessary. In this time when
>>>>> everyone
>>>>> is going in the wrong direction it would be better to stop and reflect
>>>>> if all that complexity is really necessary.
>>>>
>>>> Indeed, simplicity is one of the cornerstones of agile development. Most
>>>> over complex code I have had the dubious pleasure of maintaining got
>>>> into a mess because successive developers added more functionality
>>>> without taking the time to refactor the code.
>>>
>>> But the same doesn't seem to apply to programming languages themselves?
>>
>> Complexity has to go somewhere.  That somewhere is usually the user's
>> code or the programming language.
>
> That's not the only option. Sometimes a system grows over time and
> becomes so complex and with so many ad hoc, bolted-on features that it
> is better to start afresh. Then the result, based on experience of the
> old system, really can be smaller, simpler, more reliable, easier to
> understand and less work to maintain. It might even be faster.

That's why we write unit tests and continuously refactor code..

>> A good example is a typical bit of
>> driver code I often encounter or have to write:
>>
>> Get resource A
>> Get resource B
>> Get resource C
>> Get resource D
>
>> Do something with them.
>>
>> Would you rather see the code written pretty much as above, or have the
>> steps lost in a tangle of ifs, gotos and clean up code?
>
> A lot of stuff that people say C++ makes simpler, can already be done by
> any scripting language (even one of mine).

Where did I mention C++?

> And it is genuinely simpler and much, much cleaner in appearance; you
> don't need to try and pick out fragments of the actual code from amongst
> the punctuation, types and syntax.
>
> The only problem with such languages is speed. Yet, probably, most of a
> typical application with a user interface could run at scripting speed
> without anyone noticing.

True, but if you were to chose C++, you would keep the clarity without 
sacrificing speed.  In many cases, using exceptions rather than error 
codes not only makes the code cleaner and safer, it also makes it faster!

-- 
Ian

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

#105952

On 13/03/2017 19:05, Ian Collins wrote:
> On 03/14/17 08:00 AM, BartC wrote:

>> That's not the only option. Sometimes a system grows over time and
>> becomes so complex and with so many ad hoc, bolted-on features that it
>> is better to start afresh. Then the result, based on experience of the
>> old system, really can be smaller, simpler, more reliable, easier to
>> understand and less work to maintain. It might even be faster.
>
> That's why we write unit tests and continuously refactor code..

OK, so we're back to:

 >> But the same doesn't seem to apply to programming languages themselves?

>> A lot of stuff that people say C++ makes simpler, can already be done by
>> any scripting language (even one of mine).
>
> Where did I mention C++?

Since your posts are invariably about C++ (and how much better it is) 
that was a natural assumption.

>> And it is genuinely simpler and much, much cleaner in appearance; you
>> don't need to try and pick out fragments of the actual code from amongst
>> the punctuation, types and syntax.
>>
>> The only problem with such languages is speed. Yet, probably, most of a
>> typical application with a user interface could run at scripting speed
>> without anyone noticing.
>
> True, but if you were to chose C++, you would keep the clarity without
> sacrificing speed.

It's this 'clarity' that I'm disputing. Having to annotate types of all 
objects and interfaces may be necessary to get the best performance (and 
type safety etc), but even here C++ excels with its ugly, cluttered 
syntax that dominates everything else.

> In many cases, using exceptions rather than error
> codes not only makes the code cleaner and safer, it also makes it faster!

You mean, it might have been even worse without exceptions?!

-- 
bartc

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

#105983

On 03/14/17 12:10 PM, BartC wrote:
> On 13/03/2017 19:05, Ian Collins wrote:
>> On 03/14/17 08:00 AM, BartC wrote:
>
>>> That's not the only option. Sometimes a system grows over time and
>>> becomes so complex and with so many ad hoc, bolted-on features that it
>>> is better to start afresh. Then the result, based on experience of the
>>> old system, really can be smaller, simpler, more reliable, easier to
>>> understand and less work to maintain. It might even be faster.
>>
>> That's why we write unit tests and continuously refactor code..
>
> OK, so we're back to:
>
>   >> But the same doesn't seem to apply to programming languages themselves?
>
>>> A lot of stuff that people say C++ makes simpler, can already be done by
>>> any scripting language (even one of mine).
>>
>> Where did I mention C++?
>
> Since your posts are invariably about C++ (and how much better it is)
> that was a natural assumption.

Not in this case.

>>> And it is genuinely simpler and much, much cleaner in appearance; you
>>> don't need to try and pick out fragments of the actual code from amongst
>>> the punctuation, types and syntax.
>>>
>>> The only problem with such languages is speed. Yet, probably, most of a
>>> typical application with a user interface could run at scripting speed
>>> without anyone noticing.
>>
>> True, but if you were to chose C++, you would keep the clarity without
>> sacrificing speed.
>
> It's this 'clarity' that I'm disputing. Having to annotate types of all
> objects and interfaces may be necessary to get the best performance (and
> type safety etc), but even here C++ excels with its ugly, cluttered
> syntax that dominates everything else.

So the "ugly, cluttered syntax" is worse than a spaghetti of manual 
resource management?

Given the following interface:

struct A;

A* getA();
void freeA(A*);

struct B;

B* getB();
void freeB(B*);

struct C;

C* getC();
void freeC(C*);

struct D;

D* getD();
void freeD(D*);

If exceptions are used, a function could simply be written:

void f()
{
   auto a = shared_ptr<A>( getA(), freeA );
   auto b = shared_ptr<B>( getB(), freeB );
   auto c = shared_ptr<C>( getC(), freeC );
   auto d = shared_ptr<D>( getD(), freeD );

   // Do stuff with a,b , and d.
}

If the interface didn't use exceptions, the code would just be a cascade 
of ifs, again no spaghetti.

>> In many cases, using exceptions rather than error
>> codes not only makes the code cleaner and safer, it also makes it faster!
>
> You mean, it might have been even worse without exceptions?!

No, I mean not having to check error codes is faster (and safer) than 
checking them.

-- 
Ian

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

#106009

On Tuesday, March 14, 2017 at 1:38:55 AM UTC-3, Ian Collins wrote:
> On 03/14/17 12:10 PM, BartC wrote:
> > On 13/03/2017 19:05, Ian Collins wrote:
> >> On 03/14/17 08:00 AM, BartC wrote:
> >
> >>> That's not the only option. Sometimes a system grows over time and
> >>> becomes so complex and with so many ad hoc, bolted-on features that it
> >>> is better to start afresh. Then the result, based on experience of the
> >>> old system, really can be smaller, simpler, more reliable, easier to
> >>> understand and less work to maintain. It might even be faster.
> >>
> >> That's why we write unit tests and continuously refactor code..
> >
> > OK, so we're back to:
> >
> >   >> But the same doesn't seem to apply to programming languages themselves?
> >
> >>> A lot of stuff that people say C++ makes simpler, can already be done by
> >>> any scripting language (even one of mine).
> >>
> >> Where did I mention C++?
> >
> > Since your posts are invariably about C++ (and how much better it is)
> > that was a natural assumption.
> 
> Not in this case.
> 
> >>> And it is genuinely simpler and much, much cleaner in appearance; you
> >>> don't need to try and pick out fragments of the actual code from amongst
> >>> the punctuation, types and syntax.
> >>>
> >>> The only problem with such languages is speed. Yet, probably, most of a
> >>> typical application with a user interface could run at scripting speed
> >>> without anyone noticing.
> >>
> >> True, but if you were to chose C++, you would keep the clarity without
> >> sacrificing speed.
> >
> > It's this 'clarity' that I'm disputing. Having to annotate types of all
> > objects and interfaces may be necessary to get the best performance (and
> > type safety etc), but even here C++ excels with its ugly, cluttered
> > syntax that dominates everything else.
> 
> So the "ugly, cluttered syntax" is worse than a spaghetti of manual 
> resource management?
> 
> Given the following interface:
> 
> struct A;
> 
> A* getA();
> void freeA(A*);
> 
> struct B;
> 
> B* getB();
> void freeB(B*);
> 
> struct C;
> 
> C* getC();
> void freeC(C*);
> 
> struct D;
> 
> D* getD();
> void freeD(D*);
> 
> If exceptions are used, a function could simply be written:
> 
> void f()
> {
>    auto a = shared_ptr<A>( getA(), freeA );
>    auto b = shared_ptr<B>( getB(), freeB );
>    auto c = shared_ptr<C>( getC(), freeC );
>    auto d = shared_ptr<D>( getD(), freeD );
> 
>    // Do stuff with a,b , and d.
> }


In this sample unique_ptr would be better. 
C++ has a lot of details. If you had put a few lines
more, probably much more advice would be necessary like avoid
unnecessary ref count increment/decrements, loss of const etc etc..

I had to do a very similar sample in C. 
I will not say that C code is simpler than RAII, but
I will show that the code was not too big.

What I did was to create a function that 
initializes everything.

A a;
B b;
C c;
D d;

if (InitAll(&a, &b, &c, &d) == ok)
{
  ReleaseAll(&a, &b, &c, &d);
}

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

#105934

On Monday, March 13, 2017 at 4:01:01 PM UTC-3, Bart wrote:
> On 13/03/2017 18:33, Ian Collins wrote:
> > On 03/13/17 11:36 PM, BartC wrote:
> >> On 13/03/2017 02:43, Ian Collins wrote:
> >>> On 03/13/17 01:11 PM, jacobnavia wrote:
> >>
> >>>> Simplifying is not a luxury, it is necessary. In this time when
> >>>> everyone
> >>>> is going in the wrong direction it would be better to stop and reflect
> >>>> if all that complexity is really necessary.
> >>>
> >>> Indeed, simplicity is one of the cornerstones of agile development. Most
> >>> over complex code I have had the dubious pleasure of maintaining got
> >>> into a mess because successive developers added more functionality
> >>> without taking the time to refactor the code.
> >>
> >> But the same doesn't seem to apply to programming languages themselves?
> >
> > Complexity has to go somewhere.  That somewhere is usually the user's
> > code or the programming language.
> 
> That's not the only option. Sometimes a system grows over time and 
> becomes so complex and with so many ad hoc, bolted-on features that it 
> is better to start afresh. Then the result, based on experience of the 
> old system, really can be smaller, simpler, more reliable, easier to 
> understand and less work to maintain. It might even be faster.
> 
> > A good example is a typical bit of
> > driver code I often encounter or have to write:
> >
> > Get resource A
> > Get resource B
> > Get resource C
> > Get resource D
> 
> > Do something with them.
> >
> > Would you rather see the code written pretty much as above, or have the
> > steps lost in a tangle of ifs, gotos and clean up code?
> 
> A lot of stuff that people say C++ makes simpler, can already be done by 
> any scripting language (even one of mine).
> 
> And it is genuinely simpler and much, much cleaner in appearance; you 
> don't need to try and pick out fragments of the actual code from amongst 
> the punctuation, types and syntax.
> 
> The only problem with such languages is speed. Yet, probably, most of a 
> typical application with a user interface could run at scripting speed 
> without anyone noticing.
> 

C++ 11 - C++ 17 added more concepts to simplicity the syntax.
You have a simplified syntax, for instance, auto, for loops,
more deduction for lambdas, initializes etc.
You don't need to understand all the details, except when you got 
an template error or if by mistake you do a wrong code.
So, the language after C++ 11 is much more complicated! 
It's so complicated that I don't know a person that can answer
questions correctly , even the creators of each area.

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

#105882

Thanks for the historical review. I did not know all those details, 
specially the meetings between gcc and AMD.

jacob

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

#105757

Thiago Adams <thiago.adams@gmail.com> wrote:
> Is it possible to create a var args function without the 
> first argument? (firstArgument in va_start)

No. You are passing an unspecified number of arguments of
unspecified types, and without the first argument the
callee has no way of finding out how man arguments it
received and what their types are. And if can'r do that
it all makes no sense.

> void F(...)
> {
>   va_list vl;
>   va_start(vl,firstArgument);

>   int i1 =va_arg(vl,int);
>   int i2 =va_arg(vl,int);

>   va_end(vl);
> }

> int main ()
> {
>   F(1, 2);
>   return 0;
> }

If you always call it with two int arguments you can as well
make F() accept only those two arguments and stop messing
around with va_arg and friends.

                           Regards, Jensa
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

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

#105772

On Friday, March 10, 2017 at 5:49:42 PM UTC-3, Jens Thoms Toerring wrote:
> Thiago Adams  wrote:
> > Is it possible to create a var args function without the 
> > first argument? (firstArgument in va_start)
> 
> No. You are passing an unspecified number of arguments of
> unspecified types, and without the first argument the
> callee has no way of finding out how man arguments it
> received and what their types are. And if can'r do that
> it all makes no sense.

In this sample i know that I am passing 2 ints.

void F(...) 
{ 
  va_list vl; 
  va_start(vl,firstArgument); 

  int i1 =va_arg(vl,int); 
  int i2 =va_arg(vl,int); 

  va_end(vl); 
} 

int main () 
{ 
  F(1, 2); 
  return 0; 
} 

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

#105777

On Friday, March 10, 2017 at 4:41:11 PM UTC-6, Thiago Adams wrote:
> On Friday, March 10, 2017 at 5:49:42 PM UTC-3, Jens Thoms Toerring wrote:
> > Thiago Adams  wrote:
> > > Is it possible to create a var args function without the 
> > > first argument? (firstArgument in va_start)
> > 
> > No. You are passing an unspecified number of arguments of
> > unspecified types, and without the first argument the
> > callee has no way of finding out how man arguments it
> > received and what their types are. And if can'r do that
> > it all makes no sense.
> 
> In this sample i know that I am passing 2 ints.
> 

*How* do you know that?  How is that information passed to F?  How does F
know how many arguments were passed to it?  Or what the types of those
arguments are?  

> void F(...) 
> { 
>   va_list vl; 
>   va_start(vl,firstArgument); 
> 
>   int i1 =va_arg(vl,int); 
>   int i2 =va_arg(vl,int); 
> 
>   va_end(vl); 
> } 
> 
> int main () 
> { 
>   F(1, 2); 
>   return 0; 
> }

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

#105824

Le 11/03/2017 à 01:05, John Bode a écrit :
> *How* do you know that?  How is that information passed to F?  How does F
> know how many arguments were passed to it?  Or what the types of those
> arguments are?

Impossible without passing at least one argument with that information...

I can't really understand this.

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

#105827

On Saturday, March 11, 2017 at 2:47:57 PM UTC-6, jacob navia wrote:
> Le 11/03/2017 à 01:05, John Bode a écrit :
> > *How* do you know that?  How is that information passed to F?  How does F
> > know how many arguments were passed to it?  Or what the types of those
> > arguments are?
> 
> Impossible without passing at least one argument with that information...
> 
> I can't really understand this.

On many C compilers in the days before the Standard, it would be possible
to have a variadic function with zero fixed argument, which used a global
or static variable to select what kind of argument to fetch first; it
could fetch additional arguments using information held elsewhere in global
storage or in the first argument.

Requiring the existence of at least one fixed argument was a semantic
restriction, but not a huge one, and it may allow stdarg.h to be implemented
entirely in macros without the compiler itself needing to include any special
support for it.

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

#105831

Le 11/03/2017 à 22:07, supercat@casperkitty.com a écrit :

>
> On many C compilers in the days before the Standard, it would be possible
> to have a variadic function with zero fixed argument, which used a global
> or static variable to select what kind of argument to fetch first; it
> could fetch additional arguments using information held elsewhere in global
> storage or in the first argument.
>

But then you are using implicit arguments, what should be avoided since 
they are... invisible. Not very clear.

> Requiring the existence of at least one fixed argument was a semantic
> restriction, but not a huge one, and it may allow stdarg.h to be implemented
> entirely in macros without the compiler itself needing to include any special
> support for it.
>

Again:

How is the information passed to the function without an explicit first 
argument?

Yes you could access the global "whatever", but in that case it is an 
argument (INPUT) to that function and should be named explicitely at the 
call point to make reading the code easier!

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

#105906

On Saturday, March 11, 2017 at 6:24:20 PM UTC-3, jacobnavia wrote:

> How is the information passed to the function without an explicit first 
> argument?

I sent 2 to ints to function F. How do I know? (Because I sent)
There is just one F called by just one caller that sends 2 ints.
The problem is statically determined. 

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

#105907

On 3/13/2017 8:44 AM, Thiago Adams wrote:
> On Saturday, March 11, 2017 at 6:24:20 PM UTC-3, jacobnavia wrote:
> 
>> How is the information passed to the function without an explicit first 
>> argument?
> 
> I sent 2 to ints to function F. How do I know? (Because I sent)
> There is just one F called by just one caller that sends 2 ints.
> The problem is statically determined. 
> 

So if F is called by just one caller that sends two ints, why do you
need va_start?  Just define F to take two ints.

But you misunderstand his questions.  How does F know it was called with
2 ints?  How does it know it wasn't called from another place with a
char * and three doubles?

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

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

#105909

On Monday, March 13, 2017 at 9:59:10 AM UTC-3, Jerry Stuckle wrote:
> On 3/13/2017 8:44 AM, Thiago Adams wrote:
> > On Saturday, March 11, 2017 at 6:24:20 PM UTC-3, jacobnavia wrote:
> > 
> >> How is the information passed to the function without an explicit first 
> >> argument?
> > 
> > I sent 2 to ints to function F. How do I know? (Because I sent)
> > There is just one F called by just one caller that sends 2 ints.
> > The problem is statically determined. 
> > 
> 
> So if F is called by just one caller that sends two ints, why do you
> need va_start?  Just define F to take two ints.

See the motivation in the sample.

> 
> But you misunderstand his questions.  How does F know it was called with
> 2 ints?  How does it know it wasn't called from another place with a
> char * and three doubles?

This is the answer:

void F(void (*Callback)(va_list*), va_list args) 
{ 
  //do something 
  Callback(args); 
} 


int main() 
{ 
   F(void (*)(va_list args) 
   { 
      int i1 = va_arg(args, int); 
      int i2 = va_arg(args, int); 

      va_list_free(args); 
   }, va_list_malloc(1, 2)); 
} 

But in current C, the answer would be: 
Because I sent 2 ints, I have a static function F and I 
call it just in one place passing 2 ints in that translation unit.
The problem is statically determined.

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

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

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

csiph-web