Sunday, May 17, 2015

Digest for comp.lang.c++@googlegroups.com - 15 updates in 5 topics

Jorgen Grahn <grahn+nntp@snipabacken.se>: May 17 12:05PM

On Fri, 2015-05-15, Stefan Ram wrote:
 
> (This approach might not be suitable when there are very
> many such if-branches or the request syntax changes very
> often at runtime.)
 
Yeah. The problem, as stated, really boils down to the
old "execute a command, specified in a certain input language".
Nothing special about it -- and unless that language changes a lot, I
find it best to just suck it up and do it the boring if ... else if
... way described above. Overengineering this problem doesn't pay
off.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
legalize+jeeves@mail.xmission.com (Richard): May 17 05:38PM

[Please do not mail me a copy of your followup]
 
Jorgen Grahn <grahn+nntp@snipabacken.se> spake the secret code
>find it best to just suck it up and do it the boring if ... else if
>... way described above. Overengineering this problem doesn't pay
>off.
 
Parsing is one of those things that is so easy to unit test that there
really isn't any excuse for not unit testing it.
 
If you put tests around it, you can do the regex match style above until
it becomes burdensome and then switch to some kind of more formal parser
and your tests will ensure that everything is still working.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
Chicken Mcnuggets <chicken@mcnuggets.com>: May 18 12:11AM +0100

On 17/05/15 18:38, Richard wrote:
 
> If you put tests around it, you can do the regex match style above until
> it becomes burdensome and then switch to some kind of more formal parser
> and your tests will ensure that everything is still working.
 
Sorry folks. Been busy the last day or two so haven't been able to reply.
 
I think I explained the problem rather poorly in my original post. Let
me try and explain better.
 
If the request was coming directly into the framework and the framework
could provide the regex and the member function that should be called
this would be a non-issue and it would be easy to solve as described
above. But that is not the case.
 
The request actually comes into the framework via an SCGI protocol
handling class but the regex and the class containing the member
function which renders the HTML for the response is provided by the
user. I have no control over this (other than specifying conventions in
documentation of course).
 
So the problem is this:
 
HTTP Request -> HTTP Server -> SCGI Request - C++ Web Framework -> User
provided C++ code to match request to a regex and then call a member
function -> User provided C++ member function -> C++ Web Framework ->
SCGI Response -> HTTP Server -> HTTP Response
 
The only code I have control over is the C++ web framework. Somehow I
need to allow a user to extend the framework with a set of code that
will allow requests to be routed to a class which contains a member
function that renders HTML as a response (for those who know MVC this is
the view class).
 
I've been basing my design off the Django web framework which is written
in Python since I already know that but I'm having a hard time
converting things which make heavy use of Python's dynamism into the
more static C++ world.
 
For reference this is how Django deals with URLs:
 
https://docs.djangoproject.com/en/1.8/topics/http/urls/
 
and this is what I was roughly hoping to emulate. The URL regex and the
views are provided by the user and the framework provides the code to
link the two together.
 
So it is not as simple as a if / else if / else branch since the
framework doesn't know ahead of time what is being provided by the user.
 
Hopefully that has explained things a little bit better.
udtelco@gmail.com: May 17 11:32AM -0700

Hope everyone for a nice weekend,
 
