discuss@lists.openscad.org

OpenSCAD general discussion Mailing-list

View all threads

printf?

JB
Jordan Brown
Sat, Oct 3, 2020 10:46 PM

On 10/3/2020 12:46 PM, Torsten Paul wrote:

Implementation wise c++20 is still far out of reach, but the spec is
based on the (even more flexible) fmt library which, I believe, is
c++14 compatible. This makes the lib easily usable with OpenSCAD until
a switch to c++20 is possible.

I'm an old-school C guy and can only barely spell C++, but based on
experience with printf my guess is that the C/C++ library won't really
help implement a printf-style function like this in your own language. 
The problem is in data types and argument passing - somehow you have to
take the arguments and data types from your language and massage them
into being in the form that the underlying C/C++ library wants.  For C
and printf it just isn't possible; there's no way to dynamically
generate the call-style argument list that printf and its friends want.

Maybe the C++ function is more flexible - maybe it can take some kind of
multi-type array as its argument list - but I wouldn't be too optimistic.

Thankfully, writing a traditional printf is not very hard, and I expect
that this one is not much harder.

On 10/3/2020 12:46 PM, Torsten Paul wrote: > Implementation wise c++20 is still far out of reach, but the spec is > based on the (even more flexible) fmt library which, I believe, is > c++14 compatible. This makes the lib easily usable with OpenSCAD until > a switch to c++20 is possible. I'm an old-school C guy and can only barely spell C++, but based on experience with printf my guess is that the C/C++ library won't really help implement a printf-style function like this in your own language.  The problem is in data types and argument passing - somehow you have to take the arguments and data types from your language and massage them into being in the form that the underlying C/C++ library wants.  For C and printf it just isn't possible; there's no way to dynamically generate the call-style argument list that printf and its friends want. Maybe the C++ function is more flexible - maybe it can take some kind of multi-type array as its argument list - but I wouldn't be too optimistic. Thankfully, writing a traditional printf is not very hard, and I expect that this one is not much harder.
NH
nop head
Sat, Oct 3, 2020 10:52 PM

That has always been the case, even in C. The solution was vprintf, which
takes a structure holding the arguments instead of a variable number of
arguments.

On Sat, 3 Oct 2020 at 23:47, Jordan Brown openscad@jordan.maileater.net
wrote:

On 10/3/2020 12:46 PM, Torsten Paul wrote:

Implementation wise c++20 is still far out of reach, but the spec is based
on the (even more flexible) fmt library which, I believe, is c++14
compatible. This makes the lib easily usable with OpenSCAD until a switch
to c++20 is possible.

I'm an old-school C guy and can only barely spell C++, but based on
experience with printf my guess is that the C/C++ library won't really help
implement a printf-style function like this in your own language.  The
problem is in data types and argument passing - somehow you have to take
the arguments and data types from your language and massage them into being
in the form that the underlying C/C++ library wants.  For C and printf it
just isn't possible; there's no way to dynamically generate the call-style
argument list that printf and its friends want.

Maybe the C++ function is more flexible - maybe it can take some kind of
multi-type array as its argument list - but I wouldn't be too optimistic.

Thankfully, writing a traditional printf is not very hard, and I expect
that this one is not much harder.


OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

That has always been the case, even in C. The solution was vprintf, which takes a structure holding the arguments instead of a variable number of arguments. On Sat, 3 Oct 2020 at 23:47, Jordan Brown <openscad@jordan.maileater.net> wrote: > On 10/3/2020 12:46 PM, Torsten Paul wrote: > > Implementation wise c++20 is still far out of reach, but the spec is based > on the (even more flexible) fmt library which, I believe, is c++14 > compatible. This makes the lib easily usable with OpenSCAD until a switch > to c++20 is possible. > > > I'm an old-school C guy and can only barely spell C++, but based on > experience with printf my guess is that the C/C++ library won't really help > implement a printf-style function like this in your own language. The > problem is in data types and argument passing - somehow you have to take > the arguments and data types from your language and massage them into being > in the form that the underlying C/C++ library wants. For C and printf it > just isn't possible; there's no way to dynamically generate the call-style > argument list that printf and its friends want. > > Maybe the C++ function is more flexible - maybe it can take some kind of > multi-type array as its argument list - but I wouldn't be too optimistic. > > Thankfully, writing a traditional printf is not very hard, and I expect > that this one is not much harder. > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >
TP
Torsten Paul
Sat, Oct 3, 2020 11:25 PM

On 04.10.20 00:46, Jordan Brown wrote:

Maybe the C++ function is more flexible - maybe it can take
some kind of multi-type array as its argument list - but I> wouldn't be too optimistic.

It's C++, it can handle custom data types quite well and
the library defines a dedicated interface to both parse
custom format specifiers and the actual formatting of
user defined data types.

Example: https://godbolt.org/z/nsdcTY

I have not tried with something more complicated like
the nested vectors, but it's not comparable to the printf
way of doing things at all.

ciao,
Torsten.

On 04.10.20 00:46, Jordan Brown wrote: > Maybe the C++ function is more flexible - maybe it can take > some kind of multi-type array as its argument list - but I> wouldn't be too optimistic. It's C++, it can handle custom data types quite well and the library defines a dedicated interface to both parse custom format specifiers and the actual formatting of user defined data types. Example: https://godbolt.org/z/nsdcTY I have not tried with something more complicated like the nested vectors, but it's not comparable to the printf way of doing things at all. ciao, Torsten.
JB
Jordan Brown
Sun, Oct 4, 2020 5:41 AM

[ Oops, sent the first time as a private message. ]

On 10/3/2020 4:25 PM, Torsten Paul wrote:

It's C++, it can handle custom data types quite well and the library
defines a dedicated interface to both parse custom format specifiers
and the actual formatting of user defined data types.

Indeed, it looks like it probably can handle it from a data type
perspective.

And make_format_args and friends look like they provide a way to
dynamically create an argument list, which is one of the big things that
C lacks.

Cool.

Apologies for not checking it out first.

I have not tried with something more complicated like
the nested vectors, but it's not comparable to the printf
way of doing things at all.

I don't know that it needs to handle those.  Handling those would
involve making decisions about how to format them, and the whole idea is
to give formatting control to the OpenSCAD program.  You can always
str() them if you just want OpenSCAD to format them.

[ Oops, sent the first time as a private message. ] On 10/3/2020 4:25 PM, Torsten Paul wrote: > It's C++, it can handle custom data types quite well and the library > defines a dedicated interface to both parse custom format specifiers > and the actual formatting of user defined data types. Indeed, it looks like it probably can handle it from a data type perspective. And make_format_args and friends look like they provide a way to dynamically create an argument list, which is one of the big things that C lacks. Cool. Apologies for not checking it out first. > I have not tried with something more complicated like > the nested vectors, but it's not comparable to the printf > way of doing things at all. I don't know that it needs to handle those.  Handling those would involve making decisions about how to format them, and the whole idea is to give formatting control to the OpenSCAD program.  You can always str() them if you just want OpenSCAD to format them.