Tuesday, February 16, 2016

Digest for comp.lang.c++@googlegroups.com - 7 updates in 4 topics

Christopher Pisz <nospam@notanaddress.com>: Feb 16 04:39PM -0600

On 2/14/2016 11:01 AM, alexo wrote:
> C/C++ program using TCP/IP o SMTP for both linux and windows.
 
> thank you
 
> alexo
 
 
If you want to do it the old school way then you learn how to program
sockets and then you learn the protocol you want to use. In this case SMTP.
 
In linux, you would use Berkely Sockets.
In Windows, you would use Winsock.
 
Both have a plethora of tutorials and books that all go through the same
thing.
 
The guide I used some decades ago:
http://beej.us/guide/bgnet/output/html/multipage/index.html
 
If you want something more modern, after you learn how they actually
work, then you would use boost::asio or some 3rd party library.
boost::asio is much easier to understand after you know what you are
doing with Berkley sockets.
 
After you can program sockets sufficiently, you would just google up the
RFC for whatever protocol you want to use. In this case SMTP:
 
http://www.rfc-base.org/txt/rfc-2821.txt
 
But, again, with something as popular as SMTP, someone else has probably
already created a library that will save you the hassle of learning
every significant detail.
 
 
 
 
--
I have chosen to troll filter/ignore all subthreads containing the
words: "Rick C. Hodgins", "Flibble", and "Islam"
So, I won't be able to see or respond to any such messages
---
legalize+jeeves@mail.xmission.com (Richard): Feb 16 08:13PM

[Please do not mail me a copy of your followup]
 
Paavo Helde <myfirstname@osa.pri.ee> spake the secret code
>must have some idea what to write, i.e. there must be some design,
>either written down or at least in the head in case of purist
>test-driven-design people (which I do not really advocate).
 
Meh. I've done it both ways: start with a design and flesh it out, or
start with no idea what the design is supposed to be and grow the
design incrementally.
 
In the latter scenario, TDD is a way of exploring the design space and
not just a way to implement a design.
 
>Anyway, the TDD work cycle is meant so that you implement your design
>step-by-step,
 
This is starting to sound like waterfall:
 
1. design something
2. implement something
3. test something
4. ship something
 
In waterfall, design is treated as a phase. In TDD, design is a
continuous activity. I'm doing design every time my tests are green
and I refactor. Does that mean I don't think about things up front?
Of course not. Does it mean that I design every member function and
all the types and all their arguments up front? Of course not.
 
When I say that I've done TDD with no design up front, it's because
literally I didn't know what the design would be and I just sat down
to write the first test from the perspective of: "If I had a perfect
API that did exactly what I want to do, what would it look like?"
This is a design question. It is a design question stated as a
failing unit test. The answer to the question is the implementation
that makes the test pass.
 
>The granularity of the cycle depends on the speed of project rebuild.
 
I agree that this is a problem with C++ code bases. Rebuild times can
be quite expensive. However, my experience with doing TDD for almost
10 years has been that build cycles are shorter with TDD from the time
I type some code to the time I get an answer, than they are with
traditional edit-compile-link-manually test cycles in C++.
 
Modules should help this situation drastically, so I am really excited
to see modules moving forward with some hope for delivery in C++17.
 
>The hard-core TDD advocates talk about rebuild times in seconds.
 
Actually they talk about rebuild times in milliseconds :-). You get
really spoiled with things like NUnit/C# where the stuff is running
your tests continuously as you edit.
 
So far my TDD cycles haven't gotten longer than a handfull of seconds.
 
A couple years ago, a coworker and I decided to try the "C++ Grand
Master" challenge thingy that was going around at the time. I was
working on an early assignment where it was doing some of the first
phases of preprocessor tokenization. I tweeted every time I wrote a
failing test (red), passing test (green) or refactored my code
(refactor). On average, the red/green/refactor cycle was under a
minute and many times it was 30 seconds or less. That's a powerful
psychological motivator that comes with TDD. Every 30 seconds I had
proof my code was getting better.
--
"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>
Paavo Helde <myfirstname@osa.pri.ee>: Feb 16 10:51PM +0200

