January 10, 2015
On Friday, 9 January 2015 at 17:15:43 UTC, Adam D. Ruppe wrote:
> import arsd.dom;
> import std.net.curl;
> import std.stdio, std.algorithm;
>
> void main() {
> 	auto document = new Document(cast(string) get("http://www.stroustrup.com/C++.html"));
> 	writeln(document.querySelectorAll("a[href]").map!(a=>a.href));
> }
>
> Or perhaps better yet:
>
> import arsd.dom;
> import std.net.curl;
> import std.stdio;
>
> void main() {
> 	auto document = new Document(cast(string) get("http://www.stroustrup.com/C++.html"));
> 	foreach(a; document.querySelectorAll("a[href]"))
> 		writeln(a.href);
> }
>
> Which puts each one on a separate line.

Both these code examples triggers the same assert()

dmd: expression.c:3761: size_t StringExp::length(int): Assertion `encSize == 1 || encSize == 2 || encSize == 4' failed.

on dmd git master. Ideas anyone?
January 10, 2015
On Saturday, 10 January 2015 at 13:22:57 UTC, Nordlöw wrote:
> on dmd git master. Ideas anyone?

Don't use git master :P

Definitely another regression. That line was just pushed to git like two weeks ago and the failing assertion is pretty obviously a pure dmd code bug, it doesn't know the length of char apparently.
January 10, 2015
On Saturday, 10 January 2015 at 12:34:42 UTC, Tobias Pankrath wrote:
> Since it is a comparison of languages it's okay to match the original behaviour.

I don't think this is really a great comparison of languages either though because it is gluing together a couple library tasks. Only a few bits about the actual language are showing through.


In the given regex solutions, C++ has an advantage over C wherein the regex structure can be freed automatically in a destructor and a raw string literal in here, but that's about all from the language itself. The original one is kinda long because he didn't use a http get library, not because the language couldn't do one.

There are bits where the language can make those libraries nicer too: dom.d uses operator overloading and opDispatch to support things like .attribute and also .attr.X and .style.foo and element["selector"].addClass("foo") and so on implemented in very very little code - I didn't have to manually list methods for the collection or properties for the attributes - ...but a library *could* do it that way and get similar results for the end user; the given posts wouldn't show that.
January 10, 2015
Adam D. Ruppe:

> Don't use git master :P

Is the issue in Bugzilla?

Bye,
bearophile
January 10, 2015
On Saturday, 10 January 2015 at 15:24:45 UTC, bearophile wrote:
> Is the issue in Bugzilla?

I don't know, bugzilla is extremely difficult to search.

I guess I'll post it again and worst case it will be closed as a duplicate.
January 10, 2015
On Saturday, 10 January 2015 at 15:24:45 UTC, bearophile wrote:
> Is the issue in Bugzilla?


https://issues.dlang.org/show_bug.cgi?id=13966
January 10, 2015
Vladimir Panteleev via Digitalmars-d-learn píše v So 10. 01. 2015 v 07:42 +0000:
> On Saturday, 10 January 2015 at 02:10:04 UTC, Jesse Phillips wrote:
> > On Friday, 9 January 2015 at 13:50:29 UTC, eles wrote:
> >> https://codegolf.stackexchange.com/questions/44278/debunking-stroustrups-debunking-of-the-myth-c-is-for-large-complicated-pro
> >
> > Link to answer in D: http://codegolf.stackexchange.com/a/44417/13362
> 
> I think byLine is not necessary. By default . will not match line breaks.
> 
> One statement solution:
> 
> import std.net.curl, std.stdio;
> import std.algorithm, std.regex;
> 
> void main() {
> 	get("http://www.stroustrup.com/C++.html")
> 	    .matchAll(`<a.*?href="(.*)"`)
> 	    .map!(m => m[1])
> 	    .each!writeln();
> }
> 
> Requires Phobos PR#2024 ;)
Oh here is it, I was looking for each. I think it is allready in a phobos but I can not find. Now I know why :D

January 10, 2015
On Saturday, 10 January 2015 at 15:13:27 UTC, Adam D. Ruppe wrote:
> On Saturday, 10 January 2015 at 12:34:42 UTC, Tobias Pankrath wrote:
>> Since it is a comparison of languages it's okay to match the original behaviour.
>
> I don't think this is really a great comparison of languages either though because it is gluing together a couple library tasks. Only a few bits about the actual language are showing through.
>
>
> In the given regex solutions, C++ has an advantage over C wherein the regex structure can be freed automatically in a destructor and a raw string literal in here, but that's about all from the language itself. The original one is kinda long because he didn't use a http get library, not because the language couldn't do one.
>
> There are bits where the language can make those libraries nicer too: dom.d uses operator overloading and opDispatch to support things like .attribute and also .attr.X and .style.foo and element["selector"].addClass("foo") and so on implemented in very very little code - I didn't have to manually list methods for the collection or properties for the attributes - ...but a library *could* do it that way and get similar results for the end user; the given posts wouldn't show that.

I agree and one of the answers says:

> I think the "no third-party" assumption is a fallacy. And is a specific fallacy that afflicts C++ developers, since it's so hard to make reusable code in C++. When you are developing anything at all, even if it's a small script, you will always make use of whatever pieces of reusable code are available to you.

> The thing is, in languages like Perl, Python, Ruby (to name a few), reusing
> someone else's code is not only easy, but it is how most people actually write code most of the time.

I think he's wrong, because it spoils the comparison. Every answer should delegate those tasks to a library that Stroustroup used as well, e.g. regex matching, string to number conversion and some kind of TCP sockets. But it must do the same work that he's solution does: Create and parse HTML header and extract the html links, probably using regex, but I wouldn't mind another solution.

Everyone can put a libdo_the_stroustroup_thing on dub and then call do_the_stroustroup_thing() in main. To compare what the standard libraries (and libraries easily obtained or quasi standard) offer is another challenge.

January 10, 2015
On Saturday, 10 January 2015 at 15:52:21 UTC, Tobias Pankrath wrote:
> But it must do the same work that he's solution does: Create and parse HTML header and extract the html links, probably using regex, but I wouldn't mind another solution.

Yeah, that would be best. BTW interesting line here:

   s << "GET " << "http://" + server + "/" + file << " HTTP/1.0\r\n";
    s << "Host: " << server << "\r\n";

Why + instead of <<? C++'s usage of << is totally blargh to me anyway, but seeing both is even stranger.

Weird language, weird library.

> Everyone can put a libdo_the_stroustroup_thing on dub and then call do_the_stroustroup_thing() in main. To compare what the standard libraries (and libraries easily obtained or quasi standard) offer is another challenge.

Yeah.
January 10, 2015
On Saturday, 10 January 2015 at 15:52:21 UTC, Tobias Pankrath wrote:
> ...
>
>> The thing is, in languages like Perl, Python, Ruby (to name a few), reusing
>> someone else's code is not only easy, but it is how most people actually write code most of the time.
>
> I think he's wrong, because it spoils the comparison. Every answer should delegate those tasks to a library that Stroustroup used as well, e.g. regex matching, string to number conversion and some kind of TCP sockets. But it must do the same work that he's solution does: Create and parse HTML header and extract the html links, probably using regex, but I wouldn't mind another solution.
>
> Everyone can put a libdo_the_stroustroup_thing on dub and then call do_the_stroustroup_thing() in main. To compare what the standard libraries (and libraries easily obtained or quasi standard) offer is another challenge.

I disagree.

The great thing about comes with batteries runtimes is that I have the guarantee the desired features exist in all platforms supported by the language.

If the libraries are dumped into a repository, there is always a problem if the library works across all OS supported by the language or even if they work together at all. Specially if they depend on common packages with incompatible versions.

This is the cause of so many string and vector types across all C++ libraries as most of those libraries were developed before C++98 was even done.

Or why C runtime isn't nothing more than a light version of UNIX as it was back in 1989, without any worthwhile feature since then, besides some extra support for numeric types and a little more secure libraries.

Nowadays, unless I am doing something very OS specific, I hardly care which OS I am using, thanks to such "comes with batteries" runtimes.


--
Paulo