Re: Example of Windows SSL with Secure Channel?
On Saturday, 19 March 2022 at 16:54:03 UTC, Anonymouse wrote: Does anyone have an example snippet code connecting to, reading from and writing to a server using SSL under Windows with Secure Channel? Something in a personal project you wouldn't mind sharing a part of to let me dissect? https://www.amazon.com/Programming-Server-Side-Applications-Microsoft-Windows/dp/0735607532 You can download example for it: SslChat
Re: Nested Classes with inheritance
On Sunday, 20 March 2022 at 05:44:44 UTC, Salih Dincer wrote:
On Sunday, 20 March 2022 at 01:28:44 UTC, Era Scarecrow wrote:
Inheritance and Polymorphism is one of the hardest things to
grasp mostly because examples they give in other books of
'objects' is so far unrelated to software that it doesn't
really compare.
You are right, difficult model yet so abeyant. Moreover, there
is a lot of freedom given in D. I think OOP alone is not worth
5 cents without design patterns.
OOP can be aggressive like a dog. I think D should be a little
more rigid on OOP.
Actually one good example for Objects is a game, specifically
Magic The Gathering.
MTG is a card game, of that everyone knows. But there's so many
effects. When it comes into play, when it goes to the graveyard,
if it gets exiled, cost to cast it from the gaveyard/exile,
tapping, untapping, paying and tapping to do an ability, milling
cards, drawing cards, scrying cards, attacking without untapping,
deathtouch, islandwalk. Then there's enchantments, equipment,
passive always active abilities (*all your creatures get +0/+1*)
and a myriad of other things.
Now with that out of the way making a base 'card' with all it's
actions as a mere interface and then making each card
individually OR inheriting from a base card using polymorphism
would be a great way to do things.
Going the one route
```d
abstract class Card {
string name, description, picture, quote;
string types; //Green Insect Token, Indestructable, etc
int basePower, baseToughness;
Card[] enchantments; //affecting this card specifically
static Card[] globalEnchantments, //affecting all cards
playerEnchantments; //affecting only my own cards
//When a card leaves play remove from enchantments list.
//globals will just remove from the static list
void purgeCard(Card target);
//calculate power
int power() {
int t;
foreach(x; enchantments) {t += x.basePower;}
foreach(x; globalEnchantments) {t += x.basePower;}
foreach(x; playerEnchantments) {t += x.basePower;}
return t;
}
int toughness();
//etc for a base class with expected functional hooks for
combat, instants etc.
}
class Wurm : Card {
this() {
name = "Greater Wurm";
quote = "When the Wurm comes, all flee it's destruction";
basePower = 3;
baseToughness = 3;
}
//no tap or other abilities, left blank
}
class Beetle : Card {
Card original;
this(Card target) {
description = "The target card becomes a 0/1 indestructible
beetle";
types="Green,Insect,Indestructible,Enchantment";
//code to swap original and target
}
~this() {//unswap }
override int power(){return 0;}
override int toughness(){return 1;}
}
class Sword : Card {
this() {
name="Soldier's sword";
description = "Enchanted creature gets +2/0";
types="Enchantment,Equipment,Colorless";
basePower = 2;
}
this(Card target) {
target.enchantments ~= this;
}
}
```
Here you have a base card to work with, a monster, enchantment
and an override.
Re: I like dlang but i don't like dub
On 3/20/22 05:27, Adam D Ruppe wrote: > So if it just coincidentally happens to be the same code, I'd actually > rather copy/paste it than import it. This is very interesting because it is so much against common guidelines. I first read about such copy/paste in a book (my guess is John Lakos's Large Scale C++ Software Design book because my next example below is from that book.) The author was saying exactly the same thing: Yes, copy/paste is bad but dependencies are bad as well. I was surprised by John Lakos's decision to use external header guards. In addition to the following common include guard idiom: // This is foo.h #ifndef INCLUDED_FOO_H_ #define INCLUDED_FOO_H_ // ... #endif // INCLUDED_FOO_H_ He would do the same in the including modules as well: // This is bar.c #ifndef INCLUDED_FOO_H_ #include "foo.h" #endif // ... Such a crazy idea and it is completely against the DRY principle! However, according to his measurements on hardware and file systems at that time, he was saving a lot of build time. (File system's reading the file many times to determine that it has already been included was too expensive. Instead, he was determining it from the very include guard macro himself.) Those were the first examples when I started to learn that it was possible to go against common guidelines. I admire people like you and John Lakos who don't follow guidelines blindly. I started to realize the power of engineering very late. Engineering almost by definition should break guidelines. Ali
Re: I like dlang but i don't like dub
On Friday, 18 March 2022 at 18:16:51 UTC, Ali Çehreli wrote:
As a long-time part of the D community, I am ashamed to admit
that I don't use dub. I am ashamed because there is no
particular reason, or my reasons may not be rational.
dub is legitimately awful. I only use it when forced to, and even
making my libs available for others to use through it is quite an
unnecessary hassle due to its bad design.
That sounds great but aren't there common needs of those
modules to share code from common modules?
Some. My policy is:
1) Factor out shared things when I *must*, not just because I can.
So if it just coincidentally happens to be the same code, I'd
actually rather copy/paste it than import it. Having a private
copy can be a hassle - if a bug fix applies to both, I need to
copy/paste it again - but it also has two major benefits: it
keeps the build simple and it keeps the private implementation
actually private. This means I'm not tempted to complicate the
interface to support two slightly different use cases if the need
arises; I have the freedom to edit it to customize for one use
without worrying about breaking it for another.
When I must factor out it is usually because it is part of a
shared public *interface* rather than an implementation detail. A
shared interface happens when interoperability is required. The
biggest example in my libs is the Color and MemoryImage objects,
which are loaded from independent image format modules and then
can be loaded into independent screen drawing or editing modules.
Loading an image then being unable to display it without a type
conversion* would be a bit silly, hence the shared type.
* Of course, sometimes you convert anyway. With .tupleof or
getAsBytes or something, you can do agnostic conversions, but it
is sometimes nice to just have `class SpecialImage {
this(GenericImage) { } }` to do the conversions and that's where
a shared third module comes in, so they can both `import
genericimage;`.
2) Once I do decide to share something, there's a policy of tiers:
first tier has zero imports (exceptions made for druntime and
SOMETIMES phobos, but i've been strict about phobos lately too).
These try to be the majority of them, providing interop
components and some encapsulated basic functionality. They can
import other things but only if the user actually uses it. For
example, dom.d has zero imports for basic functions. But if you
ask it to load a non-utf8 file, or a file from the web, it will
import arsd.characterencodings and/or arsd.http2 on-demand.
Basic functionality must just work, it allows those opt-in
extensions though.
second tier has generally just one import, and it must be from
the first tier or maybe a common C library. I make some
exceptions to add an interop interface module too, but I really
try to keep it to just one. These built on the interop components
to provide some advanced functionality. This is where my
`script.d` comes in, for example, extending `jsvar.d`'s basic
functionality with a dynamic script capability.
I also consider `minigui.d` to be here, since it extends
simpledisplay's basic drawing with a higher-level representation
of widgets and controls, though since simpledisplay itself
imports color.d now (it didn't when I first wrote them... making
that change was something I really didn't want to do, but was
forced to by practical considerations), minigui does have two
imports... but still, I'm leaving it there.
Then, finally, there's the third tier, which I call the
application/framework tier, which is the rarest one in my
released code (but most common in my proprietary code, where I
just `dmd -i` it and use whatever is convenient). At this point,
I'll actually pull in whatever I want (from the arsd package,
that is) so there is no limit on the number of imports. I still
tend to minimize them, but won't take extraordinary effort. This
is quite rare for me to do in a library module since this locks
it out of use by any other library module! Obviously, no tier one
or two files can import a tier three, so if I want to actually
reuse anything in there, it must be factored out back to
independence first.
C libraries btw are themselves also imports, so I also minimize
them, but there's again some grey area: postgres.d use both
database.d as the shared interface, but libpq as its
implementation. I still consider it tier two though, despite a C
library being even harder for the user to set up than 50 arsd
modules.
3) I try to minimize and batch breaking changes, including breaks
to the build instructions. When I changed simpledisplay to import
color, it kinda bugged me since for a few years at that point, I
told people they can just download it off my website and go.
I AM considering changing this policy slightly and moving more to
tier two, so it is the majority instead of tier one. All my new
instructions say "dmd -i" instead of "download the file"
Re: Printing a quoted string
On Sunday, 20 March 2022 at 09:42:44 UTC, Caten wrote:
On Sunday, 2 January 2022 at 21:16:55 UTC, Amit wrote:
On Sunday, 2 January 2022 at 19:26:50 UTC, WebFreak001 wrote:
[...]
On Sunday, 2 January 2022 at 19:37:38 UTC, JG wrote:
[...]
Yes! That's what I needed.
I wrapped it in a function like so:
```d
string quote(string s) {
return format("%s", [s])[1 .. $ - 1];
}
unittest {
assert(quote("one \"two\"\nthree four") == `"one
\"two\"\nthree four"`);
}
```
Thanks for your responses ^_^
Hi, I also need a function to "unquote" string, like this:
```d
assert(unquote(`\n`)=="\n");
```
Is there a way to do that?
```d
void main()
{
import std.array : replace;
auto q = `Hello,\n deneme`;
auto p = "Hello,\n deneme";
assert(q.replace("\\n", "\n") == p);
}
```
SDB@79
Re: Printing a quoted string
On Sunday, 2 January 2022 at 21:16:55 UTC, Amit wrote:
On Sunday, 2 January 2022 at 19:26:50 UTC, WebFreak001 wrote:
[...]
On Sunday, 2 January 2022 at 19:37:38 UTC, JG wrote:
[...]
Yes! That's what I needed.
I wrapped it in a function like so:
```d
string quote(string s) {
return format("%s", [s])[1 .. $ - 1];
}
unittest {
assert(quote("one \"two\"\nthree four") == `"one
\"two\"\nthree four"`);
}
```
Thanks for your responses ^_^
Hi, I also need a function to "unquote" string, like this:
```d
assert(unquote(`\n`)=="\n");
```
Is there a way to do that?
Re: Help needed to learn templates
On Saturday, 19 March 2022 at 22:31:19 UTC, Stanislav Blinov
wrote:
It is appearing not in the `static if`, but in the `is`
expression, which I described further in the rest of my first
reply. Sorry if that wasn't clear.
No, it was my mistake, I missed it.
The other template syntax - `template foo(alias T)` can take as
`T` any symbol, not just a type.
I understand this.
It comes from you, the programmer. Like I said before, `is(T ==
U[], U)` means "is T an array of some type, the type which I
(the programmer) would like to refer to as U?". That's all
there is to it (well, not quite, but it should suffice for
starters). You're simply introducing an identifier. So, when
`T` is an `int[][][]`, naturally, `U` becomes an alias to
`int[][]` (look at the converse - when `U` is `int[][]`, `U[]`
is naturally an `int[][][]`).
Okay, got it.
You can think of that test as this:
```d
import std.traits : isDynamicArray;
// ...
static if (isDynamicArray!T)
{
alias U = typeof(T.init[0]);
// ...
}
```
Yes, in this case everything is simple and clear.
...which would roughly be the same thing - you test if `T` is a
dynamic array of some type, and then make an alias for that
array's element type. It's just that the `is` expression allows
you to create such alias in situ.
Okay. Got the point. Thanks. Now, I understand that why Ali
suggest me to learn **`is()`** expression.
Re: How to exclude function from being imported in D language?
On Tuesday, 8 March 2022 at 18:38:47 UTC, Paul Backus wrote:
On Tuesday, 8 March 2022 at 17:47:47 UTC, BoQsc wrote:
For example, you could use a [`version` condition][1]:
```d
module otherprogram;
version (Otherprogram_NoMain)
{
// no main function
}
else
{
void main(string[] args)
{
// ...
}
}
// other functions...
```
There is no need for extra features when there is a version
feature in D. Moreover, you can abstract the libraries it depends
on, as I did
[here](https://forum.dlang.org/post/dcfkmssxbzgbkkpar...@forum.dlang.org).
SDB@79