On 16.02.2016 22:13, Richard wrote:
 
>> Anyway, the TDD work cycle is meant so that you implement your design
>> step-by-step,
 
> This is starting to sound like waterfall:
 
For some people "agile" means a 2-week waterfall. And I believe it's
still bad (or worse) in 2 weeks as opposed to 2 years. No, I'm not
advocating waterfall. I hoped that using the word *some* repeatedly
would make that clear:
 
> API that did exactly what I want to do, what would it look like?"
> This is a design question. It is a design question stated as a
> failing unit test.
 
Here, the interface of the API call was that *some* initial design.
 
Cheers
Paavo
legalize+jeeves@mail.xmission.com (Richard): Feb 16 09:19PM

[Please do not mail me a copy of your followup]
 
Paavo Helde <myfirstname@osa.pri.ee> spake the secret code
 
>On 15.02.2016 22:31, Wouter van Ooijen wrote:
>> *any* methodology that forbids people to sit back and think sucks.
 
Straw man alert!
 
>I'm pretty sure TDD does not forbid thinking.
 
I'm more than pretty sure. I'm 100% sure.
--
"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>
legalize+jeeves@mail.xmission.com (Richard): Feb 16 09:22PM

[Please do not mail me a copy of your followup]
 
Ian Collins <ian-news@hotmail.com> spake the secret code
 
>> My usual answer to that problem is "throw more hardware it"! My trip
>> point for a hardware boost is usually around 30 for a full build...
 
>.. 30 seconds ..
 
30 seconds between strting to write a failing test, making the test
pass and complete any refactoring.
 
It wasn't 30 seconds waiting for a compile. That 30 seconds includes
everything: "thinking time", the time to type the code, the time to
compile the test and watch it fail, the time to edit the code to make
the test pass, the time to recompile the code again and watch it pass,
the time to refactor the implementation as needed.
--
"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>
"K. Frank" <kfrank29.c@gmail.com>: Feb 16 01:18PM -0800

Hello All!
 
Thanks to everyone for their follow-up comments.
 
On Tuesday, February 16, 2016 at 2:26:12 PM UTC-5, Öö Tiib wrote:
> ...
> CWindowImpl: https://msdn.microsoft.com/en-us/library/h4616bh2.aspx
> IOleControlImpl: https://msdn.microsoft.com/en-us/library/a2w18t1x.aspx
 
This is all very helpful.
 
 
Thanks again.
 
 
K. Frank
ram@zedat.fu-berlin.de (Stefan Ram): Feb 16 02:15AM

I showed this example in my C++ course:
 
#include <iostream>
#include <ostream>
#include <cctype>
#include <string>
 
using namespace ::std::literals;
 
int main(){ ::std::cout << ::std::isalpha( 64.9 )<< "\n"s; }
 
and one student complained that C++ was not very »type-safe«.
 
So, can we make a more »type-safe« »isalpha«?
 
What would you think about a C++ where functions can be
called as follows:
 
int main(){ ::std::cout << ::std::isalpha{ 64.9 }<< "\n"s; }
 
meaning that no narrowing is allowed? (As long as this is
not used for declarations, it does not re-introduce the
most vexing parse.)
 
Here is my first quick attempt to achieve this with today's C++:
 
#include <iostream>
#include <ostream>
#include <cctype>
#include <string>
#include <initializer_list>
 
using namespace ::std::literals;
 
struct is_alpha
{ int result;
is_alpha( ::std::initializer_list< int >arguments ):
result( ::std::isalpha( *::std::cbegin( arguments ))) {}
operator int(){ return this->result; } };
 
int main(){ ::std::cout << is_alpha{ 64 }<< "\n"s; }
 
Ok, now it will complain on »64.9«, but not on »64,9«!
 
Can you improve my first attempt, so that we have a
call syntax in the form
 
»is_alpha« leftparen int-expression rightparen
 
where the compiler complains when there is anything
else than an int-expression between the parens
(which could be »()«, »{}«, »[]«, or »<>«) and the
semantics are those of »::std::isalpha«?
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)