Defining programmers as those who authored any amount of C++ code that made it into production environment -
If you could add one thing - anything at all - to the core language or the new standard, what would it be ?
And in a same way, but trickier, what if anything would you like to see removed ? (in a sense of not just not having to use a feature or a paradigm, but also not having to deal with it or consider it's use by others)
 
Thanks
Wouter van Ooijen <wouter@voti.nl>: May 17 09:07PM +0200

> If you could add one thing - anything at all - to the core language or the new standard, what would it be ?
> And in a same way, but trickier, what if anything would you like to see removed ? (in a sense of not just not having to use a feature or a paradigm, but also not having to deal with it or consider it's use by others)
 
> Thanks
 
add:
- in general: make the language & libraries more usable in a small
system, that is: without heap, RTTI, exceptions
- make all constexpr values acceptable as template arguments
- named parameter association
- 'override' also for static methods
- (compiler option) issue a warning for a missing override
 
remove:
The problem is that any drastic removal will harm the survival of the
language, so for that reason I would not remove anything. If that was
not an issue:
- most automatic (invisible) conversions
- the declare-as-you-would-use-it style of syntax
- goto, labels (except for a switch), fallthrough in a switch
- char being a kind of integer
 
Wouter
Jorgen Grahn <grahn+nntp@snipabacken.se>: May 17 07:57PM


> And in a same way, but trickier, what if anything would you like to
> see removed ? (in a sense of not just not having to use a feature or a
> paradigm
 
Nothing, and nothing. I'm fairly pleased with C++ as it is, and leave
improvements to others. It didn't occur to me, for example, that
'auto' could be used as in C++11, even though I was familiar with type
inference from other languages.
 
> but also not having to deal with it or consider it's use by
> others)
 
There are lots of features I think are overused (arrays and stuff from
C-style programmers, new/delete from Java programmers, deep
inheritance hierarchies from OOP people, ...) but they all have
important uses and it wouldn't be C++ without them.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
"Öö Tiib" <ootiib@hot.ee>: May 17 01:57PM -0700

> made it into production environment -
> If you could add one thing - anything at all - to the core language or
> the new standard, what would it be ?
 
Most odd for me is that C++ lacks a type for representing "UTF-8
code unit". 'char' does not work as it means "a byte" in C++ and
so a pointer to it means a pointer to some memory.
 
> see removed ? (in a sense of not just not having to use a feature
> or a paradigm, but also not having to deal with it or consider it's
> use by others)
 
I would happily remove lot of pointless looseness of it (but that may
mean actually adding to language or changing it). For example:
* Silent conversions between arithmetic types.
* Silent conversions between pointers and bools.
* Implicitly compiler-generated constructors and assignment operators.
* Undefined signed integer overflow.
* Unspecified argument evaluation order.
...
and so on.
udtelco@gmail.com: May 17 01:57PM -0700

Personally, I would like to see some operators that would map to hardware features that are fairly common, yet not so accessible at the time (like bit rotation). Being called a glorified assembler isn't necessarily a bad thing, and gives some street cred to live up to ...
Also, while C++11 tasking and lambdas is a step in the right direction, I find Ada way of handling tasking impressive and C++ could benefit from stuff like task types , select/accept and protected types.
And standardizing symbol mangling would make object code compatible across different compilers.
 
Most coders I know would love to see implicit casting castrated. Their complaint usually lays with "other people's code", since "themselves" are disciplined enough, and compiler can be set up to its strictest to catch the most hidden conversions.
"Öö Tiib" <ootiib@hot.ee>: May 17 02:10PM -0700

On Monday, 18 May 2015 00:02:50 UTC+3, Stefan Ram wrote:
> >code unit".
 
> The UTF-8 RFC 3629 does not define a term »code unit«.
> What does »code unit« suggest to you?
 
I trust C++ standard does use "code unit" when talking about strings.
"Öö Tiib" <ootiib@hot.ee>: May 17 02:24PM -0700

On Monday, 18 May 2015 00:12:07 UTC+3, Stefan Ram wrote:
 
> Maybe it refers to »encoding unit« or to »code point«?
 
> An encoding unit might be »uint8_t« or »uint_least8_t«,
> a code point »uint_least64_t« or simply »unsigned long«.
 
Unicode code point U+00B0 is degree character ° that is represented
by two 8-bit units in UTF-8: c2 and b0 (in that order). C++ standard
does call those "code units". I want a type that is meant to represent
that "code unit" (and nothing else). Do you understand now?
ram@zedat.fu-berlin.de (Stefan Ram): May 17 08:39PM

>the name of the technique of creating operators by the mechanism: A::operator B()
 
12.3.2 Conversion functions [class.conv.fct]
ram@zedat.fu-berlin.de (Stefan Ram): May 17 09:02PM

>Most odd for me is that C++ lacks a type for representing "UTF-8
>code unit".
 
The UTF-8 RFC 3629 does not define a term »code unit«.
What does »code unit« suggest to you?
ram@zedat.fu-berlin.de (Stefan Ram): May 17 09:11PM

>>code unit".
>The UTF-8 RFC 3629 does not define a term »code unit«.
>What does »code unit« suggest to you?
 
Maybe it refers to »encoding unit« or to »code point«?
 
An encoding unit might be »uint8_t« or »uint_least8_t«,
a code point »uint_least64_t« or simply »unsigned long«.
Paul <pepstein5@gmail.com>: May 17 01:31PM -0700

This code (below) is copied from another website. I'd like to know the name of the technique of creating operators by the mechanism: A::operator B() so that I can research this independently. What is the name of this methodology for creating the member function of struct A?
 
Thank you,
 
Paul
 
#include <iostream>
struct B;
struct A {
operator B();
};
 
struct B {
B() { }
B(A const&) { std::cout << "<direct> "; }
};
 
A::operator B() { std::cout << "<copy> "; return B(); }
 
int main() {
A a;
B b1(a); // 1)
B b2 = a; // 2)
}
woodbrian77@gmail.com: May 17 09:47AM -0700

On Friday, May 15, 2015 at 10:42:33 AM UTC-5, Juha Nieminen wrote:
> > Answer depends on if your question is of academical or of practical nature.
 
> I am making a library that handles binary data on a rather low level,
> and would require different code depending on endianness. However,
 
I have similar situation working with binary data in library code.
I didn't find an approach I liked so I rely on users to read
the documentation and set -DCMW_BIG_ENDIAN if necessary. From
what I can tell, big-endian systems are fading from the landscape.
 
 
Brian
Ebenezer Enterprises
http://webEbenezer.net
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)