Re: Multiple subtyping with alias this and nested classes
On 06/10/2009 02:15, Andrei Alexandrescu wrote: Yigal Chripun wrote: I think 'alias this' is a powerful feature. Given the constraints like "easy for the compiler writer to implement" and "we have many other things to do", I doubt traits or something like that will be or needs to be in the language. Alias this is powerful black magic. being powerful doesn't make it any less dark. So how does this work? Alias this was meant very clearly for allowing subtyping. Conversely, using it for subtyping is precisely how it was meant to be used. How exactly did you decide it was a hack or black magic or whatever? Andrei D already has syntax for sub-typing reference types and alias this introduces a completely different syntax doing the same for value types which is bad human interface IMO. it also mixes two concepts - sub-typing and opImplicitCast (as i recall, this is done by alias this to a function) we discussed this in the past already and IIRC you agreed with me about implementing compile time inheritance for structs which I feel is much cleaner and more consistent with the existing syntax of interfaces.
Re: What does Coverity/clang static analysis actually do?
I am Sorry for my delay for this small answer... Walter Bright: >5. dead code (code that can never be executed)< In particular whole unused functions, methods, classes, modules, packages. Also rather important unused constants, variables. GCC has a function attribute named "used" that tells the optimizer to keep a function in the binary even if it appears to be unused (because it may be used in strange ways from asm, etc). >The =void case is rare enough to be irrelevant.< In good D code it's very uncommon, but spotting such bugs too is positive. (And eventually D variables may not be initialyzed anymore?) >6. Arrays are solidly covered by a runtime check. There is code in the >optimizer to detect many cases of overflows at compile time, but the code is >currently disabled because the runtime check covers 100% of the cases.< Spotting such bugs at compile time, where possible, is 200% better (if such test is reliable). >8. D2 has acquired some decent checking for this.< In my opinion it's not enough, some optional runtime tests too are be useful. >More along these lines will be interesting.< Sure. There's a lot that can be done still. Other possible bugs: - optional runtime errors when a pointer goes out of the allocated memory (C# does something like this). - safety: people that try to mess with the stack to try to break the safety of a program. Also stack canaries (now they can be used wuith LLVM). - errors in indentation, when an if-then-else has an indentation that's the opposite of the its semantics. New GCC can spot this problem. - finding where a structure is modified, but such changes will not influence the program, because the structure is copied by value. This is tricky, but I've fallen in this trap, for example modifying a struct array, if you don't use "ref" you will not change the original array. If inside a function that takes a string in input you change the string length, such string will not be seen outside the function unless you mark the string as "ref", etc. - Spotting bugs in "switch", for example where a programmer may have forgotten a break. I don't know if this can be done, probably not. - There are many other possibile bugs. I suggest to read online lists of common bugs in C/C++/Java/C# programs, and to try to give the compiler ways to spot some of them. Lints like Splint and gimpel are designed for this, see below. - disallowing implicit signed=>unsigned conversions. You can also take a look at Splint: http://www.splint.org/ Splint also shows that adding few annotations in the source code can save from many bugs. Annotations for example that assert that a pointer is never null, etc. And gimpel: http://www.gimpel.com/ The bug of the month now is interactive, so you can use it to test how good this software is: http://www.gimpel-online.com/bugsLinkPage.html The very large list of possible bugs/problems spotted by gimpel software: http://gimpel-online.com/MsgRef.html The Cyclone language is a safe variant of C, it can give some ideas. C#4 too has surely some safety ideas that D is missing still. For example warning every time a variable is supposed to be converted automatically into another type of variable with some information loss (eg. double => float, etc). Bye, bearophile
Re: Multiple subtyping with alias this and nested classes
Yigal Chripun wrote: I think 'alias this' is a powerful feature. Given the constraints like "easy for the compiler writer to implement" and "we have many other things to do", I doubt traits or something like that will be or needs to be in the language. Alias this is powerful black magic. being powerful doesn't make it any less dark. So how does this work? Alias this was meant very clearly for allowing subtyping. Conversely, using it for subtyping is precisely how it was meant to be used. How exactly did you decide it was a hack or black magic or whatever? Andrei
Re: Multiple subtyping with alias this and nested classes
On 05/10/2009 12:19, Max Samukha wrote:
On Sun, 04 Oct 2009 12:31:08 -0400, Yigal Chripun
wrote:
Max Samukha Wrote:
I see. What you want is non-virtual MI.
I don't think that allowing the derived class to have two distinct
implementations for the same function prototype is a good idea.
Eiffel handles this by giving the programmer controls to select features and
rename them in the derived class which I think is better.
// hypothetical syntax example
class FlippingBlipper : IBlipper, IFilpper {
mixin Flipper F;
mixin Blipper B;
// rename the inherited interface functions
alias IBlipper.nameCollision boo;
alias IFilpper.nameCollision foo;
// implement the now two distinct functions
void foo() { F.nameCollision(); }
void boo() { B.nameCollision(); }
}
you can further subtype and the derived foo& boo will override the respective
interfaces.
Yes, but what if nameCollision is a virtual function called somewhere
in the template mixin? Your example has effectively removed the
virtuality.
it doesn't remove virtuality. Virtual functions are stored as pointers in the
vtable. with my suggested solution the idea is that the same pointer in the
vtable gets a new name in the derived class.
when you mixin the template into the derived class the compiler would resolve
nameCollision to the new name "foo" because of the renaming rule in the derived
class.
Ok, I still cannot see how the compiler can reliably determine that
IFlipper.nameCollision is implemented by Flipper and not by Blipper
and call the correct override when flip is called.
Should the compiler deduce that from F.nameCollision? If yes, what
about:
void foo() { B.nameCollision; F.nameCollision; } ?
Or should it decide based on the fact that Flipper contains the 'flip'
function that implements IFlipper.flip? If yes, then what if the
interfaces had nothing more than the 'nameCollision' functions?
I see you want to discuss the details of the renaming mechanism, while I
just talked about the general idea itself until now.
we have two cases: regular and mixins.
for case a it's simple, the class itself lists the renames:
Interface A {
void foo();
}
Interface B {
void foo();
}
class C : A, B {
alias A.foo func1; // or similar syntax to mark the renaming
alias B.foo func2; // ditto
override void func1() {...} // C.func1 overrides A.foo
override void func2() {...} // C.func2 overrides B.foo
}
case 2, mixins:
I think some sort of annotations by the programmer is needed.
class C : A, B {
alias A.foo func1; // or similar syntax to mark the renaming
alias B.foo func2; // ditto
// hypothetical syntax to connect mixins to interfaces
// the compiler will apply the rename rules of this class assuming that
// any references to foo in ImplA are "A.foo" and will be renamed to
// func1 in C
// if the mixin explicitly specifies the interface (e.g B.foo) than the
// compiler already knows what to map this to.
mixin ImplA A;
mixin ImplB B;
}
btw, this all can be done in a much simpler way with (hygienic) AST Macros.
I don't think I want non virtual MI in D since it is more trouble than it's
worth. but *if* we discuss this, I think my suggested semantics are simpler.
The syntax probably can be much better but that's a secondary issue IMO.
It's unrelated to virtual MI. See Sergey Gromov's post. We are
discussing this only because it's a real world problem that has no
decent solution in D.
I said *non* virtual MI above..
with my design:
class Foo : FlippingBlipper {
override foo ...
override bar ...
}
IFlipper obj = new Foo;
obj.nameCollision; // will call Foo.bar
I don't think that's possible with your design.
I'm not claiming it's my design. Andrei is the author.
And yes, it's possible in a number of ways. One is:
class BlippingFlipper
{
class Flipper_ : Flipper
{
override void nameCollision() { foo(); }
final void super_nameCollision() { super.nameCollision; }
}
this() { flipper = new Flipper_; }
Flipper_ flipper;
alias flipper this;
void foo() { flipper.super_nameCollision; }
}
class Foo : BlippingFlipper
{
override void foo() {}
}
(Wordy but still possible. Can be made easier on the eye with a helper
mixin)
This gets more and more complicated - Like I said before, I feel that
renaming has easier to understand semantics.
I agree that possibility to implement renamed interface methods AND
explicit interface implementation would solve the problem of name
collisions. But it doesn't solve the problem of subtyping structs and
built-in types.
the problem with explicit interface implementation as discussed in
another thread is that the implementations will become hidden.
class C: A, B {
override void A.foo () { ... }
override void B.foo () { ... }
}
C obj = new C;
obj.foo(); // error
class D : C { ... }
what happens in class D? Can I override the functions there as well? how?
you do not need explicit interface implementation at al
Re: null references redux + Looney Tunes
"Justin Johansson" wrote in message news:had7hc$1dc...@digitalmars.com... > Nick Sabalausky Wrote: >> >> This is gonna sound trivial (and probably is), but it's been bugging the >> hell out of me: >> >> What is the meaning of the "+ Looney Tunes" added to the title of this >> sub-thread? I don't see a connection...? > > > Good question. Next question? :-) > > Okay, Nick, this is the twist (warped as it may be). > > For starters I'm guessing that you are somewhat younger than me. > (Walter said once that D seems to attract a lot of the younger crowd; > myself, I'm Walter's vintage.) > > I grew up watching a lot of Marx Brothers movies (and, btw, I'm > continually surprised by just > how many people, mostly younger, have never heard of the Marx Brothers, so > just in case > you are a member of said set, here's his bio: > http://en.wikipedia.org/wiki/Groucho_Marx ). > > Groucho Marx was the absolute master of wisecracks; IMHO, few comedians > have ever come > close to matching his undeniable ability to make fast-talking wit out of > the even the > most subtle of connections. Alan Alda (in M*A*S*H) often played out > Groucho, much to my > delight. > > I also grew up with eyes glued to every Bugs Bunny cartoon that I could > watch and every > Looney Tune that accompanied the same. ( > http://en.wikipedia.org/wiki/Looney_Tunes ) > > So now, having mentioned Marx, Alda and Bunny, this explains where my > sense of humour > comes from. > > Now the title of the Elliotte Rusty Harold article, > > http://cafe.elharo.com/programming/imagine-theres-no-null/ , > > that started this thread was a play on words from the title of the song > "Imagine theres no Heaven" by John Lennon, and acknowledged by ERH at the > end of the article. > (Also so happens that The Beatles along with Pink Floyd are some of my > favourite bands.) > > ( Lyrics to Imagine written up here - > http://www.slymarketing.com/2007/10/imagine-there-is-no-heaven/ ) > > So at the time I was thinking, > > "Hey, that's a good controversial story line to throw in for a bit of > Fudd** on the D newsgroup" > > and, come to think of it (still saying to myself), it's probably a bit of > a Looney Tune. > > Now having said all that, several possible interpretations are left open > for the amusement > of readers. > > ** Fudd. > > Acronym Definition > FUDD Functional Description Document > FUDD Fear Uncertainty Doubt and Disinformation > > Also Google on (exactly and typed below) > > define:fudd > > to get further connection with Looney Tunes > > Cheers > Ahh, I see. I came moderately close (Ie, recognized the John Lennon connection...my dad and younger brother are big Beatles fans so it's hard for me not to know ;) ) but didn't immediately catch on to the puns with Elmer "Fudd" and "bit of a Looney Tune". I probably would count as one of the younger-ish ones (27), but we do seem to have a similar taste in humor. I grew up on the Chuck Jones Looney Tunes (Some of the earlier ones before Chuck are creepy!). As far as I'm concerned, Marx Brothers are an absolute comedic legend, right up there with Three Stooges and Mel Brooks, although I admit I've only seen Duck Soup and Go West so far. But still, I've noticed that Looney Tunes and Mel Brooks seem pay a lot of homage to Marx Brothers (but, of course, Looney Tunes makes constant references to all the celebrities of the time), like the frequent "Mirror" gags in Looney tunes are straight out of Duck Soup, and so is the big song&dance number at the end of Blazing Saddles. It absolutely is a shame that there's so much unfamiliarity with the Marx brothers (ex: Try to find another person these days who can name more than just Groucho...or someone who knows where those funny nose and mustache toy glasses come from), considering just how influential they've been and how well their material has held up. It's actually really funny that you should mention that about Alan Alda's MASH character: The local libraries have the DVD sets for each season of MASH (plus the movie), and my dad and I have been systematically going through all them lately (We just got to the introduction of Potter and Honeycut at the beginning of season four, although we did temporarily skip season three). Funny thing is though, I swear, just recently, sometime around season two, I started noticing "Hey, Pierce has much the same quick-wit humor as Groucho Marx". And in conclusion: "Oh my god they've shot him!" "Hot Lips, you incredible nincompoop!..."
Re: null references redux + Looney Tunes
downs: > I'm not buying that. What kind of function would that be? I can't imagine a > need for this. I don't know, sorry. But I'd like to have such method to define my collections as false when they are empty, this is really handy. And it may be useful to make nullable values false. Bye, bearophile
Re: null references redux + Looney Tunes
bearophile wrote:
> Denis Koroskin:
>
>> I don't see any reason why if (someComplexNumber) { ... } should be a
> valid code, it hardly makes any sense for me.<
>
> In general I think adding a boolean-evaluation standard method to D can be
> positive and handy and not that bug-prone.
> But complex numbers are FP, so you usually test if they are close to zero
> (test of exactly zero can be useful to know if a value was not changed, etc).
> So I agree with you that for complex numbers such boolarn-eveluation method
> isn't very useful.
> Once D has such operator, it can be defined for library complex numbers too,
> but probably it will not be used often.
> It's useful if you want to write generic code, so if in a templated function
> you use if(x){... it will work with integers, double, complex values, etc,
> without special casing.
>
I'm not buying that. What kind of function would that be? I can't imagine a
need for this.
Re: null references redux + Looney Tunes
Rainer Deyke wrote: Boost.Units (C++) checks units at compile time. There is no reason why D could not use the same approach. Oskar's code I posted does it at compile time.
Re: null references redux + Looney Tunes
bearophile wrote:
Scala has a powerful type system that allows to implement such things in a good
enough way:
http://www.michaelnygard.com/blog/2009/05/units_of_measure_in_scala.html
So does D:
===
// by Oskar Linde Aug 2006
// This is just a quick hack to test
// IFTI operators opMul and opDel
import std.stdio;
import std.math;
import std.string;
version = unicode;
struct SiQuantity(T,int e1, int e2, int e3, int e4, int e5, int e6, int
e7) {
T value = 0;
alias T ValueType;
const exp1 = e1;
const exp2 = e2;
const exp3 = e3;
const exp4 = e4;
const exp5 = e5;
const exp6 = e6;
const exp7 = e7;
static assert(SiQuantity.sizeof == ValueType.sizeof);
template AddDimensions(int mul, U) {
static assert(is(U.ValueType == ValueType) ||
is(U == ValueType),
"incompatible value types");
static if (is(U == ValueType))
alias SiQuantity AddDimensions;
else
alias SiQuantity!(T,exp1+mul*U.exp1,exp2+mul*U.exp2,
exp3+mul*U.exp3,exp4+mul*U.exp4,
exp5+mul*U.exp5,exp6+mul*U.exp6,
exp7+U.exp7) AddDimensions;
}
SiQuantity opAddAssign(SiQuantity rhs) {
value += rhs.value;
return this;
}
SiQuantity opSubAssign(SiQuantity rhs) {
value -= rhs.value;
return this;
}
const
{
SiQuantity opAdd(SiQuantity rhs) {
SiQuantity ret;
ret.value = value + rhs.value;
return ret;
}
SiQuantity opSub(SiQuantity rhs) {
SiQuantity ret;
ret.value = value - rhs.value;
return ret;
}
SiQuantity opNeg() {
SiQuantity ret;
ret.value = -value;
return ret;
}
SiQuantity opPos() {
typeof(return) ret;
ret.value = value;
return ret;
}
int opCmp(SiQuantity rhs) {
if (value > rhs.value)
return 1;
if (value < rhs.value)
return -1;
return 0; // BUG: NaN
}
AddDimensions!(+1,Rhs) opMul(Rhs)(Rhs rhs) {
AddDimensions!(+1,Rhs) ret;
static if (is(Rhs : T))
ret.value = value * rhs;
else
ret.value = value * rhs.value;
return ret;
}
AddDimensions!(-1,Rhs) opDiv(Rhs)(Rhs rhs) {
AddDimensions!(-1,Rhs) ret;
static if (is(Rhs : T))
ret.value = value / rhs;
else
ret.value = value / rhs.value;
return ret;
}
SiQuantity opMul_r(T lhs) {
SiQuantity ret;
ret.value = lhs * value;
return ret;
}
SiQuantity!(T,-e1,-e2,-e3,-e4,-e5,-e6,-e7) opDiv_r(T lhs) {
SiQuantity!(T,-e1,-e2,-e3,-e4,-e5,-e6,-e7) ret;
ret.value = lhs / value;
return ret;
}
string toString() {
string prefix = "";
T multiplier = 1;
T value = this.value;
string unit;
static if (is(typeof(UnitName!(SiQuantity
unit = UnitName!(SiQuantity);
else {
value *= pow(cast(real)1e3,cast(uint)e2); // convert kg
-> g
// Take mass (e2) first to handle kg->g prefix issue
if (e2 != 0) unit ~= format("·g^%s",e2);
if (e1 != 0) unit ~= format("·m^%s",e1);
if (e3 != 0) unit ~= format("·s^%s",e3);
if (e4 != 0) unit ~= format("·A^%s",e4);
if (e5 != 0) unit ~= format("·K^%s",e5);
if (e6 != 0) unit ~= format("·mol^%s",e6);
if (e7 != 0) unit ~= format("·cd^%s",e7);
if (unit)
unit = unit[2..$].split("^1").join("");
}
if (value >= 1e24) { prefix = "Y"; multiplier = 1e24; }
else if (value >= 1e21) { prefix = "Z"; multiplier = 1e21; }
else if (value >= 1e18) { prefix = "E"; multiplier = 1e18; }
else if (value >= 1e15) { prefix = "P"; multiplier = 1e15; }
else if (value >= 1e12) { prefix = "T"; multiplier = 1e12; }
else if (value >= 1e9) { prefix = "G"; m
Re: I wrote some D today and it's completely blowing my mind. Ever
digited wrote: Walter Bright Wrote: D isn't meant as a language to enlighten people, it isn't a religion, it's a language meant to get things done with. Amen that holy true! All hail D!
Re: Google C++ style guide
== Quote from Don (nos...@nospam.com)'s article
> Jeremie Pelletier wrote:
> > Christopher Wright wrote:
> >> Jeremie Pelletier wrote:
> >>> Me neither, in fact I would *love* to see a -nrtti switch in DMD to
> >>> disable the generation of all ClassInfo and TypeInfo instances, along
> >>> with a version identifier, maybe "version = RTTI_Disabled;" to let
> >>> code handle it.
> >>>
> >>> I use RTTI a lot for simple debugging like printing the name of a
> >>> class or type in generic code or meta programming, but not at all in
> >>> production code. Most of the time I can rely on .stringof and a
> >>> message pragma to do the same.
> >>
> >> You use RTTI for dynamic casts, variadic functions, and the default
> >> implementation of toString. You could safely eliminate some fields
> >> from ClassInfo and TypeInfo, but you can't get rid of them entirely.
> >>
> >> The best you can do is make TypeInfo entirely opaque (no fields) and
> >> only include the base class, interfaces, and name for ClassInfo.
> >
> > Yeah something like "don't generate type names" and other extra
> > informations would be a definive plus, that makes reverse engineering
> > too easy :)
> I've often thought that a pragma for a module to "don't generate module
> info" would be very useful for executable size. I'm particularly
> thinking of bindings like the Win32 headers, where there are a hundred
> modules, and the module info isn't actually useful. There could be a
> default ModuleInfo instance, with module name "ModuleInfoUnavailable",
> which all such modules would point to.
One thing that can trip this up is structs containing floating point numbers
or static arrays, since they have custom initializers. I've taken to declaring
structs from C headers with an "= void" to eliminate the link dependency,
but maybe the initializer could be eliminated by declaring the struct as:
struct S
{
char c = 0;
float[2] f = 0.0[];
}
Or something like that.
Re: null references redux + Looney Tunes
Nick Sabalausky Wrote: > "Justin Johansson" wrote in message > news:ha4qpi$189...@digitalmars.com... > > For the interest of newsgroups readers, I dropped in at the Cafe the other > > day and > > the barista had this to say > > > > http://cafe.elharo.com/programming/imagine-theres-no-null/ > > > > Disclaimer: YMMV > > > > Cheers > > > > This is gonna sound trivial (and probably is), but it's been bugging the > hell out of me: > > What is the meaning of the "+ Looney Tunes" added to the title of this > sub-thread? I don't see a connection...? Good question. Next question? :-) Okay, Nick, this is the twist (warped as it may be). For starters I'm guessing that you are somewhat younger than me. (Walter said once that D seems to attract a lot of the younger crowd; myself, I'm Walter's vintage.) I grew up watching a lot of Marx Brothers movies (and, btw, I'm continually surprised by just how many people, mostly younger, have never heard of the Marx Brothers, so just in case you are a member of said set, here's his bio: http://en.wikipedia.org/wiki/Groucho_Marx ). Groucho Marx was the absolute master of wisecracks; IMHO, few comedians have ever come close to matching his undeniable ability to make fast-talking wit out of the even the most subtle of connections. Alan Alda (in M*A*S*H) often played out Groucho, much to my delight. I also grew up with eyes glued to every Bugs Bunny cartoon that I could watch and every Looney Tune that accompanied the same. ( http://en.wikipedia.org/wiki/Looney_Tunes ) So now, having mentioned Marx, Alda and Bunny, this explains where my sense of humour comes from. Now the title of the Elliotte Rusty Harold article, http://cafe.elharo.com/programming/imagine-theres-no-null/ , that started this thread was a play on words from the title of the song "Imagine theres no Heaven" by John Lennon, and acknowledged by ERH at the end of the article. (Also so happens that The Beatles along with Pink Floyd are some of my favourite bands.) ( Lyrics to Imagine written up here - http://www.slymarketing.com/2007/10/imagine-there-is-no-heaven/ ) So at the time I was thinking, "Hey, that's a good controversial story line to throw in for a bit of Fudd** on the D newsgroup" and, come to think of it (still saying to myself), it's probably a bit of a Looney Tune. Now having said all that, several possible interpretations are left open for the amusement of readers. ** Fudd. Acronym Definition FUDDFunctional Description Document FUDDFear Uncertainty Doubt and Disinformation Also Google on (exactly and typed below) define:fudd to get further connection with Looney Tunes Cheers -- Justin Johansson
Re: Google C++ style guide
>If you want me to list something that's a little evil, is the automatic silent
>cast from an integral to its unsigned version. I'd like to disallow such
>silent cast in D (maybe C# does the same).<
We may even disallow all implicit conversions that lose a significant amount of
information:
double => float
real => float
(I think C# requires such casts).
And maybe even (but this is less handy, so I am not sure): real => double
Even long => real sometimes loses a little information:
import std.stdio: writeln;
void main() {
real r = long.min;
writeln(r, " ", cast(long)r, " ", long.max-cast(long)r);
}
But for now I'm not interested in regulating long => real implicit casts.
Bye,
bearophile
Re: Google C++ style guide
Jeremie Pelletier wrote: bearophile wrote: Don: I've often thought that a pragma for a module to "don't generate module info" would be very useful for executable size. Do you use the LDC compiler? LDC has the pragmas: pragma(no_typeinfo): You can use this pragma to stop typeinfo from being implicitly generated for a declaration. pragma(no_moduleinfo): You can use this pragma to stop moduleinfo from being implicitly generated for a declaration. Sounds great. They should be standard. I've never used those yet, I'll try them soon. But you meant something more global, module-wide. Maybe you can ask to LDC devs. I agree that having standard and not compiler-specific features is better. Bye, bearophile I would much prefer these to be compiler switches, so you can make them global with very little effort. That's a completely different use case, I think. For internal modules, the existence of that module is an implementation detail, and shouldn't be externally visible even through reflection, IMHO.
Re: Google C++ style guide
Jeremie Pelletier: > However we're > talking systems programming here, people want the choice between using > the feature or not using it :) We aren't talking about a feature here, but a standard syntax to denote class attributes. And D being a system language has nothing to do with being free to take such kind of choices. A system language has to give freedom in how you use memory or how you use the CPU at runtime, it has nothing to do to the syntax you use to write identifiers. Such freedom isn't required. Bye, bearophile
Re: Google C++ style guide
Kagamin: > > I'm for the removal of size_t from everywhere it's not stricly necessary > > (so for example from array lenghts) to avoid bugs. > > Yess, unsigneds are evil. They must go to the camp of gotos and unsafe > pointers. In D it's better to not use them when you want a strictly positive number, or for general iteration purposes, etc. So I don't like to see them used in the built-ins and std lib where they aren't necessary. I use them when I need bitfields, or when I need the full range (but that's less common). If you want me to list something that's a little evil, is the automatic silent cast from an integral to its unsigned version. I'd like to disallow such silent cast in D (maybe C# does the same). Walter may answer on this. Regarding pointers, they are unsafe, but there are ways to increase their safety a little, with no performance costs in release mode. I think this is positive because it helps find and fix bugs in less time. Bye, bearophile
Re: Google C++ style guide
Jeremie Pelletier: > I would much prefer these to be compiler switches, so you can make them > global with very little effort. Compiler switches are a blunt tool. So I think module-wide switches are better. Bye, bearophile
Re: Salasana hukassa
On Mon, 05 Oct 2009 19:15:58 +0400, Justin Johansson wrote: [JJ: The only difficulty for me was trying to figure out what source language to tell the Google language tool.] I use translate.google.com, you can select "Detected language" from a source language list (it is the first entry).
Re: Salasana hukassa
Georg Wrede Wrote: > Moi. > > Kone joka muisti liikuttimem salasanan hajosi. Eikä se ollut paperilla. > > Saiskos uuden, kiitos. > > Mun email on teidän listassa, joten sinne. > > Georg Wrede For the benefit of NG readers, here's a loose translation. Translation: Finnish » English Courtesy: http://www.google.com.au/language_tools?hl=en Subject: Forgotten password Body: Hi. Machine which broke down memory liikuttimem password. And it was not on paper. Saiskos new, thank you. My email is in your list, so there. Georg Wrede [JJ: The only difficulty for me was trying to figure out what source language to tell the Google language tool.]
Re: Google C++ style guide
bearophile wrote: Don: I've often thought that a pragma for a module to "don't generate module info" would be very useful for executable size. Do you use the LDC compiler? LDC has the pragmas: pragma(no_typeinfo): You can use this pragma to stop typeinfo from being implicitly generated for a declaration. pragma(no_moduleinfo): You can use this pragma to stop moduleinfo from being implicitly generated for a declaration. I've never used those yet, I'll try them soon. But you meant something more global, module-wide. Maybe you can ask to LDC devs. I agree that having standard and not compiler-specific features is better. Bye, bearophile I would much prefer these to be compiler switches, so you can make them global with very little effort.
Salasana hukassa
Moi. Kone joka muisti liikuttimem salasanan hajosi. Eikä se ollut paperilla. Saiskos uuden, kiitos. Mun email on teidän listassa, joten sinne. Georg Wrede
Re: I wrote some D today and it's completely blowing my mind. Ever
Walter Bright Wrote: > D isn't meant as a language to enlighten people, it isn't a religion, > it's a language meant to get things done with. Amen that holy true!
unit libraries, was Re: null references redux + Looney Tunes
language_fan wrote: > The only problem with these was that there was no way to signal the > location of the type error in the client code, it always reported the > location of the (static) assert in the library, which is pretty much > useless. That's a compiler problem, no? I don't think this is a big deal either way. Unit errors should be exceedingly rare. The purpose of a unit library not to track down unit errors, but to formally prove that correct code is correct. -- Rainer Deyke - rain...@eldwood.com
Re: null references redux + Looney Tunes
Nick Sabalausky wrote: > I've been thinking it might be nice to have both. Compile-time for obvious > reasons but then also run-time ones that could do conversions: > > auto velocity = convert(meter/second)(distance / time); // Actual > runtime-conversion I'm pretty sure Boost.Units already does this, although in general it's probably better to stick with SI units in your code and only perform conversions on input/output. -- Rainer Deyke - rain...@eldwood.com
Re: Google C++ style guide
Kagamin Wrote: > In fact DMD has bug here: spec says, this pointer must not be taken > implicitly or explicitly, yet dmd allows calling virtual methods on the > object being constructed. A... I've misread the spec a little. Though I think, it's still a problem that constructor allows to call virtual methods.
Re: null references redux + Looney Tunes
"language_fan" wrote in message news:hacm6o$2e...@digitalmars.com... > Mon, 05 Oct 2009 11:41:52 +, language_fan wrote: >> >> There have been several existing implementations of SI unit libraries >> for D. By Oskar Linde et al. The checking can be built statically >> without any runtime performance penalty. > > The only problem with these was that there was no way to signal the > location of the type error in the client code, it always reported the > location of the (static) assert in the library, which is pretty much > useless. Yea, that's been a problem for a *lot* of stuff... Although I think it might be fixed now... I could swear there was a patch on bugzilla for that that I had grabbed and made a custom-build of DMD with, and then saw that a newer version of DMD had incorporated it... But in my current sleepless stupor I might be confusing it with something else...
Re: null references redux + Looney Tunes
"language_fan" wrote in message news:hacnq3$2e...@digitalmars.com... > Mon, 05 Oct 2009 08:03:11 -0400, Nick Sabalausky thusly wrote: > >> "Rainer Deyke" wrote in message > >> I've been thinking it might be nice to have both. Compile-time for >> obvious reasons but then also run-time ones that could do conversions: > >> Although that would probably be far from trivial to design/implement. > > Why? Because of the NIH syndrome? Because everything seems super-hard when I'm as tired as I am right now ;)
Re: null references redux + Looney Tunes
Mon, 05 Oct 2009 08:03:11 -0400, Nick Sabalausky thusly wrote: > "Rainer Deyke" wrote in message > I've been thinking it might be nice to have both. Compile-time for > obvious reasons but then also run-time ones that could do conversions: > Although that would probably be far from trivial to design/implement. Why? Because of the NIH syndrome? Just grab the O. Linde's sources from the ng archives and build the conversion function you mentioned above. It's not that hard to do..
Re: null references redux + Looney Tunes
"Rainer Deyke" wrote in message news:haclah$33...@digitalmars.com... > bearophile wrote: >> Scala has a powerful type system that allows to implement such things >> in a good enough way: >> >> http://www.michaelnygard.com/blog/2009/05/units_of_measure_in_scala.html > > Either I'm missing something, or this system only checks units at > runtime (which would make it both slow and unsafe). > > Boost.Units (C++) checks units at compile time. There is no reason why > D could not use the same approach. > I've been thinking it might be nice to have both. Compile-time for obvious reasons but then also run-time ones that could do conversions: double(inch) distance = 7; double(minute) time = 1.5; double(meter/second) velocity = distance / time; // Compile-time error auto velocity = convert(meter/second)(distance / time); // Actual runtime-conversion auto velocity = convert(meter)(distance / time); // Compile-time error: Incompatible Although that would probably be far from trivial to design/implement.
Re: null references redux + Looney Tunes
Mon, 05 Oct 2009 05:29:20 -0600, Rainer Deyke thusly wrote: > bearophile wrote: >> Scala has a powerful type system that allows to implement such things >> in a good enough way: >> >> http://www.michaelnygard.com/blog/2009/05/ units_of_measure_in_scala.html > > Either I'm missing something, or this system only checks units at > runtime (which would make it both slow and unsafe). > > Boost.Units (C++) checks units at compile time. There is no reason why > D could not use the same approach. There have been several existing implementations of SI unit libraries for D. By Oskar Linde et al. The checking can be built statically without any runtime performance penalty.
Re: null references redux + Looney Tunes
Mon, 05 Oct 2009 11:41:52 +, language_fan wrote: > Mon, 05 Oct 2009 05:29:20 -0600, Rainer Deyke thusly wrote: > >> bearophile wrote: >>> Scala has a powerful type system that allows to implement such things >>> in a good enough way: >>> >>> http://www.michaelnygard.com/blog/2009/05/ > units_of_measure_in_scala.html >> >> Either I'm missing something, or this system only checks units at >> runtime (which would make it both slow and unsafe). >> >> Boost.Units (C++) checks units at compile time. There is no reason why >> D could not use the same approach. > > There have been several existing implementations of SI unit libraries > for D. By Oskar Linde et al. The checking can be built statically > without any runtime performance penalty. The only problem with these was that there was no way to signal the location of the type error in the client code, it always reported the location of the (static) assert in the library, which is pretty much useless.
Re: null references redux + Looney Tunes
bearophile wrote: > Scala has a powerful type system that allows to implement such things > in a good enough way: > > http://www.michaelnygard.com/blog/2009/05/units_of_measure_in_scala.html Either I'm missing something, or this system only checks units at runtime (which would make it both slow and unsafe). Boost.Units (C++) checks units at compile time. There is no reason why D could not use the same approach. -- Rainer Deyke - rain...@eldwood.com
Re: null references redux + Looney Tunes
> ranged y = 1000; // Uh, bypasses the setter, no errors > writeln(y); // 0? In the last version of DMD it gives an error: ranged y = 1000; temp.d(23): Error: cannot implicitly convert expression (1000) of type int to ranged Better. And opCast may help here. No implicit cast. Bye, bearophile
Re: Google C++ style guide
bearophile Wrote: > >Function Parameter Ordering: When defining a function, parameter order is: > >inputs, then outputs.< > > D may even enforce this, allowing "out" only after "in" arguments. I'm trying to do the reverse. Maybe I used fprintf and sprintf too much. > >Static and Global Variables: Static or global variables of class type are > >forbidden: they cause hard-to-find bugs due to indeterminate order of > >construction and destruction. [...] The order in which class constructors, > >destructors, and initializers for static variables are called is only > >partially specified in C++ and can even change from build to build, which > >can cause bugs that are difficult to find. [...] As a result we only allow > >static variables to contain POD data.< > > I think D avoids such problem. No. D has static constructors which do the same. > >Doing Work in Constructors: Do only trivial initialization in a constructor. > >If at all possible, use an Init() method for non-trivial initialization. > >[...] If the work calls virtual functions, these calls will not get > >dispatched to the subclass implementations. Future modification to your > >class can quietly introduce this problem even if your class is not currently > >subclassed, causing much confusion.< > Never understood this advice to split the construction of object? What is it trying to solve? And how they plan to not dispatch calls to subclasses? Do they overwrite vtbl at the end of constructor? In fact DMD has bug here: spec says, this pointer must not be taken implicitly or explicitly, yet dmd allows calling virtual methods on the object being constructed. > >Declaration Order: Use the specified order of declarations within a class: > >public: before private:, methods before data members (variables), etc.< > > D may even enforce such order (Pascal does something similar). Methods before data seems unnatural for me. > >Decision: If you want to overload a function, consider qualifying the name > >with some information about the arguments, e.g., AppendString(), AppendInt() > >rather than just Append().< > > > This is a strong limitation. One of the things that makes C++ more handy than > C. I accept it for normal code, but I refuse it for "library code". Library > code is designed to be more flexible and reusable, making syntax simpler, etc. > So I want D to keep overloaded functions. A good example is BinaryWriter. It's unusable when implemented with overloaded methods. > >Default Arguments: We do not allow default function parameters.< > > >Decision: We require all arguments to be explicitly specified, to force > >programmers to consider the API and the values they are passing for each > >argument rather than silently accepting defaults they may not be aware of.< > Is it a solution? Default parameters can be emulated by overloads with different number of parameters, which call actual method with defaults for the rest of the parameters. They just propose to always use the full api? How about going back to asm to consider your code rather than accepting compiler magic? > Integer Types: > > >You should not use the unsigned integer types such as uint32_t, unless the > >quantity you are representing is really a bit pattern rather than a number, > >or unless you need defined twos-complement overflow. In particular, do not > >use unsigned types to say a number will never be negative. Instead, use > >assertions for this.< > > I'm for the removal of size_t from everywhere it's not stricly necessary (so > for example from array lenghts) to avoid bugs. Yess, unsigneds are evil. They must go to the camp of gotos and unsafe pointers. > Type Names: often I don't like the C++ practice of using a single uppercase > letter for a template type, like T. Better to give a meaningful name to > types, when possible. > I thought it's a common practice that the length (meaningfulness) of the name of a variable is determined more by the size of its scope rather than its purpose. > >Spaces vs. Tabs: Use only spaces, and indent 2 spaces at a time.< > > 4 spaces are more readable :-) > I prefer 3. 4 is too much. Almost every editor has the option to specify the tab width and people have different tastes.
Re: null references redux + Looney Tunes
Nick Sabalausky:
> -- fig A ---
> open(inFile ~ "out" ~ inFile.file ~ "log");
> // As many as 4 different errors that could be caught but currently aren't.
> // (But obviously all would be overridable, of course)
> // Without such checking, if inFile contained "/usr/home/joe/foo/bar.dat",
> // the result would be:
> // "/usr/home/joe/foo/bar.datoutbar.datlog"
>
> // Meant to do this:
> open(inFile.path ~ "out/" ~ inFile.name ~ ".log");
> // Result now: "/usr/home/joe/foo/out/bar.log"
> -
>
> -- fig B ---
> int add(int* a, int* b)
> {
> return a + b; // Error currently caught
> // Meant:
> return *a + *b;
> }
> -
>
> -- fig C ---
> auto accel = velocity * time; // Error caught with that "dimensional
> analysis"
> // Meant this:
> auto accel = velocity / time;
> -
Scala has a powerful type system that allows to implement such things in a good
enough way:
http://www.michaelnygard.com/blog/2009/05/units_of_measure_in_scala.html
Bye,
bearophile
Re: Google C++ style guide
Don: > I've often thought that a pragma for a module to "don't generate module > info" would be very useful for executable size. Do you use the LDC compiler? LDC has the pragmas: pragma(no_typeinfo): You can use this pragma to stop typeinfo from being implicitly generated for a declaration. pragma(no_moduleinfo): You can use this pragma to stop moduleinfo from being implicitly generated for a declaration. I've never used those yet, I'll try them soon. But you meant something more global, module-wide. Maybe you can ask to LDC devs. I agree that having standard and not compiler-specific features is better. Bye, bearophile
Re: null references redux + Looney Tunes
Denis Koroskin:
>I don't see any reason why if (someComplexNumber) { ... } should be a
valid code, it hardly makes any sense for me.<
In general I think adding a boolean-evaluation standard method to D can be
positive and handy and not that bug-prone.
But complex numbers are FP, so you usually test if they are close to zero (test
of exactly zero can be useful to know if a value was not changed, etc). So I
agree with you that for complex numbers such boolarn-eveluation method isn't
very useful.
Once D has such operator, it can be defined for library complex numbers too,
but probably it will not be used often.
It's useful if you want to write generic code, so if in a templated function
you use if(x){... it will work with integers, double, complex values, etc,
without special casing.
Bye,
bearophile
Re: Multiple subtyping with alias this and nested classes
On Sun, 04 Oct 2009 12:31:08 -0400, Yigal Chripun
wrote:
>Max Samukha Wrote:
>> >
>> >I see. What you want is non-virtual MI.
>> >I don't think that allowing the derived class to have two distinct
>> >implementations for the same function prototype is a good idea.
>> >Eiffel handles this by giving the programmer controls to select features
>> >and rename them in the derived class which I think is better.
>> >
>> >// hypothetical syntax example
>> >class FlippingBlipper : IBlipper, IFilpper {
>> > mixin Flipper F;
>> > mixin Blipper B;
>> > // rename the inherited interface functions
>> > alias IBlipper.nameCollision boo;
>> > alias IFilpper.nameCollision foo;
>> >// implement the now two distinct functions
>> > void foo() { F.nameCollision(); }
>> > void boo() { B.nameCollision(); }
>> >}
>> >
>> >you can further subtype and the derived foo & boo will override the
>> >respective interfaces.
>>
>> Yes, but what if nameCollision is a virtual function called somewhere
>> in the template mixin? Your example has effectively removed the
>> virtuality.
>>
>
>it doesn't remove virtuality. Virtual functions are stored as pointers in the
>vtable. with my suggested solution the idea is that the same pointer in the
>vtable gets a new name in the derived class.
>when you mixin the template into the derived class the compiler would resolve
>nameCollision to the new name "foo" because of the renaming rule in the
>derived class.
Ok, I still cannot see how the compiler can reliably determine that
IFlipper.nameCollision is implemented by Flipper and not by Blipper
and call the correct override when flip is called.
Should the compiler deduce that from F.nameCollision? If yes, what
about:
void foo() { B.nameCollision; F.nameCollision; } ?
Or should it decide based on the fact that Flipper contains the 'flip'
function that implements IFlipper.flip? If yes, then what if the
interfaces had nothing more than the 'nameCollision' functions?
>I don't think I want non virtual MI in D since it is more trouble than it's
>worth. but *if* we discuss this, I think my suggested semantics are simpler.
>The syntax probably can be much better but that's a secondary issue IMO.
>
It's unrelated to virtual MI. See Sergey Gromov's post. We are
discussing this only because it's a real world problem that has no
decent solution in D.
>
>with my design:
>class Foo : FlippingBlipper {
> override foo ...
> override bar ...
>}
>IFlipper obj = new Foo;
>obj.nameCollision; // will call Foo.bar
>
>I don't think that's possible with your design.
I'm not claiming it's my design. Andrei is the author.
And yes, it's possible in a number of ways. One is:
class BlippingFlipper
{
class Flipper_ : Flipper
{
override void nameCollision() { foo(); }
final void super_nameCollision() { super.nameCollision; }
}
this() { flipper = new Flipper_; }
Flipper_ flipper;
alias flipper this;
void foo() { flipper.super_nameCollision; }
}
class Foo : BlippingFlipper
{
override void foo() {}
}
(Wordy but still possible. Can be made easier on the eye with a helper
mixin)
I agree that possibility to implement renamed interface methods AND
explicit interface implementation would solve the problem of name
collisions. But it doesn't solve the problem of subtyping structs and
built-in types.
>
>besides, alias this is a hack. a better mechanism would be to have
>compile-time inheritance, IMO.
I think 'alias this' is a powerful feature.
Given the constraints like "easy for the compiler writer to implement"
and "we have many other things to do", I doubt traits or something
like that will be or needs to be in the language.
Re: Is there a way to get the size of a class object statically?
On Mon, 05 Oct 2009 14:13:06 +0400, Nick Sabalausky wrote:
"Andrei Alexandrescu" wrote in message
news:hac4pl$1s2...@digitalmars.com...
I figured out a way to get the offsetof any member statically:
class A {
char a;
int b;
char c;
}
void main()
{
int[A.init.a.offsetof] x;
}
Unfortunately, I can't figure a way to get the class' size statically.
This doesn't work:
int[A.classinfo.init.length] x;
Any way to fetch the size of A?
sizeof(A) doesn't work?
sizeof(A) doesn't compile.
A.sizeof == Object.sizeof == (void*).sizeof
Re: null references redux + Looney Tunes
"Justin Johansson" wrote in message news:ha4qpi$189...@digitalmars.com... > For the interest of newsgroups readers, I dropped in at the Cafe the other > day and > the barista had this to say > > http://cafe.elharo.com/programming/imagine-theres-no-null/ > > Disclaimer: YMMV > > Cheers > This is gonna sound trivial (and probably is), but it's been bugging the hell out of me: What is the meaning of the "+ Looney Tunes" added to the title of this sub-thread? I don't see a connection...?
Re: null references redux + Looney Tunes
Andrei Alexandrescu: > We got to stop somewhere. The precise stopping point can be discussed. In the new C++ they have even added some flexibility in such regard: http://stackoverflow.com/questions/237804/user-defined-literals-in-c0x-a-much-needed-addition-or-making-c-even-more-bl Bye, bearophile
Re: null references redux + Looney Tunes
Ary Borenszweig: > What are those two methods named in C#? I didn't know about them. They are just named operator true and operator false. What I don't understand is why there are two of them, one of them looks enough to me: http://msdn.microsoft.com/en-us/library/6x6y6z4d%28loband%29.aspx http://www.blackwasp.co.uk/CSharpTrueFalseOverload.aspx Bye, bearophile
Re: Is there a way to get the size of a class object statically?
"Andrei Alexandrescu" wrote in message
news:hac4pl$1s2...@digitalmars.com...
>I figured out a way to get the offsetof any member statically:
>
> class A {
> char a;
> int b;
> char c;
> }
>
> void main()
> {
> int[A.init.a.offsetof] x;
> }
>
> Unfortunately, I can't figure a way to get the class' size statically.
> This doesn't work:
>
> int[A.classinfo.init.length] x;
>
> Any way to fetch the size of A?
>
sizeof(A) doesn't work?
Re: Should certain abstract classes be instantiable?
Nick Sabalausky wrote:
"Andrei Alexandrescu" wrote in message
news:ha8beq$2tn...@digitalmars.com...
Ary Borenszweig wrote:
Umm... so it defines a body that will never be used because that class
can't be instantiated and the method must be redefined by subclasses?
Isn't that the same as "doesn't provide a body"?
import std.stdio;
class A {
abstract void fun() { writeln("wyda"); }
}
class B : A {
void fun() { A.fun(); }
}
unittest {
A a = new B;
a.fun();
a.A.fun();
}
Not a rhetorical or a loaded question: Has that sort of thing ever been
useful?
I was wondering the same. It's also very bug prone because when
overriding the function you must remember to invoke the super method, a
thing you can forget.
Re: null references redux + Looney Tunes
Andrei Alexandrescu Wrote: > Justin Johansson wrote: > > Andrei Alexandrescu Wrote: > > > >> Nick Sabalausky wrote: > >>> "Justin Johansson" wrote in message > >>> news:haavf1$2gs...@digitalmars.com... > It's a difficult challenge to get high performance, readable and > maintainable code out of complex number > intensive algorithms. Use of library types for complex numbers has, in > my experience been problematic. > Complex numbers should be first class value types I say. > > >>> There's been discussion before (I can't find it now, or remember the name > >>> for it) of type systems that allow for proper handling of things like m/s > >>> vs. m/(s*s) vs inch/min etc. I haven't actually worked with such a > >>> feature > >>> or with complex/imaginary numbers in any actual code, so I can't be sure, > >>> but I've been wondering if a type system like that would be an > >>> appropriate > >>> (or even ideal) way to handle real/complex/imaginary numbers. > >> It better be. Complex numbers aren't that complicated of a notion. > >> What's lost in pulling them out of the language is the ability to define > >> literals. > > > >> "Now please name five remarkable complex literals." > > > > (re, im) ::= (0, 0), (1,0), (0,1), (1,1), (pi/2, 0), (0, pi/2), > > e_to_the_power_(minus j), > > e_to_the_power_(minus j * pi/2) > > > > Is that what you mean? > > (Three of those are real.) > > What I meant was that complex literals helped by syntax are seldom > likely to improve code quality. Many numeric literals are of > questionable taste anyway and should at best defined as symbols. I don't > see why complex literals shouldn't follow the same recommendation. "Three of those are real." What? Members of the set of real numbers are not members of the set of complex numbers? If anything remove from the language type which is a subtype of a bigger type!!! -- Devil's advocate :-) P.S. Thanks for the clarification, Andrei, I understand what you mean now.
Re: Google C++ style guide
Jeremie Pelletier wrote: Christopher Wright wrote: Jeremie Pelletier wrote: Me neither, in fact I would *love* to see a -nrtti switch in DMD to disable the generation of all ClassInfo and TypeInfo instances, along with a version identifier, maybe "version = RTTI_Disabled;" to let code handle it. I use RTTI a lot for simple debugging like printing the name of a class or type in generic code or meta programming, but not at all in production code. Most of the time I can rely on .stringof and a message pragma to do the same. You use RTTI for dynamic casts, variadic functions, and the default implementation of toString. You could safely eliminate some fields from ClassInfo and TypeInfo, but you can't get rid of them entirely. The best you can do is make TypeInfo entirely opaque (no fields) and only include the base class, interfaces, and name for ClassInfo. Yeah something like "don't generate type names" and other extra informations would be a definive plus, that makes reverse engineering too easy :) I've often thought that a pragma for a module to "don't generate module info" would be very useful for executable size. I'm particularly thinking of bindings like the Win32 headers, where there are a hundred modules, and the module info isn't actually useful. There could be a default ModuleInfo instance, with module name "ModuleInfoUnavailable", which all such modules would point to.
Re: null references redux + Looney Tunes
bearophile wrote: (Python has such standard method, as I have described (its name is diffeernt), while C# has two methods for true and falseness of an object/struct). Hi bearophile, What are those two methods named in C#? I didn't know about them.
Re: Is there a way to get the size of a class object statically?
Lutger wrote:
Andrei Alexandrescu wrote:
I figured out a way to get the offsetof any member statically:
class A {
char a;
int b;
char c;
}
void main()
{
int[A.init.a.offsetof] x;
}
Unfortunately, I can't figure a way to get the class' size statically.
This doesn't work:
int[A.classinfo.init.length] x;
Any way to fetch the size of A?
Andrei
This question was on .learn, from where the answer (by Jarret) was:
__traits(classInstanceSize, Class)
Thanks, Lutger and Max!
Andrei
Re: Is there a way to get the size of a class object statically?
On Mon, 05 Oct 2009 01:47:21 -0500, Andrei Alexandrescu
wrote:
>I figured out a way to get the offsetof any member statically:
>
>class A {
> char a;
> int b;
> char c;
>}
>
>void main()
>{
> int[A.init.a.offsetof] x;
>}
>
>Unfortunately, I can't figure a way to get the class' size statically.
>This doesn't work:
>
> int[A.classinfo.init.length] x;
>
>Any way to fetch the size of A?
>
>
>Andrei
__traits(classInstanceSize, A)
Re: Is there a way to get the size of a class object statically?
Andrei Alexandrescu wrote:
> I figured out a way to get the offsetof any member statically:
>
> class A {
> char a;
> int b;
> char c;
> }
>
> void main()
> {
> int[A.init.a.offsetof] x;
> }
>
> Unfortunately, I can't figure a way to get the class' size statically.
> This doesn't work:
>
> int[A.classinfo.init.length] x;
>
> Any way to fetch the size of A?
>
>
> Andrei
This question was on .learn, from where the answer (by Jarret) was:
__traits(classInstanceSize, Class)
